Just because something works when you put it live doesn’t mean it stays true. The world that the model learned has evolved and the only question is whether you spot it before your customers do.
All deployed models are based on the belief that the data we see tomorrow will be similar enough to what we trained on. And so the answers will still be relevant. But that will eventually not be true.
As the user base shifts, the prices change, fraud patterns mutate and words shift in meaning. The model just sits there like a rock while the world goes around it. This is model drift… and it’s subtle, hidden in plain sight and generally treated as a problem when we find out in the company, not when we find out in the tech.
It can be costly.
Two kinds of drift, two different problems
“Model drift” is the umbrella term for performance degrading over time, but underneath it sit two distinct phenomena worth keeping separate, because they are detected differently.
Data drift is a change in the input distribution: the data flowing into the model no longer looks like the data it was trained on. A credit model built on one customer demographic starts seeing another. A vision system trained on summer imagery meets winter.
The mapping the model learned may still be valid, but it is being fed inputs it never saw enough of. The useful property of data drift is that you can detect it without labels by comparing live input distributions against the training baseline.
Concept drift is more dangerous because it changes the answer itself. The relationship between inputs and the correct output shifts, so the same input should now produce a different prediction. Fraud is the classic case: the behavioural signature of fraud keeps evolving precisely because fraudsters adapt to detection.
Concept drift usually needs labels or human review to confirm, because the inputs can look perfectly normal while the model’s verdict on them quietly becomes wrong.
What it costs when nobody is watching
The most expensive public lesson in unmanaged drift is Zillow. Its iBuying arm, Zillow Offers, used an automated valuation model to decide what to pay for thousands of homes. The model had been trained on a relatively stable market, and when post-pandemic conditions became volatile, it continued to overvalue properties as demand cooled. Zillow bought homes faster than it could resell them, nearly 9,700 in a single quarter, at prices it could not recoup.
The result, announced in November 2021, was a $304 million write-down, total losses exceeding $500 million, the shutdown of the entire programme, and a workforce cut of about 25%, roughly 2,000 jobs. The failure is widely read in machine-learning circles as concept drift: the relationship between a home’s features and its price had changed, and the model was never updated to reflect it.
What makes Zillow instructive is that the company was not careless. It had tested the model and rolled it out gradually. The gap was not in building the model but in catching the moment its world changed faster than it did. That is the whole problem in miniature. Drift is rarely a modelling failure; far more often it is a monitoring one.
How to catch it early
Detecting drift means watching several signals at once, because no single one tells the whole story.
Statistical tests do the input-side work cheaply and continuously, giving the earliest warning. The Population Stability Index and the Kolmogorov-Smirnov test flag when a feature’s live distribution has wandered from its baseline, while sequential methods like the Page-Hinkley test watch a model’s error stream and trip when it crosses a threshold.
As a rough guide, a PSI below 0.1 indicates no meaningful change, 0.1 to 0.2 warrants investigation, and values above 0.2 usually mean the model needs attention.
But input drift on its own is a noisy signal. A distribution can shift without the model’s accuracy suffering at all, and alerting on every such shift just trains your team to ignore the alarms. The more reliable approach is to watch three layers together:
- Input distributions. The earliest, label-free warning that the world is changing.
- The model’s own prediction distribution. A shift here without a matching input shift often points to concept drift.
- Downstream business metrics. The conversion and approval rates show whether any of it is actually costing you.
Drift that shows up across several of these at once is real; drift visible in only one is often noise.
Where ground-truth labels arrive late, which is common in credit scoring or any long-horizon prediction, you can still estimate performance in the gap. This is NannyML’s speciality, inferring likely accuracy under drift before the true labels land. For day-to-day work, Evidently is the open-source standard, with commercial platforms like Arize and Fiddler adding managed dashboards and alerting on top.
One caution worth building in from the start: plenty of incidents blamed on drift are really a broken pipeline underneath, a feed that started sending nulls, a renamed column, a changed unit. Rule those out before you retrain, because retraining will not fix a plumbing problem.
The 2026 wrinkle: drift when you did not train the model
The picture gains a complication as more teams build on models they did not train themselves. When your product sits behind a third-party LLM or an agent that calls external tools, classic accuracy metrics give way to signals like answer faithfulness and tool-call success.
The practical advice that has been settled by 2026 is to alert on the joint condition of input drift plus a measurable drop in evaluation scores. Drift with no eval impact is usually a false alarm, and chasing it burns the on-call attention you need for the real thing.
What happens after the alert
The discipline that separates a working drift programme from a dashboard nobody reads is what happens once the alarm goes off. A few rules make the difference:
- Tie every threshold to an action, from a ticket for human review through to an automatic retrain, so alerts drive a response rather than piling up unread.
- Use two levels, a warning and a critical one, and require drift to persist across more than one monitoring window before it escalates, which filters out transient blips.
- Gate any drift-triggered retrain behind a quality check, so a bad automatic retrain cannot quietly replace a working model with a worse one.
Tying alerts to defined responses and keeping a record of what was done is also where drift monitoring meets the governance layer covered in our post on governance tools for enterprise AI model lifecycle management. The aim is not to eliminate drift, which is impossible, but to shorten the distance between when it starts and when you respond.
Drift is a lifecycle property
The reason drift catches teams out is that it falls in the gap between “the model works” and “the model keeps working,” and those get treated as the same milestone far too often. Monitoring belongs at launch, not after it, because it is what makes the launch safe in the first place.
A model shipped without drift detection is performing well today while quietly carrying an unmeasured liability, and the two only separate once it matters. Building drift monitoring from the first deployment is what turns a clever model into a system you can actually depend on.
Drift detection is one piece of managing a model across its whole life, from training through to retirement, which our guide to AI model lifecycle and governance sets out in full. It is also the piece most often left until it is too late. That is where SkyBiometry’s applied AI work comes in: we build the monitoring into hosted models from the first deployment, so decay gets caught on a dashboard rather than in a quarterly result.
