A working AI prototype creates a dangerous illusion: the hard part feels done. In reality, a prototype has only ever been tested on the demo path — a handful of friendly inputs, one rehearsed presenter, and no consequences when it stumbles. Production is the opposite: thousands of unpredictable inputs, users who never read the instructions, and a support inbox that fills up the moment things go wrong. The distance between those two worlds is where most AI features fail. Teams that cross it safely treat the move as an engineering process with explicit gates, not as a launch-date celebration.
Why the gap is wider for AI
Traditional software fails loudly; AI features often fail quietly. A crashed page announces itself, but a confidently wrong answer can travel through your product unnoticed — quoted in an email, pasted into a report, acted on by a customer. Three properties make the gap wider than it is for conventional code:
- Outputs are probabilistic — the same input can produce different answers, so “it worked in testing” is a weaker guarantee than it is for deterministic code.
- Quality is data-shaped — model behaviour is a product of its training and retrieval data, and real user inputs will drift away from your sample inputs within days.
- Failure is plausible — an error message says something broke, while a hallucinated answer says the wrong thing fluently, with confidence.
Gate one: write down what “good” means
Before any rollout, assemble a small evaluation set: 50 to 200 real task inputs, each with an answer a knowledgeable human endorses. It does not need to be elaborate — a spreadsheet and a grading rubric are enough to start. It needs to exist, be versioned, and run automatically every time you change a prompt, a model, or a retrieval setting. Then set acceptance thresholds in advance: for example, the assistant must cite the correct policy document on at least 90 per cent of retrieval questions, and must refuse out-of-scope requests cleanly. Written thresholds turn launch decisions into measurements; without them, decisions quietly become vibes, and vibes do not survive contact with an unhappy customer.
Gate two: design the failure paths
Every prototype has a happy path; every production system needs a decided answer for what happens when it is unsure. Work through the failure modes before launch:
- Constrain the scope — a narrow assistant that refuses gracefully beats a broad one that improvises, so keep the system prompt explicit about what the feature will not do.
- Bound the blast radius — anything consequential such as refunds, emails, deletions or payments belongs behind a confirmation step or a human approval, not an autonomous model call.
- Build the escape hatch — every user path should reach a human in one click, and the handover should carry the conversation so nobody has to repeat themselves.
- Log everything — inputs, outputs, retrieved documents and latency, with retention and privacy rules agreed up front, are what make every later investigation possible.
Gate three: roll out in stages
Shipping to every user at once is a bet that your evaluation set was complete. A staged rollout costs a few days and buys real information about real usage:
- Shadow mode — run the feature silently alongside the existing process and compare outputs without exposing anyone.
- Internal pilot — your own colleagues are the least forgiving early users you will ever get; let them break it.
- Percentage rollout — release to 5, then 25, then 50 per cent of users behind a feature flag with one-command rollback.
- Rollback criteria — decide the numbers that send you back, such as complaint rate, escalation spike or latency budget, before you flip the flag rather than after.
Monitor what the dashboard misses
Uptime is not quality: a feature can be 100 per cent available and quietly wrong. After launch, sample real outputs daily for the first weeks and read them yourself. Track latency percentiles and cost per request rather than averages, because the 99th percentile is where your users live. Watch escalation rates and complaint phrasing — users describe problems in words before metrics show them in numbers. And every corrected answer should flow back into the evaluation set, so your regression suite grows with each real failure instead of the team re-learning the same lesson.
A one-week pre-launch checklist
- The evaluation set runs automatically, and every acceptance threshold is met.
- Refusal and escalation behaviour has been tested against adversarial and out-of-scope inputs.
- A named owner is on call for launch week, with a rollback procedure that has actually been tested.
- Logging, retention and personal-data handling are documented, not improvised.
None of this is glamorous, and none of it is optional. The teams that ship AI features well are not the ones with the best demo — they are the ones that defined quality in writing, constrained failure, staged their exposure, and kept measuring after launch day. Do that, and the feature that impressed five people in a meeting room will hold up for the thousands who never read the release notes.
