AI — Subirachs Ventures —
Choose workflows, not functions
'Bring AI to customer service' is not a scope. It is a department. Departments contain dozens of distinct workflows with different data, different risk profiles and different people doing them, and an initiative aimed at all of them at once tends to land on none.
A workflow is small enough to describe end to end: what triggers it, who touches it, what information it needs, what it produces, and how anyone knows the output was correct. Once a workflow is written down at that level, whether a model can help usually becomes obvious - and so does what would have to be true for it to be trusted.
Design for verification from the start
The practical constraint on adoption is rarely capability. It is verification: whether the people responsible for an output can confirm it is right at acceptable cost.
Where verification is cheap - a draft a person reviews anyway, a search that surfaces a source, a summary checked against the document behind it - adoption tends to be fast and durable. Where verification is expensive or impossible, enthusiasm outruns trust and the tool is quietly abandoned.
This is why the first question about any candidate workflow should be how the person accountable for the result will check it, not how accurate the model is in benchmark conditions.
- Can the person accountable verify the output quickly?
- Is there a source, citation or trace they can check against?
- What is the cost of an error that gets through?
- Who decides when the system is wrong often enough to stop?
Be specific about agents
AI agents extend the question from 'can it produce a good output' to 'can it be allowed to act'. That is a materially different bar, and it moves the conversation from model quality to permissions, boundaries, logging and reversibility.
Useful agent deployments tend to start where actions are reversible, bounded and observable: preparing work for approval, gathering and reconciling information, carrying out routine steps inside a system that already records what happened. Starting where actions are irreversible is how organisations acquire a governance problem before they have acquired any value.
Plan the operating model early
A pilot has a team behind it. Production does not, unless someone decided it would. Before scaling anything, an organisation needs to have settled who owns the workflow, who monitors quality, who handles the cases the system cannot, how changes are reviewed, and what the escalation path is when it degrades.
These are unglamorous questions, and they determine almost everything about whether the improvement survives the first quarter after launch.
Measure against the current process
The right comparison is not a benchmark. It is how the work is done today: how long it takes, how often it is wrong, what it costs, and how the people doing it experience it.
Measuring against the current process keeps the conversation grounded and makes the result legible to people outside the project. It also surfaces the cases where the honest conclusion is that the existing process was already good enough - which is a useful outcome, and considerably cheaper to reach early.