Drift Is Real: Why AI Products Decay Quietly

Drift in AI products is real, and your dashboard cannot see it

Drift in AI products is the slow divergence between what your system does and what it is supposed to do, happening while every graph stays green. Ordinary software fails loudly: a 500, a timeout, a stack trace you can page someone about. An AI feature keeps returning fluent, confident, well formed answers the entire time it gets worse.

There is no exception to catch. That is the whole problem.

Four things move underneath every AI feature, and they move independently of each other: the questions users bring, the model, the corpus you retrieve from, and the definition of a good answer. Exactly one of those has a version number.

Why classic drift detection does not transfer

The academic framing predates the current wave. Gama and colleagues' 2014 survey defines concept drift as the relation between input data and the target variable changing over time, and the field's methods mostly assume labels eventually arrive. Fraud gets charged back. Churn happens.

An LLM product usually never gets a label. Nobody tells you the summary quietly dropped the one clause that mattered, and if ground truth arrives at all it arrives as a support ticket six weeks later, attached to an output nobody logged. That asymmetry is why drift here is a product management problem before it is an infrastructure problem.

The four kinds of drift, and how each one announces itself

Kind	What actually moves	How you usually find out
Input drift	The questions and documents users bring	Retrieval quality sags on a topic nobody tested
Model drift	Provider updates, or you migrate snapshots	A behavior changes with no code change on your side
Retrieval drift	The corpus grows, gets edited, gets re-chunked	The chunk that used to rank first stops ranking
Spec drift	The definition of a good answer	Someone in sales says "we stopped saying it that way"

These get lumped together as "the model got worse." They are four different failures with four different fixes, and conflating them is why teams spend a sprint tuning prompts when the real cause was a re-indexed corpus.

The evidence that model behavior moves under you

The clearest published study is Chen, Zaharia and Zou's longitudinal evaluation of GPT-3.5 and GPT-4. Testing the March 2023 and June 2023 versions on the same tasks, they found GPT-4 identified prime versus composite numbers at 84% accuracy in March and 51% in June, which they attribute partly to the model becoming less amenable to chain-of-thought prompting.

That paper drew a direct rebuttal from Arvind Narayanan and Sayash Kapoor, who argued the result largely reflects a change in answer format and instruction following rather than a loss of underlying capability. The original authors acknowledge the critique in later revisions.

For a product team, the argument barely matters. Both readings say the same operational thing: identical call, identical prompt, materially different output, no release note. If your product depended on that format, your product broke.

The best documented drift incident was caught by humans, not evals

In April 2025, OpenAI shipped a GPT-4o update that made the model markedly sycophantic, then rolled it back four days later. The postmortem is the useful part. In their expanded write-up, OpenAI states that offline evaluations generally looked good, A/B tests suggested users liked the model, and there were no deployment evaluations tracking sycophancy at all. Some expert testers reported the behavior "felt" slightly off, and that qualitative signal turned out to be the accurate one.

Read that again in your own context. A frontier lab, with more eval infrastructure than your company will build this decade, shipped a behavior regression that its automated suite scored as fine and its humans caught by feel.

This is the inference I would build a process around: automated evals measure regression against yesterday's definition of good. They are structurally incapable of noticing that the definition moved.

Users drift too, and they drift because of you

The four kinds above are things that move underneath you. User behavior is different in kind, because it is a loop. Your product changes how people use it, that usage becomes your data, and your data shapes the next version of the product.

Three mechanisms, worst first:

Users adapt their prompts. They learn what phrasing works and quietly route around your weak spots. Six months in, your logs are no longer a sample of what users want. They are a record of what users learned to ask. Any golden set drawn from those logs encodes your own past failures as the target.

Trust decalibrates. Parasuraman and Riley's survey of human-automation interaction defines misuse as over-reliance on automation, producing failures of monitoring and decision bias. Applied here, and I am flagging this as analogy rather than evidence, since that literature predates LLMs and studied aviation and decision aids: output quality can hold perfectly steady while verification behavior collapses. Harm rises. No metric moves.

