Model Drift: The Ticking Time Bomb Inside Every “Production” AI System

On 31 August 2025, for one hour, 16% of requests to one of the most widely used language models in the world went to servers configured for a different context window. Answers got worse. The model weights hadn’t changed, and neither had the code of the companies calling it. A load-balancing tweak at the provider was enough. It took the provider weeks to connect the scattered complaints to that cause. A team calling the model would only have seen it in its own data if it was measuring answer quality on its own traffic.

People say “it’s in production” with relief, as if launch were the finish line. In practice, launch starts a clock. A model is fitted to the world as it was. Production is the world as it is becoming, and the gap between the two grows every day. With hosted large language models there is now a second clock that has nothing to do with your data: the supplier’s. The model, the serving infrastructure and the scaffolding around it can all change while your repository stays exactly as it was.

My argument in this article is simple. Drift is not an edge case. It is the default trajectory of every deployed model. A system has not earned the word “production” until it has three things: a frozen baseline to compare against, drift alarms whose false-alarm rate somebody has actually calibrated, and a response playbook that has been rehearsed at least once.

The article covers why this matters more now, what the evidence shows (and doesn’t), and a framework of five kinds of drift. I take each kind in turn: how it arises, the statistics that detect it, and how it fails. Then come thresholds and false alarms, a response playbook built on versioning and pinning, case examples, the strongest objections, implications by role, a 30/60/90-day programme, and the limits of the evidence.

Context: why this matters now

Concern about drift is as old as predictive modelling. Credit-risk teams were computing population stability indices long before anyone said “MLOps”. Three things have changed, and together they move drift from a model-maintenance chore to an operational risk.

First, the model is now a service you rent. In classic ML, a model file only changed when your team retrained it. A hosted LLM belongs to the vendor, which patches, re-serves and eventually retires it on its own schedule. Even a pinned version runs on the vendor’s hardware, compiler, load balancer and sampling code, and those change.

Second, the stack has more moving parts. A typical retrieval-augmented generation (RAG) system has a system prompt, a retrieval index, a chunking strategy, an embedding model, a reranker, tool definitions, an orchestration harness and the LLM. Each can drift. Some aren’t versioned at all, and many are changed by your own team in deploys that look harmless.

Third, usage is open-ended. A churn model does one thing. A general-purpose assistant gets used for whatever people think of. Six months after launch it is handling a different mix of intents from the one you evaluated, often including tasks nobody tested.

Meanwhile the cost of getting it wrong has become measurable. McKinsey’s November 2025 State of AI survey found that 51% of respondents’ organisations had experienced at least one negative consequence from AI, and inaccuracy was the most commonly reported one: nearly a third of respondents cited it. A good share of that inaccuracy did not exist on launch day. It drifted in.

Regulators have noticed too. Article 72 of the EU AI Act requires providers of high-risk systems to “establish and document a post-market monitoring system” that will “actively and systematically collect, document and analyse relevant data” over the system’s lifetime, proportionate to the risk. The 2026 digital omnibus pushed Annex III high-risk obligations to 2 December 2027, but the direction is set: monitoring after deployment is becoming a legal duty.

The evidence: what the data actually shows

Classic models degrade, and often abruptly

The best systematic evidence I know comes from Vela and colleagues, writing in Scientific Reports in 2022. They took 32 datasets from four industries (weather, hospital operations, airline departures and finance) and trained four standard model types on each: penalised linear regression (Ridge), random forest, gradient boosting (XGBoost) and a neural network (MLP). They then simulated 20,000 deployments, measuring how each model’s error grew with its “age”, meaning the time since it was last trained on then-current data.

Exhibit 1

91%of model–dataset pairs showed temporal degradation

Degradation was measured as error relative to error at deployment (relative MSE), across 20,000 simulated deployments per pair. Datasets are tabular time series, not language tasks.

Source: Vela et al., Scientific Reports (2022)

The headline is that the researchers “observed temporal model degradation in 91% of cases”. Three secondary findings matter just as much for anyone designing a monitoring system:

