Stalled AI projects follow the same shape. The demo went well. Everyone was impressed. Then eight months passed and it is still not in production, and nobody can quite say what happened.
We get called in at roughly that point often enough to have a list. The model is almost never the reason.
1. Nobody owns the exceptions
A demo shows the happy path. Production is mostly not the happy path.
The moment a system produces something it is not sure about, a question appears: who deals with that? If the answer is “it goes back to the team”, you have added a queue rather than an automation.
Projects that get to production define the exception path before they define the model. Projects that stall discover the exception path in week nine of a twelve week build.
2. The measurement never existed
Ask a stalled project what accuracy the manual process achieves. Usually nobody knows.
Without that baseline there is no threshold for good enough. The system gets measured against perfect. It fails, obviously, and the program quietly loses its sponsor.
Build the evaluation set from your own historical cases before you build anything else. It is the highest leverage two weeks in the project.
3. The data problem was deferred
Everyone knows the data is messy. The plan is to fix it in parallel.
It is never fixed in parallel. Data remediation is its own project with its own political weight, and running it alongside a build means both move at the speed of the slower one.
Either scope the data work explicitly and sequence it first, or choose a workflow whose data is already good enough. Pretending the data is clean costs more.
4. It was built against the wrong altitude
A lot of pilots automate a task when the value was in the handoff, or automate a handoff when the value was in a single task.
The invoice example is the cleanest one. Teams look at approval because approval is where the delay is visible. But approvers are usually fast. They are waiting on the coding and matching upstream. Automating approval changes nothing.
Watch where the hours go rather than asking.
5. There was no operator
The system shipped and the team that built it moved on. Six months later a supplier changed a format, accuracy dropped, and nobody noticed until a customer did.
Someone inside the business has to be able to read the logs, adjust the rules and rerun the evaluation. If that person does not exist, you have rented a system rather than bought one.
The pattern underneath
All five are organisational problems. That is why they are hard to see from inside a technology project, and why the fix usually starts with a conversation rather than a build.
If any of this is uncomfortably familiar, an AI workshop is the cheapest way to find out which of the five you are living in.