A working prototype and a production AI system share almost nothing except the model call. Everything else — the parts that determine whether it survives real traffic, real edge cases, and real failure — has to be built separately.
Before it touches a real user
- An evaluation set with expected outputs, run automatically on every prompt or model change.
- Structured logging of every input, output, and tool call, with a way to replay any single request.
- A fallback path for when the model errors, times out, or returns something malformed.
- Rate limiting and cost ceilings, so a bug or an abusive user can't turn into a runaway bill.
- A human review or approval step for any action with real-world consequences.
After launch
- Ongoing sampling of live outputs against your eval set, since quality can drift as usage patterns shift.
- Alerting on latency and error-rate anomalies, the same way you'd alert on any other production service.
- A versioned prompt and config history, so you can tell exactly what changed when behaviour changes.
Common mistake
Teams treat the eval set as a one-time setup step. It needs the same versioning and review discipline as the code itself, or it quietly stops catching the regressions it was built to catch.
None of this is exotic engineering — it's the same discipline you'd apply to any production service. The difference is that AI systems fail in softer, quieter ways than a crashed process, which is exactly why the checklist matters more, not less.
If you're weighing whether your team has this covered before shipping, that's the exact gap our AI Opportunity Assessment is designed to find.