Why most AI projects fail, and what the few that work do differently

Most AI projects fail for an unglamorous reason: they were never attached to a real piece of work. Something gets built, it demos beautifully, and then it sits beside the business instead of inside it. Nobody changes how they actually spend Tuesday. So nothing changes in the numbers either.

That is the short version. The longer version is worth your time, because the same research that produced the scary headline also quietly explains how to be on the right side of it.

What does the research actually say?

In 2025, MIT’s NANDA initiative published a study called State of AI in Business, looking at how companies were really doing with generative AI. The finding that travelled around the world was this: roughly 95% of enterprise generative AI pilots produced no measurable return on the profit and loss statement. Not modest returns. None.

It is a genuinely uncomfortable number, and plenty of people used it to argue that AI is overhyped. We read it differently. A 95% failure rate in a technology that demonstrably works tells you the failures are not about the technology. They are about how the work was set up.

So why do AI projects fail?

The patterns repeat with almost boring consistency:

• It started with the tool, not the problem. Someone saw a demo, bought a licence, and then went looking for something to point it at. Backwards, and expensive.
• The pilot never touched a real workflow. It lived in a sandbox, or a side tab, or one enthusiastic person’s browser. The company’s actual process carried on unchanged next door.
• Nothing learned anything. The MIT researchers put weight on this one. The systems that stalled were the ones that could not absorb feedback or adapt to how the team really worked, so people quietly went back to doing it the old way.
• There was no owner. A project that belongs to everyone belongs to nobody. When it gets awkward, and it always gets awkward around week three, there is no one whose week depends on making it work.
• It was measured in activity, not money. Prompts run, documents summarised, seats adopted. All interesting, none of it something you can take to a bank.

Notice that not one of those is a model problem. Swapping to a better model fixes none of them.

What do the 5% do differently?

Three things, none of them clever.

They pick something narrow and unsexy. The study found the successful work clustered in the back office, in the plumbing, rather than in the glamorous customer-facing experiments where most of the budget went. Invoice handling. Intake. Routing. The stuff nobody demos at a conference, and everybody pays for every single week.

They put it inside the workflow. Not a tool your team has to remember to open, but a step that simply happens. The best sign a system is working is that people stop talking about it.

They partner instead of building from scratch. This was one of the report’s sharper findings: solutions bought or built with an outside partner succeeded at roughly twice the rate of ones built entirely in-house. Not because internal teams lack talent, but because a first attempt at something is a first attempt, and most companies only get one budget cycle to prove it.

Does this apply to a small business, or only to enterprises?

The study looked at large organisations, so read it with that in mind. But if anything, the odds are friendlier for a smaller company, for one specific reason: you can change how work happens without asking anyone’s permission.

Most enterprise pilots die in the gap between “the model works” and “four departments agree to change their process.” You do not have four departments. If the owner decides on Monday that every new enquiry gets answered by the system within sixty seconds, that is simply how it works on Monday. That speed is a real advantage, and it is wasted on experiments.

How do you avoid becoming a statistic?

Before you start anything, answer these five questions honestly. If you cannot answer them, you are not ready to build yet, and that is useful to know before you spend money.

• What exactly breaks today? Name the leak. “Leads wait four hours for a reply” is a project. “We should use AI” is a mood.
• What is it costing? In hours a week, or deals lost. If you cannot estimate it, you will never be able to prove you fixed it.
• Whose job gets easier? Name the person. They are your owner, and their relief is your success metric.
• What changes on day one? If the honest answer is “nothing, we will look at the dashboard,” stop.
• How will you know in thirty days? Pick the number before you build, not after.

Every one of those questions is about the business, not the technology. That is the whole point. The companies getting real returns are not the ones with the best models. They are the ones who picked a real problem, gave it to a real person, and wired the fix into how the work actually happens.

Questions people ask us

Is AI automation worth it for a small business?

Often yes, but only when it is aimed at something specific and repetitive. The wins that hold up are boring and measurable, replying to every enquiry instantly, chasing follow-ups nobody has time for, moving data between tools so your team stops doing it by hand. If a proposal cannot tell you which hours it gives back, it is not ready.

How long before an automation pays for itself?

A well-chosen first automation usually shows something within thirty days, because it is aimed at work that happens every week. If a project needs six months before anyone can tell whether it helped, that is a warning sign about the project, not a sign of ambition.

Should we build it ourselves or bring in a partner?

Build it yourself if you have someone who owns it as their actual job, not as a side project. The MIT findings suggest most companies overestimate their capacity here, and the cost of a failed internal build is rarely just the money. It is the year you spend convinced the technology does not work for you.

What is the single most common mistake?

Starting with ten small experiments instead of one connected system. Ten tools that do not talk to each other do not add up to automation, they add up to ten more logins and a new kind of copy-paste.