The demo worked. The board was impressed. Eight months later it is still a demo. The reasons enterprise AI pilots never go live are predictable – and four of the five have nothing to do with the model.

Industry surveys keep reporting the same uncomfortable figure: the vast majority of enterprise AI pilots never make it into production. The reflex is to blame the model’s capability or the quality of the data, but that is rarely the real cause. We have been called in to rescue stalled pilots often enough to know the pattern – and the model is almost never the bottleneck. The bottleneck is everything around the model that nobody planned for, because the demo did not need it.

The real problem: a demo and a production system are different artefacts

A demo runs once, on hand-picked input, under the eyes of the person who built it, optimised to impress in a meeting. A production system runs thousands of times a day, on whatever comes in, while everyone is asleep, optimised not to fail. The skills, components and budgets that produce the first are largely irrelevant to the second. Treating the pilot as “90% done, just needs hardening” is the category error it runs aground on.

Here are the five gaps, in the order in which they bring projects down.

Gap 1: nobody owns the production system

The pilot was built by an innovation team or an external partner on a project budget. Production needs a named team with an on-call rota, a maintenance budget and accountability for availability and quality. When the pilot ends, the project budget ends with it, and there is nobody whose job it is to operate the system. It does not get stopped – it gets orphaned, which is slower and more demoralising. This is by far the most common cause, and it is a failure of organisational design, not a technical one. Decide who owns the system in production before you build the pilot.

Gap 2: no evaluation harness

The pilot was judged on “looks good”. Production has to answer the question “is version 2 better or worse than version 1?” – and a model or prompt change can degrade quality unnoticed, with no error message and no alarm. Without an eval suite, every change is a gamble and every update from the model provider is a round of roulette. Teams would rather freeze the system than touch it, and a frozen AI system decays while the world around it moves on. What you cannot measure, you cannot operate.

Gap 3: integration and fallback were never built

The demo called a clean API. In production the system calls your CRM, which times out at peak, your auth system, your logging and three internal services with inconsistent interface contracts – and it has to behave correctly when one of them is slow or down. The fallback path (what happens when the AI cannot answer or a dependency fails) is often more code than the AI feature itself, and in the demo it is invisible. Pilots that ignored it discover at launch that the happy path was only 30% of the work.

Gap 4: unit economics that do not survive scale

At pilot volume nobody checks the cost per call. At production volume an AI feature can quietly run at a negative gross margin or blow through a budget nobody ever set. Teams that have not modelled inference costs for the expected volume either get a nasty invoice or have to re-architect under pressure after launch. Cost is an architectural decision; put it off until later and you will re-architect later.

Gap 5: no way to build user trust

The pilot impressed the executive team. The people who actually have to use it every day – agents, analysts, doctors – were not involved, and they will work around any tool that wastes their time or makes them look bad in front of customers. A technically excellent system with 10% adoption delivers 10% of its business case. Trust comes from transparency (showing the sources), a confident handling of uncertainty (saying “not sure” instead of bluffing) and involving users in the design – none of which the demo accounted for.

A worked example: a stalled contract analysis pilot

A legal ops team had a contract analysis pilot that scored excellently in tests and had been sitting unshipped for seven months. The diagnosis along the five gaps:

• Ownership: none – built by an innovation lab, with no funded production team. (Fixed: handed over to legal ops engineering, with a maintenance budget.)
• Evals: none – quality was measured by “the lawyers liked it”. (Fixed: 150 annotated contracts as a regression set.)
• Integration: the pilot read uploaded PDFs; production had to pull documents from the DMS and write back into the matter management system. Roughly 60% of the remaining work.
• Economics: fine, low volume.
• Trust: the lawyers did not trust extractions without a source reference. (Fixed: mandatory clause-level citations.)

Time from “stalled pilot” to production: nine weeks, none of it spent on the model. Adoption among the intended lawyers reached roughly 75% within a month, once the citations made the output verifiable.

The pattern behind the pattern: pilots optimise for the wrong audience

Step back from the five gaps and a deeper cause becomes visible. Pilots are built to win an internal decision – to impress the executive who controls the budget – whereas production systems exist to serve the people who do the work. Those are different audiences with opposing needs. The executive wants to see the most ambitious capability in a five-minute demo; the users want a narrow, reliable tool that does not embarrass them in front of customers. Optimise for the first and you build a broad, shallow shop window. Production rewards the opposite: narrow, deep and dependable.

That is why the most successful programmes we run deliberately shrink the scope of the pilot instead of expanding it. Instead of demonstrating ten capabilities at 80%, prove a single one at 98% – on the real integration, with the real fallback, in front of the real users. A pilot that does one thing to production standard is a far better indicator of success than one that does ten things impressively, because it has already paid the operational tax that the impressive demo deferred. We have watched a deliberately unspectacular single-intent pilot go live in six weeks while a glossy multi-capability pilot from the same company sat aground for a year – the only difference was which audience it had been built for.

This has consequences for the budget as well. Because pilots are sold on their ambition, they are funded as innovation experiments, and innovation budgets contain no line for operations. Reframing the pilot as “the first increment of a production service” – with an accountable owner and a maintenance budget from the start – changes the funding model and removes gap 1 before it can arise. The most important decision about a pilot is made before the first line of code is written: is this an experiment we are going to throw away, or the first slice of something we are going to operate? Answer that honestly and fund it accordingly.

The checklist for the road into production

1. Who owns the system in production, and is their time funded? (If unanswered: stop here.)
2. Is there an evaluation harness that catches regressions on every change?
3. Are all the real integrations and their error and fallback paths built and tested?
4. Have we modelled unit costs for the expected volume, not the pilot volume?
5. Did the daily users help shape the design, and does the system earn their trust?
6. Is there monitoring in production for quality, latency, cost and error rates?
7. Is there a defined route to updating the system safely as models and data change?

The gridz view

The gap between a pilot and a product is overwhelmingly organisational and operational, not technical – and that is good news, because those gaps can be closed in weeks once you stop expecting the model to be the hard part. Before we approve an AI pilot, we ask who will own it in production; if there is no answer, the pilot is already a demo with an expiry date. We get stalled pilots into production by closing the five gaps in the order that matters – and the model is usually the part we touch least.

If you have a pilot in limbo right now, assess it honestly against the five gaps before you put another franc into the model. In our experience the diagnosis almost always has the same shape: ownership is not funded, there is no evaluation harness, and the real integrations were never built – three organisational and operational gaps in technical disguise. Close those three and most “stalled” pilots reach production in weeks, because the intelligence was never the obstacle. The uncomfortable but liberating truth: shipping enterprise AI is above all an exercise in operational discipline, and operational discipline is something you can apply on Monday – no model upgrade required. If you would like a second opinion on that, talk to us.