From AI proof of concept to production: what the gap actually contains

A proof of concept is a demonstration that something is possible. Production is a commitment that it will keep working while nobody is watching. Those are different claims, and the work between them is largely not the work people expect.

Here is what is actually in the gap, in rough order of how often it is the thing that stalls a rollout.

1. An evaluation set that can detect a regression

A proof of concept is validated by someone looking at the output and nodding. That does not scale and it does not survive a change. The moment you swap a model version, edit a prompt, or adjust retrieval, you need to know whether you improved things or quietly broke a category of inputs nobody was watching.

This is the single most common missing piece. It is unglamorous, it takes real hours of labelling by people who understand the domain, and it is the difference between a system you can improve and a system you are afraid to touch. We go deeper on how to build one in LLM evaluation in practice.

2. A designed path for the output you do not trust

Prototypes show the happy path. Production is mostly everything else: the low-confidence cases, the malformed inputs, the document in an unexpected language, the request that is out of scope, the model that returns something structurally invalid.

• What confidence threshold separates "act" from "ask a human"?
• Where do the "ask a human" cases go, and does that queue have an owner and a service level?
• How does a human correction get recorded so it improves the system rather than evaporating?
• What does the user see when the system declines to answer? "Something went wrong" is not a design.

3. Integration with the systems that hold the truth

Proofs of concept run on an exported spreadsheet. Production runs against the system of record, with its permissions model, its rate limits, its overnight batch window, and the field that three teams populate inconsistently.

This is ordinary engineering, but it is frequently the largest single line item and it is almost never in the pilot estimate. Touching the scariest integration during the pilot — rather than after it — is one of the highest-leverage scoping decisions available.

4. Observability, cost, and latency under real load

A demo makes a handful of calls. Production makes them continuously, and three properties that did not matter suddenly do.

1. Observability. You need the input, the retrieved context, the output, the model version, and the latency for every call — otherwise a user complaint is unfalsifiable and undebuggable.
2. Cost. Per-call cost multiplied by real volume is a number worth computing before launch, not after the first invoice. It frequently changes the architecture.
3. Latency. A response time that is charming in a demo is intolerable inside a workflow someone runs two hundred times a day.

5. The security and data review you deferred

Pilots run on a permissive exception. Production does not. Expect questions about where data goes, what is retained, whether anything trains a third-party model, and whether the system respects the permissions of the user on whose behalf it acts.

That last one is subtle and catches teams out: a retrieval system that indexes everything will happily surface a document the requesting user was never entitled to see. Permission-aware retrieval is a design decision, not a configuration flag, and retrofitting it is painful. If your constraints push inference into your own environment, private LLM deployment covers the practical options.

6. An owner

The quiet killer. A pilot has a sponsor; production needs an owner — a named person whose job includes this system working, who receives the alerts, who reviews the queue depth, and who decides when the thresholds move.

A pilot without a named production owner is a demo with a budget. It will not be stopped, and it will not be shipped.

How to not end up here

The gap is much smaller if the pilot was built as a thin version of production rather than as a demonstration. Concretely:

• Build the evaluation set in week one, not after the demo lands.
• Ship the pilot to a small number of real users doing real work, not to a review meeting.
• Touch the riskiest integration during the pilot.
• Name the production owner before the pilot starts, and have them in the weekly.
• Log everything from the first call, including the cases the system refuses.

None of this is expensive at pilot scale. All of it is expensive to add later.

• production
• MLOps
• playbook
• pilots