• Degradation is not always gradual. The authors write that it “can develop gradually, but can also escalate very abruptly”. In some pairs, error stayed flat and then jumped, at a breakpoint they could not tie to any obvious change in the data. A monitor that only alerts on slow trends will miss the cliff.
• Variance grows as well as the mean. The variability of errors “can significantly grow or fluctuate with time”. A model whose median error looks acceptable can be producing far more bad predictions at the tails. Monitoring only an average hides this.
• Different models on the same data age differently. On one dataset, the Ridge model stayed accurate while the neural network started degrading after about a year. How well a model ages has to be measured per deployment, not assumed from a benchmark.

Hosted LLMs change under a stable name

Chen, Zaharia and Zou ran the same questions against the March 2023 and June 2023 versions of GPT-4 and GPT-3.5, which developers were calling through the same model names. They tested seven tasks, including math, sensitive questions, opinion surveys, multi-hop knowledge questions, code generation, medical licensing questions and visual reasoning. The behaviour of the “same” service changed substantially within three months.

Exhibit 2

Figures from the published version of the study, which framed the task as prime vs. composite. The authors attribute part of the drop to GPT-4 following chain-of-thought prompts less reliably; GPT-3.5 moved in the opposite direction on this task.

Source: Chen, Zaharia & Zou (Harvard Data Science Review, 2024; arXiv 2307.09009)

The paper does not show that GPT-4 “got worse”. It shows that GPT-4 changed: some behaviours improved, others regressed, and GPT-3.5 often moved the other way. The common thread the authors identify is that the June GPT-4 followed user instructions less well, so prompts tuned on the March version stopped working as intended. That is the real production risk. It isn’t a universal decline but a silent change that breaks the assumptions your prompts, parsers and evaluators rely on.

The model can stay the same while the service drifts

The most instructive recent evidence comes from vendors’ own postmortems. They show that you can drift even when the model weights have not changed at all.

In September 2025 Anthropic published a postmortem of three infrastructure bugs that degraded Claude’s responses between early August and early September. One was a context-window routing error. It began on 5 August affecting 0.8% of Sonnet 4 requests, was amplified by a routine load-balancing change on 29 August, and peaked at 16% of Sonnet 4 requests in the worst hour on 31 August. Because routing was “sticky”, the same users were hit repeatedly: roughly 30% of Claude Code users who made requests in the period had at least one message misrouted. A second bug corrupted token generation and occasionally inserted Thai or Chinese characters into English answers. A third, a compiler miscompilation on TPUs, caused the model to sometimes drop the most probable token.

Exhibit 3

Onset, 5 Augshare of requests0.8%

Worst hour, 31 Augshare of requests16%

Claude Code users hitat least one message~30%

Bars use different bases: the first two are shares of Sonnet 4 requests; the third is the share of Claude Code users with at least one misrouted message during the incident. On Amazon Bedrock, misrouted traffic peaked at 0.18%.

Source: Anthropic Engineering, A postmortem of three recent issues (Sep 2025)

View data table

Measure	Value
Share of Sonnet 4 requests affected at onset (5 Aug)	0.8%
Share of Sonnet 4 requests affected, worst hour (31 Aug)	16%
Claude Code users with at least one misrouted message	~30%

Two lines from that postmortem should worry anyone running an LLM system. The vendor’s own evaluations “did not capture the degradation users reported”, partly because the model often recovers from isolated mistakes. And the reports looked random at first, because each bug produced different symptoms on different platforms. If the provider struggled to see this from the inside, a customer without monitoring had little chance.

The April 2026 postmortem on Claude Code adds another layer. The API was not affected, but three product-layer changes degraded the coding assistant for weeks. A lowered default reasoning effort was live from 4 March to 7 April. A caching change meant to clear old reasoning once after an idle hour cleared it on every turn instead, from 26 March until it was fixed on 10 April. A system-prompt line capping response length was added on 16 April and reverted on 20 April, after an evaluation showed a 3% drop. None of these changed a model. All of them changed what users got.

Exhibit 4

GPT-4o updateChatGPT, Apr 20254 days

