Why AI Pilots Fail (and How to Get to Production)
of organizations saw no measurable P&L return from GenAI, according to MIT NANDA (2025)
95%
of organizations have not yet begun scaling AI across the enterprise, according to McKinsey (2025)
~2/3
of agentic AI projects Gartner expects to be canceled by the end of 2027
40%+
Use this article with AI
Open a buyer-ready brief in your preferred assistant.
ChatGPT, Claude, Perplexity and Grok open with the prompt attached. Gemini copies the prompt to your clipboard first.
Mitori
Article assistant
Ask about this article
I can help you understand the key arguments, how they apply to your organisation, and what questions to ask next.
Powered by Mitori · Scoped to this article
AI pilots mostly fail because of how they are implemented, not because the model is weak. They get picked on enthusiasm instead of evidence, launch without a baseline, miss the exceptions in the real workflow, lack an owner and add governance too late. Getting to production means fixing those gaps before you build.
Mitori is an operational intelligence platform that observes how work actually happens across your people, tools and handoffs, then tells you what to automate first, in what order and under what controls — and builds and monitors the AI agents that do it.
Why do most AI pilots fail?
Most AI pilots fail because they are bolted onto workflows nobody measured or fully understood. The model usually works in the demo. What breaks is the fit with real work: the exceptions, the handoffs, the approvals and the absence of a number that proves the pilot was worth scaling.
The research is consistent on this point. According to MIT NANDA's "The GenAI Divide: State of AI in Business 2025," about 95% of organizations saw no measurable P&L return from their generative AI efforts. The authors trace the gap to a "learning gap" and flawed enterprise integration: generic tools stall because they don't adapt to the workflows they are dropped into. Model quality is not the main story.
McKinsey's "The state of AI in 2025" shows the same pattern from another angle. According to McKinsey, 88% of organizations use AI in at least one business function, yet nearly two-thirds have not begun scaling it across the enterprise, and only 39% report any enterprise-level EBIT impact. Adoption is broad. Production value is not.
Agents raise the stakes. According to Gartner, more than 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls. All three are decisions made before the first line of code, not properties of the model.
What is AI pilot purgatory?
AI pilot purgatory is the state where a pilot technically works but never earns the budget, ownership or trust to move into production. It keeps running, it keeps getting demoed, and nobody can say whether it should be scaled or shut down.
Purgatory is expensive because it looks like progress. Teams keep paying for licenses and integration time, leadership keeps hearing that results are promising, and the next pilot starts before the last one is resolved. Ask these questions to find out if you're in it:
- Can anyone state the pilot's result as a change against a measured before-state? If not, there is no baseline.
- Is there a named business owner who will decide go or no-go by a date? If not, the pilot has no exit.
- Does the pilot handle the cases that real operators escalate today, or only the clean path?
- Has risk, compliance or IT signed off on how it would run at full volume, or only as an experiment?
- Is usage confined to the team that built or championed it?
What are the most common reasons AI pilots fail, and how do you fix each one?
Seven failure modes account for most stalled pilots. Each one has a specific fix, and almost every fix happens before build rather than after the demo.
- Picked by enthusiasm, not evidence. The use case came from a vendor demo, a conference talk or the loudest team. According to MIT NANDA's research, more than half of generative AI budgets go to sales and marketing tools, while the biggest returns showed up in back-office automation. The fix: choose workflows from observed data on volume, time spent and exception rates, then score each candidate on value, effort and confidence.
- No baseline, so no way to prove value. If nobody measured cycle time, handle time, error rate or rework before the pilot, any result is an opinion. The fix: capture the current-state numbers for the workflow first, and agree on the metric the pilot has to move before anyone builds.
- Brittle workflows the pilot didn't understand. Real work lives in email threads, spreadsheets, side-channel chat and workarounds that never appear in a process map. A pilot designed from interviews automates the happy path and breaks on the exceptions. The fix: map how the work actually moves across tools and people, including the exceptions, and design escalation paths for them.
- No owner. A pilot sponsored by an innovation team, with no operational leader accountable for the outcome, has nobody to push it through the hard parts of rollout. The fix: name a business owner who owns the metric and the go/no-go decision, plus the operators who handle escalations day to day.
- Governance bolted on late. Risk review arrives after the demo, finds that the agent can take actions nobody approved, and the project stalls. Gartner names inadequate risk controls as one of the three drivers of agentic AI cancellations. The fix: define approvals, escalation rules, data access and action logging as part of the design, not as a gate at the end.
- Agent washing and tool-first buying. Gartner uses "agent washing" for rebranding chatbots, RPA and assistants as agentic, and estimates that only about 130 of the thousands of agentic AI vendors are real. Buying a tool first means fitting your work to its demo. The fix: start from the workflow and decide whether it needs rules-based automation, an assistant or an agent.
- Can't scale beyond the demo team. The pilot ran on a curated slice of data with motivated users and manual cleanup behind the scenes. At full volume, with real systems of record and teams who didn't choose it, it falls over. The fix: pilot on real volume and real data from the start, and plan the rollout in waves with checkpoints between them.
Read next:Where should a company start with AI? →AI agents vs automation vs chatbots →
What's the difference between an AI pilot and a production deployment?
A pilot proves that something can work. A production deployment proves that it works on real volume, with real exceptions, under controls the business has approved, and keeps working after the launch team moves on.
| Dimension | Typical AI pilot | Production deployment |
|---|---|---|
| How the use case was chosen | Enthusiasm, a vendor demo or an executive request | Observed workflow evidence, scored on value, effort and confidence |
| Success measure | "Users liked it" or a demo that impressed leadership | A change against a measured baseline the owner agreed to upfront |
| Workflow coverage | The clean, happy path | The real path, including exceptions, handoffs and escalations |
| Ownership | An innovation team or a single champion | A named business owner plus operators who handle escalations |
| Governance | Reviewed at the end, if at all | Approvals, escalation and action logging designed in from the start |
| Data and systems | Curated sample data, manual cleanup behind the scenes | Live systems of record at full volume |
| After launch | No monitoring; drift goes unnoticed | Every action logged and performance tracked against the baseline |
Dimension
How the use case was chosen
Typical AI pilot
Enthusiasm, a vendor demo or an executive request
Production deployment
Observed workflow evidence, scored on value, effort and confidence
Dimension
Success measure
Typical AI pilot
"Users liked it" or a demo that impressed leadership
Production deployment
A change against a measured baseline the owner agreed to upfront
Dimension
Workflow coverage
Typical AI pilot
The clean, happy path
Production deployment
The real path, including exceptions, handoffs and escalations
Dimension
Ownership
Typical AI pilot
An innovation team or a single champion
Production deployment
A named business owner plus operators who handle escalations
Dimension
Governance
Typical AI pilot
Reviewed at the end, if at all
Production deployment
Approvals, escalation and action logging designed in from the start
Dimension
Data and systems
Typical AI pilot
Curated sample data, manual cleanup behind the scenes
Production deployment
Live systems of record at full volume
Dimension
After launch
Typical AI pilot
No monitoring; drift goes unnoticed
Production deployment
Every action logged and performance tracked against the baseline
How do you get an AI pilot to production?
Work backward from production. Decide what production has to look like, including the baseline, the owner and the controls, then design a pilot that proves exactly that.
- 1Observe the work before choosing the use case. Capture how the workflow actually runs across tools and people, including volume, time spent, handoffs and exceptions.
- 2Record the baseline. Write down the current numbers the pilot has to move, such as cycle time, handle time, error rate or backlog, and how you will measure them later.
- 3Score and sequence candidates. Rank workflows on value, effort and confidence, and start with one where the evidence is strong and the blast radius is small.
- 4Name the owner and the exit criteria. One business owner, one metric, a target, and a date for the go/no-go decision.
- 5Design governance in. Decide which actions need human approval, when the system escalates, what data it can touch, and how every action is logged.
- 6Pilot on real work. Use live volume and real data, include the exceptions, and involve the operators who will run it at scale.
- 7Roll out in waves. Expand to the next team or workflow only after the previous wave hits its checkpoint.
- 8Monitor against the baseline. Track performance and drift after launch so you know if the gains hold, and who acts if they don't.
Read next:How to deploy AI in your business (step-by-step guide) →How to measure AI ROI before you buy any tools →
How does an evidence-first approach change the odds?
An evidence-first approach removes the failure modes that happen before build. When the use case, the baseline and the controls come from observed work instead of interviews and demos, the pilot is designed to graduate rather than to impress.
This is the problem Mitori was built around. Mitori follows an Audit → Roadmap → Build → Control model. The Audit runs for 30, 60 or 90 days and observes real work, with consent, across the tools teams already use: email, spreadsheets, chat and business systems. It is observed, not interviewed, which is how exceptions and workarounds surface instead of disappearing into a process map.
The output is a sequenced, confidence-scored roadmap. Each automation is scored on savings, effort and confidence, then sequenced into deployment waves with governance checkpoints, including approvals and escalation. That answers the enthusiasm, baseline and late-governance problems before anything is built.
Mitori then builds the agents, which start from the observed workflows, and monitors them in the Control phase: every action is logged and drift is tracked against the observed baseline. Mitori's team helped scale a healthcare staffing company, SnapNurse, to $1.3B in revenue, and Mitori's agents already run in healthcare operations, including IVF clinics and healthcare staffing agencies.
- Observed baseline: the before-state is measured, so the result can be proven.
- Scored roadmap: use cases are chosen on savings, effort and confidence, not enthusiasm.
- Approvals built in: governance checkpoints are part of the sequence, not a late gate.
- Monitored against baseline: every agent action is logged and drift is tracked after launch.
Read next:How the Mitori Audit works →Take the AI readiness assessment →How Mitori handles trust and controls →See the proof →
Should you rescue a stalled AI pilot or shut it down?
Rescue it only if you can still establish a baseline, name an owner and define controls for the workflow it touches. If the use case was never grounded in evidence, it is usually cheaper to restart from observed work than to retrofit a justification.
- Rescue when the workflow is high-volume, the pain is measurable, and the gaps are ownership or governance rather than fit.
- Re-scope when the pilot handles the clean path well but breaks on exceptions. Narrow it to the cases it handles reliably and route the rest to people.
- Shut it down when nobody can say what it should improve, or when the tool was bought first and the workflow was bent to fit it.
- Either way, capture what you learned about the workflow. That evidence is the starting point for the next, better-chosen use case.
Read next:AI consultants vs an AI audit vs doing it yourself →Governance-first AI automation for regulated teams →Pricing →
Frequently asked questions
Estimates vary by definition, but they are high. According to MIT NANDA's 2025 "GenAI Divide" report, about 95% of organizations saw no measurable P&L return from generative AI. McKinsey's 2025 survey found nearly two-thirds of organizations have not begun scaling AI. The common thread is that pilots rarely translate into measured, enterprise-level value.
Because the model is rarely the bottleneck. Projects fail when the use case was chosen without evidence, nobody measured a baseline, the real workflow's exceptions were missed, no business owner was accountable, or governance arrived too late. The research from MIT NANDA and Gartner points to integration, value and risk controls rather than model quality.
Long enough to cover real volume and the normal cycle of exceptions in that workflow, and no longer. Set the exit criteria before the pilot starts: one owner, one metric measured against a baseline, a target and a decision date. A pilot without a decision date tends to drift into pilot purgatory.
According to MIT NANDA's research, as reported by Fortune, buying from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded about one-third as often. Whichever route you choose, start from the workflow, not the tool, so you can judge any option against the same baseline.
Agent washing is Gartner's term for vendors rebranding existing products, such as chatbots, RPA and AI assistants, as agentic AI without real agentic capabilities. Gartner estimates only about 130 of the thousands of agentic AI vendors are real. Defining the workflow first helps you see whether you need an agent at all.
Next step
Book an audit scoping call
Talk through a stalled or planned pilot and how an observed baseline and scored roadmap would get it to production.
Sources
Related reading
AI Deployment Guide
How to Deploy AI in Your Business: A Step-by-Step Guide (2026)
How to deploy AI in your business in 7 steps: observe real work, pick workflows by evidence, set governance, build agents with approvals, then scale in waves.
Getting Started
Where Should a Company Start With AI? How to Find the Workflows Worth Automating
Where to start with AI in business: skip the brainstorm. Score real workflows on volume, repetition, handoffs, error cost, data and risk, then start there.
AI ROI
How to Measure AI ROI Before You Buy Any Tools
How to measure AI ROI before you buy: capture an observed baseline, model savings as ranges with confidence, price effort and risk, then track realized value.
Governance
Governance-First AI Automation for Regulated Teams
Regulated teams do not need more automation ideas. They need a rollout model that survives audit, exception handling, and executive scrutiny.