A machine learning term, not a legal one
Model drift is a machine learning term, not a legal one. The EU AI Act never uses the phrase, and that’s exactly why it gets overlooked in compliance planning: nobody is searching the Regulation for a word that isn’t there. But drift, the gradual degradation of a model’s performance as the data it sees in production diverges from the data it was trained on, sits squarely inside several provisions that are already binding. Article 9 requires a risk management system that runs continuously throughout a high-risk system’s lifecycle, not just at launch. Article 15 requires that accuracy stay at or above the level declared in the instructions for use, and specifically addresses systems that keep learning after deployment. Article 72 requires providers to run a post-market monitoring plan that tracks real-world performance. And Article 26(5) gives deployers their own, separate duty to watch the system in their own environment and report what they see back to the provider. None of these provisions were written with the word “drift” in mind, but all of them describe exactly what happens when it occurs.
Data drift, concept drift, and why the distinction matters
Two related but different things usually get lumped together under “drift”:
- Data drift is a change in the statistical properties of the input data itself, the mix of customers, transactions, or images a model sees in production starts to look different from what it was trained on, even though the underlying relationship between inputs and correct outputs hasn’t changed.
- Concept drift is a change in that underlying relationship. The same input that used to predict one outcome now predicts something else, because the real-world pattern the model learned has shifted.
Both produce the same visible symptom, which is declining accuracy, but they call for different fixes. Data drift often means the model needs retraining on more representative data. Concept drift can mean the model’s fundamental logic no longer matches reality, regardless of how much data it sees. Knowing which one is happening matters when deciding whether a fix counts as routine maintenance or a change significant enough to affect the system’s compliance status.
Which provision covers what
| Provision | What it requires | Who it applies to |
|---|---|---|
| Article 9 | Continuous risk management throughout the system’s lifecycle, including identifying risks that emerge only after deployment | Provider |
| Article 15 | Accuracy at or above the level declared in the instructions for use; for continuously learning systems, safeguards against feedback loops and post-deployment bias | Provider |
| Article 72 | A documented post-market monitoring plan and system that actively tracks real-world performance data | Provider |
| Article 26(5) | Monitoring the system’s operation in the deployer’s own environment and reporting relevant findings back to the provider | Deployer |
| Article 26(6) | Retaining logs generated by the system for at least six months, the record a drift investigation actually depends on | Deployer |
| Article 73 | Reporting to the provider, and where necessary the relevant authority, if drift crosses into a serious incident | Provider and deployer |
In practice, a provider and a deployer are watching the same system for the same problem from two different view points. The provider is responsible for building the monitoring capability and for its own aggregate view across every deployment of the system. The deployer is responsible for watching what happens in its own specific environment and telling the provider when something looks off, since a provider several steps removed from the deployment has no way to see that on its own.
When drift becomes a reportable incident
Ordinary performance decline is not, on its own, a reporting event. It becomes one under Article 73 only if it results in, or could plausibly result in, death, serious injury, significant damage to property, a significant disruption to critical infrastructure, or a serious and irreversible infringement of fundamental rights obligations. Where drift does cross that line, the reporting clock runs on the same schedule as any other serious incident: 15 days as the standard window, 10 days where the incident has resulted in a death, and 2 days for the most severe cases, such as a widespread infringement or a serious disruption to critical infrastructure.
Most drift never gets anywhere near that threshold. What it does require, well before any incident-reporting question arises, is monitoring good enough to notice the decline before it gets there.
When drift triggers a new conformity assessment
A significant change to the system’s design, intended purpose, or risk profile can trigger the need for a new conformity assessment under Article 43(4). Retraining on substantially different data, or drift that materially changes how the system performs on safety-relevant tasks, is the kind of change that qualifies. Routine maintenance and minor updates that do not affect the system’s fundamental behaviour generally do not. For systems that keep learning after deployment, there is one carve-out: changes the provider already predetermined and documented in the technical documentation at the time of the original assessment do not count as a substantial modification, even if the model’s behaviour shifts as a result.
How Deeploy helps in catching model drift
Catching drift before it becomes a compliance problem depends on monitoring that runs continuously against a stable baseline, not a manual check run occasionally by whoever remembers to do it. Deeploy tracks model inputs and outputs against training data distributions in production, flags the point where performance starts to move outside expected bounds, and keeps that record in a form that maps directly onto what Article 9, Article 15, and Article 72 already ask a provider to demonstrate.
Frequently asked questions
Yes, though the obligation sits with whoever builds and places the resulting application on the market, not with the GPAI model provider. A company building a high-risk system on top of a third-party model such as GPT-4 or Claude is the provider of that high-risk system, even though it is only a deployer of the underlying GPAI model, and remains responsible for monitoring the system's real-world performance under Articles 9, 15, and 72 regardless of whether the underlying model itself changes. If the GPAI provider updates the model in a way that affects the application's behaviour, that is exactly the kind of change this monitoring is meant to catch.
At least six months, under Article 26(6), for logs generated automatically by the system and under the deployer's control.
When does model drift become a reportable serious incident? Only when it results in, or could plausibly result in, death, serious injury, significant property damage, a significant disruption to critical infrastructure, or a serious and irreversible infringement of fundamental rights obligations under Article 73. Ordinary performance decline below that threshold is a monitoring finding, not a reporting event.
Both, with different duties. The provider builds the monitoring capability and runs the post-market monitoring plan under Article 72. The deployer monitors the system in its own environment under Article 26(5) and reports what it sees back to the provider.
It isn't named directly. The Regulation doesn't use the term ‘model drift’ anywhere. What it does contain are several separate provisions, Article 9's continuous risk management duty, Article 15's accuracy requirement, and Article 72's post-market monitoring plan, that describe the same underlying problem without naming it.