Routing bugSonnet 4, Aug 202530 days

Reasoning defaultClaude Code, Mar 202634 days

Cache bugClaude Code, Mar 202615 days

Verbosity promptClaude Code, Apr 20264 days

Author’s calculation from dates in the cited sources. GPT-4o dates (25–29 Apr 2025) are from a secondary source summarising OpenAI’s posts; the update was to GPT-4o in ChatGPT. Routing-bug figure runs from onset (5 Aug 2025) to the first fix deploy (4 Sep); full rollout of the fix completed 16–18 Sep.

Source: Georgetown Law Tech Institute (GPT-4o); Anthropic Engineering postmortems (Sep 2025, Apr 2026)

View data table

Change	Live	Days
GPT-4o personality update (ChatGPT)	25–29 Apr 2025	4
Sonnet 4 context-window routing bug	5 Aug–4 Sep 2025	30
Claude Code default reasoning effort lowered	4 Mar–7 Apr 2026	34
Claude Code thinking-cache bug	26 Mar–10 Apr 2026	15
Claude Code verbosity prompt	16–20 Apr 2026	4

I don’t cite these incidents to single out these vendors. Publishing detailed postmortems is to their credit. The lesson is structural. When you rely on a service, you rely on its whole serving path, and that path changes more often than its version number does.

What the evidence does not show

Vela’s 91% comes from tabular regression and depends on how the authors defined degradation. Chen’s results cover two 2023 snapshots. The postmortems are self-reported, and no large independent study measures how often hosted LLM behaviour shifts in ways that matter to applications. So I am not claiming a known rate of LLM drift. I am claiming something narrower and, I think, harder to dispute: degradation over time is the base case for classic models, and the mechanisms for silent change in hosted LLM systems are real, documented and recurring.

A framework: three clocks, five drifts

“Drift” is used loosely. It helps to ask which clock moved. The world’s clock moves when inputs, meanings or users change. The supplier’s clock moves when the vendor changes the model or its serving path. Your own clock moves when your team changes prompts, retrieval or configuration. Those three clocks produce five kinds of drift that I monitor separately, because each fails differently and each needs its own detector.

Exhibit 5

	Clock	What changes	Typical symptom	Primary detector
Data (covariate) drift	World	The distribution of inputs: new formats, topics, languages, segments	Retrieval misses, odd outputs on unfamiliar inputs	Distribution tests on features or embeddings vs. a frozen baseline
Concept drift	World	What the right answer is: new policy, prices, products, fraud patterns	Answers that were right are now wrong, on inputs that look the same	Accuracy on a refreshed, labelled eval set; delayed-label tracking
Upstream model drift	Supplier	Model snapshot, serving stack, harness or defaults behind an endpoint	Format breaks, refusals, tone or length shifts overnight	Daily canary evals on the production path; output-shape metrics
Prompt & retrieval drift	Yours	Prompts, chunking, index contents, embedding model, tools	Quality moves after an innocent-looking deploy	Eval gates in CI; config hashes in every trace
Usage drift	World	Who uses the system and for what	Cost and latency creep; off-label tasks; new intents	Intent clustering, embedding drift, cost per request

Author’s framework.

The framework rules out two habits. The first is assuming one drift metric covers everything. An input-distribution test will never see concept drift, because concept drift means the inputs look the same while the right answers have moved. The second is assuming upstream changes are someone else’s problem. If you ship it, its behaviour is your problem, whoever caused the change.

Deep dive 1: Data drift, and the statistics that detect it

Mechanism. Data drift, also called covariate shift, is a change in the distribution of inputs P(x) while the relationship between inputs and correct outputs P(y | x) holds. A claims model starts seeing a new hospital network. A support assistant starts receiving queries in Taglish. A document pipeline gets scanned PDFs instead of digital ones. The model may still be correct in principle, but it is now operating in regions of input space where it saw little training data, and that is where errors concentrate.

Detection. You compare a sample of current inputs with a reference sample and ask how different they are. Four families of statistic do almost all the work in practice. Each answers a slightly different question.

