AI drift
Why governance comes before technical execution
AI model drift refers to the gradual degradation of its performance after deployment, as reality evolves without the model being updated. This phenomenon is well known to technical teams, but it is rarely governed by a formal framework. It is precisely at this level that the risk becomes concrete.
An AI model deployed in production is not a static asset. It is a living system, exposed to changing data, evolving behaviours and shifting regulatory contexts. Yet, once the project is signed off and delivered, many organisations move on, implicitly assuming that the model will continue to perform just as it did on day one.
It is this silent assumption that is at the heart of the problem.
What is AI model drift in production?
Drift, or model drift, refers to the gradual degradation of a model's performance after deployment. It occurs because the world the model analyses continues to evolve, while it remains frozen in what it learned during training.
Its most formidable characteristic: it is silent. The system continues to produce normal-looking results. No breakdown, no alert, no visible incident. But decisions gradually become less fair. Some cases are misdirected, others wrongly blocked, without anyone being warned.
To concretely illustrate this phenomenon, let us take the fictitious example of a medium-sized mutual insurance company that deploys an AI model to sort reimbursement claims. Some files are validated automatically, while others are referred for human review.
At launch, the model is performant, rigorously tested and validated by the technical team. Eighteen months later, new types of care, new policyholder behaviours and regulatory developments have transformed the profile of claims.
The model itself still applies the regularities from two years ago.
Mistakes are quietly piling up.
Why are pre-deployment tests not enough?
The validation tests carried out prior to deployment provide an accurate snapshot of the model's performance at a given point in time. They do not constitute a permanent guarantee.
Once in production, several dynamics can alter its performance:
Data drift, or data drift the input data differs from that used during training.
Concept drift, or concept drift the relationship between the input variables and the target variable changes over time.
Contextual changes: new regulations, new user behaviours or new categories of cases appear even though they were not represented in historical data.
A model can therefore be perfectly valid at launch, and then gradually fail, without the system emitting the slightest warning signal
Is drift a technical problem or a governance problem?
This is a fundamental question, and the answer changes everything.
Data science teams are generally very familiar with the phenomenon of drift. It is not a technical blind spot. What is missing, in the vast majority of organisations, is a framework capable of turning this knowledge into concrete action.
Let's take back the example of the fictitious mutual insurance company. In this scenario, the data scientists were aware of the risk of drift. Yet, eighteen months after deployment, no one was formally responsible for monitoring the model. No regular measurement process had been defined. No alert thresholds had been set. And in the event of a problem, no one knew who should be informed or what measures should be taken.
Knowing a risk is not enough to control it.
What makes the difference is governance: clearly allocated responsibility, a defined process and a prepared response.
How to set up effective post-deployment monitoring?
What are the regulatory obligations linked to the post-deployment monitoring of AI systems?
The issue of monitoring is not just a matter of good practice; it can constitute a legal obligation.
The NIST AI Risk Management Framework recommends continuous evaluation of AI systems in real-world conditions throughout their lifecycle. Meanwhile, the’European AI Act mandates, for high-risk AI systems, a post-market monitoring system (post-market monitoring) which must be actively maintained after deployment.
These requirements do not implement themselves. They assume that someone in the organisation is responsible for them and that the associated processes are formalised.
For systems that influence access to rights or that make decisions affecting individuals, ignoring this dimension means exposing the organisation to both operational and compliance risks.
What are the regulatory obligations linked to the post-deployment monitoring of AI systems?
The issue of monitoring is not just a matter of good practice; it can constitute a legal obligation.
The NIST AI Risk Management Framework recommends continuous evaluation of AI systems in real-world conditions throughout their lifecycle. Meanwhile, the’European AI Act mandates, for high-risk AI systems, a post-market monitoring system (post-market monitoring) which must be actively maintained after deployment.
These requirements do not implement themselves. They assume that someone in the organisation is responsible for them and that the associated processes are formalised.
For systems that influence access to rights or that make decisions affecting individuals, ignoring this dimension means exposing the organisation to both operational and compliance risks.
The real question every organisation should ask itself
An AI model is never static, and its reliability is never guaranteed. It must be monitored; and monitoring implies designating who is responsible, how measurements are taken, and what follow-up actions are taken.
So the real question is not just «is our system working properly today?», but «will we recognise the day it stops working properly — and will we know what to do?»
This is the question governance must answer.
FAQ: AI model drift and post-deployment governance
Drift refers to the gradual degradation of a model's performance after deployment, because the reality it analyses evolves while it remains fixed on what it has learned. It is silent: the system continues to produce results that appear normal, but are increasingly less reliable, without any breakdown or obvious alert.
Pre-deployment tests provide a snapshot of performance at a given point in time. They do not take account of future changes: new data, new behaviours, regulatory shifts. A model that is validated at launch can become faulty without anything signalling it.
Both dimensions exist, but the weak spot is almost always governance. Technical teams generally know about the phenomenon. What is missing is clearly assigned accountability, a monitoring process, alert thresholds and a response plan. Knowing the risk is not enough to manage it.
At the very least: appoint a monitoring officer, measure performance regularly and by sub-group, set alert thresholds that automatically trigger a review, and prepare a documented response plan (correction, retraining, suspension).
For high-risk AI systems covered by the European AI Act, a post-market monitoring mechanism is explicitly required throughout their lifecycle. The NIST also recommends continuous evaluation in real-world conditions. Beyond compliance obligations, this is a necessity as soon as the system influences decisions that affect people.
