Your AI pilot won't survive the second 90%.
The demo works. The board loves it. Then production happens, evals drift, the model behaves like a different person on Tuesdays, and the operating cost doubles. A field guide to the part nobody scopes.
There's a name for the part of an AI programme that ships: the first 90%. There's no good name for the second 90%, the eval drift, the retrieval bugs, the cost spike on Tuesday afternoons, the analyst who quietly turns the agent off because it's writing fiction. That's the part this article is about.
Why the pilot wins, and lies.
Pilots are designed to win. The data is curated, the prompts are golden, the user is an enthusiast, and the failure modes haven't had time to compound. The first measurement of the pilot is almost never the one that matters. The third measurement, taken eight weeks into production with a different cohort, is.
We've now run enough production AI engagements to predict the shape of the gap. It is not subtle. The pilot's accuracy number is between 6 and 22 percentage points higher than the steady-state production number, depending on the domain. Anyone who tells you otherwise is selling something.
What actually breaks in production.
Eval drift
Your eval set was perfect on day one. Six weeks in, it has been silently overfit. The model now scores 94% on your evals and 71% on the work the model is actually doing. The reason is that your eval set wasn't drawn from production traffic, it was drawn from the data you had when you wrote the eval set.
The fix is a continuous eval pipeline that samples production traffic, hand-grades a fraction of it weekly, and treats the eval set as a living artefact. eval_v37 is normal. eval_v1.0 in production is a red flag.
The retrieval problem
RAG looked solved at the demo. In production, three things go wrong: the corpus grows, the chunking strategy that worked at 4,000 documents fails at 80,000, and the retrieval relevance is the single biggest predictor of model behaviour, more than the model itself. We've shipped projects where swapping the embedding model and the chunking strategy mattered five times more than swapping the LLM.
Cost surprise
The cost projection from the pilot is wrong, almost always. The pilot's average token usage is not the production average, because the pilot's prompts are short, controlled, and ideal. Production prompts are long, messy, and recursive. The cost will be 1.4x to 3.2x your projection. Plan for it explicitly or get caught.
The human-in-the-loop is not a person
"Human-in-the-loop" sounds reassuring. In practice, the human is a $34/hour analyst who has been handed 600 model outputs to review per day, with a target of three minutes per case. They will not review. They will rubber-stamp. Your governance regime exists on paper and not in the workflow. Design accordingly.
Your build proposal needs a line item for production hardening that is roughly equal in size to the pilot itself. If a vendor's proposal has a $400K pilot and a $90K "productionisation phase", you are looking at the wrong vendor.
The part to scope.
Here is the part of an AI build that almost nobody puts in the SOW, and that determines whether the system survives. Use this list as a procurement checklist, or as a punch list for an engagement that has already started.
The production-hardening checklist
- A continuous eval pipeline that samples and grades production traffic. Not the pilot's eval set, frozen.
- An observability layer that records prompts, retrievals, model versions, and token costs per request, with a 90-day retention window minimum.
- A regression test suite that runs before every model, prompt, or retrieval change, with a defined failure threshold that blocks deploys.
- A rollback plan, tested at least once, with a 30-minute target rollback time.
- A cost budget per request and a daily/weekly cost alert. Not a monthly bill review.
- A human-review workflow that is sized to actual review capacity, not to a number written on a slide. If you don't have the headcount, the loop isn't real.
- A failure-mode taxonomy and a triage process. When the model misbehaves, the on-call should know what category it falls into.
- A post-launch hyper-care period of at least 30 days where the build team stays embedded and watches the metrics with you.
The second 90% as a phase.
The way we structure engagements at Xperion is to call this phase what it is, and budget for it. Phase one is the pilot. Phase two is the productionisation. They are not the same engagement, and they are not the same cost. We tell clients up front: the pilot is roughly half the spend. The other half is what makes it survive.
Most firms don't price it that way because the pilot is what wins the deal and the productionisation is what survives the audit. Pricing the second half honestly is the discipline. Our operating model exists, in large part, to make that conversation possible at the procurement stage rather than at the production-incident stage.
One last thing.
The pilots that survive are the ones where the people who built the pilot stay to run it. That is not always the same firm. When it isn't, you are paying for a context reset, an onboarding cycle, and a knowledge transfer that is almost guaranteed to lose 30-40% of what mattered. The structural fix is to insist on a single partner across both phases. The cultural fix is to stop treating "production" as a separate engagement from "build".
If you've recognised any part of this article in your own programme, the highest-value next step is a 30-minute conversation about which item on the checklist above is missing. Not a sales call. A diagnostic.
Keep reading.
Got a pilot stuck somewhere past the demo?
One scoping call, we'll tell you which item on the checklist is the bottleneck. Free, no obligation, no sales pyramid.