Population stability index (PSI). Bin a variable using the baseline’s distribution, typically into ten bins. For each bin, take the baseline share e and the current share a, then sum (a − e) × ln(a / e) over the bins. If a bin’s share moves from 20% to 30%, that bin contributes 0.10 × ln(1.5) ≈ 0.041. PSI is closely related to the Kullback–Leibler divergence. It is in fact the symmetric version, the sum of the divergences in both directions. The industry rule of thumb reads PSI below 0.10 as little change, 0.10 to 0.25 as moderate, and above 0.25 as “significant change, action required”. Yurdakul and Naranjo point out that these cut-offs are used “without reference to statistical type I or type II error rates” and have no support in the academic literature. PSI’s expected value under no change depends on the number of bins and both sample sizes. A fixed 0.10 therefore means different things for a sample of 500 and a sample of 500,000. PSI is a useful, interpretable distance. The traffic lights are folklore.

Kolmogorov–Smirnov (KS) test. For a numeric variable, draw the empirical cumulative distribution of the baseline and of the current window. The KS statistic is the largest vertical gap between the two curves, and the test turns that gap into a p-value. It needs no binning and is sensitive to shifts anywhere in the distribution. Its weakness is the flip side of its strength: with enough data, a statistically significant difference becomes almost guaranteed even when it has no practical consequence. Evidently, a widely used open-source monitoring library, handles this by default. It applies KS (and chi-squared for categorical columns) only when the reference has 1,000 rows or fewer. Above that it switches to distance measures, Wasserstein distance for numeric and Jensen–Shannon divergence for categorical, with a default threshold of 0.1.

Maximum mean discrepancy (MMD). For multivariate data such as embeddings, testing each dimension separately is clumsy. MMD, formalised as a two-sample test by Gretton and colleagues in 2012, maps both samples into a rich feature space defined by a kernel (usually a Gaussian kernel) and measures the distance between the two samples’ means in that space. With a suitable kernel, MMD is zero only when the two distributions are identical, so it can catch changes in spread and shape as well as location. A permutation test turns it into a p-value: shuffle the pooled samples many times and see how often a random split is as different as the real one. The cost is computation. The standard estimator is quadratic in sample size, which is why it is usually run on samples or on alarm rather than continuously.

Domain classifier. Train a simple model to tell “baseline” from “current”. If it can’t do better than chance (an ROC AUC near 0.5), the two samples are indistinguishable for practical purposes. If it can, the drift is real, and the classifier’s most important features tell you what drifted. Evidently uses this as its default for text and embeddings, flagging drift above an ROC AUC of 0.55 for large samples.

Exhibit 6

	Asks	Best for	Cost	Blind spot
PSI	How far have binned shares moved?	Scores and key features; regulated credit-style reporting	Very low	Binning choices; fixed cut-offs ignore sample size
KS test	Is the largest CDF gap bigger than chance?	Single numeric features, small samples	Low	Flags trivial shifts at large n; one feature at a time
Wasserstein / Jensen–Shannon	How much does the distribution have to move?	Large samples where p-values become meaningless	Low	Threshold is a judgement call, not a probability
MMD	Do two multivariate samples come from the same distribution?	Embeddings; confirming an alarm	High (quadratic)	Slow; kernel bandwidth choice; hard-to-read scale
Centroid cosine	Has the average embedding moved?	Continuous, cheap topic-shift watch	Very low	Sees only the mean; misses spread and new clusters
Domain classifier	Can a model tell old from new?	High-dimensional data; explaining what drifted	Medium	Needs enough data; weak in low-data settings

Author’s synthesis from the cited sources.

Source: Yurdakul & Naranjo (2020); Gretton et al. (2012); Rabanser et al. (2019); Evidently AI documentation

The most rigorous comparison I know is Rabanser, Günnemann and Lipton’s Failing Loudly (NeurIPS 2019). They found that the best results came from a two-sample test run on the outputs of a pre-trained classifier, used as a way to reduce dimensionality. They also found that testing many dimensions one at a time with a Bonferroni correction performed comparably to multivariate tests. Large shifts could be detected better than chance with as few as 20 samples. Shifts affecting only 10% of samples were hard to detect at all. That last result is a sobering calibration point: subtle drift on a minority of traffic is inherently hard to see, and you should size your windows accordingly.

