The bottleneck isn’t the technology

Many enterprise AI projects do not make it into production, and when one stalls, the first instinct is to interrogate the technology — the model, the data, the vendor. That is almost always the wrong place to look. In one analysis of more than 140 enterprise AI deployments, 77% of the failures traced back to organisational causes, not model performance, data quality, or integration. The technology gets the blame. The organisation rarely does.

The technology is probably fine. That is worth saying plainly, because it is the part everyone is most tempted to keep fixing.

Two engineers at a recent industry conference described building an agentic application in two weeks. Getting it into production took another twelve months. Not because the code was wrong. Because every function it touched had to align before anything could ship — security, data, the owners of the systems it plugged into — each with its own sign-off, each moving at its own pace. And it does not take a large organisation for this to bite: two or three functions that must agree, and a review process built for a slower kind of change, are enough.

That is not an unusual story.

Most organisations were built for a world where change moved slowly enough to be managed by committees, approval chains, and quarterly planning cycles. That worked well for a long time. But AI — and agentic AI in particular — does not move at that pace. A security review designed for annual software releases takes six weeks. Applied to a model update cycle, it becomes a bottleneck few organisations budgeted for. The gap between what the technology can do and what the organisation can absorb is where projects go to die.

This is worth understanding clearly, because the instinct when a project stalls is usually to push harder on the technology side. Better tools, more data, a different vendor. Sometimes those things help. More often, the bottleneck is elsewhere — in the approval process that was never designed for this volume of change, the finance function that needs a guaranteed return before it will back an uncertain bet, or the delivery structure that treats an AI initiative like a conventional software project with fixed milestones and predictable outputs.

None of that is anyone’s fault. It is just what happens when something genuinely new arrives inside a structure built for something else.

What changes the outcome is not a better demo. It is how you set the initiative up from the start — who owns it, how it is funded, what the governance looks like, and how you build confidence in the output before you ask the organisation to trust it fully.

In my experience, the organisations that get this right treat trust in the AI system as something to be earned incrementally, not declared at go-live. They start with the system observing real decisions — comparing what it would recommend against what people actually do. Then it advises. Only then does it act, in narrow, well-understood situations. Each stage is unlocked by what the system actually does, not by what the project plan says it should do by a given date.

That kind of progression requires someone who understands both sides — what the technology needs to demonstrate, and what the organisation needs to see before it will extend trust. It is a different skill set from building the technology, and a different skill set from running the business. That role sits between them.

The question worth asking before the next round of funding is not what the model needs. It is whether the person who controls the funding and the approvals understands what is actually blocking this — and is willing to change it.