You then train on the drifted user. The sycophancy case above is exactly this loop closing. OpenAI's own account points to short-term feedback being weighted too heavily. Tuning on aggregate thumbs data is not measuring quality, it is measuring what an already-adapted population rewards.

The fix here is distinct from the other four, which is why it deserves its own section. Sample new-user cohorts, not your logs. Power users have adapted; the people your product genuinely failed already left, so your telemetry is survivorship-biased by construction.

The uncomfortable part: your eval set drifts too

Here is the failure practitioners learn the hard way. Your golden set is a frozen opinion about what good meant on the day you wrote it, drawn from a user population that has since changed shape.

The business changes. Legal adds a disclaimer requirement. Sales repositions the product and the old phrasing is now wrong. A new segment brings questions your rubric never anticipated. None of that touches your eval suite, so the suite keeps returning 96% while the product drifts away from the job it was hired for.

Spec drift is invisible to every automated check, because the check is the thing that is out of date. "We have evals" is not an answer to drift. An unrefreshed eval set eventually becomes a machine for certifying the wrong behavior with high confidence.

Pinning the model buys you time, not stability

The standard advice is to pin your model version and stop floating on aliases. That advice is right, and it is a smaller win than it sounds.

Pinned models do not drift. They expire.

Anthropic's model deprecations page commits to at least 60 days notice before retiring a publicly released model, with an explicit lifecycle of active, legacy, deprecated, retired, and requests to retired models failing outright. In practice the clock runs fast: claude-3-5-sonnet-20241022 was deprecated on 13 August 2025 and retired on 28 October 2025.

So a pin is a lease. You get stable behavior for a quarter or a few, then take the full behavior delta in a single migration, on a date someone else picked, usually alongside whatever else your roadmap promised that month. The drift did not go away. It got batched.

What is worth optimising, then, is not stability. It is the cost of switching. An eval harness that turns a model migration into a two hour decision instead of a two week regression hunt is the actual asset.

What to actually build

Ordered by return on effort:

1. Pin the version and put the retirement date on the roadmap. Not the backlog. A dated calendar entry with an owner, sized like a feature, because that is what it is.
2. Keep 50 to 200 real cases with graded answers, and refresh them quarterly. Delete roughly a fifth each cycle and replace with recent traffic, weighted toward new-user sessions. The refresh is the mechanism; the size is not.
3. Log the full trace, not the final answer. Model version, prompt version, retrieved chunk identifiers, tool calls. Without attribution you cannot separate retrieval drift from model drift, and you will tune the wrong layer.
4. Have someone who owns the outcome read 20 to 30 live outputs a week. Not a contractor against a rubric. The person who gets blamed if the product is wrong. This is the only reliable detector for spec drift.
5. Treat prompt edits and index rebuilds as releases. Providers ship on a schedule you can look up. Your own team ships on Thursdays without telling anyone. Before blaming the model, check the changelog you should have been keeping.

Who should skip all of this: if you are pre-product-market-fit with fifty users and one prompt, read every output yourself. That is your eval, and it is better than anything you would build. The machinery earns its cost around the point where you can no longer read everything, or where a paying customer has an expectation written into a contract.

Where this gets worse, and what we still do not know

Agents compound the problem, and I would treat this as reasoning rather than measured fact: in a multi-step chain, a small shift in step behavior propagates through every downstream decision, and grading only the final output tells you nothing about which step moved. Trajectory-level evaluation is the honest requirement, and it is meaningfully harder to build than answer grading.

Three things I have not found good public evidence on. How fast enterprise retrieval corpora actually drift in practice. Whether any defensible refresh cadence for eval sets exists beyond "quarterly feels right." And how quickly user prompting behavior converges around a product's quirks, which would tell us how fast log-derived eval sets go stale. If you have real numbers on any of these, they are worth more than another framework.

The takeaway

Drift is not an edge case in AI products. It is the default state, because four systems move independently under every feature, a fifth loop runs between your users and your data, and only one of them tells you when it changes.

Concrete next step: take your highest-traffic AI feature and answer three questions today. What model version is it pinned to, what date does that version die, and who last decided what a good answer looks like. If any answer is "nobody knows," you do not have a drift risk. You have drift.