What percentage of AI projects fail, and why?

What percentage of AI projects fail?

The honest answer is that no single percentage applies to every AI project. The most useful current public evidence spans at least 30% forecast abandonment, at least 50% reported abandonment after proof of concept, 42% of surveyed companies abandoning most initiatives before production, and an average 46% of projects scrapped before broad adoption. These figures are not interchangeable. They come from different years, populations, evidence types, stages, and definitions.

A search result that strips those qualifiers creates a false benchmark. If a company runs ten low-cost experiments and stops six weak ideas before integration, that may show disciplined portfolio management. If it funds one production system without an owner, acceptance test, or recoverable operating path, that one project may be the larger business failure. Use the table to preserve what each number actually counts.

Why AI project failure rates disagree

The denominator changes first. A percentage of organizations is not a percentage of projects. An average share reported by each organization is not the same as pooling every project. A survey of leaders already investing in AI does not represent every business. An analyst’s project set may differ from a probability sample. Before quoting a figure, name who or what was counted.

The finish line also changes. A proof of concept may only test whether a model can perform a task on selected examples. Production means the system performs real work, but may cover one team or a small volume. Broad adoption asks whether the organization expanded the system. Enterprise impact asks whether respondents observed a strong objective-level result. A project can cross one threshold and miss the next.

Finally, “failed” can describe a technical fault, a commercial decision, an operational breakdown, or an outcome that never appeared. The word may include a prototype stopped because it was infeasible, a working demo that could not access production data, a deployed tool that employees did not use, or a system that saved time without producing financial value. Those events require different fixes.

A practical failure taxonomy

• Problem failure. The team selected a vague, low-value, or unsuitable job. There is no accepted destination outcome or named person who owns it.
• Evidence failure. The proof of concept uses handpicked examples, model scores, or draft speed instead of representative cases and accepted business results.
• Data failure. Sources are incomplete, stale, inaccessible, weakly identified, or not permitted for the intended use.
• Integration failure. The model produces a plausible answer, but identity, permissions, provider limits, destination write paths, and read-back are unverified.
• Control failure. The system can take actions outside its authority, cannot handle sensitive cases, or lacks human review where consequence requires it.
• Operating failure. Exceptions, provider outages, duplicate execution, correction, reconciliation, incidents, monitoring, and ownership after launch were omitted.
• Economic failure. Review, usage, integration, support, correction, and exit costs exceed attributable value.
• Adoption failure. The system does not fit the real work, makes users slower, or lacks a trusted path to contest and correct its output.

What Gartner’s 30%, 50%, and 60% figures mean

Gartner’s July 2024 newsroom release predicted that at least 30% of generative-AI projects would be abandoned after proof of concept by the end of 2025. It named poor data quality, inadequate risk controls, escalating costs, and unclear business value. The release also described a separate survey of 822 business leaders, but it did not present those leaders as the project denominator for the 30% forecast. Read the 2024 Gartner release.

A 2026 Gartner article says at least 50% of generative-AI projects had been abandoned after proof of concept by the end of 2025. Gartner says it analyzed hundreds of projects and organizes the causes around business value, data, total cost, responsible AI, and model performance. The public article does not provide the exact sample, selection frame, or formula, so the figure is useful as an analyst finding—not a universal probability for a buyer’s next project. See the 2026 Gartner analysis.

The 60% figure is narrower. Gartner predicted that through 2026, organizations would abandon 60% of AI projects not supported by AI-ready data. The condition belongs in the sentence. Its related survey covered 1,203 data-management leaders, 63% of whom said their organizations lacked or were unsure they had the right data-management practices for AI. The AI-ready data release supports a data-readiness warning, not the claim that 60% of all AI projects fail.

A separate Gartner abstract reports that an average 41% of generative-AI prototypes and 42% of non-generative-AI prototypes reached production in its 2024 survey. That comparison suggests the prototype-to-production gap is not unique to generative AI. The public research abstract does not disclose the sample or production definition, and a prototype stopped on evidence is not automatically a failed investment.

What S&P Global’s 1,006-person survey observed

S&P Global Market Intelligence surveyed 1,006 mid-level and senior IT and line-of-business respondents in North America and Europe. It reported that 42% of companies had abandoned the majority of their AI initiatives before production, up from 17% in the prior year. That is a percentage of companies making an organization-level report. It is not evidence that 42% of all projects failed.

The same S&P Global analysis says the average organization scrapped 46% of projects between proof of concept and broad adoption. Among organizations actively investing in generative AI, 46% of respondents reported no strong positive impact for any enterprise objective. These two 46% figures have different denominators and outcomes. One is an average project share; the other is a respondent share reporting no strong objective-level impact.

S&P also reported 27% organization-wide production adoption and 33% limited department or project adoption among organizations actively investing in generative AI. A limited production release can be a sensible control stage. Treating it as a failure simply because it is not organization-wide would reward premature expansion.

What RAND actually found about why AI projects fail

