Why enterprise AI projects fail, and how to start smaller

Over the past two years almost every company has “tried AI”: accounts were bought, a training day was held, a few demos were shown, sometimes a pilot was launched. The question owners keep is the same. After the noise, what actually changed in the work?

Several research groups point the same way: only a minority of enterprise AI projects become part of daily work and show a measurable return. This page collects the studies that are cited most often, separates what they measured from what they did not, and turns the shared causes into a smaller way to start. There is a checklist at the end.

The failure rates are not one number

Three sources are quoted constantly. Their definitions differ, and none of them is a precise failure rate for your company. They do point the same direction.

Originals: RAND, The Root Causes of Failure for Artificial Intelligence Projects, Gartner news release, 29 July 2024, and MIT NANDA, The GenAI Divide: State of AI in Business 2025.

Arguing whether the figure is 80% or 95% does not change the next decision. The studies agree on why projects stall. Five causes show up in almost every one of them.

1. The project starts from the technology

In the RAND interviews, the cause mentioned most often was that the business had not decided, or had not said, what problem the AI was supposed to solve. The usual sequence is “everyone else is doing a large model, so we should too,” and only then a search for a use.

The result is something that demos, and does not sit in the day’s work. It answers questions nobody asks. The time it saves is time nobody was counting. RAND also describes teams that care more about using the newest technique than about the user’s actual job.

A plainer start is one sentence: which task repeats every day or every week, takes people, is easy to get wrong, and has a method you can explain? AI is one tool for that task, not the task.

2. The documents are not ready

RAND lists data as the second cause. Gartner puts poor data quality first among reasons projects are dropped. For a smaller company the issue is rarely “not enough data.” It is usually this:

• The same policy exists in several versions, and nobody can say which is current.
• The important judgment is still only in an experienced person’s head.
• The records are photos and scans, and the fields live in different systems.

A model will not decide which file is the right one. Sorting that out usually takes longer than the technical build, and it decides whether the result is usable.

3. The pilot sits beside the real work

The MIT NANDA report describes a split: general chat tools are widely used, mostly as personal productivity, while tools built for a specific business task mostly stay in pilot. The reasons they give are fragile processes, tools that do not improve from feedback, and a disconnect from daily operations.

In plain words, the pilot was built next to the job, not inside it. If people have to open another system and add a step, then check the result themselves anyway, they stop.

The applications that remain are usually inside a place people already open: a web page they use, a chat tool the company already runs, the ERP, a shared drive. And they say clearly what the system does and what a person still does.

4. Nobody wrote down what success is

Gartner notes that many companies cannot turn a generative-AI efficiency claim into a financial result, and that cost pressure grows as the scope grows.

If the project starts without an answer to “what does done look like,” the ending is a feeling. Write one or two numbers before the pilot, and a line for “if we miss this, we stop.” For the work we take on, those numbers should be about the business getting larger, not about employing fewer people:

• Less overtime on the same volume.
• More orders handled carefully on the same shift.
• Fewer returns, penalties, or repeats caused by a mismatch.
• Faster collection, because documents are no longer stuck in reconciliation.
• The current team taking on more business, without cutting the team first.

Also write the ongoing cost: model calls, servers, and the person who maintains the material. Those are not one-time.

5. Nobody owns it, so people stop using it

Going live is not the same as being used. Many projects peak on acceptance day and then fade. Documents are not updated, wrong answers are not fixed, and new hires never hear that the tool exists.

The worries are concrete. “If I use this, is my job still needed?” “If it is wrong, whose fault is it?” If nobody answers those, a capable tool sits unused.

Each application needs a business owner, not an IT owner by default, and one session for the people in that role: what it will do, what it will not do, and what to do when it is wrong.

A smaller way to start

Reverse the five causes and the path is ordinary:

1. Pick a process, not a technology. A frequent, repeated job with a method you can explain: matching documents, internal questions, a first draft of a quote.
2. Write the success line. One or two of the measures above, and the point at which you stop.
3. Try it on your own material. Not the whole company. Anonymized examples, in a few days, enough to see whether it works.
4. Run it beside people for a while. The system prepares. A person checks. Compare, then adjust the rule or the skill.
5. Then decide whether to widen it. If the measure is met, more of the same job. If not, the loss is a few days.

The MIT NANDA report also notes that projects done with an outside partner succeeded about twice as often as those built only internally. The reason is not mysterious. A team that has done it before already knows which parts break.

A checklist before you buy anything

• Can we say, in one sentence, which job this is for?
• Is there a current, trusted version of the documents, and a person who decides which file wins?
• Will it show up inside a system people already use?
• Is it clear what the system does and what a person does, including when the output is wrong?
• Is there one measure from the list above, and has the ongoing cost been written down?
• Is there a business owner, and do the people in the job know how to use it and why?

If three or more of those have no answer, do not buy a tool yet. A 3-minute readiness check is enough to see where you are, or a free conversation can pick the first job.

FAQ

Is the failure rate of enterprise AI really 80% or 95%?

Those figures use different definitions and should not be treated as a precise census. RAND’s 80% is an estimate it cites. MIT NANDA’s 95% comes from preliminary research, and the authors say it is directional. What the studies share is narrower: few AI projects become part of daily work and show a measurable return.

Where should a smaller company start?

With one frequent, repeated job whose method can be explained: answering questions from your own policies, pulling fields from documents, or a first draft of a quote. A small scope is easier to judge, including the decision to stop.

Buy a ready-made AI tool, or build?

Writing, translation, and summarizing are fine on a ready-made tool. Custom work is worth it when the job has to use your documents, your steps, and your systems. The test is whether the ready-made tool can sit inside the real process. The difference between a generic assistant and a skill your own people can edit is covered in custom AI and employee-written skills.

How do we tell whether a pilot worked?

Write one or two measures before you start, from overtime, orders handled, costly errors, collection, or the same team taking more work. Use the same measures at the end. Meet them, and widen. Miss them, and stop.