Why Most AI Projects Stall After Launch (and What Leaders Can Do About It)

A briefing for CEOs and operations leaders trying to work out why AI projects that looked great on paper have gone quiet, written by Chris Watson-James.

If you have lived through an AI rollout in the last twelve months, the shape of it will be familiar. The plan looked great, the team kicked off, and then, somehow, nothing much changed. The pitch had landed, the vendor demo was good, the pilot scoped well, and the build came in on time with everyone duly trained, and yet six weeks in, the dashboard data starts to thin out, the project stops getting mentioned in board updates, and nobody can quite remember whether the agent is still running. The thing is, most AI projects do not fail at launch. They stall after it, which is a very different problem and one that almost nobody plans for.

Deloitte's 2026 State of AI in the Enterprise report puts some numbers on the gap. It found that 85% of enterprises are pursuing AI in 2026 while only 39% have deployed it at scale, and that gap is essentially where most of the year's wasted AI investment sits. What is worth noting is that it is not really a technology problem. The pilots usually work fine. It is what happens, or more accurately what does not happen, in the months after launch that decides whether the value materialises or slowly disappears.

So the question worth asking is less about whether your AI project will launch successfully and more about what happens to it between week six and week twenty-six, because that stretch is where the implementation gap tends to live.

Why Launch Looks Like the Finish Line (And isn’t)

There is a structural reason behind AI projects failing, and it comes down to how they get treated. Most of them are run like a software rollout, so you scope the thing, you build it, you train people on it and then the project closes, the budget code shuts down, the project manager moves on to whatever is next, and the agent gets handed over to a team to use and is broadly forgotten about.

The problem is that AI tools do not really behave like other software. They are much closer to new hires than to new systems, in the sense that they need supervision and the occasional performance review. They need retraining when the work around them changes, and they need someone whose job it is to notice when their outputs start drifting.

A piece of software you deploy once will work the same way every time, whereas an AI agent you deploy once almost certainly will not, and that distinction is what most leadership teams have not fully made yet. Agents are not deploy-and-forget. They need owners, they need maintenance, and they need someone paying enough attention to spot when they have stopped doing what you originally built them to do.

Here are the 3 main reasons AI projects stall.

Reason 1 - Adoption Is the Metric Most Leaders Aren't Measuring

The most common version of the post-launch stall is also, fortunately, the easiest one to diagnose, and it usually comes down to measuring the impact of the tool without ever measuring whether anyone is using it. That sounds obvious when you say it out loud, but it happens constantly. A team builds a sales agent, deploys it, runs an ROI analysis at the three-month mark and finds the impact numbers underwhelming, so the conclusion is that the AI simply is not very good. More often than not, though, the real answer is that the sales team has stopped using it, and if the tool is not being used, then the impact was never the metric to measure in the first place.

So the fix here is essentially structural, and it means tracking two numbers rather than one. Impact tells you whether the tool works when it is used, and adoption tells you whether it is being used at all. Without both, you cannot diagnose what is going wrong, and the team will keep concluding that the AI was not ready when what wasn’t ready was the change management around it.

Reason 2 - AI Tools Are Not Deploy-and-Forget

The second reason is harder to spot because the symptoms creep in slowly rather than announcing themselves. AI tools, and particularly the custom-built ones like GPTs, gems, copilots and agents, tend to drift over time. They learn from the conversations they have, they pick up patterns from whatever documents they get fed, and gradually, they start producing outputs that look right but are subtly off.

Here is an example from my own work that should make any leader pause. I had been using a shared AI workspace for a specific piece of analysis, and at some point, I had uploaded a document where I had written something like "HubSpot combined with Make would be a really good setup for this use case." Fast forward several weeks to a different question in a completely different context, and the AI came back with a recommendation:

"HubSpot combined with a platform like Make would be a really good tool for this."

I read it, paused, and asked it where it had got that from, and it traced the recommendation straight back to my own document. So something I had written as a passing opinion had come back to me weeks later, dressed up as fact.

That is the kind of failure that does not look like a failure, because the output is perfectly plausible and the reasoning behind it is invisible. If someone else on the team had asked the same question they would almost certainly have taken the recommendation at face value, because that is simply how we are wired to treat outputs from a tool we trust. The real danger, then, is not that AI tools break in any obvious way; it is that they carry on working, producing outputs nobody is checking on, logic nobody is questioning, which is a far quieter and far more expensive way for things to go wrong.

