The pilot worked. Everyone saw the demo. Then nothing shipped. This is the most common outcome in enterprise AI right now, and it is almost never the model’s fault.
Pilots die for a short list of reasons, and the list repeats. The pilot was built on clean sample data, and production data is a swamp. The workflow the pilot assumed is not the workflow people actually run. Nobody owned the number the pilot was supposed to move, so its success was unmeasurable and therefore arguable. And the integration work — the part where the pilot meets the ERP — was estimated at two weeks and took four months.
The demo trap
A demo is optimized for a room: happy path, clean inputs, an audience that wants to be impressed. Production is optimized for nobody: partial data, malformed orders, the Tuesday-morning edge cases. A pilot that cannot survive a malformed order is not a pilot — it is a concept. The distance between the two is where budgets go to be embarrassed.
Nobody’s job changed
The quietest killer is adoption. If the tool lives next to the workflow instead of inside it, usage decays to zero within a month. People do not change how they work because a pilot exists; they change when the tool is the path of least resistance — when the quote draft is already in the system they quote from, and the exception queue is shorter than the manual one.
A pilot that lives next to the workflow is tourism. A system that lives inside it is infrastructure.
How the ones that live, live
The survivors share a shape. The baseline number was written down before anything was built. The pilot ran inside the real workflow, on real data, with real volume — small scope, honest conditions. Someone with authority owned the result. And the handover was planned on day one: who runs it, who maintains it, what happens when it drifts. None of that is exotic. It is just what happens when you treat a pilot as the first step of a system instead of a proof you can point at.
All insights