Cloud-ready isn't AI-native — and that gap is where pilots die

The model worked in the demo. It read the document, drafted the answer, and the room nodded. Six months later it still is not in production, and nobody can quite say why. The data science was never the problem. The stack underneath it was.

If that story sounds familiar, you are not an outlier. You are the base rate.

The demo works. Production is a different building.

Gartner has put the failure rate of AI projects at roughly 85% — the share that never make it into dependable production or deliver the outcome they promised. The instinct is to blame the model, so teams tune, swap and retrain. That is usually the wrong drawer to look in.

A pilot runs on a laptop's worth of data, a permissive environment and a human babysitting every call. Production runs on live data, real load, an auditor watching, and a budget. The model barely changes between the two. Everything around it does. When a pilot cannot cross that line, the thing standing in the way is almost always infrastructure that was built to be cloud-capable, not AI-capable.

Cloud-ready is not the same as AI-native

Most enterprises finished a cloud migration in the last decade. Workloads lifted, data warehouses stood up, dashboards refreshed on schedule. That estate is excellent at what it was designed for: reporting on what already happened. AI needs something else — the current picture, in the moment a decision is made, with the controls to prove how it was made.

Think of it as five layers that all have to be ready at once, not just the one your data team owns:

• Data foundation — a governed store that serves live features to a model, not a warehouse that refreshes overnight.
• Compute — elastic, GPU-capable capacity that scales with spiky AI workloads instead of a fixed cluster.
• ML platform — a standard path from a notebook to a governed, monitored production service.
• Governance — lineage, access and audit built in, so an approved model ships in days rather than after a six-month review.
• Applications — a way for AI to read and act inside the systems that already run the business, not from a disconnected side app.

A pilot only needs one of these to be good enough for a demo. Production needs all five. The weakest layer sets the ceiling for the whole stack.

Where the gap actually sits

The specific blocker differs by company, but it is rarely mysterious once you look. Fraud scoring that runs overnight will never stop a payment in flight, because the data lands in a batch warehouse and the model only ever sees yesterday. A copilot on your own documents never ships, because there is no private compute for it to run on without sensitive data leaving the building. Good models rot in notebooks, because there is no platform to deploy and watch them. And plenty of models that would work are simply not allowed near a customer, because nothing captures how they decide.

None of those are model problems. They are missing pieces of substrate. Name the one that is actually in the way before you spend another quarter on the algorithm.

The weakest layer of your stack sets the ceiling for every AI ambition above it. Fix that layer, and the pilots you already have start to ship.

Close it layer by layer, not big-bang

The reflex, once the gap is clear, is to propose a two-year platform rebuild. Boards rightly refuse it, and they are right to. You do not need to re-architect the whole estate to get AI into production. You need to modernise the two or three layers that are actually blocking the use cases you care about, funded by the value they unlock, with the rest left alone until it earns attention.

Done well, that is a phased programme, not a leap of faith: assess the gap, rearchitect the layer, prove it against the old world before you cut over, and keep a way back at every step. Minimal disruption is not a nice-to-have here. It is the only version a running business will actually approve.