Here’s a story most ML teams will recognize, even though this version is made up. A fraud model scores 94% in testing. Three months after launch, it starts blocking a handful of genuine customers every Friday evening. Nobody touched the model. A payments partner renamed a field, one feature quietly filled up with nulls, and every dashboard stayed green. The service never went down. It just kept making worse calls.
An accurate model can still let the business down once it runs into real data, real traffic and real budgets. Right now that seems to be where most of the money is getting stuck.
McKinsey’s 2026 State of AI survey asked 1,719 people in 97 countries about AI’s effect on earnings. Thirty-seven percent said it had contributed to EBIT, about the same as in 2025. That flat line came even as more companies scaled AI. At firms with over $1 billion in revenue, the share scaling AI agents climbed from 27% to 40% in a single year. On top of that, roughly one in five respondents said running costs, tokens included, were already limiting their AI use.
Adoption is sprinting ahead, and returns are standing still. What usually fills that gap is production engineering, the dull, necessary work that keeps a model earning its keep long after launch day.
Why good models stumble once they’re live
A model learns from history. A production system has to keep applying those lessons while the data, the traffic and the business all keep moving.
Take a retailer’s demand forecast that looked brilliant in testing. Once it’s live, product codes get reshuffled, promo data turns up a day late, and someone’s warehouse system starts counting returns twice. The algorithm does exactly what it was built to do, and the forecasts slide anyway.
Researchers at Google flagged this years ago in a paper titled “Hidden Technical Debt in Machine Learning Systems.” Their argument was that in real ML systems, the model code is a small slice of the whole. Most of the risk hides in data dependencies, configuration, glue code and monitoring. A model can be well built and still fragile if everything around it is held together with tape.
So the real work starts before training. Someone has to pin down the business decision the model supports, agree on acceptable performance, check incoming data, and decide ahead of time what happens when predictions can no longer be trusted.
The groundwork that gets models production-ready
Several pieces have to work together, and one weak spot can undo the rest. For companies leaving the pilot stage, building production-grade machine learning solutions means treating data engineering, model work, deployment, and monitoring as one system with one set of owners.
Pipelines that make noise when they break
The nastiest data problems don’t crash anything. A pipeline can report success while shipping stale records, surprise nulls, duplicate transactions or features whose patterns have drifted.
Automated checks catch most of it: schemas, allowed values, freshness, and plain business rules like “an order total can’t be negative.” Feature logic also has to match exactly between training and live predictions. Otherwise, the model sees different inputs in production than it learned from, a problem known as training-serving skew.
Data contracts help a lot. They spell out what upstream teams must deliver, how often, and what happens when they don’t. When a source system changes, the contract fails loudly and the model doesn’t sink quietly.
Picking the right shape for the job
Plenty of models don’t need real-time answers. Fraud checks at checkout do. Weekly demand forecasts, customer segments and periodic risk scores usually run better as batch jobs.
That choice drives latency, infrastructure bills and how much can go wrong. Real-time systems have to cope with concurrency, uptime and response times under pressure. Batch systems need dependable scheduling, fresh inputs and a sensible recovery plan when a run falls over.
Let the business need choose the architecture, whatever the data science team would enjoy building. A smaller model with good-enough accuracy and steady costs often beats a heavyweight that’s slightly better and expensive to serve. With one in five organizations already feeling cost pressure, per McKinsey, it’s worth deciding this early.
MLOps you can actually repeat
An ML release changes more than code. Dataset versions, feature definitions, hyperparameters, libraries and model files can all shift behavior.
MLOps stitches these together with experiment tracking, versioned artifacts, automated checks and controlled releases. Every candidate model should prove itself against operational and business requirements before promotion, since a strong offline score on its own says little.
Canary releases and shadow deployments let a new model show what it can do on live traffic without risking the whole business. A tested rollback plan gets you back to a known-good version fast when something crosses a line. Automation speeds all of that up, but a named person still owns the release criteria and signs off.
Monitoring that reaches the business
Ordinary app monitoring covers uptime, latency, throughput and resource use. ML needs a few more layers:
| Layer | What to keep an eye on |
| Infrastructure | Latency, uptime, failed predictions, resource use, cost |
| Data | Missing values, schema changes, shifting distributions, freshness |
| Model | Prediction quality, drift, performance by segment, late-arriving ground truth |
| Business | Forecast error, fraud losses, manual review volumes |
A service can look perfectly healthy while its predictions get quietly less useful. That’s why the bottom row matters most. If nobody puts fraud losses or review queues next to model metrics, drift can run for months before anyone notices.
When drift shows up, start by working out why. It might be a real change in customer behavior, a one-off blip or broken upstream data. Retraining on bad data just bakes the problem in.
Governance from the first sprint
Production ML needs named owners, written-down limitations, access controls, audit trails and a clear escalation path, especially when outputs touch money, operations or customers. NIST’s AI Risk Management Framework gives a widely used structure for spotting and managing these risks across development, deployment and evaluation.
It also needs real human oversight. Reviewers need enough context and authority to push back on a prediction, and someone has to decide which calls always get a person in the loop. Plenty of programs stall right here, because AI transformation is a problem of governance as much as engineering. When data, platform, security and business teams don’t know who owns what, an incident quickly turns into an argument about whose job it was.
Proving a model is ready
A deployment checklist can’t prove much. Readiness comes from evidence that the whole system meets its targets, recovers when things break and pays back what it costs. Agree on those targets before launch, while it’s still a planning conversation and before anyone defended a bad week.
| Area | What to measure |
| Predictive quality | Accuracy, error rates, performance across key segments |
| Reliability | Uptime, latency, throughput, recovery time |
| Data integrity | Freshness, schema compliance, feature consistency |
| Economics | Training, inference and upkeep costs |
| Governance | Traceability, access controls, named ownership |
| Business impact | Losses avoided, forecast accuracy, workflow gains |
The bar depends on the job. A real-time payments model needs strict latency and uptime promises. A weekly forecast cares more about fresh inputs and prediction quality.
Cost deserves the same attention as accuracy. Infrastructure, storage, monitoring, retraining and incident response all come back every month, and pilots rarely reveal the full bill. That’s doubly true now that AI API costs can spiral once usage grows. What really matters is the cost of each useful business result. Cost per prediction misses most of the picture. A pricier fraud model can be a bargain if it stops much bigger losses, while a clever forecast may not be worth maintaining if a simple one leads to nearly the same stock decisions.
Retraining should follow the same rules. Drift signals, late-arriving results and business context decide whether a new model is needed, and every candidate passes validation before it takes over.
Agents up the ante
McKinsey’s data hints at what’s next. Big companies are scaling AI agents quickly, and the high performers stand out. The roughly 6% of respondents who credit AI with at least 5% of EBIT are much more likely to rebuild workflows around it. Nearly three in four of them say they’ve done so, against about one in four of everyone else.
Agents pile more work onto production engineering. Alongside a model there are prompts, retrieved documents, tool calls and multi-step workflows, and each one is another place for something to fail without a sound. Testing one model tells you little about whether the whole chain behaves. Teams need a clear trail across data, model versions, application code and the decisions that come out the far end, plus shared ownership across engineering, security, product and the business.
Some companies will build all of this themselves. Others will bring in outside help for specific gaps, like inference services, monitoring or lifecycle controls. If you go that way, it’s worth knowing how to select the right machine learning development company. Test vendors on your own data, check that their past systems are still running, keep the held-out test set in your own hands, and agree who owns model performance after handover before anyone signs. Long-term maturity still comes down to repeatable engineering habits and clear ownership in-house.
So where’s the edge?
Fancier models alone won’t close the gap McKinsey keeps measuring. The companies that pull ahead will be the ones that ship models reliably, keep running costs in check, catch problems early and keep improving as things change.
A model makes predictions. The system wrapped around it decides whether anyone should act on them. So the next time a model hits its accuracy target, ask your team a harder question: if it started getting things quietly wrong tomorrow, how soon would you find out?
Related: Best AI Development Companies for Data AI Solutions in 2026 You Should Know About
