The pilot-to-production gap is not a model problem.

Most enterprises have at least one AI pilot that worked. Sometimes several. The demo went well. The accuracy looked acceptable. Someone presented the slide deck. Then the pilot quietly stopped where pilots stop — not in production, not killed, just running on a laptop somewhere, drifting toward irrelevance.

The instinct in the room is usually that the model was not good enough. We will wait for the next jump. But that is rarely what is actually wrong. The constraint shifted a while ago. OpenAI's own enterprise data is direct about it: the primary constraints for organizations are no longer model performance or tooling, but organizational readiness and implementation. McKinsey, looking at the same question from a different angle, reports that nearly two-thirds of organizations have not begun scaling AI enterprise-wide, even though AI use is widespread.

The model is good enough. The organisation is not ready.

Pilots are easy. Production is a different kind of work.

Pilots are easy because the constraints that make production hard are not constraints at the pilot stage. The dataset is curated. The cases are clean. The model only has to work on the demo path. Edge cases get filed under "we'll handle that later." The people running the pilot are also the people demoing it, so feedback loops are fast and informal.

Production is the part that comes after "later." It is when the system has to work on cases nobody curated, integrate with systems nobody owns, fall back gracefully when it fails, and be maintained by people who were not in the original demo.

The five things pilots usually lack

The pattern is consistent enough to write down. The pilots that do not ship are missing some combination of five things.

• A workflow owner. Someone whose job changes when the system ships. Not a sponsor. Not a steering committee. An owner.
• Production-grade data access. Demo pilots usually run against a static export. Production needs pipelines, contracts, refresh cycles, and access controls — at the volume and freshness the real workflow needs.
• An integration path. The system has to live somewhere — inside an existing tool, behind an API, as part of a process. "We will figure out integration later" is where pilots go to stall.
• An evaluation loop. A way to tell, on real cases, whether the system is right. Not benchmark accuracy. Not user satisfaction surveys. Something you can audit.
• A handoff plan. Documentation that lets a different team maintain it. Architecture decisions written down. A named person who picks up the pager.

A pilot can succeed without any of these. A production system cannot.

Demo quality is not production quality

Demo quality lives or dies on the happy path. The model returns a plausible answer to a question someone in the room asked. Production quality lives or dies on edge cases, latency under load, data drift, broken upstream systems, and what happens when the model is confidently wrong.

The work between those two states is not a model upgrade. It is a different category of work. It involves integrating data architectures, writing evaluation harnesses, defining failure modes, building monitoring, and writing the documentation a team you have not met yet will need.

That work is what most pilots skip — and skipping it is what produces the gap.

How to scope something that can actually ship

The cheapest way to avoid the pilot-to-production gap is to scope for handoff from day one.

Pick a workflow with a named owner. Define what "shipped" means in terms an executive can sign off on. Build the integration and the evaluation alongside the model, not after it. Document everything as you go. Assume the team that runs this in six months is not you, and build for them.

When a pilot stalls, the conversation in the room is usually about the model. Almost always, the actual problem is upstream of the model — and the fix is not a better one. The fix is to build for production from the start.