Most AI projects that disappoint don’t fail because the technology stopped working. They go wrong earlier: in the brief, the contract or the conversation nobody had about what success looks like. A post-mortem finds out which, so the next project doesn’t repeat it.
We build AI integrations through our AI integration service, so weigh that. Every fact below about RAND’s research, the NIST AI Risk Management Framework, Google’s postmortem practice and Anthropic’s model lifecycle was checked against their own publications in October 2026.
Short answer: The most common cause of AI project failure is a misunderstood problem, not a weak model. RAND interviewed 65 experienced practitioners and found five root causes: the wrong problem, missing data, chasing technology over users, weak infrastructure, and problems too hard for AI. Keep the post-mortem blameless: look for causes in the process, not the people. Compare results with success criteria written before the build, check the tool was used, and give each follow-up an owner. If nobody wrote success criteria, that is your first finding.
What the Research and the Standards Say
As of October 2026, from RAND, NIST, Google and Anthropic:
| Source | What it says |
|---|---|
| RAND, Aug 2024 | Five root causes, from 65 interviews |
| RAND | Misunderstood purpose is the most common cause |
| RAND | Cites estimates that over 80% of AI projects fail |
| NIST AI RMF 1.0 | Four functions: govern, map, measure, manage |
| NIST, Measure 2.4 | Monitor the system while in production |
| NIST, Manage 4.1 | Post-launch monitoring plans, incl. change management |
| Google SRE book | Postmortems are blameless and reviewed |
| Claude model IDs | Pinned snapshots; at least 60 days’ retirement notice |
Sources: RAND report RR-A2680-1, NIST AI RMF, AI RMF Core, Google SRE: Postmortem Culture, Claude models overview, Claude model deprecations.
What the Headline Numbers Measure
The Failure-Rate Figure: What It Actually Measures
One figure you will often see comes from a RAND report, “The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed”, published in August 2024. Read it closely. RAND writes that “by some estimates, more than 80 percent of AI projects fail”, twice the rate of IT projects without AI (source). That is an estimate RAND cites, not a rate it measured.
What RAND measured itself was qualitative: interviews with 65 data scientists and engineers, each with at least five years of experience building AI models (source). The value is the list of causes, not the headline number. Studies define “failure” differently, so treat any single rate as a rough signal.
When AI Spend Became a Budget Line Item
AI spending figures are easy to find and hard to check. Money spent is a procurement number, not a result. A budget line shows a decision was made, not whether anyone defined what it should produce. A post-mortem asks the second question.
The Six Failure Patterns That Keep Repeating
Pattern 1: The Problem Was Never Actually Defined
“Use AI to improve customer experience” is a direction, not a problem. RAND found that misunderstandings and miscommunication about the intent and purpose of a project are the most common reasons for AI project failure. Models get deployed that are optimized for the wrong metrics or don’t fit the business workflow (source).
Projects built on directional briefs have no agreed benchmark to succeed or fail against, often because the brief was written by people who won’t use the output. RAND’s fix is making sure technical staff understand the purpose and domain. NIST’s Map function asks for the intended purpose, users and business value to be documented (source).
Pattern 2: The Data Foundation Was Not Ready
RAND’s second root cause is lacking the data to train an effective model. Its fourth is inadequate infrastructure to manage data and deploy models (source).
The pattern is familiar. The CRM and support tickets are handed over without an audit. Records are incomplete, inconsistent or duplicated, and the outputs show it mid-build, when it costs most. RAND recommends investing in data governance and deployment infrastructure up front. A data audit at scoping is the small-business version.
Pattern 3: Sponsorship Faded After Launch
A named sponsor at kickoff isn’t a sponsor who stays. By the first messy integration phase, attention is often elsewhere. Nobody escalates blockers, and the project drifts: still live, producing nothing anyone looks at.
RAND’s advice: choose enduring problems, and be ready to commit a team to one specific problem for at least a year. If it isn’t worth that, it isn’t worth starting (source). NIST asks for documented roles and lines of communication for AI risks (Govern 2.1) (source). Write the sponsor’s role down, with a review date.
Pattern 4: The Model Drifted With No One Watching
Output quality slips when production inputs move away from what the system was built and tested on: new products, new customer language, changed upstream fields. On a hosted model, the model itself may not change, since every Claude model ID is a pinned snapshot (source). Your data and prompts change, and eventually the model’s availability does. Anthropic retires older models, gives at least 60 days’ notice for publicly released ones, and requests to a retired model fail (source).
If nobody owns monitoring after launch, nobody notices. NIST says to monitor the system in production (Measure 2.4) and to monitor pre-trained models as part of regular maintenance (Manage 3.2) (source). Agree who does it, and how often, before the build ends.
Pattern 5: Change Management Was Underfunded
We know of no reliable figure for how AI projects fund change management, so we won’t give one. The pattern is easy to spot anyway: the build gets the budget, and changing how people work gets a training session.
Change management means rewriting workflows and making the tool the obvious path, not an extra step. NIST puts it inside post-deployment monitoring plans, next to user input, override and incident response (Manage 4.1) (source). Skip it and the team routes around the tool the first time it causes friction.
Pattern 6: Success Metrics Were Never Defined
Vague metrics are sometimes a choice. “Improve efficiency” feels safer to write than a number both sides could miss. It protects nobody: when the project underdelivers, there is nothing to measure against.
Anthropic’s evaluation guidance says good success criteria are specific, measurable, achievable and relevant, and tests should mirror the real task, edge cases included (source). In practice: time per document from X to Y, error rate from X to Y, measured on your own real inputs. If the contract has no numbers, agree them before you sign.
Why Post-Mortems Fail Too
The Blame-the-Data Reflex
When an AI project fails, “data quality” is the default explanation. It is often partly true, and it skips the decisions behind it: no audit at scoping, no readiness standard, no funded cleanup.
Google’s SRE book describes a better habit. A blameless postmortem focuses on contributing causes without indicting any individual or team, and assumes people acted in good faith (source). Blameless doesn’t mean vague. The write-up names the decisions, not the culprits.
Ownership Ends Before the Write-Up
Post-mortems need an honest facilitator, and the people closest to the project are often those whose judgment it reflects. The builder may be gone, the champion moved on.
What gets written is the comfortable version: “scope was challenging”, “integration complexity”. What doesn’t: the success criteria never agreed, the data audit skipped to hit a date. Google’s answer is review: drafts are checked for completeness, including whether the root cause went deep enough and the action plan fits. In its words, “an unreviewed postmortem might as well never have existed” (source).
Running an Honest AI Post-Mortem (Even If You’re Not Technical)
Google defines a postmortem as a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions to prevent recurrence (source). It works for a whole AI project too.
The Five Questions Every Post-Mortem Must Answer
You don’t need technical depth to answer these:
- What specific outcome was the project supposed to produce, and who agreed to that in writing? If the answer is unclear, the failure started at the contract.
- What did the system actually produce, in the same units as the success criteria? If nobody was measuring, the failure continued through the run.
- Who held the build to its deliverables, and by what mechanism? A good relationship is not an accountability mechanism.
- Did the team actually use the tool? How often? What made them stop or work around it? Usage tells you more than status reports.
- What would have to be true for the next project to succeed? “Better data” or “more budget” without specifics changes nothing.
Turn each answer into an action with an owner and a date.
What to Document Before the Vendor Contract Ends
Much of what is known about an AI system sits with whoever built it: architecture decisions, prompts and data logic, known edge cases. When the engagement closes, that knowledge leaves unless it is written down.
Before sign-off, get in writing:
- what the system does, and what it doesn’t do
- why the main design decisions were made
- which inputs it handles badly
- which model and version it runs on, and when that model retires
- what monitoring it needs, and who does it
NIST also asks for a safe way to decommission AI systems (Govern 1.7) (source), so add the off switch. If any of this is hard to get, that is a finding.
For a structured approach to this kind of work, see designodin.com/ai.
Related Posts
- How to scope an AI project so it doesn’t fail: the problem definition that prevents Pattern 1
- Change management for AI tools: why adoption fails after launch
- AI model updates and your integration: what happens when the model changes
- How to monitor an AI automation after launch: spotting degradation early
Frequently Asked Questions
What is the AI project failure rate?
There’s no single reliable figure. RAND’s 2024 report cites estimates that more than 80% of AI projects fail, but it quotes that estimate rather than measuring it. Its own research was 65 practitioner interviews. A better question is whether your project has defined success criteria.
What are the most common reasons AI projects fail?
RAND lists five root causes: a misunderstood or miscommunicated problem, not enough data to train an effective model, a focus on the latest technology over users’ real problems, inadequate data and deployment infrastructure, and problems too hard for AI to solve. It names the first as the most common. Missing success criteria and no owner after launch make each of them harder to catch.
How do you run a post-mortem on a failed AI project without a technical team?
Keep it blameless and answer five questions: was the outcome defined in writing, were results measured in the same units, who held the build accountable, did the team use the tool, and what must change next time. Have someone outside the project review it, then give each finding an owner.
What is model drift and why does it cause AI projects to fail after launch?
Drift is when output quality slips because production inputs move away from what the system was tested on. Claude model IDs are pinned snapshots, so the bigger risks are changing inputs, edited prompts and retirement. NIST says to monitor AI systems in production. Without that, quality slips quietly and trust goes with it.
How can you evaluate an AI vendor before the project starts to reduce failure risk?
Ask for success criteria in numbers, tested on your own data. Ask when the work counts as finished, what monitoring continues after launch and how model retirements are handled. Ask for evidence from projects well past launch, not just the first weeks. For a direct read on your setup before you commit, tell us what you’re working on and we’ll be honest about what we see.
Why do AI project failures go undocumented?
Because the people closest to the project are often those whose decisions it reflects, and an honest record can feel like blame. Google’s SRE practice answers this with blameless postmortems: focus on causes, assume good intent, review every draft. People who don’t fear punishment bring problems to light.
The Same Movie, Again
RAND published its root causes in 2024, and most are about people and process, not the model. Post-mortems written to protect reputations don’t change the next project, so the patterns come back.
If your last AI project failed, the useful question isn’t what went wrong technically. It’s what would have to be true for the next one to succeed, and which of those decisions you control. Answer that with owners and dates, and the post-mortem worked.