Twenty-eight AI failures, and the pattern nobody names.

I have, over the last three years, sat in twenty-eight rooms where someone explained why an AI initiative had failed. Some were billion-dollar banks. Some were funded startups two quarters from a Series B. The titles changed. The tone changed. The numbers in the slide changed. The story did not.

It always begins the same way. A senior leader, often technical, sometimes not, walks the room through what was attempted. There is a polite acknowledgement of the model selection. There is a thinner acknowledgement of the data quality. There is a quick mention of cost overrun. And then, with the practised composure of someone who has already absorbed the loss, they say: we have learned a lot.

What they have not done, in any of the twenty-eight cases I sat through, is name the actual failure.

§ 01The pilot was never going to ship.

The most common pattern is also the most embarrassing one, which is why nobody writes it down. The pilot was approved on the assumption that it would never have to integrate with the production system. It was a demo. It was funded as a demo. It was staffed as a demo. And then, six months in, somebody asked when it would ship — and there was no answer, because no one had ever drawn the line from the demo to anything that customers, regulators, or the income statement would actually touch.

The honest version of the post-mortem is one sentence: we built something that was never connected to anything that mattered.

This is not a model problem. This is not a data problem. It is an intent problem. And it is uncomfortable to admit, because admitting it means admitting that the original sponsor — usually still in the room — green-lit a project without a path to value. Nobody wants to embarrass the sponsor. So the post-mortem talks about model performance instead.

§ 02The success metric was invented after the work began.

In nineteen of the twenty-eight cases, the success metric was either absent at the start, or rewritten partway through, or replaced with a softer one once it became clear the original would not be hit. I do not say this to be unkind. I say it because the failure mode is mechanical: if you cannot say, before the work begins, what number on what dashboard would make this project unambiguously successful — you are not running a project. You are running an exploration. And explorations are fine. They are simply much, much cheaper than what you ended up paying for.

The cleanest engagements I have ever seen — AI or otherwise — start with a single, falsifiable metric written down in the first meeting and never softened. Reduce reconciliation breaks by forty percent in twelve weeks. Cut underwriter handle time from eighteen minutes to nine. Replace the manual escalation queue entirely. One number. One deadline. Everybody knows what winning looks like, and more importantly, everybody knows what losing looks like. Losing has a date.

§ 03Nobody owned the operating model.

This is the failure mode that hurts the most because it is the most preventable. An AI capability is not a feature. It is an organism. It needs feeding — fresh data, human review, retraining cadence, drift monitoring, escalation paths, kill switches. Most pilots are scoped as software projects, not as living systems, and so when the team that built them gets reassigned, the capability begins to rot on a schedule that was always inevitable but never planned for.

Three months in, accuracy slips two points and nobody notices. Six months in, a regulator asks who reviews the override log. Nine months in, the original project manager has moved teams and the new owner has no context for why the thresholds were set where they were set. By month twelve, the system is producing outputs that nobody fully trusts and nobody is empowered to stop. So it gets quietly turned off, and the post-mortem records it as poor adoption.

The MIT figure gets quoted constantly, usually with the implicit suggestion that the technology is not ready. That is not the conclusion the data supports. The technology shipped. The operating model did not.

§ 04The board confused velocity with progress.

In a meaningful number of these cases — I would say roughly a third — the project ran for far longer than it should have, because senior stakeholders mistook activity for traction. Sprints were closing. Tickets were being burnt down. Engineers were demonstrating things in stand-ups. The Jira board looked alive. None of that, as I have learned the hard way over twenty-one years, is the same as moving toward an outcome.

Velocity is a measure of how much the team is doing. Progress is a measure of how much the team is finishing. The first is observable from a comfortable distance. The second requires somebody, usually the most senior technical person in the building, to walk into the room every two weeks and ask the uncomfortable question: what did we close, and what changed because we closed it?

§ 05The pattern, finally.

If I had to compress the twenty-eight cases into a single sentence, it would be this: AI initiatives fail because the organisation never decided, with sufficient seriousness, what it wanted them to do.

The model, the data, the platform — those are downstream concerns. They become genuinely difficult only when the upstream decision has been made, owned, and protected. When the upstream decision is fuzzy, every downstream choice becomes a coin flip dressed up as engineering. And the coin lands wrong roughly nineteen times in twenty.

The pattern nobody names is that most AI failures are governance failures wearing a technology costume.

This is not a comfortable thing to write, because it implicates the people who commissioned the work as much as the people who did it. But I think the honest reckoning is overdue. The next wave of enterprise AI will be done by organisations that treat the decision to build as more demanding than the building itself. The ones who do not, will fund another twenty-eight rooms, in another three years, in which nobody quite says what went wrong.

I would rather we said it now.