The famous AI failure rates are fake. The data problem is real.

On the 10th of May, 2022, the CEO of Unity told investors that the company's ad targeting had broken, and he was unusually specific about why: the models had been poisoned by "ingesting bad data from a large customer." His estimate of the damage, verbatim: "approximately $110 million in 2022." The stock lost about a third of its value the next day, roughly five billion dollars of market cap, and the CEO offered the most honest sentence in the history of data engineering: "we built more for growth and less for resiliency."

I keep that quote around because it is the rarest thing in the AI-failure genre: a primary source, with a dollar figure, and the word "data" in the causal sentence. The rest of the genre is in much worse shape. You have seen the headlines: 95% of AI pilots fail. 80% of AI projects fail. These numbers are doing enormous work right now, in board decks, in vendor pitches, in think pieces, and almost none of them survive a provenance check. So this essay does two things. First it autopsies the famous failure statistics, because the numbers you have read are mostly marketing wearing a citation. Then it walks through what the credible evidence actually shows, and the pattern is consistent: when AI projects die for a fixable reason, the fix is almost never the model. The data was never ready.

The failure statistics are a crime scene

The 95% that wasn't

The most famous number in enterprise AI came from a July 2025 MIT report called The GenAI Divide, and here is what sits underneath it: 52 structured interviews, 153 conference surveys, a review of public initiatives, a self-applied "Preliminary Findings" label, and no peer review. The 95% headline came from the executive summary's claim that "95% of organizations are getting zero return," but the quantified basis inside the report is narrower: 5% of custom enterprise AI tools reached successful deployment within a six-month window, by self-report. The same document says workers at over 90% of the surveyed companies use AI regularly and that most generic chatbot pilots get implemented. Fortune's coverage turned it into "95% of AI pilots fail," the market briefly sold off on it, and Wharton's Kevin Werbach said what needed saying: he could not figure out where the number came from, and if the authors stood behind it they should release the data. The report has since quietly vanished from MIT NANDA's own publications page. The Register, which read the PDF rather than the coverage, is the sober account.

The 80% number is worse. It appears in a 2024 RAND report as "by some estimates, more than 80 percent of AI projects fail," and the footnote trail is short: it leads to a 2022 Fortune profile that attributes the figure to "a slew of recent surveys," none named. That is where the trail ends. An unsourced estimate in a magazine profile got laundered through a think tank's hedged citation into "research shows 80% of AI projects fail." RAND never measured any such thing, and its actual contribution, which is good, is a different one we will get to.

Predictions dressed as measurements

Gartner supplies the other family of famous numbers, and the important thing about them is their grammar. "Through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data" is a prediction, published February 2025, with no methodology attached and no follow-up scoring. So is the 2024 claim that at least 30% of generative AI projects would be abandoned after proof of concept. In the retelling, "Gartner predicts" becomes "Gartner reveals," "abandon" becomes "fail," and the conditional clause about AI-ready data quietly falls off, converting a hedged forecast about a subset into a universal base rate. When Gartner later asserted the 30% prediction had been exceeded, the stated basis was that it had "analyzed hundreds of implementations." No survey, no sample size, no published method.

The numbers that survive

Strip out the predictions and the laundered estimates and a few measurements remain. S&P Global's 451 Research ran a real survey, a thousand respondents with published methodology, and found that 42% of companies abandoned the majority of their AI initiatives before they reached production in 2025, up from 17% a year earlier, with roughly 46% of projects scrapped between proof of concept and adoption. Gartner's one genuinely measured result, a late-2025 survey of 782 infrastructure and operations leaders, found 28% of AI use cases fully succeed, 20% fail outright, and the rest muddle through.

So the honest picture: roughly 40 to 50% of enterprise AI projects die between pilot and production, a minority fail outright, a similar minority fully deliver, and the attrition is rising as portfolios grow. That is a real problem. It is also an ordinary-looking innovation funnel, not a 95% catastrophe, and some of the attrition is the funnel working: killing weak pilots at proof of concept is what proofs of concept are for.

Put simply: Nobody measuring carefully finds an 80 or 95% failure rate; everybody quoting one is quoting someone who didn't measure. The defensible number is that four or five in ten enterprise AI projects die before production. Before repeating any failure statistic, ask two questions: was it a measurement or a prediction, and who was selling what.

What the postmortems actually say

Failure rates tell you how often. Postmortems tell you why, and the named, documented cases sort into two eras.

The training-data era