This, fundamentally, is why agents need owners, and ideally, that owner is a department head rather than a project manager, someone who treats the agent as if it were a member of the team. Someone whose job it genuinely is to check the outputs from time to time, refresh the prompts, audit the knowledge base and notice when the tool has started saying things it really should not be. Without that, the tool keeps running, the team keeps trusting it, and the output quality decays in a way nobody catches until something breaks in public.

Reason 3 - The Change Management Cost Most Projects Underestimate

The third reason is more familiar, but it is worth saying plainly. The full cost of an AI project is not really the cost of building the AI; it is the build plus the training, the change management, the communication and the person whose job it is to keep it running afterwards. In most budgets, the build is the part that gets costed properly, and everything else gets treated as a soft cost, rolled into someone's existing role or quietly assumed to take care of itself.

It does not take care of itself. Deloitte's 2026 research identifies the AI skills gap as the biggest single barrier to successful deployment and finds that only 34% of organisations are genuinely transforming their operations with AI rather than layering it onto what they already do. Those two findings are connected because without a budget for the harder work of changing how people do the job, you end up bolting AI onto the existing process instead, so you get the tool and a little efficiency but miss the bigger transformation you invested in.

The leadership move, then, is to treat change management as a first-class line item in the AI budget rather than an afterthought, which in practice means:

• role-specific training rather than a single all-hands demo,
• champions embedded in each affected team instead of an expectation that IT will somehow drive adoption,
• clear escalation paths for when the AI gets something wrong,
• a communication plan that answers the "what does this change for me" question before launch rather than scrambling to answer it afterwards.

How to Get This Right

There is a reasonably consistent pattern across the businesses we work with where AI projects stick rather than stall, and none of it is especially exciting. It is mostly the unglamorous discipline that most projects skip over in the rush to launch.

• They benchmark before they launch, so they have something to measure against afterwards.
• They measure adoption alongside impact, so they know whether a poor result is a tool problem or a usage problem.
• They assign clear ownership at the department-head level, so there is someone whose job it is to notice when the agent has gone wrong.
• They treat the agent like a living system that needs maintenance, prompt refreshes, knowledge base updates and periodic audits of outputs, rather than a one-off deployment.
• They budget for change management as a real cost, not a goodwill assumption.
• They build a champion network of people in the affected teams who can answer questions and surface problems, rather than relying on top-down enforcement.

None of that is especially complicated; it’s just discipline, and the leaders who get it right over the next twelve months will be the ones whose AI investment is still earning its keep while the businesses around them are writing off projects that looked great on paper at launch.

Frequently Asked Questions

The questions below come up consistently when we work with leadership teams on this topic. They are intended as a reference, definitions and diagnostics you can return to rather than a recap of the argument above.

Why do most AI projects stall after launch?

The dominant reasons are organisational rather than technical. Most projects are scoped, built and launched without a plan for what happens next, so there is no measurement of adoption, no clear ownership of the deployed tool, and no budget allocated to change management. Without those three things in place, even a technically successful launch tends to lose momentum within the first six months, because the technology carries on working while the attention that would have kept it useful drifts elsewhere.

What is the implementation gap?

The implementation gap is the distance between AI projects being pursued and AI projects being deployed at scale. Deloitte's 2026 State of AI report puts the gap at 46 percentage points, with 85% of enterprises pursuing AI but only 39% deploying it at scale. The gap is largely created by projects that launched successfully but never reached the point of generating consistent value, usually because adoption, ownership and change management were treated as soft costs.

How do I tell whether my AI project is working?

You really need to measure two things rather than one. Impact tells you whether the tool produces value when it is used, and adoption tells you whether it is being used at all. The most common diagnostic mistake is to measure only impact, conclude the AI is not working and write the project off, when in most cases, the tool is fine and the adoption is the problem, so it is worth tracking both numbers from day one.

Who should own an AI agent after it is deployed?

Ideally, a department head rather than a project manager, and usually the person who owns the team affected by the agent, should also own the agent itself. Their responsibilities include periodic audits of outputs, refreshing the prompts and knowledge base, updating the tool as the team's needs change, and noticing when the agent has stopped doing what it was originally built to do. Without that ownership, the tool drifts, output quality decays, and nobody notices until something breaks publicly.