The Gap Between a Working Pilot and a Live System

The pilot proved feasibility, not readiness

A successful pilot answers whether the approach produces useful output on representative input. That is worth knowing and it is not the same as being ready to run unattended against real work.

The gap is unglamorous, which is why it gets skipped and why so many promising pilots are still pilots.

Know whether it is working

1. An evaluation set of real cases with agreed answers, run on every change
2. A quality metric with a threshold decided before you are invested in shipping
3. Regression testing, because prompt and model changes have side effects

Know when it stops working

1. Monitoring on quality, not just uptime
2. Alerting on drift — refusal rate, correction rate, output length
3. Cost monitoring with a hard cap, per user and per day

A model that is up and answering badly is worse than one that is down, because nothing pages anyone. Quality monitoring is the difference.

Behave properly when it fails

1. Graceful degradation on outage, rate limit or timeout
2. Human escalation that works, with full context handed over
3. An audit trail: input, retrieved context, output, model version, who reviewed

Let people fix it

1. A correction interface that is fast enough to actually be used
2. A feedback loop turning corrections into evaluation cases

Systems without these get abandoned quietly, because being unable to fix an obvious error is the most infuriating property software can have.

What it costs and how long

Eight to sixteen weeks and roughly the pilot budget again. Not padding — evaluation, monitoring, interfaces and failure paths, in that order.

Weeks 1–2 evaluation set and baseline; 3–5 failure handling and guardrails; 4–7 correction interface; 6–9 shadow running; week 10 limited launch.

Frequently asked questions