The user wants to understand Model Drift in the context of AI Safety & Risk and apply it to practical AI governance or compliance work.
Model drift is the degradation or change in model performance over time as real-world data, user behavior, or operating conditions diverge from the data used during training or evaluation. Detecting drift is important for deciding when to retrain, recalibrate, or replace a model.
Model drift is a change in model performance or behaviour over time because real-world data, user behaviour, operating conditions, or the relationship between inputs and outcomes no longer match the conditions used during training or evaluation. It is a lifecycle risk, not just a technical metric. Drift can make an AI system less accurate, less fair, less safe, or less compliant even if it worked well at launch.
Model drift means the world has moved, but the model has not kept up. A fraud model trained on old transaction patterns may miss new fraud tactics. A demand forecast may fail after market behaviour changes. A moderation model may degrade as users invent new slang. Monitoring drift helps teams decide when to investigate, recalibrate, retrain, restrict, or retire a model.
Analogy
A map can be accurate when printed and still become unreliable after roads, traffic, and destinations change.
Model drift matters because many AI controls are validated at a point in time, while deployment environments keep changing. If drift is not monitored, organisations may keep relying on a system whose assumptions are no longer true. That can create errors, bias, unsafe recommendations, customer harm, regulatory exposure, and poor business decisions. For compliance teams, drift monitoring is part of post-deployment governance: it supports auditability, incident detection, retraining decisions, model-change control, and evidence that the system remains fit for its intended purpose.
Urgency
Models used in dynamic, high-impact, regulated, or customer-facing environments should have drift monitoring before production reliance.
A practical drift program defines baseline data, performance metrics, fairness metrics, monitoring frequency, alert thresholds, owners, and response playbooks. Teams should distinguish data drift, where input data distribution changes, from concept drift, where the relationship between inputs and outcomes changes. Monitoring should be linked to operational decisions: investigate, update thresholds, recalibrate, retrain, rollback, suspend, or escalate. Drift records should document the signal, impact analysis, root cause, mitigation, approval, and validation after change. For regulated or high-risk systems, these records should connect to the AI inventory, risk assessment, and safety case.
The most common mistake is assuming that a model approved at launch remains approved forever. Another mistake is monitoring only overall accuracy while ignoring subgroup performance, calibration, fairness, confidence, data quality, and business-process changes. Teams also confuse data drift with concept drift, or they detect drift but have no owner or playbook for response. A final governance mistake is retraining automatically without reviewing whether the new data is lawful, representative, secure, and aligned with the intended purpose.
Mistake 1: Retraining a model after performance drops without investigating whether the new data reflects fraud, bias, seasonality, or process change.
Mistake 2: Monitoring aggregate performance while missing that the model has degraded for a smaller protected or vulnerable group.
This page should link to data-drift and concept-drift because those terms explain the two most important drift patterns. It should also link to ai-safety, ai-risk-assessment, monitoring, and safety-case concepts because drift is a post-deployment assurance issue. The strongest comparisons are model-drift-vs-concept-drift and data-drift-vs-model-drift. Related questions include what-is-a-safety-case-for-ai, how-is-data-drift-different-from-concept-drift, and what-is-ai-safety. The incident link CASE-0575 can be used as a learning anchor for performance degradation and monitoring failure.