Every organization we talk to has a folder of AI proofs of concept that demoed beautifully and then quietly died. The pattern is consistent enough to name: the prototype was never the hard part. A model that answers well on a curated prompt in a notebook has cleared the lowest bar in the project.
The last ten percent is most of the work
A prototype answers one question: can the model do this at all? Production answers a harder one: can it keep doing it, correctly enough, against inputs you did not choose, without a person checking each answer? The distance between those two questions is where budgets disappear, because it is full of work no demo shows: evaluation, retrieval that stays fresh, latency and cost under load, and behavior when a model or an API shifts underneath you.
What production actually demands
Turning a prototype into a system means building the parts nobody demos:
- Evaluation. A repeatable way to tell whether a change --- a new prompt, a model upgrade, a reranker --- made outputs better or worse, before your users do. Without it, every change is a guess and regressions ship silently.
- Hallucinations and guardrails. Real inputs produce confident wrong answers. The system has to verify outputs against sources, constrain what the model is allowed to do, and fall back rather than assert.
- Retrieval and data pipelines. A RAG answer is only as good as the index behind it. Documents change and embeddings go stale, so yesterday's correct answer quietly becomes today's wrong one unless the pipeline keeps it current.
- Latency and cost. One request in a notebook is fast and free. A thousand concurrent users make token cost and tail latency the constraint that decides whether the thing ships at all.
- Failure and security. Providers rate-limit you, deprecate models and change behavior without notice; inputs try to jailbreak your prompts. Degrading gracefully, and least privilege designed in rather than retrofitted, are production features, not extras.
Design for the second system first
The teams that cross the gap do one thing differently, and it is subtler than it sounds. They do not build production infrastructure early --- no premature Kubernetes, no scaled vector database for a hundred documents. They make production-aware architectural decisions early: where the evaluation hooks go, how retrieval stays fresh, what happens when the model is wrong, which data may leave the building. The prototype stays cheap and disposable; the architecture around it is chosen with the production system already in mind.
A support-triage assistant that scored 95% on a test set of a few hundred tickets is the usual example. In production it met real phrasing, attachments and multi-language tickets, the retrieved policy documents had drifted since the evaluation, and the provider silently updated the model version --- accuracy fell below what a human queue could absorb, and there was no evaluation harness to catch it. Nothing about the prototype was wrong; it simply had no way to survive first contact with real traffic.
That is not gold-plating; it is the difference between a prototype you can grow and one you have to throw away. Choosing that path early is usually the cheapest decision in the whole project.