The model scored beautifully in the notebook on a clean validation set. The demo went flawlessly, and the stakeholders were thrilled. Yet, within a single week in production, the support queue filled with edge cases and erratic behavior that the training data never predicted.
Anyone who has shipped AI into a live environment recognizes this exact moment. It marks the critical gap between a model that works and a system that works. In reality, the vast majority of engineering effort goes into bridging that gap, not tuning the model itself.
This is the first in a monthly series exploring the friction points of AI engineering, focusing on concrete examples of what actually breaks when a system goes live.
According to MIT’s State of AI in Business 2025, only 5% of enterprise AI concepts ever reach production. Supporting this, S&P Global reported that the average organization scraps roughly 46% of its AI initiatives before deployment. In most of these aborted projects, the underlying technology was perfectly sound—it was the deployment architecture that remained unfinished.
The friction points below are organized roughly in the order they tend to cause trouble.
1. Handling the Chaos of Real Inputs
A live system’s first mistake is assuming production data looks like the test set. Real-world inputs arrive messy: empty fields, corrupted formats, duplicate records, and inconsistent date-time stamps. Because a model tuned on clean data won’t suddenly crash when fed garbage, it degrades quietly, resulting in a slow, insidious drop in output quality.
The fix is straightforward but non-negotiable: the system must validate and normalize all data at the boundary. Any pipeline that assumes clean data at the ingestion point is destined to break first.
2. Connecting to Legacy Infrastructure
No model exists in a vacuum; it must read from and write to the core systems surrounding it. The trouble is, these legacy systems were never built with modern AI integrations in mind, and each carries its own esoteric rules, authentication protocols, data shapes, and failure modes.
The only maintainable approach is to build these connections behind a stable integration layer. Wiring a model directly into multiple upstream and downstream systems creates a fragile web; the moment a single source changes, the whole architecture shatters. A centralized interface ensures that a single upstream change requires only a single point of repair.
3. Defining the Boundaries of Autonomy
Deciding what the system can execute autonomously versus what requires a human-in-the-loop is a design choice that is incredibly painful to retrofit. Controls added after launch usually amount to nothing more than glorified logging, whereas controls baked into the initial architecture act as true checkpoints.
These checkpoints explicitly define autonomous actions, human-confirmed actions, and strictly forbidden actions. For any system touching money, identity, or compliance, security reviewers will test this framework directly. A weak design at this stage leaves a project trapped in review limbo for months while compliance teams demand late-stage guardrails.
4. Continuous Monitoring (Post-Launch)
This is the step teams skip most frequently, and it’s the one that carries the longest-running technical debt. A model that passes every pre-launch test can still drift in production as real-world behavior shifts. Without robust monitoring, your first sign of trouble will be an angry client email or a corrupted metric in an executive report.
A resilient deployment monitors inputs, outputs, and—crucially—the business metric the system was built to move. Technical accuracy proves the model is running, but the business metric proves it is actually working. Only the second metric matters to the person signing the check.
5. Planning the Retreat
Real deployments plan for failure by designing clean rollbacks and fallback processes from day one. This plan must include a literal “kill switch” accessible to non-engineers. If a system cannot be turned off safely in an emergency, the engineering team will naturally avoid touching or updating it. And a system that nobody wants to touch stops improving the day it ships.
The Pattern
Ultimately, none of these challenges can be solved by a cleverer model. The deployments that survive are those that handle messy inputs, integrate through clean interfaces, bake in human oversight, monitor continuously, and maintain a clear emergency exit.
The model is the easy part; the system around it is the real job. That system is the hidden reason 95% of pilots never see the light of day.
Next month in Deployment Notes, we will cover the nuances of connecting multiple legacy systems through a single interface, exploring what breaks when too many connections run through a single point of failure.