Failure mode. The commonest failure isn’t missing drift. It is detecting drift in everything, all the time, until the team mutes the channel. I return to this under thresholds.

Deep dive 2: Concept drift, the one input monitors can’t see

Mechanism. Concept drift is a change in P(y | x): the same input now deserves a different answer. A refund policy changes. A product is renamed. Fraudsters adapt to last quarter’s rules. A house that would have sold for a given price in spring 2021 sells for something different in autumn. The inputs look exactly as they did, so every distribution test above stays quiet while accuracy falls.

A public example. Zillow’s home-buying business priced homes on forecasts of their sale prices months later. In Q3 2021 it recorded an inventory write-down of approximately $304 million, expected a further $240–265 million of losses in Q4, and decided to wind down Zillow Offers, cutting about 25% of its workforce. The chief executive said “the unpredictability in forecasting home prices far exceeds what we anticipated.” Many factors contributed, and a drift monitor would not have saved the business. But it is a clear case of a model’s mapping from inputs to outcomes moving faster than the organisation measured it.

Detection. Concept drift can only be measured against ground truth or a credible proxy:

• A refreshed, labelled evaluation set. Label a slice of recent production cases on a schedule and track accuracy against the launch-day score. This is the only direct measurement.
• Delayed labels. In fraud, credit and claims, join outcomes back to predictions and track performance by prediction month, as credit teams do with vintage curves.
• Behavioural proxies. Reviewer override rates, escalations, thumbs-down rates and edits to model output. None is ground truth, but a sustained shift is a reason to label a sample.
• Knowledge freshness for RAG. The policy changed but the index still holds the old PDF. Track document age at retrieval and the share of answers citing superseded sources.

Failure mode. Teams treat a clean data-drift dashboard as evidence that the model is healthy. It is evidence that the inputs are stable, nothing more.

Deep dive 3: Upstream model drift, the supplier’s clock

Mechanism. The vendor changes something on its side of the API. It might ship a new snapshot behind a moving alias, change default parameters, alter the serving infrastructure, or change the harness around the model (system prompts, caching, tool scaffolding). Or it retires a version and forces a migration. The incidents in Exhibits 2–4 cover each of these.

Versioning and pinning. The first defence is to pin. Anthropic’s documentation now states that “every Claude model ID is a pinned snapshot” and publishes a retirement commitment for each current model. For the 5.5 generation, for example, retirement is not sooner than September or October 2027. Other vendors offer dated snapshots alongside moving aliases. Pin the snapshot in production, use the alias only in a canary environment, and treat each migration as a release with its own evaluation.

Pinning has limits, and they need to be said plainly. The September 2025 routing and compiler bugs affected pinned models, because they lived in the serving path, not in the weights. Product-layer defaults such as reasoning effort can change unless you set them explicitly. And every pinned snapshot has a retirement date, so pinning postpones change and schedules it. It doesn’t remove it.

Detection. Because you can’t inspect the vendor’s infrastructure, you watch its outputs:

• A daily canary set on the production path. Fifty to two hundred fixed prompts with known-good answers, sent through the same code, keys and region as real traffic, scored automatically. Anthropic’s own lesson from 2025 was to evaluate continuously “on true production systems”. Customers should do the same.
• Output-shape metrics on all traffic. Response length, refusal rate, schema validity, tool-call errors and language mismatch (the “Thai characters” symptom). They are cheap, need no labels and react within hours.
• Explicit parameters. Set temperature, maximum tokens and reasoning effort yourself, so a vendor-side default change can’t reach you.

Failure mode. Treating the vendor’s status page as your monitoring. It reports outages, not a model that has become slightly worse at following your formatting instructions.

Deep dive 4: Prompt and retrieval drift, the self-inflicted kind

