Enterprise AI
The 85 percent number was never about failure
No. Gartner predicted in February 2018 that through 2022, 85 percent of AI projects would deliver erroneous outcomes due to bias in data, algorithms or the teams managing them. That is a statement about biased results, not failed projects, and it was a forecast with an end date that has passed.
It appears in pitch decks, in board papers and in the opening line of a great many vendor articles. Eighty five percent of AI projects fail. It is usually credited to Gartner, which is unusual for a viral statistic, because Gartner did say something with an 85 in it.
What they said is not what it is quoted as saying, and the gap between the two is instructive.
What Gartner actually said
The sentence comes from a Gartner press release published on 13 February 2018, and it reads:
"Gartner predicts that through 2022, 85 percent of AI projects will deliver erroneous outcomes due to bias in data, algorithms or the teams responsible for managing them."
Read it against the version in circulation and two things have changed. "Deliver erroneous outcomes due to bias" has become "fail", and a forecast has become a finding.
A wrong answer is not a failed project
An AI system that delivers erroneous outcomes because its training data is skewed is, in the usual case, a system that is running. It was built, it was deployed, people are using it, and it is producing results that lean in a direction nobody intended. That is a serious problem and it is a completely different problem from a project that never reached production.
The two failures also have opposite remedies. A project that stalls needs someone to resolve what nobody agreed on. A system producing biased results needs measurement, review and correction of something already live. Quoting the second number as evidence for the first sends a reader to the wrong work.
It was a forecast, and it has expired
The wording is "predicts that through 2022". It was a projection made in early 2018 about a window that closed four years ago. Gartner publishes forecasts of that kind constantly, they are clearly labelled, and they are not claims about what happened.
A prediction that has run its course is not a measurement. It is an old opinion about a period that has since been observed.
Nobody, as far as we can find, has gone back and tested it. That is the odd part: the statistic is quoted in 2026 as a current fact about the state of AI, and the only thing that would make it a fact is a study that does not appear to exist.
How does a number like this go wrong?
It is worth naming the mechanism, because it is not the same one that produced the other famous number in this field. The 95 percent figure was an arithmetic mistake: a share of all organizations was read as a share of organizations that had run a pilot. Somebody divided by the wrong denominator.
This one has no mistake in it anywhere. Every step was a small, reasonable compression by somebody with a deadline.
| As published | As quoted | |
|---|---|---|
| Status | A prediction | A finding |
| Window | Through 2022 | None, so it reads as current |
| Outcome | Erroneous outcomes | Failure |
| Cause | Bias in data, algorithms or teams | Dropped |
Four small compressions and the sentence now means something its author did not write. This is the ordinary way a number goes wrong, and it is far more common than a division error, because at no point does anybody do anything obviously incorrect.
What can I use instead?
If the point being made is that most organizations are not yet running on AI, there is a properly sampled measurement of exactly that. McKinsey's "The state of AI in 2025" was published on 5 November 2025 and drew 1,993 responses across 105 nations.
If the point is that the blocker sits in the data rather than in the model, Gartner has a directly relevant figure from a survey rather than from a forecast.
Why does this matter enough to write about?
Partly because the number is used to sell things, including things we sell. A statistic that says most AI fails is convenient for anybody offering a way to make it work, and that is exactly the kind of convenience that should make a buyer suspicious.
But mostly because of what checking costs. Both of the numbers in this field that everyone repeats fall apart within about twenty minutes of reading the source. Nobody had to be an expert. Somebody had to open the link.
If a vendor cannot be bothered to read the footnotes of the statistic in their own pitch, that is a fact about the vendor, not about the statistic.
The same standard applies to us, which is why every figure on this site carries its publisher, its date and its sample size, and why figures we could not trace to a primary source are not here at all.
What to ask of any number in a deck
- Is it a measurement or a forecast? A forecast has a window, and the window may have closed.
- What exactly was measured? "Erroneous outcomes" and "failure" are different events with different remedies.
- Who was asked, and how many? A specialist panel of 248 is useful and is not a cross-section.
- When was it published, and has anything since superseded it?
- Does the primary source still exist at a link you can open? If the trail ends at a summary of a summary, treat the figure as unsourced.
None of that requires expertise. It requires opening the link, which is a low bar that a great deal of published material does not clear.
Q&A
Is it true that 85 percent of AI projects fail?
Did Gartner say 85 percent of AI projects fail?
What is the difference between a project failing and delivering erroneous outcomes?
What percentage of organizations have actually scaled AI?
How can I tell whether a statistic in a vendor deck is sound?
Sources
Where does this break in your organization?
Tell us about one process you actually run. We answer with what we would look at first, not with a deck.
Related reading
Why enterprise AI pilots stall
The most quoted statistic in enterprise AI does not survive its own source. Here is what the evidence actually supports, and what it says about the gap between a pilot and production.
Why two departments disagree about the same job
Finance, operations and legal each hold a different version of the same piece of work, and each version is correct. That is why it is not a data quality problem.