The stat you keep seeing is close to true. RAND's 2024 study of AI project failures put it above 80%, and MIT's NANDA group reported that 95% of enterprise generative AI pilots produce no measurable business impact. So "85%" is a fair round number for the headlines.
The interesting question isn't whether the stat is right. It's why. The failure modes I see when I get called into these projects aren't the exotic ones (model drift, GPU costs, regulatory shutdown). They're boring, and they repeat.
Here's what kills these projects, in the order I see it happen.
The problem was never a prompt problem
The most common failure I get called in to fix looks like this: a team built an AI feature, it worked in a demo, it broke in production, and someone said "the prompt needs tweaking".
A staffing SaaS client hired me because their AI agent took over a minute to respond and returned a malformed-JSON error about one time in ten. The client wanted me to fix the prompt. But the prompt was fine. One agent was trying to do six things at once, so any one thing going wrong took the whole response down. I split it into a team of smaller agents running in parallel. Response times dropped to five to seven seconds and the reliability issue went away.
If your first move on every AI bug is "let me tweak the wording", you're a junior. If it's "let's find the root cause and add a regression test that reproduces it", you're an engineer. The 85% number is mostly full of the first group.
Nobody defined what "working" means
RAND's summary of their interviews was blunt: leaders and technical teams never agree on the problem, so success is undefined. I see the same thing at small-firm scale.
Ove André Remme, the founder of a Norwegian therapy training company, hired another Upwork freelancer with 20+ five-star reviews before he hired me. That freelancer spent two weeks building a Custom GPT to generate course lessons in Norwegian. It produced 40% less content than needed, and when Ove asked for more, it made up filler. The freelancer had shipped what he was asked to build. But nobody had defined what "generates a real course lesson" meant, and a Custom GPT wasn't the right kind of tool for the job anyway.
I told Ove that on the first call, which sounded cocky at the time. He came back later. In his testimonial he says "You were directly pointing to the issue that I experienced." We built something else and the output quality was, in his words, perfect.
The pattern: if you can't write down what "working" looks like in one paragraph, with a concrete example of good output and bad output, don't start building yet.
The data isn't ready and nobody wants to fix it
Data problems are boring. Nobody wants to work on them. So teams jump into building an AI agent on top of a CRM where half the fields are inconsistent, contacts are duplicated, and there's no reliable source of truth for what a "customer" even is.
Then the AI hallucinates because it's reading garbage in, and the team blames the model.
I saw this at a recruitment AI startup client where the internal team, with no AI experience, had wired an analytics agent directly to the production database through a LangChain SQL library. Table-level access wasn't set up. Row-level access wasn't set up. There were maybe five or six real use cases that needed to be supported. Wiring an LLM to production SQL for that handful of cases isn't flexibility, and when the LLM writes the wrong query someone loses data. I replaced it with hardcoded parametrized queries behind tool calls, which meant fewer AI moving parts and a lot less to go wrong.
If your data is a mess, the AI project is a data project first. Skipping that step is the biggest reason pilots don't reach production.
The team picked technology before picking the outcome
A CEO of an Oslo-based real-estate developer I spoke with recently described his setup like this: they were using Copilot, ChatGPT, and Notion AI all the time, but nothing was connected, so people would ask the AI to do something, copy the output, paste it somewhere else, and then do another thing there. Every person on the team had a subscription. Nothing was integrated. The finance lead couldn't produce a cash flow report from Tripletex because the tools he'd bought didn't talk to each other.
That's what toolsmaxxing without a plan looks like. I wrote a whole piece on toolsmaxxing because for a lot of small firms it's the right first move, but only when it's anchored to a specific outcome. "We want to see project margin monthly instead of at year-end" is an outcome. "We want to use AI more" isn't.
The build shipped, but nothing catches it when it breaks
Almost every failed AI project I've inherited had no evaluation. No test suite. No monitoring. Nothing that would tell you, on Tuesday morning, that yesterday's Claude model update made your customer-facing agent 15% dumber for one specific type of question.
At Sellify AI, where I spent two years building CRM-integrated AI sales systems for pest control, we treated evals as a first-class thing. When the AI hallucinated on a scenario, the fix wasn't a prompt tweak - it was to write an automated evaluation that runs on GitHub CI with the real model, reproduces the exact scenario, fails without the fix, and passes with it. Then ship the fix. Ivan Nikolaichuk, Sellify's technical co-founder, put it this way in his LinkedIn recommendation: "Vlad knows his craft well and was able to handle complex engineering tasks independently." Doing this discipline in a fast-moving startup isn't glamorous, but it's why the systems kept working while competitors were still doing "human in the loop" for anything complex.
If your AI vendor can't answer "how would we know this stopped working?", the project is already on the failure track.
The scope grew the moment the demo worked
I've watched this pattern kill more small-firm AI projects than any technical issue.
The pilot works on a small case. The founder gets excited. Suddenly the ask is: can it also do X? and Y? and can we plug it into Z? Meanwhile the pilot was never hardened for its original job. Six months in, the thing is a Frankenstein of half-finished features and no owner.
A founder I spoke with recently described her dream as having a builder to keep shipping interesting projects with, one after another. That's the right instinct for a long relationship with a builder, and the wrong instinct for a single project. Pick one thing, make it boringly reliable, then start the next one.
People trust the demo more than they trust the reality
Modern LLM demos are convincing. Founders watch a 90-second Loom of an agent doing something impressive and start budgeting like it's going to work on day one at 100% reliability.
Real AI systems degrade in ways non-technical buyers don't expect. Model providers push updates that change behavior. APIs rate-limit or slow down at random. Context windows overflow. I heard a story recently about a person whose inbox got wiped by an AI they'd given write access to. It worked for weeks on small cases, then at some point the context overflowed, the AI got confused, and it cleared the whole inbox.
The trade-off is real: the more access you give the AI, the more it can do for you, and the more damage it can do when something goes wrong. Buyers who don't understand that go into projects with the wrong expectations and the wrong guardrails.
Firms that don't join the 85%
Every AI project I've shipped that stayed shipped had the same handful of properties. They're not exotic:
- One outcome defined in one sentence, with a concrete example of good and bad output.
- A data layer that isn't a hallucination waiting to happen.
- An architecture with the right number of moving pieces for the job. Not one big agent doing everything, and not a microservice per prompt.
- Guardrails that go beyond regex. LLM-as-a-judge (a small, fast model checking the main model's output) is the version I reach for most.
- Automated evals that run on CI and reproduce every past failure.
- A human in the loop where cost of error is high, and no human in the loop where speed matters more than a 1% quality delta.
- A single owner who cares whether it works next month.
That list isn't a build vs. buy question. It applies whether you're using Claude Business, hiring an AI consultant, or writing a custom pipeline. And most of it maps onto what separates AI consulting that pays back from AI consulting that doesn't.
What to do if you're about to start one
Pick one workflow. Not a category, not a strategy - one workflow. "Draft the first version of our client status report on Friday afternoon from our project data, so I can edit it instead of writing it from scratch" is a workflow. "Add AI to our operations" isn't.
Write the outcome, a good-output example, and a bad-output example in a Google Doc that fits on one page. If you can't, the project isn't ready.
Then ask, in this order: can we do this with a tool we already pay for (Notion AI, ChatGPT Business, Copilot in the tool that owns the data)? If not, is there a boring SaaS that already solves it? If not, is it worth the money to build custom?
Custom is the right answer more often than most vendors will tell you, and less often than most technical founders assume. The reader who thinks their problem needs a custom AI build is usually 60% right about the problem and 30% right about the solution.
If you want a second pair of eyes on which bucket your project sits in, or you've already burned a budget on one that didn't ship and you want to understand why, that's exactly the conversation I run.
FAQ
Why do 85% of AI projects fail?
The headline number comes from RAND's 2024 study, which put the failure rate above 80% - roughly twice the failure rate of non-AI IT projects. MIT's NANDA group found 95% of generative AI pilots produce no measurable business impact. The root causes are almost always the same handful: nobody defined what "working" means, the data wasn't ready, teams picked technology before outcomes, there were no automated evaluations to catch regressions, and scope grew before the first version was hardened.
Is the 85% failure rate really about AI or about IT projects in general?
Both, but AI is worse. Most IT projects fail for the same organizational reasons - unclear scope, weak sponsorship, bad data. AI projects add a few unique failure modes on top: model non-determinism means the same input can produce different outputs, model providers push updates that silently change behavior, and non-technical buyers set unrealistic expectations from watching demos.
What's the number-one reason small business AI projects fail?
For small B2B firms the top killer is skipping the "define what working looks like" step. Owners describe the business problem in one paragraph, a builder ships something reasonable, and the outputs turn out to be 40% short of what was needed because "good enough" was never written down. The second most common killer is building on top of messy CRM data and blaming the model when it hallucinates.
Can AI projects fail because of the model itself?
Rarely. Modern frontier models from Claude, OpenAI, and Google are strong enough for almost any small-business workflow. When a project fails, the cause is usually architecture (one agent doing too much), data (garbage inputs), scope (the pilot never got hardened), or evaluation (nothing catches regressions). "The model isn't smart enough" is a real answer maybe one project in ten.
How do I avoid becoming part of the 85%?
Pick one workflow, not a strategy. Write down the outcome and a concrete example of good and bad output before writing a line of code or signing a vendor. Do the data cleanup work even though it's boring. Insist on automated evaluations that run in CI. Give the project a single owner who cares whether it still works in three months. If your vendor can't answer "how would we know this stopped working?", find a different vendor.
