# Why AI Projects Fail: The Nine Things a Demo Skips

*Most AI projects fail between the demo and the live system. No one put a dollar figure on the problem. And no one built the nine things a live system needs to survive real users and an auditor.*

By Cameron Sullivan, Founder & CEO, Techify AI · 15 October 2026 · 9 min read

> **Key takeaways**
>
> - RAND talked to 65 data scientists and engineers, each with years of hands-on work. They found five root causes of AI project failure. The most common: leaders misread the problem the AI should solve, or explain it badly.
> - Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027. Its reasons are rising costs, unclear business value or weak risk controls.
> - IBM asked 2,000 CEOs in 2025. Only 25% of their AI projects had paid back what was hoped. Only 16% had scaled firm-wide.
> - A demo has to work once. A live system has to work every day. Nine things sit between the two. That gap is The Demo Gap.
> - Four of RAND's five root causes are set before anyone writes a line of code. Most failed projects were failing on the day they were approved.

AI projects fail for plain reasons. The model is seldom one of them. Most die in one of two places.

The first is before the build. No one wrote down what the system had to change, in dollars. So no one can say if it worked.

The second is after the demo. A demo works once, on clean data, in front of a friendly room. Then it gets treated as a system. But the parts a real system needs never get built. Those are the parts that let it survive real users, real data and an auditor.

That second failure has a shape. I call it The Demo Gap, and it is made of nine things. First, below: how often AI projects fail, and the five root causes RAND found. Then the nine things, and what failure looks like from the inside. Last come six questions. They tell you if a project you own is headed the same way.

## How many AI projects fail?

It depends on how you count. People quote four numbers, and each one measures its own thing.

- **Gartner** expects over 40% of agentic AI projects to be scrapped by the end of 2027. Agentic AI is AI that takes steps on its own, not just answers. Gartner's reasons: rising costs, unclear business value or weak risk controls.
- **MIT NANDA** looked at generative AI pilots at large firms. That is the kind of AI that writes text or makes images. Only about 5% made a fast gain in revenue that could be measured, it reported. The bar is narrow. The pilot has to scale up and move a money number months later. It is also the bar your CFO uses.
- **IBM's 2025 CEO Study** asked 2,000 CEOs in 33 countries. Only 25% of their AI projects had earned the ROI they expected over the last few years. ROI is what you get back for what you spend. Just 16% had scaled firm-wide.
- **RAND** cites estimates that more than 80% of AI projects fail. That is about twice the rate of IT projects without AI. RAND quotes that estimate. It did not measure it.

Four bars, one pattern. Getting a model to answer a question is the cheap part. The money goes missing between an answer and a system.

## The five root causes of AI project failure

RAND is a U.S. research group. It talked to 65 data scientists and engineers. Each had at least five years of building AI and machine learning models. They named five leading root causes. Here they are in RAND's order, with how each one looks inside a mid-sized business.

1. **The problem is misread, or explained badly.** This is the most common cause. Someone asks for "a chatbot" or "an agent". No one writes down what it must change. So the model gets tuned to the wrong number, or built for a workflow no one follows.
2. **The data isn't there.** RAND means the data to train a model that works. For most business systems today, the data exists. It sits in a CRM, an inbox, a shared drive and two people's heads. No one priced the work of getting it into one place.
3. **The tech comes before the problem.** The project starts from the newest model or tool, then goes looking for work. RAND says this is one of the most common ways to fail.
4. **The infrastructure can't carry it.** That means the plumbing under the model. There is no way to manage the data, put the model live or watch it run. Most of the nine rows below live here.
5. **The problem is too hard for AI.** Some tasks can't be done by any model you can buy. Finding that out after the build is the costly way.

Look at when each one is decided. Four are set when the project is approved, before anyone writes code. They are the problem, the data plan, the tech and how hard the task is. Only the infrastructure is decided during the build. Even that is mostly decided by what the scope left out. Each one stays hidden until much later, and it costs money the whole time.

RAND's fix for the first cause is blunt. Commit a team to one problem for at least a year. If a project isn't worth that, RAND says, "it most likely is not worth committing to at all." A price on the problem tells you if it is worth a year. The method is in [how to find AI use cases](/insights/how-to-find-ai-use-cases). The math is in [how to calculate AI ROI](/insights/how-to-calculate-ai-roi).