Mechanism. Your own team changes the system. Someone shortens a prompt to save tokens, re-chunks the corpus, refreshes the index, upgrades the embedding model, adds a tool, or edits few-shot examples. Each change is reasonable on its own, but the combination has never been evaluated. The April 2026 Claude Code postmortem is a vendor-side version of this: a one-line instruction limiting response length cost about 3% on an internal coding evaluation, and it was only caught after release.

A subtle trap: the embedding model. If you monitor drift in embedding space and then upgrade the embedding model, every comparison against the old baseline is meaningless, because the two sets of vectors live in different spaces. Re-embed the baseline sample with the new model and re-freeze it as part of the upgrade. Otherwise your drift monitor will either scream or go quietly wrong.

Detection. This is the easiest drift to catch, because you control the trigger:

• Evaluation gates in CI. Any change to a prompt, retrieval parameter, index or model ID runs the regression suite before merge, blocking on statistically significant drops.
• A configuration hash in every trace. When quality moves, split the time series by configuration and see which change moved it.
• Structural diffs. Detect prompt changes made outside the release process, such as a hot-fix in a database row.

Failure mode. Prompts and retrieval settings that live in a database or a vendor console without version history. A change you can’t diff can’t be rolled back with confidence.

Deep dive 5: Usage drift, and monitoring in embedding space

Mechanism. The people using the system, and what they use it for, change. A pilot with a finance team expands to operations. A copilot built for policy questions starts being asked to draft emails. Seasonal patterns appear. The model may handle the new usage well or badly, but either way your evaluation set no longer represents your traffic, so your quality metrics no longer represent your quality.

Detection. For text inputs, the practical approach is to embed every query and monitor the distribution of embeddings. Evidently compared five methods for this: Euclidean distance between mean embeddings, cosine distance between mean embeddings, a domain classifier, the share of individually drifted dimensions, and MMD. They tested them on three text datasets with two embedding models. Their findings are worth knowing before you build anything:

• Cosine distance between centroids is fast but compressed. Drift showed up at cosine distances of around 0.001, and the method did not work after PCA. Thresholds must be calibrated per embedding model, because a “small” cosine change can be a large drift.
• MMD was very slow and weaker on the hardest dataset.
• The domain classifier was the recommended default. It was reasonably fast, consistent across embedding models and with or without PCA, and its ROC AUC threshold is easy to explain.
• Their caveat: an embedding shift doesn’t always mean a quality loss, so thresholds have to be tuned to the use case.

Alongside embedding drift, cluster queries into intents and track the intent mix weekly. Track cost and latency per request by intent too, because usage drift usually shows up in the bill before it shows up in a complaint.

Exhibit 7

vs. frozen launch baselinevs. previous week

Illustrative — not measured data. The same simulated traffic is compared against the launch baseline (falling line) and against the previous week (flat line). Each week differs only slightly from the last, so the week-over-week view never alarms.

A centroid check has a structural blind spot. It sees only the mean of the distribution. If a new cluster of queries appears while an old one shrinks, the average can stay put. If queries become more varied without changing on average, the centroid doesn’t move at all. In kernel terms, comparing means is what MMD reduces to when you use a plain linear kernel. The richer kernel is what lets MMD see spread and shape. That is why the cheap check needs a heavier second opinion, and why I would add an intent-mix monitor alongside it.

Thresholds and the false-alarm problem

Most drift-monitoring programmes don’t fail for lack of statistics. They fail because the alarms fire too often, nobody can tell which ones matter, and within a quarter the alerts are going to a channel nobody reads.

The arithmetic is unforgiving. Test 100 features independently at the conventional 5% significance level, and with no drift at all you should expect five false alarms per check. The probability of at least one is above 99%. Run that check hourly and you have built a machine that cries wolf all day.

Exhibit 8

5%

23%

40%

64%

92%

99%

1 test5102050100

Arithmetic illustration: 1 − 0.95ⁿ, assuming independent tests. Real features are correlated, which lowers the rate somewhat, but the direction holds. A 768-dimension embedding tested per dimension is effectively the right-hand column.

View data table

