Contents
- The numbers, and why they disagree so much
- The six gaps
- The production readiness checklist
- What 8 to 12 weeks actually buys
- When to kill the pilot instead
- FAQ
- Next step
Your pilot demoed well. Everyone in the room agreed it was impressive. That was seven months ago and it is still not in production, and at this point nobody asks about it in the leadership meeting because the answer is always “we’re close.”
This is not a strategy problem, and it is not an adoption problem. It is six specific engineering gaps, each of which is closeable, and each of which has a cost you can actually estimate.
This article names all six.
The numbers, and why they disagree so much
Published failure rates for enterprise AI pilots range from roughly two-thirds to over nine in ten.
Two sources are cited below as examples of the spread. Both are secondary summaries, not primary research. Before publishing, trace each back to the underlying study, confirm it still says what the summary claims, and cite the primary source instead. If a primary source can’t be found, describe the range without attributing a number to it — the argument in this section works without any specific figure, which is the whole point of the section.
- Agent Market Cap’s 2026 analysis reporting ~67% of enterprise AI agent pilots not reaching production
- Software Seni’s summary of the 88–95% range
That spread is wide enough that you should be suspicious of all of it, and the reason for the spread is worth understanding before you cite any of these numbers to your board.
The figures disagree because “reached production” has no shared definition. Some studies count any deployment to real users. Some require sustained use after ninety days. Some require measurable P&L impact. A pilot that serves twelve internal users daily is a success under the first definition and a failure under the third.
So use the range as a signal about the shape of the problem, not as a statistic. The honest version is: a large majority of pilots stall, the stall is consistent, and it happens at the same six places. That claim is well-supported. A specific percentage is not.
If you are going to quote a number to your board, define what you mean by production first. That definitional discipline is itself most of the fix.
The six gaps
Every stalled pilot we are brought into is stuck on at least three of these. None of them are strategy problems. All of them are the difference between a demo and a system.
1. No eval harness
The pilot was judged by people looking at outputs and nodding. That works for a demo and collapses the moment you need to answer “did the change we made yesterday make it better or worse?”
Without a test set, a scoring method and a recorded baseline, every subsequent change is a vibe. Teams stall here because they cannot prove an improvement, so they cannot justify a release, so they keep tuning.
What closing it looks like: a labelled evaluation set drawn from real usage, a scoring rubric appropriate to the task, and a regression run that executes on every change. Typically the first two to three weeks of a stabilization engagement.
2. No data contracts
The pilot ran against a snapshot someone exported to a notebook. Production runs against live systems where a column gets renamed on a Tuesday and nobody tells you.
Without an explicit contract — schema, freshness guarantee, null behaviour, an owner who is accountable when it changes — the model silently degrades and nobody can say when it started.
What closing it looks like: schema validation at ingest, freshness monitoring, a named owner per source, and defined behaviour when a contract is violated. This is ordinary data engineering, and it is the gap teams most resent paying for.
3. No rollback path
Ask what happens if the model starts producing something harmful at 2am on a Saturday. If the answer involves a deploy, you do not have a rollback path — you have a plan to write one under pressure.
This is the gap that actually blocks the go-live decision, and it is often blocking it invisibly. A security or risk stakeholder who cannot get a clean answer will keep finding reasons to delay rather than say no on the record.
What closing it looks like: a feature flag that disables the AI path and falls back to prior behaviour, reachable without a deploy, tested under load, with a named person who can pull it.
4. Cost per call was never modelled
The pilot cost a rounding error because twelve people used it. Nobody modelled what a hundred thousand calls a day costs, or what happens when a user pastes a 40-page document into a context window you are billed for.
Pilots die quietly here. Someone finally runs the arithmetic, the unit economics do not work, and rather than saying so the project simply stops being prioritized.
What closing it looks like: a cost model per request type, a projection at realistic volume, caching and routing strategy, and a per-user or per-tenant ceiling. Usually a week, and it should honestly happen before anything else on this list.
5. Security review was never scheduled
Nobody booked it, because the pilot was “just an experiment.” Now it is on the critical path and your security team is seeing prompt injection, data egress to a third-party API, PII in logs and a vendor DPA nobody has read — all for the first time, all at once, with a launch date already announced.
What closing it looks like: threat model, data flow map, retention and logging policy, vendor review, and a red-team pass against prompt injection. Two to four weeks, and you cannot compress it by starting late.
6. Nobody owns it
The pilot was built by a small team or an individual with executive air cover. Production systems need an on-call rotation, a runbook, an error budget and a person whose job it is when it breaks.
Without that, the pilot cannot go to production even if everything else is perfect, because operations will not accept a system nobody will carry a pager for. This gap is organizational, not technical, and it is the one most often missed in planning.
What closing it looks like: a named owning team, on-call inclusion, a runbook and an agreed error budget — decided before launch, not after the first incident.
The production readiness checklist
Run this against your stalled pilot. Every unchecked box is a reason the launch date keeps moving.
AI PRODUCTION READINESS
EVALUATION
☐ Labelled eval set drawn from real usage, not synthetic examples
☐ Scoring method agreed by the people who will judge success
☐ Recorded baseline
☐ Regression run on every change
☐ A defined threshold that means “do not ship”
DATA
☐ Schema contract per source, with a named owner
☐ Freshness monitoring and alerting
☐ Defined behaviour when a contract breaks
☐ Provenance tracking — you can say which data produced which output
OPERATIONS
☐ Feature flag disabling the AI path, no deploy required
☐ Fallback behaviour defined and tested
☐ Named person who can pull the flag at 2am
☐ On-call rotation includes this system
☐ Runbook exists and someone other than the author has followed it
ECONOMICS
☐ Cost per request type, modelled
☐ Projection at realistic peak volume
☐ Caching and model-routing strategy
☐ Per-user or per-tenant spend ceiling
SECURITY
☐ Threat model written
☐ Prompt injection red-team pass completed
☐ PII handling and log retention policy
☐ Vendor DPA reviewed
☐ Data flow map approved by whoever owns risk
Ungated, no email required. [INTERNAL LINK: /insights/signs-of-legacy-system-failure “our other checklists are ungated too”]
What 8 to 12 weeks actually buys
A Stabilization Sprint runs $85K–$180K over 8–12 weeks, and taking one stalled AI pilot the whole way into production is exactly what that band is sized for.
What that period realistically closes: eval harness and baseline, data contracts on the sources that matter, rollback and flag infrastructure, a cost model with a ceiling, and the security artifacts your risk owner needs. What it does not do is make a pilot work that was never going to work — see below.
The reason this is a sprint rather than a program is that the gaps are known. This is not exploratory work. It is six specific pieces of engineering that a demo skipped, and skipping them was the correct decision at demo time. It stopped being correct the moment someone said the word “launch.”
How the stabilization band compares to the rest of our pricing
When to kill the pilot instead
Not every stalled pilot should be rescued. Four conditions mean stop, and recognizing them early is worth more than any of the six fixes above.
The unit economics don’t close. If cost per successful outcome exceeds the value of that outcome and no realistic optimization path gets you under, the answer is no. Do the arithmetic before you spend on engineering.
Quality plateaued below the usable threshold. If accuracy stalled and the last three improvement attempts moved it by noise, you are on the wrong side of a capability boundary. Waiting for a better model is a legitimate strategy — continuing to engineer around it is not.
The problem was never the bottleneck. Some pilots automate a step that was never expensive. The demo was impressive and the value was theoretical. Nobody wants to say this out loud after nine months of work.
No owner will take it. If you cannot find a team willing to carry the pager, that is information. Teams decline to own things they believe will hurt them, and they are usually correct about which those are.
Killing a pilot well is a real skill. Write down what you learned, what it cost, and what would have to be true to revisit it. That document makes the next pilot better, and it protects the people who worked on this one.
FAQ
What percentage of AI pilots reach production?
Published figures range from roughly one-third to under one in eight, depending on the study. The spread is that wide because “production” is defined differently in each — some count any deployment, some require sustained use, some require measurable P&L impact. Treat the range as a signal, not a statistic, and define your own threshold before quoting anyone else’s.
Why do AI pilots fail to reach production?
Rarely for strategy reasons. The recurring blockers are six engineering gaps: no evaluation harness, no data contracts, no rollback path, no cost model, no security review, and no owning team. A pilot is allowed to skip all six. A production system is not.
How long does it take to move an AI pilot into production?
Eight to twelve weeks for a pilot that is fundamentally sound, assuming dedicated engineering rather than spare capacity. Most of that time goes to evaluation infrastructure and security review — neither of which compresses well.
What is the most common blocker for AI production deployment?
The missing rollback path, because it blocks the go-live decision invisibly. A risk stakeholder who cannot get a clean answer to “what happens at 2am on a Saturday” will keep finding delays rather than formally refuse.
Should we kill a stalled AI pilot?
Yes, under four conditions: the unit economics don’t close at realistic volume, quality has plateaued below usable, the automated step was never the actual bottleneck, or no team will accept ownership. The last one is the most reliable signal, because teams are good at predicting what will hurt them.
Next step
Run the readiness checklist against your pilot this week. If more than three boxes are unchecked in any one section, that section is your blocker, and it is probably not the one you thought.
If it’s fundamentally sound and just stuck, that’s what the Stabilization Sprint is for. If you’re not sure whether it’s sound, the free 90-minute Code & Risk Review will tell you — two engineers, no salespeople, and you keep the findings.
