Most AI projects fail for the same reason: they start with the technology instead of the problem. A team picks a tool, looks for somewhere to use it, and builds a pilot that impresses in a demo and never reaches production. The projects that work start from the other end. They find a specific, expensive, repetitive task, and they design the system around the business’s rules, with the model doing only the part it is good at. This is the difference between an AI initiative that returns hours and margin and one that quietly gets switched off.
The failure pattern is almost always the same
The story repeats across companies of every size. Someone senior decides the business needs AI. A tool is chosen, a budget is set, and a team goes looking for a place to apply it. A pilot gets built, it demos well, everyone is briefly excited, and then it stalls. Six months later the pilot is still a pilot, the enthusiasm has drained, and the honest internal verdict is that AI “did not really work for us”.
The technology was rarely the problem. The problem was the order of operations. Starting from the tool means you are solving for “where can we use this thing” instead of “what is actually costing us time and money”. You end up automating something that was cheap to do by hand, or something that happens twice a month, or something that needed human judgment every time. The demo looked good because a demo only has to work once. Production is different, because production has to work every day, on messy real input, in a way someone can trust and defend.
What the projects that work have in common
The systems that reach production and stay there share a small number of traits. None of them is about having a better model. All of them are about how the work was framed before a line of code was written.
They start from a constraint, not a tool
The successful projects begin with a task that is repetitive, high volume, rule-bound, and currently eating the time of someone whose hours are worth more elsewhere. That description is the filter. If a task does not fit it, no amount of clever technology makes automating it worthwhile. The question is never “where can we use AI”, it is “where is human time trapped in work that does not need human judgment”, and then whether AI is even the right way to free it.
They let rules decide and the model read
This is the single most important design choice, and the one that most doomed pilots get wrong. A language model is excellent at reading messy text and writing a clean response. It is a poor place to put a decision, because it is not consistent, not auditable, and cannot explain itself the same way twice. The systems that work use the model for what it is good at, reading and drafting, and put every decision in explicit business rules written in code. When someone asks why a case was handled a certain way, there is a concrete answer: a named rule with named conditions. The same input always produces the same output. The business owns those rules and can change them without a developer.
They keep a human on the decisions that matter
Working systems do the first pass and route anything uncertain to a person, with the reason explained in plain language. This is not a limitation, it is what makes the system trustworthy enough to use. A system that acts confidently on everything, including the cases it got wrong, is a system that gets switched off the first time it causes a visible mistake.
They are measured on the right number
The projects that survive are judged on the share of work completed without human intervention, not on average model accuracy. Average accuracy is a trap. A system that is 95% accurate on average can be useless if the 5% of errors are scattered through cases that look correct, because then there is no exception queue, just silent mistakes flowing downstream. The goal is to err rarely, and when you do, to know it, so the mistake lands in a review queue instead of the business’s records.
Why starting from the tool is so tempting
If starting from the problem works better, why does almost everyone start from the tool? Because the tool is the exciting part. There is pressure to “be doing something with AI”, and buying a tool or building a flashy pilot feels like progress. Mapping your own processes to find where time is actually trapped is slower, less glamorous, and forces uncomfortable answers, sometimes the answer that the most talked-about use case is not worth automating at all.
There is also a vendor incentive worth naming. Most of the market sells you the model, the platform, or the build hours, because that is what they have to sell. Starting from your constraint sometimes concludes that the right answer is a small, unglamorous system, or no system at all this quarter. That is a harder thing to sell and a more honest thing to advise.
What starting from the problem looks like
The alternative is a diagnosis before a build. Before choosing any tool, map the processes, find where human time is trapped in repeatable tasks, and rank the candidates by the effort to automate them against the hours and margin they would return. The output is a short list of opportunities ordered by payoff. Sometimes the most valuable line on that list is the one that says a given task is not worth automating yet.
Only then does a build make sense, and it is a focused one: one or two systems into production in a matter of weeks, with a fixed scope and a real deliverable, rather than an open-ended programme. This is the same diagnostic discipline we apply to the rest of a business through the Growth Engine. An AI system gets built because the numbers support it, not because AI is on the agenda.
What this looks like in real systems
The pattern holds across the systems we have built, described in general terms because the clients stay anonymous. An underwriting desk for a commercial insurance broker reads free-text requests into structured risk sheets and drafts responses, but every accept, decline or refer decision comes from the broker’s own criteria in code, not from the model. A document extraction system for a law firm pulls fields from invoices and contracts, then checks them with deterministic validation, arithmetic and format rules with no model involved, before anything reaches a person. A price monitoring system for a retailer tracks roughly fifty thousand references across seven competitors continuously, giving back a week of manual work every month. In each one, the model does the reading and the writing, the rules do the deciding, and a person stays on the calls that carry consequences. That division is why they are still running.
The deeper lesson from all of them is the same. The value was never in the model, which is a commodity anyone can access. The value was in framing the right problem and building the rules, the checks and the human review around it. That is the work that makes AI pay off, and it is the work most failed projects skipped.
Frequently asked questions
Why do so many AI projects fail to reach production?
Because they start from the technology instead of the problem. A tool gets chosen and a pilot gets built to show it off, but it solves for “where can we use this” rather than “what is costing us time and money”. Demos only have to work once; production has to work every day on messy input.
What do successful AI projects do differently?
They start from a specific repetitive, rule-bound task, let explicit rules make the decisions while the model only reads and drafts, keep a human on consequential calls, and measure the share of work done without intervention rather than average accuracy.
Should AI make the decisions in a business process?
No. The model is good at reading messy input and writing responses, and poor at making consistent, auditable decisions. Put the decisions in explicit business rules in code, so the outcome can be explained and the same input always produces the same result.
How do I know if an AI project is worth doing?
Through a diagnosis before any build: map the processes, find where human time is trapped in repeatable work, and rank candidates by effort against the hours and margin returned. Often the most useful finding is that a task is not worth automating yet.
Thinking about an AI project?
The cheapest way to avoid a failed one is to start from the problem. Request a strategy call and we will map where AI would return hours and margin, and where it would not.
