There's a gap between what gets announced about AI and what actually runs inside a business that has to close month-end, answer customers and keep the wheels on. The announcements are about models, capability and the future of work. The operation is about an inbox that fills faster than anyone can clear it, a contract review queue, and a handover process that only one person really understands. Almost none of the announcements are written for that person.
Practical AI, as we mean it, isn't a strategy or a platform decision. It's a small number of specific processes, chosen deliberately, where a model does a defined piece of work and a person remains accountable for the outcome. Everything else is either research, or it's a solution looking for a problem.
Where it actually pays
The use cases that hold up in practice share a shape: bounded input, a defined output, and a human who reviews the result before it goes anywhere consequential. That shape rules out a lot of the more ambitious pitches, and it's exactly why the ones that pass it tend to work.
Four patterns turn up again and again in businesses that get real value out of this, rather than a demo:
- Document extraction: pulling structured data out of invoices, applications and contracts that used to be typed in by hand
- Drafting inside existing workflows: first-draft replies, summaries and reports that a person still edits and sends
- Triage and classification: routing tickets, tagging leads, flagging exceptions for someone to decide, rather than deciding for them
- Multi-step admin handled by an agent, with an approval step before anything commits or sends
Why most initiatives stall
When an AI project disappoints, the model is rarely the reason. The reason is almost always the same as it was before AI turned up: the data is inconsistent, the process it's meant to sit inside was never documented, and nobody owns the exceptions when the input doesn't match what was demonstrated.
A pilot built on twenty well-chosen examples will work beautifully. The same approach against a live queue, where invoices arrive as photographs, fields go missing, and formats drift depending on who sent them, is a different problem. Fixing that isn't a modelling exercise. It's the unglamorous work of tidying the process the model has to plug into, which is where most of the effort in a good AI project actually goes.
Governance as an enabler, not a brake
Governance gets framed as friction: the thing that slows a rollout down. In practice it's the thing that lets you extend one further, faster, because you're not relying on hope. Visibility into what the system saw and did, an approval step before anything with real consequences goes out, and an audit trail that shows why a decision was made: these aren't compliance overhead, they're what let you scale scope with confidence instead of nerve.
Skip that layer and the first serious mistake (a wrong figure sent to a customer, an approval that shouldn't have gone through) ends with everything pulled back for a manual review anyway. Build it in from the start and the same mistake is a logged exception, not a crisis.
The provider question
We stay pragmatic about which model does the work, and we'd treat any client who wanted to lock permanently to one vendor's model with a raised eyebrow. Models are improving quickly and unevenly across tasks, and the provider that's best for drafting is not necessarily the one that's best for extraction or classification.
The way to stay free to move is architectural, not contractual: keep the business logic, the data and the approval workflow in your own systems, and treat the model as a component that's called into that workflow rather than the thing the workflow is built around. Swapping a component is a configuration change. Rebuilding a workflow that was written around one model's particular habits is a project.
Where to start
Not with an AI strategy document, and not with a platform. Start with the smallest process in the business that has a measurable return (a queue with a known volume, a task with a known cost, a bottleneck someone already complains about) and prove the pattern there, with the governance built in from day one rather than bolted on afterwards.
That's a discovery conversation before it's an engineering one, and it's how we start every AI engagement, because the process worth automating first is rarely the one that gets pitched first.
