Why AI pilots stall before production

The pattern

A company runs an AI pilot. It goes well. There is a demo, and the demo is genuinely impressive — the thing answers questions about internal documents, or drafts the reply, or extracts the fields from the invoice. Everyone can see it working.

Then six months pass and it is not in production. Not cancelled, exactly. It is being “evaluated,” or it is waiting on a security review, or the champion moved teams. Eventually someone writes it up as a learning experience and the next pilot starts.

This is common enough that it has become the default outcome rather than the exception. The interesting part is that the reasons are consistent, mostly not about the model, and largely knowable in advance. What follows is what actually breaks, in rough order of how often it is the thing that kills a deployment.

The pilot was designed to succeed

Start with the uncomfortable one, because it explains most of the rest.

A pilot is usually built to demonstrate that something is possible. That is a reasonable goal, but it selects for specific conditions: a curated set of test documents, one workflow with clear rules, data someone tidied first, and an audience that has already decided the technology is interesting.

Production has none of those properties. The documents include the photographed one, the one that is a spreadsheet exported as a PDF, and the one whose template changed in 2019. The workflow has four exception paths nobody documented. The audience is a customer with a problem and no interest in your architecture.

So the pilot did not fail — it answered a different question than the one you needed answered. “Can this work?” is nearly always yes. The useful questions are “does this work on our worst inputs, at our volume, at a cost we would accept, when the person using it is not rooting for it?”

The fix is not a longer pilot. It is a pilot pointed at the hard cases from the start: run it on a random sample of real inputs, including the ones staff complain about, rather than on examples selected because they are representative. A prototype that works on 70% of genuinely messy data tells you far more than one that works on 100% of clean data.

The integration was the actual project

Ask people what went wrong and a large share of the answer is not about AI at all. It is that the system has to read from the CRM, write to the ticketing system, respect permissions from an identity provider, and do all of that inside a network that was not built with this in mind.

None of that is visible in a pilot, because a pilot reads from a folder of exported files and writes to a screen.

This is worth naming plainly: much of an AI project is ordinary software engineering. APIs, authentication, data plumbing, error handling, retries, deployment, monitoring. The model is one component in a system, and the system is where the effort goes. Teams that treat AI as a fundamentally new discipline tend to under-resource the part that is just software, which is most of it.

It also means the relevant question about a vendor or a team is not only whether they know how to prompt a model. It is whether they can integrate with the systems you already run — the software development and DevOps work that surrounds the model and holds it up.

Nobody defined what “working” means

This one is quiet and it kills things slowly.

Ask a team midway through an AI project how accurate the system is, and you often get an anecdote. It handled this case well. It got confused on that one. Someone tried it last Tuesday and it seemed fine.

Without an evaluation set — a fixed collection of inputs with known-good outputs, scored automatically — you cannot tell improvement from noise. You cannot answer whether last week’s prompt change helped. You cannot tell whether switching models made things better or worse. And critically, you cannot tell whether the system is good enough to ship, because “good enough” was never expressed as a number anyone agreed to.

What that looks like in practice is a project that oscillates. Someone tweaks a prompt, it fixes the case that was complained about, it silently breaks two others, and the cycle repeats until confidence drains out of the project and it quietly ends.

Building the evaluation set is unglamorous and it is the highest-leverage thing on most AI projects. It does not need to be large — a hundred real cases with agreed correct answers is enough to change how a team works. It needs to exist, to be versioned, and to run automatically. It also needs to include the cases where the right behaviour is to refuse, escalate, or say “I don’t know,” because a system that is confidently wrong is worse than one that declines.

Agree the bar before building: what accuracy on which categories, what an unacceptable failure looks like, and what happens when the system is unsure. Those three answers determine most of the architecture.

The running cost was discovered late

Traditional software has costs that are roughly fixed against usage. A model-backed feature does not: every request costs money, and the cost scales with how much context you send and how much output you generate.

This surprises people at the worst moment, when the pilot succeeds and someone asks what it costs to roll out to everyone. A design that is fine at ten requests a day — stuffing an entire document set into every prompt, calling the largest available model for every task — becomes indefensible at ten thousand.

Cost is an architecture decision, and it is made early whether or not anyone makes it deliberately. Retrieving the right three paragraphs instead of sending forty pages, routing simple requests to a smaller model and reserving the expensive one for the hard cases, caching what repeats — these change the unit economics by an order of magnitude, and they are much cheaper to design in than to retrofit.

Work out the cost per transaction during the prototype, then multiply by realistic volume. If the number does not survive that multiplication, you have learned something important while it is still cheap to act on.

No one would take responsibility for a wrong answer

The last barrier is not technical, and it is often the real reason a finished system does not go live.

Someone has to own what the system says. If it gives a customer wrong information about their account, misclassifies a document that turns out to matter, or takes an action that has to be reversed — who is accountable, and what is the recourse?

Projects that clear this hurdle tend to have answered it in the design rather than at the approval meeting. That means: the system cites its sources so an answer can be checked; there is a log of what it did and what information it acted on; there are actions it is not permitted to take without a person confirming; and there is a defined path for a human to take over.

Notice that this shapes the product, not just the governance paperwork. “The agent drafts the response and a person sends it” is a different system from “the agent responds,” and the first one ships. A narrower system that goes live beats a more ambitious one that does not.

What a pilot should be designed to find out

Given all of the above, the useful pilot looks different from the demo-driven one. It is not longer or more expensive — it is pointed at different questions.

• Run it on real, unfiltered data, including the inputs staff already complain about. Curated samples answer the wrong question.
• Build the evaluation set first, and agree the bar before writing the system. A hundred real cases with known answers is enough.
• Integrate one system for real, even if it is the easiest one. A pilot that reads from a folder has skipped the part that usually costs the most.
• Measure cost per transaction and multiply by realistic volume before committing to an architecture.
• Decide who owns a wrong answer, and design the checkpoint that makes that ownership possible.
• Define the smallest version worth shipping. Then ship it, and expand from something real rather than from a prototype.

Most of this is unglamorous, and none of it is about choosing a model. That is roughly the point: model choice is one of the more reversible decisions in an AI project, and the ones that determine whether it reaches production are made around it.

Where we sit

We build AI systems with production as the target rather than the demo, which mostly means doing the boring parts early — evaluation, integration, guardrails, cost — rather than treating them as hardening work that happens after the interesting part.

It also means occasionally saying that a problem does not need AI. A retrieval system with citations, a fixed rule, or a query against a database you already have will sometimes do the job for a fraction of the cost and none of the uncertainty. That answer is cheaper for you and less profitable for us, which is precisely why it is worth asking a vendor to give it.

If you have a pilot that stalled, the diagnosis is usually quick, and it is usually one of the five above. The initial consultation is free and we reply within 24 hours.