RAND interviewed 65 experienced AI practitioners from industry and academia. The report’s core contribution is qualitative: it organizes recurring causes from practitioner experience. It says more than 80% of AI projects fail “by some estimates,” with a footnote to a 2022 Fortune article. That article describes surveys as placing failure between 83% and 92% but does not name or link them. RAND did not calculate that rate from its interviews or from a project sample. Calling it “RAND’s 80% failure rate” overstates the evidence.

RAND did calculate that 84% of its industry interviewees cited one or more leadership-driven reasons among the primary causes of project failure. That 84% is about coded interview responses, not the share of projects that failed. The report identifies five recurring causes: stakeholders misunderstand or miscommunicate the problem; required data are missing; leaders chase new technology rather than the problem; infrastructure is inadequate; and the task is technically infeasible. Read the full RAND report.

RAND also excludes projects that merely prompt a pretrained large language model. That scope matters when applying the findings to modern copilots or hosted chat tools. The leadership themes remain useful for planning, but the interview evidence should not be presented as a probability model for every type of AI implementation.

Why the 95% claim is not in the normalized table

A claim that 95% of enterprise generative-AI pilots fail has spread through news and social posts. We found a hosted document associated with the claim, but not enough public methodology to normalize its population, sampling frame, unit of analysis, success threshold, and calculation alongside the records above. Repetition is not a substitute for a usable denominator. The claim is excluded from the dataset until those elements can be checked from the originating research.

How to reduce avoidable AI project failure

Start with an acceptance contract before selecting a model or platform. The contract should make it possible to stop a weak project early and distinguish a useful stop from a preventable breakdown. It should cover the following decisions.

1. Name one eligible workflow. Define its trigger, exclusions, current path, completed unit, destination system, volume, exception classes, and accountable owner.
2. Set a baseline and target. Record accepted completion, time, errors, rework, waits, escalation, operating cost, and the downstream business outcome over a representative period.
3. Prove the sources. Verify access, identity, freshness, provenance, permissions, conflict rules, retention, correction, and what happens when required data are absent.
4. Choose the simplest architecture that passes. Compare manual improvement, deterministic automation, model-assisted work, and agent action. Do not add autonomy when a rule or approval is enough.
5. Define authority outside the model. State allowed actions, denied actions, records, destinations, value limits, credentials, approval conditions, and read-back requirements.
6. Build representative evaluations. Include normal, difficult, ambiguous, missing-data, stale-data, abuse, privacy, security, accessibility, provider-failure, duplicate, correction, and recovery cases.
7. Release in a bounded mode. Use shadow, draft, approval-required, limited-volume, or limited-population operation until accepted results and failure behavior meet the written threshold.
8. Measure the full outcome. Count confirmed destination results, correction, human review, failures, provider cost, support, incidents, and attributable customer or financial outcomes.
9. Assign post-launch ownership. Name who watches queues and alerts, reviews drift, handles incidents, approves changes, reconciles external systems, and can pause or roll back.
10. Write the stop rule. State in advance which evidence leads to expand, revise, contain, or retire. A credible stop rule protects capital and makes experimentation more useful.

Use the AI readiness assessment to score outcome, ownership, data, identity, authority, integration, evaluations, operations, and economics. The AI implementation cost guide shows which build and operating costs belong in a proposal. For observed gains and slowdowns on specific tasks, compare the AI productivity statistics dataset.

Questions to ask an AI vendor

• What completed business outcome is the release responsible for, and where is that outcome confirmed?
• Which cases are included, excluded, denied, or handed to a person?
• What customer accounts, data, credentials, prompts, configurations, code, logs, and exports does the buyer own?
• Which evidence proves the production integration and tenant—not a demo—can read and write the intended records?
• How are model error, provider outage, partial execution, duplicates, corrections, privacy requests, incidents, and rollback handled?
• What acceptance cases must pass, what metric must improve, and what result causes the project to stop?
• What is the first-year total cost, including usage, review, correction, monitoring, support, retraining, changes, and exit?

Method, exclusions, and open data

Cognautic researched current search results for AI project failure-rate questions, opened the originating institutional pages or report, and recorded each figure with its statistic, value, unit, evidence type, population, period, sample, definition, source, limitation, and check date. Forecasts, survey findings, analyst findings, secondary estimates, and qualitative interview coding remain separate.

We do not average these percentages, reverse prototype-to-production rates into an invented failure rate, turn a percentage of companies into a percentage of projects, or treat failure to reach broad adoption as failure to reach any production. We also do not count the RAND-cited estimate as RAND’s own measurement. Values and public source details were last checked August 17, 2026. Publishers may revise pages or disclose additional methods later.

The normalized compilation is available under CC BY 4.0. Cite the original publisher for an underlying claim and Cognautic for the compilation. Preserve the evidence type, population, definition, and limitation beside a number. Report a correction through the contact page; our content standards explain sourcing, review, updates, disclosures, and corrections.

From failure-rate research to a controlled project

A failure statistic cannot decide whether your workflow should use AI. Cognautic’s AI consulting service maps the workflow, baseline, sources, risk boundary, implementation choice, accepted outcome, evaluation set, operating owner, and written stop rule before a production commitment. For systems that may take actions, the AI agent development service defines identity, permissions, approvals, confirmations, monitoring, and recovery. Review AI agent security and the AI agent observability plan before giving a model production authority.