## The Demo Gap: nine things a demo is allowed to skip

A demo has one job: to make a room say yes. So it is allowed to work once. It can run on clean data, for a friendly crowd. The person who built it can stand right next to it.

A live system has a harder job. It has to work every day, on messy data, for people who never met the builder. And an auditor may ask it anything. The Demo Gap is the distance between those two jobs. Nine things fill it.

| # | The thing | What the demo does | What production needs |
|---|---|---|---|
| 1 | Access | One user sees everything. The login is for show. | The database itself decides which rows each person may see, on every query. A bug in a screen can't leak another customer's file. |
| 2 | Audit trail | An answer appears. | Every value it pulls out is stored with its source document, page and a snippet of proof. People approve where it matters. |
| 3 | Evaluation set | Three questions, picked by the person giving the demo. No one picks the one that fails. | A fixed set of real cases with known right answers, run before every change. So "better" is a number. |
| 4 | Fallback providers | One model, one provider, working today. | A main provider plus backups, so one provider's bad afternoon is not yours. |
| 5 | Cost controls | Ten queries a day. No one checks the bill. | Each job goes to the cheapest model that can do it. Repeated prompts are cached. Budget alarms and circuit breakers stop a runaway loop. |
| 6 | Monitoring | The builder watches it. | Every model call is traced (OpenTelemetry, Langfuse), so a problem shows up before a customer finds it. |
| 7 | Handover | It lives in the builder's head. | Documents, SOPs and training for your people, listed as deliverables. |
| 8 | Acceptance criteria | "It looks great." | Win conditions written before the build: what it must do, in yes-or-no terms, to count as done. |
| 9 | Ownership | It runs on the builder's accounts. | Your cloud, your code repository, your hosting, from day 0. The code and the IP are yours. |

Read the table against Gartner's three reasons. Rising costs live in row 5. Unclear business value lives in rows 3 and 8. Weak risk controls live in rows 1, 2, 4 and 6. Rows 7 and 9 decide something else: whether the system outlives the team that built it.

Row 5 is the one with a price on it. Take the systems in our builds that handle 1,000+ AI interactions a day. Their model costs tend to run $200 to $1,200 a month, all in. That is because each job goes to the cheapest model that can do it. Without row 5, the bill has no ceiling. And the day finance first sees it is the day someone asks if the project should exist.

Row 2 can be the reason a system exists at all. We built a research copilot for a capital-markets publisher. It is an AI helper for the research team. Every answer carries its citation, the source it came from. A compliance disclaimer is added to every output. So the system can't put out an answer that breaks the rules.

## What month four looks like without rows 1 to 3

A composite, not a client. It is drawn from many projects.

The pilot has been live for the sales team for a few weeks. A sales director asks it for the renewal terms on a contract. It answers smoothly. But the terms it gives are from the wrong buyer's contract. No one notices. Then the customer does.

The CFO asks two questions. Which document did that answer come from? Who else could have seen it?

The team opens the logs. There is a transcript. There is no source document and no page number. There is no record of who was allowed to see what. There is no test set either. So no one can say if last week's change made things better or worse.

You switch it off on a Thursday and call it a "pause".

## Can a prototype become the production system?

Seldom, and it shouldn't try. Keep the prototype, though. A weekend build is the cheapest spec you will ever write. It shows what you want. It proves the idea can work on your cases.

What it can't prove is the nine rows. Vibe coding a dashboard is one thing. (Vibe coding means asking an AI to write the code and taking what it gives you.) Working out what it needs to run at production scale is another. Some code is written to be thrown away. Bolting access rules, tracing and tests onto it most often costs more. It is cheaper to write it again with them in the plan.

So let the prototype answer its question. Then build the real thing once, with the nine rows in the scope, and retire the prototype.

## How to tell if your AI project is going to fail

Here are six questions for any AI project you own, fund or are about to approve. Each one names the proof that answers it. A screen, a document or a live run counts. "We do that" doesn't.

1. **Access.** Does the database itself stop each user from reading data that isn't theirs, on every query? The app screen doesn't count. Ask to see the access rules. Then ask to see a failed try at reading a row you shouldn't.
2. **Trace.** Pick any answer from last week. Can the team show the source document, the page and the model call behind it, in five minutes?
3. **Test.** Is there a fixed set of real cases with known right answers? Does it run before every change? Ask for the set, and the score from the last change.
4. **Fail.** Say the main model provider goes down at 9 a.m. What happens? And what stops the monthly bill from running away? Ask for the fallback provider and the budget alarm.
5. **Done.** Is "done" written in the contract as yes/no tests a stranger could check? Is there a date for each phase?
6. **Keys.** Do the cloud accounts and the code live in your name? Could a new team take over from the docs?