Unity is the anchor: bad third-party data ingested into training pipelines, a hundred-million-dollar earnings miss, attributed by the CEO in a public transcript. Amazon spent years on a resume-scoring model that taught itself to penalize the word "women's", because it was trained on a decade of male-dominated hiring history; the model faithfully compressed a biased dataset, and the team could not guarantee it would not discriminate in new ways, so it died. IBM's Watson for Oncology produced treatment recommendations that internal documents described as unsafe, and STAT News traced the mechanism: it was trained on a small number of hypothetical cases devised by doctors rather than real patient data, while a related deployment at MD Anderson burned $62 million, per a state audit, without ever being used on a patient, in part because it could not connect to the hospital's new medical records system. Epic's sepsis model, deployed at hundreds of hospitals, was externally validated well below its claimed accuracy, missing about two-thirds of sepsis cases at its alert threshold; the model had been developed against billing-code labels, a wrong-grain proxy for the thing it claimed to predict. And Zillow wound down its home-buying business with a $304 million inventory write-down after its price forecasts broke under pandemic-era distribution shift, though honesty requires the caveat Zillow itself made: the company said the world had become unforecastable, not that its data was bad, and thin margins plus adverse selection turned a modeling error into a fatal one.

Different industries, one autopsy: the model did exactly what the data taught it. Google researchers surveying practitioners put a name on the pattern, "data cascades," compounding downstream failures from undervalued data work, reported by 92% of the 53 practitioners they studied (a small sample, disclosed here because this essay would like to keep its own rules). Their title is the whole diagnosis: "Everyone wants to do the model work, not the data work."

The grounding era

The generative wave changed the failure mode without changing the root cause. Air Canada's chatbot invented a bereavement refund policy, a customer relied on it, and a tribunal ordered the airline to pay, dismissing the argument that the chatbot was somehow a separate entity as "a remarkable submission." The detail that matters: the correct policy was on Air Canada's own website the whole time. The bot was not stupid, it was unbound. New York City's business chatbot told employers they could take workers' tips, which is illegal, while the actual law sat in the city's own documents. Cursor's AI support bot invented a login policy that did not exist while the true cause, a bug, sat in the company's engineering systems. Deloitte refunded part of a government contract after a report shipped with fabricated citations. Replit's coding agent deleted a production database during an explicit code freeze, then misreported what it had done.

In the training-data era, the data was wrong. In the grounding era, the data was right and the system was not connected to it. Both are the same sentence wearing different clothes: the failure lived in the relationship between the model and the data, not in the model.

One honesty note, because this essay's whole premise is not trusting convenient rankings: when RAND interviewed 65 practitioners about why AI projects fail, the top cause was not data. It was leadership misunderstanding or miscommunicating what problem needed solving. Data, the lack of what's needed to train an effective model, came second, with data infrastructure fourth, and RAND called the top two "the two dominant root causes." I read that ranking as strengthening the case rather than weakening it: you cannot consult your way out of cause one with a tool, but cause two is buildable, and it is the one that keeps appearing in postmortems with dollar signs attached.

Put simply: When AI projects fail for a reason you can fix, the fix is almost always upstream of the model: wrong training data in the last era, right data left unconnected in this one. Before blaming the model, or the vendor, check what the system was actually taught and what it was actually bound to.

What "ready" means, and why the readiness surveys are noise

Gartner's definition of AI-ready data is more useful than its predictions: data that is representative of the specific use case, governed, and contextualized, with the blunt corollary that "there is no way to make data AI-ready in general or in advance." Readiness is relative to a question. That single idea kills the boil-the-ocean data quality program as a prerequisite, and it explains a puzzle in the survey data.

The puzzle: what fraction of companies have AI-ready data? One well-known survey series answered 12% in one year and 87% the next. Same sponsor, same topic, opposite headline. What changed was who they asked: the 12% came from practitioners, the 87% from executives. Capital One found the same gap inside single companies: 87% of business leaders call their data ecosystem AI-ready while 70% of their own technical practitioners spend hours a day fixing data issues. Executives grade the estate; practitioners grade the Tuesday. Any readiness percentage quoted without saying who was asked is noise, and most of the ones in circulation are funded by companies selling the remedy.

What survives the noise is the shape of the complaint. Ask practitioners open-endedly what blocks AI and the same surfaces recur: quality errors the model amplifies, silos and entitlements that engineering burns most of its time working around, metric definitions that differ across systems so no one can say what "active customer" means, data captured at the wrong grain to answer the question being asked, staleness and drift, and rights nobody cleared. Notice that only the first of those is what people usually mean by "bad data." The rest are missing context, missing contracts, and missing resolution, which is why teams that pass a data quality audit still fail the AI project.

Put simply: There is no such thing as AI-ready data in general, only data ready for a specific question, and executives systematically overestimate how ready theirs is. Do not commission a readiness assessment of everything; pick the use case first and assess readiness for that.

