The pilot proved feasibility, not readiness
A successful pilot answers one question: can this approach produce useful output on representative input? That is worth knowing and it is not the same as being ready to run unattended against real customers.
The gap between the two is not glamorous, which is precisely why it gets skipped and why so many promising pilots are still pilots eighteen months later.
1–3: know whether it is working
- An evaluation set. A few hundred real cases with agreed correct answers, run on every change. Without this you are tuning by anecdote.
- A quality metric with a threshold. Decide the number that means acceptable before you are emotionally invested in shipping.
- Regression testing. Prompt and model changes have side effects; the evaluation set is what catches them.
4–6: know when it stops working
- Monitoring on quality, not just uptime. An AI feature fails by getting worse, not by going down.
- Alerting on drift — a change in refusal rate, escalation rate or output length usually precedes a quality problem.
- Cost monitoring with a hard cap. Per user, per day, per feature.
Uptime dashboards give false comfort with AI systems. A model that is up and answering badly is worse than one that is down, because nobody gets alerted.
7–9: behave properly when things go wrong
- Graceful degradation. Provider outage, rate limit, timeout — decide what happens: queue, fall back to a smaller model, or fail with a clear message.
- Human escalation that works, with full context handed over.
- An audit trail: input, retrieved context, output, model version, who reviewed it. You will need this the first time someone disputes a decision.
10–11: let people fix it
A correction interface. When the system is wrong, someone should be able to fix the output and have that correction captured. Systems without this get abandoned quietly, because being unable to fix an obvious error is infuriating.
A feedback loop into the evaluation set. Every correction becomes a test case, so the same mistake cannot silently return.
Budget and sequence
Plan for production hardening to cost roughly as much as the pilot again. That is not padding — it is evaluation, monitoring, the review interface and the failure paths, none of which the demo needed.
- Weeks 1–2: evaluation set and baseline measurement
- Weeks 3–5: failure handling, guardrails, cost controls
- Weeks 4–7: review and correction interface
- Weeks 6–9: shadow running against live traffic
- Week 10: limited launch to one segment, widened by evidence