Insights
- Home
- Why AI pilots stall
We have now been called in to look at more than forty stalled AI initiatives. Almost none of them failed because the model was bad. The model was usually fine — often genuinely impressive in the notebook it was born in. What failed was everything around it: nobody could get production data to it on a schedule, nobody had capacity to review its output, nobody had agreed what "working" would look like in numbers, and nobody inside the organisation owned it once the consultants left. Those four gaps show up so consistently that we now run them as a gate before any build starts. If a use case cannot clear all four, we say so in week two rather than month six.
Check one: can you get the data, repeatedly, without a person in the middle? A pilot that ran on a one-off CSV export somebody pulled by hand is not evidence that a system can run daily. Before we build, we want a scheduled, permissioned path to the same fields — and an honest count of how often they are missing, stale or wrong. This is where most pilots quietly die, and it is almost always a data engineering problem wearing an AI costume.
Check two: who reviews the output, and do they have the hours? Nearly every useful commercial model produces something a person needs to check, at least at first. If the answer to "who reviews this" is a team already running at capacity, the system will be bypassed within a month. Review capacity is a budget line, not an afterthought.
The question is never “is the model accurate enough”. It is “is it accurate enough that the person downstream changes what they do” — and nobody can answer that from a confusion matrix alone.
Elena Kovács, Head of Applied Machine Learning
Check three: what number moves, and who already watches it? "Improved efficiency" is not a measure. Median hours from submission to decision is. Percentage of cases aging out is. The metric has to be one somebody already reports on, because a number invented for the project will be abandoned with the project. If nobody was tracking anything before, that is your first piece of work — and it is worth doing whether or not you ever train a model.
Check four: who owns this in eighteen months? Name them. Put them in the design reviews from week one, give them the runbook, and have them run the first incident while you are still around to help. An AI system with no internal owner is not a capability, it is a dependency — and it will be switched off the first time it misbehaves on a Friday afternoon.
None of this is exotic. It is the same discipline any other production system gets. The reason it is worth writing down is that AI projects are unusually good at looking finished while still missing all four.
Comments
Check two is the one nobody wants to hear. We budgeted for the build and not a single hour of reviewer time, and the whole thing was shelved inside six weeks.
ReplyThat matches what we see almost every time. Review capacity is the cheapest thing to plan for and the most expensive thing to discover late.
ReplyWould add a fifth: agree in advance what happens when the model is wrong in a way that reaches a customer. Deciding that under pressure never goes well.
Reply