What Production-Ready AI Actually Looks Like
Production readiness is not a model benchmark. It is the ability to operate, explain, recover and improve a complete AI system.
A prototype is ready when it demonstrates a capability. A production AI system is ready when the organisation can depend on it after the prototype team leaves the room.
That standard includes model quality, but it extends well beyond it.
The system has a defined envelope
Production teams know what the system is intended to do, what it must refuse and which populations or data types are outside its design. Evaluations represent that envelope with ordinary cases, difficult cases and deliberate non-cases.
Quality thresholds are tied to consequences. A drafting assistant can tolerate errors that a payment decision cannot. “Ninety per cent accurate” is meaningless without the distribution and cost of the other ten per cent.
Changes are controlled
Models, prompts, retrieval sources and policies are versioned. Changes run through repeatable evaluation before release. Teams can compare outcomes, roll back and identify which version produced a disputed result.
Failure is an ordinary condition
Dependencies time out. Retrieval returns weak evidence. Models refuse, produce invalid structures or exceed budgets. Production design gives each failure a bounded response: retry, fallback, human review or a clear stop. It never invents success.
Ownership survives launch
Named teams own product outcomes, source data, reliability, security and user support. Telemetry connects requests to evidence, policy decisions and actions while respecting retention constraints. Cost and quality are monitored together because optimising one can damage the other.
The practical test is simple: when the system behaves badly at 10:00 on a Tuesday, can the organisation explain what happened, protect users, restore service and prevent recurrence? If the answer depends on finding the person who built the demo, it is not production-ready.
Production is also a transfer of responsibility. Before launch, the permanent team should deploy the service, handle a simulated incident, change a model or policy safely and recover from a failed dependency. If only the project team can do those things, the experiment has not yet become an ordinary business system.