A striking share of corporate AI initiatives never make it into daily use. The usual explanation, that the models aren’t good enough yet, is mostly wrong. The models are good enough for a great deal of real work. What fails is everything around them.
The pattern is consistent. A proof of concept is built in days and demonstrates beautifully. Then the project tries to become something a business actually depends on, and it stalls. The gap between those two states is where most of the difficulty lives, and almost none of it is about model capability.
The demo is the easy part
A demonstration runs once, on a clean input, with someone watching. Production runs constantly, on messy inputs, with no one watching most of the time. Those are different engineering problems, and the second is far harder than the first.
A proof of concept that handles the tidy, representative case proves very little about the version that has to handle the badly formatted document, the edge case nobody anticipated, and the input that looks normal but isn’t. Treating an impressive demo as evidence the hard part is done is the single most common way these projects go wrong.
There is no test layer for agent behaviour
Software engineering has decades of practice in catching regressions: a change breaks something, a test fails, the problem surfaces before users see it. AI systems built on third-party models have no equivalent safety net yet.
Model providers update their models. An agent that behaved correctly yesterday can behave differently today, on identical inputs, with no code change on your side and no failing test to warn you. A better underlying model can even produce a worse outcome for your specific task. Without a way to detect that drift, the first sign of trouble is often a customer or a colleague noticing something is off, which is exactly the situation engineering discipline exists to prevent.
Any AI system meant for production needs a behavioural testing layer: a way to check that the things it got right last week, it still gets right this week. Most stalled projects never built one.
The engineering gets harder, not easier
AI is often sold as a way to reduce engineering effort. In production it tends to demand more, not less, and of a more sophisticated kind.
Models get rate-limited, deprecated, repriced, or restricted. Building a critical workflow on a single provider with no way to switch is a fragility, not a shortcut. Serious deployments end up hedging across more than one model and keeping their workflows portable, so a change on one provider’s side doesn’t take the business down. That is real engineering work, and underestimating it is a reliable way to get stuck.
Agents with the keys to everything
The last barrier is oversight, and it is the one most likely to stop a project from being allowed into production at all.
To be useful, an agent needs access to systems: documents, databases, tools. The fast way to grant it is to hand over broad permissions. The result is an autonomous process with wide access and, very often, no record of what it actually did with it. The principle of least privilege, giving a process only the access it needs, tends to get abandoned in the rush to make something work, and observability lags well behind.
A workflow that takes meaningful action without scoped permissions and an audit trail is one that a careful organisation cannot responsibly automate. Until that is solved, the work simply stops at the demo.
Most of the rest is the data
Where the model itself isn’t the blocker, the data underneath usually is. A proof of concept talks to a clean sample; production has to contend with whatever the business actually stores, which is rarely as clean. That problem is large enough to deserve its own treatment: see getting your data AI-ready.
The takeaway is not that AI projects are doomed. It is that the work which determines success has little to do with the model and a lot to do with reliability, engineering, oversight, and data. Projects that treat the demo as the finish line fail. Projects that treat it as the starting line, and budget for the unglamorous work after it, are the ones that reach production.
That is also the case for starting small: low-stakes, verifiable work builds the engineering and judgement you need before anything important depends on it. If you’d rather not learn these lessons the expensive way, it’s the work our AI transformation practice is built around.
