Pilot to Production: 5 Things That Always Break (And How We Handle Them)
Written By: Chakravarthy Varaga · July 8, 2025
We've shipped 7 production AI systems across parking automation, satellite analytics, SaaS platforms, enterprise chatbots, and EdTech. Different industries, different stacks, different clients — but the same five things break every time, on every project, without exception.
Not because the teams are careless. Because these failure modes are structural: they live in the gap between what you can test in a pilot and what you encounter at production load with real users.
Here's what breaks, and what we do about it.
1. The data in production is nothing like the data in the pilot
In a pilot, you test with clean, representative samples. In production, you get the long tail: malformed inputs, encoding issues, null fields that were never null in the sample, formats that changed six months ago and nobody updated the docs.
What we do: Before any pilot ends, we run a data audit on a 90-day production sample — not the curated export the client gave us, the actual raw data. We deliberately break the model with edge cases before launch. Whatever breaks in testing breaks quietly. Whatever breaks in production breaks in front of users.
2. The model is confident about the wrong things
LLMs and classification models both produce high-confidence outputs on inputs they've never seen. The confidence score is not a measure of accuracy — it's a measure of how much the model's internal state resembles the training distribution. In production, that distribution shifts constantly.
What we do: We build calibration tests into every deployment. We deliberately feed the model inputs designed to produce wrong-but-confident outputs, and we verify the confidence threshold actually correlates with accuracy at our specific operating point. If it doesn't, we adjust the routing threshold before launch. We also build a feedback loop: production misclassifications get logged and used to adjust routing thresholds weekly in the first 60 days.
3. The integration breaks under concurrent load
In a pilot, you process records sequentially or in small batches. The external systems you're integrating with — CRMs, ERPs, payment gateways, ticketing systems — weren't designed for the throughput your AI pipeline will throw at them at peak load.
What we do: Load test every integration before go-live, not just the AI model. We've hit rate limits on Zendesk, Stripe, and HubSpot APIs mid-deployment because the integration wasn't designed for burst. We now treat every external API as untrusted and design queue-based architectures with backoff and retry as the default — not the exception.
4. Nobody owns the edge cases
Every AI system has inputs it can't handle confidently. The human-in-the-loop queue exists precisely for these cases. But in most deployments, nobody plans who reviews the queue, on what schedule, with what authority to make decisions. The queue fills up. SLAs are missed. Confidence in the system collapses.
What we do: Before launch, we write an operational runbook: who owns the review queue, what the SLA is for each case type, what authority the reviewer has, and what escalation path exists for ambiguous cases. We treat the human review workflow as a product feature, not an afterthought.
5. The client changes the underlying data or process after launch
The AI system was built on assumptions about your data schema, business rules, and workflow. After launch, someone adds a new field to the CRM, changes a status code, or modifies the upstream process. The system silently starts producing wrong outputs — and nobody notices until downstream effects surface weeks later.
What we do: Schema validation at the ingestion boundary. Every input is validated against an expected schema before it reaches the model. If the schema changes, the system alerts before processing the first bad record — not after processing 10,000 of them. We also require a 30-day post-launch monitoring review where we check for distribution drift in the input data.
The Pattern
All five failures share a root cause: the pilot validated the happy path. Production is everything else.
The fix isn't more careful engineering on the model itself — it's systematic hardening of the boundaries: data ingestion, model routing thresholds, external integrations, human review workflows, and change management on the underlying data. These are operational concerns, not AI concerns. And they require the same rigor as the model itself.
Every system we ship includes a production readiness checklist that addresses all five. Not because we're cautious — because we've seen what happens when you skip it.
