Two numbers have shaped how business leaders talk about AI over the past year, and they cannot both be right.
The first is the widely quoted finding that 95% of enterprise generative AI pilots deliver no measurable return. The second is Wharton’s 2025 AI Adoption Report, published in October 2025, which found that three out of four enterprise leaders see positive returns on their generative AI investments. Same year, same enterprise buyers, near opposite conclusions.
The gap between those two figures is the most useful thing in either study. It is not really a disagreement about whether AI works. It is a disagreement about what counts as working, and that ambiguity is the single best predictor of whether a pilot ever reaches production.
Read the sourcing before you quote the statistic
The 95% figure comes from a paper titled The GenAI Divide: State of AI in Business 2025, produced by a group at MIT called Project NANDA. It labels itself as preliminary findings, it was not peer reviewed, and the authors state the views are their own rather than their institutions’. Researchers who went looking for the derivation of the headline number, including Wharton’s Kevin Werbach, reported that it appears in the document without visible supporting data.
The paper also uses a demanding definition of success: a deployment counts only where users or executives describe a marked and sustained impact on productivity or profit. A tool returning modest but real value gets filed alongside a tool that returned nothing.
None of this makes the paper worthless. It makes it a study about a stringent bar, quoted for eighteen months as though it were a study about total failure. If your board has seen that statistic, it is worth showing them the sourcing before you plan around it.
The evidence that survives scrutiny
Several other datasets point at the same problem without the methodological wobble, and they are more useful because they name causes.
Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Gartner also flags “agent washing,” where existing software is rebranded as agentic without materially changing what it does.
S&P Global Market Intelligence’s 2025 survey of more than 1,000 enterprises found that 42% abandoned most of their AI initiatives, up from 17% the year before, with the average organisation scrapping close to half of its proofs of concept before production.
Deloitte’s 2026 Tech Trends research puts a finer point on it: only 14% of organisations have agentic solutions ready to deploy and just 11% are running them in production, while 42% are still drafting a roadmap and 35% have no formal strategy at all.
Read together, these describe a scoping and integration problem, not a model capability problem. Below are the five failure modes I see most often when a pilot that demonstrated well never ships.
Failure 1: Nobody checked whether the software had a door
An agent is only as deployable as the systems it needs to read from and write to. Before any build starts, there is a check that takes about ninety seconds per tool and predicts most of the project’s difficulty.
For every core platform the business runs on, ask one question: does it offer an API, an MCP server, or a documented integration path? Where the answer is yes for the tools that matter, the work is predictable, and the agent walks through a door the vendor built deliberately.
Where the answer is no, the project is still possible, but it changes shape. The agent has to operate the software the way a person does, through the screen, using browser automation or interface-driven scripting. That works, and sometimes it is the only option, but it breaks when a vendor moves a button or relabels a field, and the maintenance cost never goes away.
The organisational version of this blocker is worse than the technical one. Teams routinely cannot say whether they own their own credentials, whether source code for an internal tool still exists, or whether the contractor who built it five years ago is reachable. Discovering that in week seven of a build is far more expensive than discovering it in week one — which is usually why this stage gets outsourced to an AI consulting company that has already made this specific mistake on someone else’s dime.
Failure 2: The demo stack was never the production stack
Visual workflow builders are genuinely good at what they are for: validating that an idea has value before anyone commits engineering budget. The mistake is treating a successful validation as a production architecture.
The ceiling shows up in predictable places. Sequential execution becomes a bottleneck at volume, error handling is thin enough that failures pass silently, per-task pricing scales against the business precisely as the automation succeeds, and there is usually no version control or audit trail to speak of.
The teams I have seen struggle hardest are not the ones who chose the wrong tool. They are the ones who spent months building organisational commitment on a stack that was only ever meant to answer a question, and then had to rebuild from scratch when the answer turned out to be yes.
Failure 3: The pilot ran against live systems
Agents behave unpredictably at the edges, and the tool calls are where consequences live: emails sent, records written, payments triggered. A pilot that runs against production data is not a pilot, it is an uncontrolled release with optimistic framing.
Before an agent touches anything real, it needs an environment that mirrors production: a staging instance of the CRM, a test database, mocked responses for payment and messaging tools. I have been brought in to clean up after a runaway agent wrote bad records into a live CRM, and after another sent real customer notifications during what everyone involved believed was a test.
The specific technology matters far less than the discipline. Production is a terrible place to discover edge cases, and a single visible incident will end a pilot’s political support faster than any technical shortcoming.
Failure 4: Non-determinism was treated as a later problem
Language models do not return the same output twice. That property is fine, and it is the reason they are useful for work rules engines could never handle, but it means correctness has to be measured statistically rather than assumed.
A pilot without an evaluation harness cannot demonstrate that it works, which means it cannot graduate, no matter how well the demo went. Sampling outputs, scoring them against agreed criteria, and tracking that score over time is what turns an impressive demonstration into an operational argument.
Security belongs in the same bucket. The OWASP Top 10 for LLM Applications ranks prompt injection as the number one risk, and the indirect variant is the one that catches teams out: instructions hidden inside a document, an email, or a web page that the agent later processes as if a person had typed them. Any agent reading from an external source is consuming untrusted input, and the NIST AI Risk Management Framework is a reasonable starting point for governing that formally.
Failure 5: No one agreed what “done” looked like
This is the failure that explains the two contradictory statistics we opened with.
In most stalled projects I have reviewed, the sponsor, the operational team, and the builders each held a different picture of acceptable output, and none of it was written down. When the system finally produced something, everyone measured it against their own private benchmark, and at least one stakeholder concluded it had failed.
The fix is unglamorous. Before the build starts, write down what a good output looks like, as actual sample outputs rather than adjectives, and get every stakeholder to sign off on those samples. Adjectives like “accurate,” “helpful,” and “professional” survive a kickoff meeting comfortably and mean nothing at acceptance.
Five questions to answer before funding a pilot
- Which systems must this agent read from and write to, and does each one expose an API, an MCP server, or a documented integration path?
- Who owns the credentials and the source code for those systems, and can we reach whoever built them?
- What environment will the pilot run in, and what exactly is mocked rather than live?
- What does a correct output look like, written as five real examples that every stakeholder has approved?
- What score, measured how and over what period, moves this from pilot to production, and who signs that off?
If you want a faster gut-check before that conversation even starts, a free AI readiness assessment will surface most of the gaps in the first four questions in a few minutes rather than a few meetings.
A team that can answer all five is not guaranteed a result. A team that cannot answer them is running an experiment with no stopping condition, which is a fair description of a large share of the projects inside every failure statistic quoted above.
The failure rate is mostly an artefact of scoping
The honest reading of the current data is not that enterprise AI does not work. Deloitte’s 11% production figure and Wharton’s three-in-four ROI figure are compatible: adoption is narrow, and where it is scoped properly it tends to pay.
What the numbers actually measure is how many organisations funded a build before establishing whether their systems could be reached, what correct looked like, and who would decide. Those questions are answerable in a week, at almost no cost, and they are the difference between a pilot that graduates and one that becomes a line item in next year’s abandonment survey.