Independent tests per check	P(at least one false alarm)
1	5.0%
5	22.6%
10	40.1%
20	64.2%
50	92.3%
100	99.4%

Five practices get alarm rates down to something a team will actually respond to.

1. Calibrate thresholds from the baseline itself. Draw many random windows of the production window size from the baseline period, compute your statistic for each, and set the alert threshold at, say, the 99th percentile of that distribution. You now know the false-alarm rate per check by construction (about 1%), for your data, your embedding model and your window size. This replaces folklore cut-offs with a number you can defend.
2. Correct for multiple tests. Use a Bonferroni or false-discovery-rate correction across features, or reduce dimensionality first. Failing Loudly found per-dimension tests with Bonferroni correction competitive with multivariate tests.
3. Require persistence. Alert when the statistic stays beyond the threshold for several consecutive windows, not on a single spike. This trades a little detection delay for a large cut in noise. Because Vela found that some degradation is abrupt, keep a second, higher “cliff” threshold that alerts immediately.
4. Tier the checks. Run the cheap statistic continuously, the expensive one on alarm, and a human review only when both agree.
5. Judge drift by its effect on quality. Distribution shift is a reason to look, not a verdict. The decision about what to do depends on whether quality moved.

Exhibit 9

Concept drift: re-labelInputs look stable but quality fell. Refresh labels, sources and policies; input monitors will not catch this.

Incident: act nowLarge shift and quality loss. Roll back, re-index, re-prompt or retrain; owner paged.

Noise: log itSmall shift, no quality change. Record it and tune the threshold if it recurs.

Benign shift: re-baselineReal shift, quality holds. Review, extend the eval set to the new inputs, then refreeze the baseline.

Size of distribution shift →Measured quality impact →

Author’s framework.

The top-left quadrant is the one most programmes have no instrument for. It is also where the largest public failures sit.

The response playbook: versioning, pinning and rollback

Detection only pays off if someone acts on it. I treat drift as an incident class, with an owner, a severity scale and a playbook, the same way site-reliability teams treat latency or error-rate breaches.

Exhibit 10

1. 01BaselineAt launch, freeze reference samples of inputs, outputs, embeddings and eval scores, plus a version manifest.
2. 02DetectCheap checks continuously; heavier tests on alarm; canary evals daily on the production path.
3. 03TriageWhich clock moved? Check the version manifest and config hashes before touching the model.
4. 04RespondRoll back a version, re-index, re-prompt, re-tune, re-scope, or accept and re-baseline.
5. 05RememberAdd the failing cases to the eval set and write a short postmortem so the next detection is faster.

Author’s framework.

Triage is the step that saves the most time, and it rests on one artefact: a version manifest recorded with every request. At a minimum, it should capture:

• The model snapshot ID and every explicitly set parameter (temperature, effort, maximum tokens).
• The prompt template version, as a hash rather than a name.
• The retrieval index version, the embedding model and the chunking configuration.
• The reranker and tool definitions.
• The application release.

With that manifest, the first question in any drift incident (“did we change anything?”) takes minutes to answer instead of days.

The response follows from the diagnosis:

• Upstream model drift. Roll back to the last pinned snapshot if it is still available. If not, adapt prompts and parsers using the canary failures, and send the vendor a reproducible case rather than “it feels worse”.
• Prompt or retrieval drift. Revert through the pipeline that shipped the change, and confirm the fix in traces.
• Data or usage drift with a quality impact. Extend the eval set to the new inputs first, then add documents, adjust retrieval, tune prompts or retrain.
• Concept drift. Update the ground truth (policies, documents, labels), then retrain or re-index.
• Benign drift. Review it, extend the eval set, and refreeze the baseline deliberately, with a record of why. Re-baselining without a record is how slow degradation gets laundered into “normal”.

Case examples

Zillow Offers, 2021 (concept drift). When outcomes arrive months after a prediction, monitoring has to reach the people who set exposure limits, not just the modelling team.

