The demo worked. The model answered well, the stakeholders nodded, and someone asked the reasonable question: how quickly can this be in production?
Why the demo was easy
The honest answer is usually "later than the demo suggests" — not because the model needs to get smarter, but because the demo was allowed to skip everything that makes a system trustworthy. Teams that budget for the demo alone ship nothing. Teams that budget for the ten concerns below ship systems that survive contact with real users.
A prototype earns its impressiveness by making silent assumptions. It ran on a curated set of documents someone hand-picked. It answered questions its builders knew it could answer. Nobody asked it to respect permissions, because everyone in the room was allowed to see everything. Nobody measured its failure rate, because failures were quietly retried. It cost nothing worth tracking, because low-volume prototype usage rarely exposes the operating cost of organisational scale.
None of this is a criticism — a prototype's job is to show that the idea deserves engineering. The mistake is treating the prototype as the system with a few loose ends, rather than as the first line of a specification for the real one.
Data and grounding: from curated examples to real sources
The first production question is not "which model?" but "which data, and who may see it?"
In the demo, retrieval ran over a clean corpus. In production it runs over the organisation's actual sources — wikis that contradict each other, documents with access restrictions, records that change daily. Retrieval has to become permission-aware: a system that surfaces a document to someone who was never allowed to read it is a security failure regardless of how useful the answer appears. And answers need attribution — a response that cites its sources can be checked; one that doesn't must be trusted blindly, and enterprise users are right not to.
A useful test: take the prototype's best answer and ask where each sentence came from, and whether every person who will use the system is allowed to see those sources. If either answer is unclear, the data layer is not done.
Evaluation: define what "working" means before shipping
Prototypes are judged by impression; production systems need criteria. Before an AI feature ships, three things should exist: a definition of a correct answer for its task, a test set that represents real usage rather than happy paths, and a baseline measurement to compare every future change against.
This is not bureaucracy — it is what makes change safe. Models get updated, prompts get edited, retrieval sources grow. Without an evaluation harness, every change is a gamble nobody can quantify; a regression arrives silently and is discovered by users. With one, a model-version bump that quietly degrades answer quality is caught the day it happens, not the quarter after.
Operations: the part nobody demos
Four concerns turn an AI feature into an operable system:
- Security boundaries. The system's access to data and tools is an integration, and gets integration-grade review: its own identity, least privilege, revocation. A prototype running on a developer's personal token is not a deployment path.
- Observability. When an answer is wrong, someone must be able to see why — what was retrieved, what the model was asked, what it returned. An AI system without traces is undebuggable by design.
- Failure handling. Models time out, providers rate-limit, retrieval returns nothing. Each failure mode needs a designed behaviour — a fallback, a refusal, an escalation to a human — rather than an exception in a log.
- Cost and latency budgets. A workflow that costs cents in the demo can cost real money at organisational scale, and a ten-second answer that amused the demo audience will be abandoned by daily users. Both need budgets, measured per request, before scale — not after the invoice.
Change: the system will not hold still
Production AI systems sit on moving ground. Providers deprecate models on their own schedule. Prompts accumulate edits until nobody remembers why a sentence is there. Source data drifts. The workflow the system automates changes shape.
This is why the last concern is organisational rather than technical: ownership. Someone owns the evaluation results, decides when to adopt a new model version, reviews what the system is actually being used for, and can answer for its behaviour. An AI capability without an owner is not infrastructure — it is an experiment that happens to be exposed to users.
A production-readiness checklist
Ten questions, answerable in an afternoon, that predict whether the prototype is close to production or far from it:
- Which sources does it read, and are they permission-checked per user?
- Can every answer cite where it came from?
- What is a correct answer, in writing?
- Is there a test set that reflects real usage?
- Is there a baseline measurement to compare changes against?
- Does the system have its own identity and least-privilege access?
- Can you trace a wrong answer to its cause?
- Is every failure mode designed, not just logged?
- What are the cost and latency budgets, and what happens when they're exceeded?
- Who owns this system's behaviour a year from now?
A team that can answer all ten is finishing an engineering project. A team that can answer three has a promising demo — which is a fine thing to have, as long as nobody calls it nearly done.