The cleanest evidence is a benchmark, not a survey

Surveys ask people what went wrong. Benchmarks measure it, and the measurement is stark. On academic text-to-SQL tests, frontier models score around 90%. On Spider 2.0, a benchmark built from realistic enterprise data workflows, the same class of models scored 10 to 17% at its late-2024 launch. The leaderboard has since climbed into the 70s and 90s, and the telling part is how: the top of one main track now belongs to a context-layer product, not a bigger model. The delta is not intelligence. It is everything the enterprise knows that its schema does not say: what the tables mean, which revenue is the real revenue, what joins are legitimate. The missing ingredient has a name, context, and when you add it back the numbers move violently. In dbt Labs' 2026 benchmark, a frontier model went from 84% on raw text-to-SQL to 100% through a semantic layer. In Cube's paired benchmark, a semantic layer added 17 to 23 points across every model tested, and with it in place, which frontier model you chose stopped mattering statistically. Cube's summary sentence deserves to be famous: "the data model is the upper bound on AI quality." Practitioners keep replicating it: one recent lab run walked the same 25 questions up a grounding ladder and went from 41% to 92%, the semantic layer the biggest single step.

The agent wave raises the stakes on exactly this. An analyst who gets a wrong number notices; an agent that gets a wrong number acts on it, at machine speed, without a reviewer. McKinsey finds that while two-thirds of enterprises are experimenting with agents, fewer than one in ten have scaled them, and eight in ten name data limitations as the roadblock. Gartner's sharpest recent prediction, for once directionally useful, is that most agentic analytics projects that rely on wiring agents to raw data without semantic foundations will fail. Anthropic's own engineering guidance frames agent reliability as a context-curation problem, a finite attention budget spent on the smallest set of high-signal tokens. Context engineering is data readiness restated for inference time. The largest-scale operators agree: asked how teams should navigate the AI moment, Netflix's chief product and technology officer Elizabeth Stone answered with source-of-truth data first, then guardrails, then human ownership. The first item is this essay's subject. I have argued elsewhere that the context layer is the product; the benchmarks above are what that claim looks like with numbers on it.

Put simply: The same model scores 10% on your data and 90% with context added, so the accuracy of your AI is set by your data model, not your model choice. Budget accordingly: the marginal dollar goes to semantics and context, not to a better model.

The bottleneck moved, and it did not move to the model

Follow the money and the story closes itself. Model inference prices are collapsing on a schedule, roughly ten times cheaper per year for equivalent capability per a16z's LLMflation analysis, which is the fastest commoditization of a technology input in memory. Meanwhile the boring parts refuse to deflate: industry cost surveys, none of them audited, consistently put data preparation at a quarter to a third of AI project cost and half to two-thirds of project time, and it is the line item over-budget projects most often name as underestimated. The people building the tooling say it plainly too: Retool's data team, where I work, opens its AI-ready data explainer with the claim that data, not models, is the bottleneck, and defines readiness as data unified, governed, and documented enough to act on, not just to query. One input is a plummeting commodity, the other is a stubborn constraint. Margin does not sit with commodities.

This is the same mechanism I mapped in profit pools: commoditize one layer and the profit migrates to the next constraint. The model layer is commoditizing in real time. The constraint it exposed is the data layer, specifically the contextualized, governed, question-ready version of it that the benchmarks show doing all the work.

The encouraging part, and the reason the fake statistics matter, is that the real fix is smaller than the doom numbers imply. In the dbt benchmark, three added models took semantic coverage of the test questions from zero to complete. Cube's accuracy jump came from a semantic document of about four kilobytes. Because readiness is use-case-relative, the credible program is scoped: pick the questions that matter, make the data ready for those, prove it, expand. Weeks per domain, not a multi-year data transformation that has to finish before the first AI project starts. The companies stuck at 40 to 50% attrition are mostly not missing a platform. They are missing the unglamorous middle layer where someone wrote down what the data means.

The failure rates were inflated to sell you either despair or software. The failures are real, and they are, at the practitioner level, monotonously alike: the model did what the data taught it, or the model was never bound to the data that knew better. Models are rented, and the rent is falling. The data, its meaning, and the discipline of keeping the two connected are owned. That is where the projects die, and it is where the compounding lives.

Put simply: Model costs fall tenfold yearly while data work refuses to get cheaper, so the bottleneck, and the margin, moved to the data layer. Fix readiness question by question, prove value, and expand; the graveyard is full of projects that waited for the data estate to be perfect and companies that never wrote down what their data means.

This was part one of two. Part two picks up on that last phrase: what ready data actually looks like, the seven disciplines behind the middle layer this essay keeps pointing at.