GPT-4o in ChatGPT, April 2025 (upstream change). According to a Georgetown Law Tech Institute summary of OpenAI’s posts, an update released on 25 April made the model “overly flattering or agreeable” and was rolled back four days later. OpenAI said it had focused too much on short-term feedback. A vendor’s optimisation target can shift behaviour in ways no customer asked for. Only customers tracking tone, agreement and refusal rates would have seen it in their own traffic before the news did.

Claude, August–September 2025 (pinned model, drifting service). Anthropic’s remediations (more sensitive evaluations, continuous quality checks on production systems, character-output tests in deployment) are a monitoring programme any customer can mirror on its own side of the API.

Counterpoints

Implications by stakeholder

Exhibit 11

	Executives	Engineering leads	Practitioners	Risk & compliance
Mindset	Launch starts a cost line, not ends one	Drift is an incident class with an owner	Every alarm should leave the eval set stronger	Monitoring evidence is part of the control set
Ask for	A named owner and a quality trend per AI system	A version manifest in every trace	A bootstrapped false-alarm rate for each monitor	Post-market monitoring plans for high-risk uses
Fund	Labelling capacity for refreshed eval sets	Canary suites on the production path	Time to triage and write postmortems	Periodic independent review of thresholds
Red flag	“It’s live, so it’s done”	Prompts edited in a console with no history	A drift channel nobody reads	Monitoring that measures inputs only

Author’s framework.

If executives ask only one question of each AI system in production, it should be: show me quality over time against the launch baseline, and tell me who owns it. For risk and compliance teams, the key point is that input monitoring is not performance monitoring. A plan that can’t detect concept drift doesn’t meet the spirit of a post-market monitoring duty.

What to do next: a 30/60/90-day drift programme

Exhibit 12

1. DAYS 1–30Make change visiblePin model snapshots and set every parameter explicitly. Add a version manifest (model, prompt hash, index, embedding model, release) to every trace. Freeze a baseline sample of inputs, outputs and embeddings. Turn on output-shape metrics: length, refusal rate, schema validity, language mismatch.
2. DAYS 31–60Detect with calibrated alarmsRun a 50–200 prompt canary set daily on the production path. Add embedding drift (domain classifier or centroid plus MMD) and PSI or Wasserstein on key features. Set every threshold from a bootstrap of the baseline; add persistence rules and a separate cliff threshold.
3. DAYS 61–90Close the loopStart a monthly labelled sample of production traffic to track concept drift. Write the drift playbook with owners and severities, and rehearse it once with a simulated vendor change. Gate every prompt, index and model change on the eval suite in CI. Review alarm precision and retune.

Author’s framework.

Two things will tell you the programme works. Some alarms will lead to real fixes. And the false-alarm rate will be low enough that people read the alerts. If after 90 days you have neither, the thresholds are wrong, not the idea.

Limitations and methodology

The evidence has real gaps.

• Generalising from classic ML. Vela et al.’s evidence comes from tabular regression on 32 datasets. It shows degradation is common for classic models, not how often LLM systems degrade. I have not found a large independent study that measures that.
• Snapshot evidence on LLMs. Chen, Zaharia and Zou show that behaviour can change substantially under a stable name, not how often it does today. Vendors have since moved to pinned snapshots, which removes one mechanism.
• Self-reported incidents. The Anthropic postmortems are the vendor’s own accounts. The GPT-4o dates come from a secondary summary, because OpenAI’s original post could not be retrieved. Exhibit 4’s figures are my calculations from published dates.
• Detector benchmarks. Rabanser et al. and Evidently used synthetic shifts on public datasets. Their rankings may not transfer to your data.
• Exhibits and field notes. Exhibit 7 is illustrative and Exhibit 8 assumes independent tests. My field notes come from my own project records and have not been independently audited.

Closing

Every deployed model is moving away from the world it was built for, and with hosted LLMs, also on a path set by a supplier whose changes never appear in your repository. That is no reason not to deploy. It is a reason to stop calling deployment the finish line.

A production system is one where you would notice: a baseline frozen on launch day, alarms people trust, everything pinned that can be pinned, and every drift incident leaving the evaluation set stronger than it found it. Without that, what you have is a demo with a countdown.