Why most AI initiatives fail

MIT's Project NANDA published The GenAI Divide in 2025, after studying 300 public AI deployments, interviewing 150 executives and surveying 350 employees. Despite $30 to $40 billion of enterprise investment, 95% of generative AI pilots produced no measurable business return. The report's own explanation matters more than the number: the failure was not model quality. It was a learning gap — brittle workflows, tools that never adapted to how the work was actually done, and pilots misaligned with daily operations. Executives blamed regulation and model performance. The data pointed at integration.

The pilot is not the problem

Running a pilot is easy, which is why so many exist. A pilot has no dependencies, no integration cost and no accountable owner beyond the person who proposed it. It also has no path into production, and that is usually not discovered until after the budget is spent.

The tell is the success criterion. If a pilot succeeds when people are impressed, it is a demonstration. If it succeeds when a named metric moves, it is a project. Most are the first and are reported as the second.

A demonstration is not worthless. It is how an organisation finds out what is possible. The failure is category confusion: funding a demonstration, judging it as a project, and concluding from its collapse that the technology does not work.

Generic capability, specific failure

MIT's finding has a sharp edge: generic tools work well for individuals precisely because they are flexible, and fail in organisations for the same reason. A flexible tool adapts to anything, which means it belongs to no particular workflow, which means nothing depends on it. Removing it breaks nothing. So it is removed.

This is the opposite of how the decision usually gets framed. Organisations ask which model is best. The question that predicts the outcome is which process this will be load-bearing inside — and who is accountable when it is.

PwC's 2026 Global AI Jobs Barometer, drawn from over a billion job ads across 27 countries, shows where the value actually landed: roles where AI amplifies existing expertise show twice the job growth and 42% faster salary growth than roles where AI merely makes the work easier. Amplifying expertise requires expertise to amplify. That is an integration problem, not a procurement one.

What the 5% did differently

They picked one workflow that someone owned, made the tool load-bearing inside it, and measured a number that existed before the project started. None of that is sophisticated. It is unglamorous, and it does not demo well, which is most of why it is rare.

Load-bearing is the operative word. A tool is load-bearing when removing it forces work to stop or revert to a worse method that people notice. Everything else is optional, and optional tools lose their budget at the first review — not because they failed, but because nobody can describe what breaks without them.

The second pattern is scope. One workflow, done properly, beats five pilots running at once. Five pilots share attention, share ownership and share blame, which means none of them has any of the three.

Your Next Move

Name the metric before the pilot. Written down, with its current value, before anything is built. A pilot without a pre-agreed number cannot fail, which is why it also cannot succeed.

Pick a workflow with an owner. Not a department. A person who will be worse off if it does not work, and better off if it does.

Set a kill date. Ninety days, then it goes to production or it stops. The expensive failure is not the pilot that fails. It is the one that neither fails nor ships.