Operations
Model drift
Also called: performance drift, silent regression
Definition
Model drift is the gradual decline of an AI system's real-world performance as the world, the data, or the underlying model changes beneath a deployment that has not itself been altered.
Drift is dangerous because it is silent. Nothing errors, no alert fires, and the dashboard stays green while decision quality erodes underneath it, often for months before anyone notices. In hosted-model deployments the substrate can change without notice, so a system that was carefully evaluated at launch may not be the same system six months later, even though nobody on your team touched a single line of configuration.
Brittleness was doing work
Rule-based systems failed loudly. When a rule stopped matching, something broke and somebody noticed almost immediately, because the failure mode was a visible error rather than a subtle degradation. Probabilistic systems degrade gracefully into being wrong, which removes the free alarm the old architecture provided and replaces it with a decline that is only visible if someone is deliberately measuring for it. This is a genuine cost of the newer technology that is rarely acknowledged in the enthusiasm for its other advantages.
Re-run the eval on a schedule
The frozen case set built for launch is the drift detector, and it only works if it is actually run again after launch rather than treated as a one-time gate. Running it monthly against production turns silent erosion into a visible line on a chart, at a cost far below the incident it prevents, since the alternative is discovering the decline only after it has already produced enough bad decisions to attract attention from a customer, an auditor, or a regulator.
Drift has more than one source
Performance can erode because the underlying model changed, because the mix of cases flowing through the system shifted, or because the world itself changed in a way the training data never reflected — a new fraud pattern, a new regulation, a shift in claimant behavior. Distinguishing between these sources matters because the fix is different in each case: a model change calls for re-evaluation against the frozen set, a mix shift calls for re-segmenting the analysis, and a world change calls for updating the calibration data itself, not just re-running the same test.
In practice
- Re-score the frozen case set on a fixed cadence and chart it
- Alert on distribution shift in inputs, not only on output quality
- Re-evaluate after every provider model version change
- Diagnose whether drift comes from the model, the case mix, or the world before fixing it