Access and keys outrank the other four. They decide who can see your data, and who can take the system away from you. A project missing either one shouldn't hold customer data, even if it gets the rest right.

## How to make an AI project succeed

Turn RAND's five causes around and you get the order of work.

1. **Price the problem first.** Name one constraint (the one thing holding the business back). Write down what it costs each month, and the number the system must move. If that isn't worth a year of a team's time, stop here.
2. **Check that it is an AI problem.** Some constraints are a price, a hire or a form that should be deleted. A process change costs nothing to build.
3. **Prove the hard part on your own cases.** Run a small pilot with one written question and a date. The question: can a model do this task right, on our real data?
4. **Write "done" before the build.** Set win conditions in yes/no terms, phase by phase. Each phase is accepted before the next one starts.
5. **Build the nine rows in from the start.** Use accounts you own, and list the handover in the scope.

## When not to build it: pilots that should stay pilots

Some pilots should never become systems. If all five of these are true, don't pay for the nine rows:

- It touches no customer data.
- No money moves because of it.
- A small group uses it, and you know their names.
- It has one written question to answer, and a date to answer it by.
- You would shrug if it vanished tomorrow.

Let it answer its question. If the answer is yes, build the real thing once. If it is no, you spent a small amount to learn something. That is what a pilot is for.

## FAQ

### What percentage of AI projects fail?

There is no single figure, because each study sets its own bar. RAND cites estimates that more than 80% of AI projects fail. That is about twice the rate of other IT projects. MIT NANDA looked at generative AI pilots at large firms. Only about 5% made a fast gain in revenue that could be measured. In IBM's 2025 CEO Study, 25% of AI projects had earned the ROI expected. Gartner predicts over 40% of agentic AI projects will be scrapped by the end of 2027.

### What is the most common reason AI projects fail?

Leaders misread the problem the AI should solve, or explain it badly. RAND talked to 65 seasoned data scientists and engineers. This was the most common root cause they found. In real life, someone asks for "a chatbot". No one writes down what it must change. So the model is tuned to the wrong number, and no one can say if it worked.

### What is the difference between an AI prototype and a production system?

Nine things. A live system has access rules, an audit trail and a test set. It has fallback providers, cost controls and monitoring. And it has a handover, acceptance criteria and an owner. A prototype has to work once, for a friendly room. A production system has to work every day, for every user, on messy data. And an auditor may ask it anything.

### How long should an AI pilot run?

Until it answers one written question, by a date set before it starts. Say the question is this: "Can a model do this task right on our real cases?" When the question is answered, the pilot ends. If the answer is yes, build the live system once, with the nine rows in the scope. If it is no, you learned that cheaply.

## Sources

- RAND, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed", James Ryseff, Brandon F. De Bruhl and Sydne J. Newberry, August 2024 (65 interviews; the five root causes and five principles): [rand.org](https://www.rand.org/pubs/research_reports/RRA2680-1.html)
- Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", 25 June 2025: [gartner.com](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027)
- MIT NANDA, "The GenAI Divide: State of AI in Business 2025", July 2025 (coverage): [Virtualization Review](https://virtualizationreview.com/articles/2025/08/19/mit-report-finds-most-ai-business-investments-fail-reveals-genai-divide.aspx)
- IBM Institute for Business Value, 2025 CEO Study, 6 May 2025 (2,000 CEOs, 33 countries, 24 industries): [newsroom.ibm.com](https://newsroom.ibm.com/2025-05-06-ibm-study-ceos-double-down-on-ai-while-navigating-enterprise-hurdles)

The $200 to $1,200 monthly model-cost range is our figure for production systems at 1,000+ daily AI interactions. The research copilot is from our build library; client names are not published.

## Related

- [How to calculate AI ROI](/insights/how-to-calculate-ai-roi)
- [AI agency red flags](/insights/ai-agency-red-flags)
- [How long does it take to build an AI system?](/insights/how-long-does-it-take-to-build-an-ai-system)