Where AI earns its place
The useful question is not whether a business should adopt AI. It is which specific decisions or tasks inside that business are currently expensive because a person has to read something, judge something, or transcribe something by hand. Those are the places where a model changes the economics. Everywhere else, AI is an expensive way to do what a database query already did.
In practice the candidates cluster tightly. Unstructured input that has to become structured data. Repetitive judgement calls that follow a pattern nobody has written down. Search across a body of internal material too large for anyone to hold in their head. Classification and triage at a volume that makes a queue unmanageable. The same test we use for choosing what to automate applies here: volume, consistency, and the cost of a wrong answer.
- Documents, forms, and email that arrive in a hundred different shapes and have to end up in one
- Support and intake queues where most items follow a pattern and a minority genuinely need a person
- Internal knowledge that exists but cannot be found quickly enough to be worth having
- Inspection and monitoring tasks where a human is watching for something that rarely happens
The data question comes first
The model is now the least differentiated part of the stack. Capable general-purpose models are available to everyone at roughly the same price, and the gap between the leading options narrows every release. What is not available to everyone is your data: how it is stored, how consistent it is, how much of it is labelled, and whether anyone is allowed to use it for this.
Before committing to a build, it is worth answering four questions plainly. Where does the data actually live? Who owns it, and what are the terms it was collected under? How much manual cleaning stands between its current state and something a system could use? And is there enough of it that a model would see the edge cases, not just the common path?
A project that skips these questions does not fail at the modelling stage. It fails three months in, when the pipeline turns out to depend on a spreadsheet one person maintains by hand.
Build, buy, or wire something together
Very few businesses need to train a model. Most need to connect an existing one to their own systems, constrain it to their own material, and put a reviewed interface in front of it. That is an integration project with a model in the middle, and it should be scoped like one - which is how we approach AI development and automation.
Buying makes sense where the problem is generic and the vendor's product is the whole answer. Building makes sense where the workflow is specific to how you operate and the advantage comes from that specificity. The middle path - a bought model, your data, your interface, your rules - is where most of the practical value currently sits, and it is the cheapest of the three to reverse if the technology moves underneath you.
Designing for the human in the loop
Any system that makes judgement calls will make some of them wrong. The design question is what happens next. A well-built workflow makes the model's confidence visible, routes the uncertain cases to a person, and records the correction so it can be measured over time. In the AI surveillance system we built for a retail complex, every alert carries the frame and zone that triggered it, so an operator confirms or dismisses it in one look.
This is also what makes adoption possible. Teams do not resist automation because they distrust the technology in the abstract. They resist it when a system produces an answer they cannot check, cannot override, and are still accountable for. Give them the override and the audit trail, and the same system stops being a threat and starts being a tool.
What to measure
Model accuracy is a development metric, not a business one. The figures worth reporting to the people who funded the work are the ones tied to the workflow: how long a case takes end to end, what proportion clears without a person touching it, how often a person disagrees with the system, and what the whole thing costs to run per item processed.
Track those from the first week the system is live, including the week it is live only for a small share of traffic. A pilot that cannot produce these numbers is not a pilot - it is a demo with a longer timeline.
