Every company that has tried AI seriously has a pilot graveyard. A support assistant that answered well in the demo and was never switched on for customers. A contract summariser that three lawyers liked and nobody used after the trial. A forecasting model that lived in a notebook. Each one cost money and attention, and each one taught the organisation a little more scepticism.
The pattern is now well documented. Surveys from MIT, Gartner and S&P Global all point to the same steep drop between trying AI and running it in production. This article looks carefully at what those studies actually say, sets out the seven reasons pilots stall, and describes what the minority that ship do differently, ending with a 90-day plan and the measures that decide whether a pilot deserves to go live.
Key takeaways
- The widely quoted "95% of pilots fail" figure comes from MIT NANDA's 2025 report, which found 95% of organisations getting zero measurable return from generative AI. Read its method and caveats before quoting it.
- Pilots stall for organisational reasons more than model reasons: no owner, no baseline, no context, no decision date.
- Pilots that ship target one frequent, verifiable workflow, often in back-office work, and are bought or co-built more often than built alone.
- Decide before day one what result means "go live," and measure work closed on proof.
What does "AI pilot to production" mean?
Moving an AI pilot to production means taking a tool that worked in a limited test and making it part of how a real process runs every day, for real users, with real data, and with results someone can measure. A pilot answers "can this work?" Production answers "does this change our outcomes, at an acceptable cost and risk?"
The gap between the two is wider for AI than for most software. Traditional software either does what it was specified to do or it does not. AI systems produce variable output, depend heavily on the data and context they are given, and need people to trust them enough to change their habits. A demo with clean examples can look excellent and still fail on Monday morning's actual inbox.
What did the MIT "GenAI Divide" report actually find?
The most cited source on stalled pilots is The GenAI Divide: State of AI in Business 2025, published in July 2025 by MIT NANDA, with Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari named on the title page. Its executive summary opens: "Despite $30-40 billion in enterprise investment into GenAI, this report uncovers a surprising result in that 95% of organizations are getting zero return." It adds that "Just 5% of integrated AI pilots are extracting millions in value, while the vast majority remain stuck with no measurable P&L impact."
For enterprise-grade systems, the report gives a funnel: "Sixty percent of organizations evaluated such tools, but only 20 percent reached pilot stage and just 5 percent reached production." It attributes most failures to "brittle workflows, lack of contextual learning, and misalignment with day-to-day operations."
Three details matter when you quote it:
- Method. The report is based on a review of over 300 publicly disclosed AI initiatives, structured interviews with representatives from 52 organisations, and survey responses from 153 senior leaders, collected between January and June 2025.
- Caveats. The authors note that the deployment figures are "directionally accurate based on individual interviews rather than official company reporting," and that success definitions may differ across organisations.
- What "success" meant. A tool counted as successfully implemented when users or executives described a marked and sustained productivity or P&L impact.
The headline is often shortened to "95% of AI pilots fail." The report's own wording is about organisations getting zero return and pilots without measurable P&L impact. The direction is clear and consistent with other data. The exact percentage should be quoted with its context.
The report's diagnosis is the part most worth reading. It names a "learning gap": "Most GenAI systems do not retain feedback, adapt to context, or improve over time." The barriers users reported included "It doesn't learn from our feedback" and "Too much manual context required each time."
What does other data show about pilots that stall?
MIT is not alone. Several independent sources describe the same drop-off.
| Source | Finding |
|---|---|
| Gartner, July 2024 | At least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, due to poor data quality, inadequate risk controls, escalating costs or unclear business value (THE Journal) |
| S&P Global Market Intelligence, 2025 | The share of companies abandoning most of their AI initiatives jumped to 42%, up from 17% the year before, and the average organisation scrapped 46% of AI proofs of concept before production (CIO Dive) |
| Gartner, June 2025 | Over 40% of agentic AI projects will be cancelled by the end of 2027 due to rising costs, unclear business value and inadequate risk controls (RCR Wireless) |
| Menlo Ventures, December 2025 | 47% of AI deals go to production, compared with 25% for traditional software (Menlo Ventures) |
The Menlo figure is a useful counterweight. It measures deals a buyer has already committed to exploring, not every experiment, and it suggests that bought AI tools with a clear use case convert at a healthy rate. The problem is less "AI does not work" and more "most pilots are set up in a way that cannot produce a production decision." Gartner's Anushree Verma put it bluntly: "Many use cases positioned as agentic today don't require agentic implementations."
Seven reasons enterprise AI pilots stall
| Reason | What it looks like | The fix |
|---|---|---|
| 1. No owner | An innovation team runs the pilot. The business team that would use it is "consulted." | The person whose numbers improve owns the pilot. |
| 2. No baseline | Nobody measured the process before, so nobody can show a change after. | Record two weeks of the current numbers before starting. |
| 3. Toy data | The pilot runs on curated examples, not live email and records. | Connect real sources read-only from day one. |
| 4. No company context | The tool answers generically because it does not know customers, promises or goals. | Give it the context where work actually happens. |
| 5. Wrong use case | A visible, hard-to-measure use case chosen for the board slide. | Pick frequent, verifiable work, often in the back office. |
| 6. No approval design | Either every output is reviewed by hand forever, or nothing is, and risk teams stop it. | Write rules: what AI drafts, who approves, what never runs alone. |
| 7. No decision date | The pilot is extended, then extended again, then forgotten. | Agree a go-live test and a date before starting. |
Only one of the seven is about the technology, and even that one, context, is mostly about access rather than model quality. For how these same issues show up after launch, see why AI agents fail in production.
What do the pilots that ship do differently?
MIT's report is most useful in its description of the organisations that crossed the divide.
- They buy or co-build. In MIT's sample, external partnerships with learning-capable, customised tools reached deployment about 67% of the time, compared with about 33% for internally built tools.
- They act like outsourcing clients. The report says successful buyers "act like BPO clients, not SaaS customers." They demand customisation, drive adoption from the front lines and hold vendors to business metrics.
- They decentralise with accountability. MIT found companies succeed "when they decentralize implementation authority but retain accountability."
- They move fast. Top mid-market performers reported about 90 days from pilot to full implementation. Large enterprises took nine months or longer.
- They look past the front office. The report found budgets favour visible sales and marketing uses, while back-office automation often yields better returns.
A pilot charter: what to agree before day one
The single most effective habit is a one-page charter signed before any work starts. It should answer six questions.
- Which workflow? One, named precisely: "supplier follow-ups for open purchase orders," not "procurement."
- Who owns it? The manager whose results change, with authority to change the process.
- What is the baseline? Current volume, time, error rate or slip rate, measured before the pilot.
- What counts as proof? The evidence that a piece of work happened: the sent email, the updated record, the booked meeting.
- What are the approval rules? What the AI may draft, who approves, and what it may never do alone.
- What is the go-live test and date? For example: "If 80% of follow-ups close on proof within two days for four weeks, we go live on 1 March."
The choosing your first agent playbook helps with the first question, and enterprise AI governance covers approval rules in depth.
A 90-day plan from AI pilot to production
- Days 1 to 14: baseline and charter.
Sign the charter. Measure the current process. Connect the real sources read-only.
- Days 15 to 45: shadow mode.
The AI proposes, people decide and act as usual. Compare its proposals with what people actually did.
- Days 46 to 75: approve and send.
The AI drafts, a person approves each output, and the system checks for proof. Track edits and rejections.
- Days 76 to 90: decide.
Apply the go-live test. If it passes, move to production with the same approval rules. If it fails, write down why and stop.
- After go-live: widen by evidence.
Where approvals go through unchanged for weeks, consider letting that narrow type of work run with lighter review.
Stopping is a valid outcome. A pilot that ends with a clear "no" and a written reason is far more valuable than one extended indefinitely.
How to measure an AI pilot
| Measure | What it tells you |
|---|---|
| Work closed on proof by its date, vs baseline | Whether outcomes improved |
| Outputs approved without edits | Whether quality is good enough for lighter review |
| Outputs rejected or marked not relevant | Whether the tool understands the company's context |
| Time from signal to action | Whether work starts sooner |
| Cost per completed item | Whether it pays for itself at production volume |
| Days from pilot start to go-live decision | Whether the organisation can decide, not just test |
For agent-specific testing methods, see AI agent evals.
How GeniOS approaches AI pilot to production
GeniOS is built so that the first weeks already run on real work. It reads the places where a company's work happens, such as email, calendar, chat and the business tools you already use, read-only to start. It forms the company's goals from its own emails, decks and meetings, and checks every team's pending work against them.
What reaches a person is one situation, what to do, why, one owner and a date. The owner answers Delegate, Done, Later or Not relevant. Delegate hands work to a person or an AI agent, and nothing is sent until a human approves.
An item closes only on proof, such as the email that went out, and GeniOS learns from each outcome. That gives every pilot its baseline, its approval rules and its evidence from day one, which are three of the seven reasons pilots stall.
Worked example: a stalled pilot and a shipped one at the same company
The names, dates and numbers in this example are made up to explain the idea. Vaultex makes safety footwear in Greater Noida, selling to Bata, Reebok and Adidas.
The pilot that stalled. Last year, a consultant set up a chatbot over Vaultex's product catalogue. In the demo it answered specification questions well. It had no access to email, so it knew nothing about live orders. Nobody owned it after the consultant left, nobody measured anything before, and there was no decision date. Six months later it had a dozen users and no measurable effect.
The pilot that shipped. This year, management picks one workflow: buyer commitments that must be met before vendor reviews and audits. Harsh in sales owns it. The baseline from the previous month: five commitments slipped past their date.
In the second week, with email, calendar and chat connected read-only, three live situations surface:
- Bata wants 12,000 pairs of S3 safety shoes at $12 a pair, about $144,000, on 60-day terms, with a vendor review on Friday. The steel toe cap supplier has raised prices 8%. Owner: Harsh, re-check the quote by Thursday.
- Reebok samples hold Line 2, and the Bata volume has no confirmed slot. Owner: Anushka in production.
- Adidas has a vendor audit and the IS 15298 test reports have not been sent. Owner: Anushka.
Harsh delegates the revised quote draft to an agent and approves it. Anushka confirms the slot and sends the reports. Each item closes on the sent email or the plan entry. After four weeks, slipped commitments are down to one, against a baseline of five. The go-live test in the charter passes, and the company moves the workflow to production. The Vaultex case study covers the real partnership.
Conclusion
Most enterprise AI pilots stall for reasons decided before they start: no owner, no baseline, toy data, no context, the wrong use case, no approval design and no decision date. The research, read carefully, says the same. The minority that move from AI pilot to production choose one frequent, verifiable workflow, connect real sources, buy or co-build, write approval rules and measure outcomes on proof. For the wider adoption path, read how enterprise AI will actually be adopted, and for how buying outcomes changes the vendor relationship, see service as software. To set up a pilot that ends in a decision, book a call.
Sources
- MIT NANDA, The GenAI Divide: State of AI in Business 2025, July 2025
- THE Journal, Gartner: 30% of Gen AI Projects Will Be Abandoned, 6 August 2024
- CIO Dive, AI project failure rates are on the rise: report (S&P Global), 14 March 2025
- RCR Wireless, Gartner: More than 40% of agentic AI projects will fail by 2027, 27 June 2025
- Menlo Ventures, 2025: The State of Generative AI in the Enterprise, 9 December 2025