Why do AI projects fail?

Most AI projects in commercial organisations deliver less than promised. That isn't pessimism, that's what the numbers show. International research suggests that somewhere between 70 and 85 percent of enterprise AI projects don't realise the expected value.

That’s a high failure rate for an investment that now involves tens of billions globally.

What strikes us in the projects we see go past: they’re rarely technical failures. The technology usually works fine. They’re organisational, commercial, and strategic failures that keep repeating. Three of them show up so often that we’ve come to treat them as signal patterns. For anyone considering an AI project or already deep in one, they’re worth recognising.

Failure pattern 1: The pilot without a production perspective

A typical start. The leadership team decides something has to happen with AI. A team gets tasked with “investigating what AI could mean for us”. A pilot starts. A tool gets bought. A use case gets chosen. Three to six months later, the team comes back with a report. The pilot worked. A few interesting applications were found. The leadership team nods appreciatively.

And then nothing happens.

The problem is that the pilot never had a production perspective. It tested whether something is technically possible, but not how it fits into the existing process, how it gets maintained, who owns it, how it gets funded over multiple years, and what it delivers in concrete commercial numbers. The pilot only proves what’s technically possible. But technically possible isn’t the same as organisationally embedded.

After that, there’s no path forward. The team moves to other priorities. The pilot lingers as an interesting experiment in a shared drive. A year later, when someone asks about the state of AI in the company, it gets referenced as if it were something operational. But nothing’s running in production.

This pattern is so predictable it’s almost a ritual. It comes from the gap between “can we do this?” (a research question) and “do we want to embed this in our organisation?” (a board decision). The pilot only answers the first. The second gets skipped. And without the second decision, nothing happens after the pilot.

Failure pattern 2: The use case without data

A second pattern, often combined with the first. An AI use case gets chosen that’s conceptually attractive. For example: “We’ll use AI to predict which customers are about to churn, so sales can intervene.” Lovely, concrete, commercially relevant. Everyone gets enthusiastic.

Until the project team discovers that the data needed to do this isn’t available. Customer behaviour isn’t systematically logged. Contact moments sit in three different systems that aren’t connected. Sales doesn’t record the signals that would be predictive. Customer service has its own logging that isn’t shared. The data that is available covers six months, while the pattern you want to predict only unfolds over eighteen.

Then there are two options. Either the project gets adapted to what current data allows, which usually delivers a much less commercially relevant use case. Or the project proceeds on inadequate data, producing unreliable predictions.

Both options lead to disappointment. And the problem underneath isn’t AI. It’s the organisation’s data discipline. AI amplifies what you have, and exposes what you don’t.

What most organisations then discover is that the real preparatory work isn’t buying an AI tool. It’s getting the foundation in order. Which data do we capture, how structured, how long do we keep it, how do we make it accessible across systems? That’s groundwork that has to come first, and it often takes more time than the AI implementation itself. Many teams stop at that point, because it sits further from what they got excited about.

Failure pattern 3: The tool without ownership

The third pattern: an AI tool gets purchased. The licence is signed. It’s demonstrated to the team. People get training. It gets integrated into a workflow. And then, slowly, over the first six months, usage fades.

Not because the tool is bad. Because nobody owns it.

A good AI application in a commercial organisation needs an owner. Someone who tracks usage, sees where it works and where it falters, makes adjustments, keeps it up to date with new versions, checks output for quality, and intervenes when it goes off course. That’s a role. Ideally half or one day a week structurally, not “on the side” when someone has time.

In most organisations, that owner doesn’t exist. The marketing manager thinks IT handles it. IT thinks marketing handles it. The person who bought it is on a different project six weeks later and has no time. The team uses it or doesn’t, depending on the day. Discipline gradually disappears. After a year, you’re still paying for the licence, but nobody is actively using the tool.

Ownership sounds like an HR detail. But it’s a commercial decision. Anyone who doesn’t allocate and pay for ownership up front is effectively buying an underutilised tool with a recurring cost.

What the three patterns have in common

Three different failure patterns, but they share something fundamental.

None of them is about technology. The technology works fine in all three cases. They’re about the organisational embedding of the technology. About who decides what, what happens to data, who the owner is, how it gets built into the work. Those are board questions, not IT questions.

And all three are caused by starting “what do we do” too soon, before “why are we doing this and how do we embed it” is clear. The pilot starts before a production perspective exists. The use case gets chosen before the data is checked. The tool gets bought before ownership is assigned.

This isn’t accidental. It’s a consequence of how most organisations put AI on the agenda: as something that has to happen fast, because others are doing it, with the idea that we’ll learn by doing. That sounds energetic. It rarely works.

What does work

What we see working at organisations that do achieve results: an AI track that puts one application into production in four to twelve weeks, with pre-agreed arrangements for how it gets embedded, who the owner is, and what data is needed. Small enough to deliver within three months. Big enough to have commercial impact. After that first cycle, the organisation has learned how it works, what real time and attention it costs, and what the next step should be.

But that isn’t the most important thing in this piece. The most important thing is that you recognise the three failure patterns in every AI project proposed within your organisation. A pilot without a production perspective, a use case without data, or a tool without ownership. Anyone who addresses these three in advance avoids three of the most common reasons AI projects disappoint.

---

Further reading

Want to read more about how AI can fundamentally redesign commercial work rather than just dress it up? Our pillar piece works it out, with three concrete examples from marketing, sales, and customer success: AI as the engine under commercial strategy: how a team of five does what twelve used to.