Drift, and the Article 72 post-market monitoring system

Accuracy measured at validation is a claim about the past. It holds while the world the system meets resembles the world it learned from, and it stops holding quietly, without an error, an alert or a failed test. Drift is the name for that, and post-market monitoring is the statutory response.

Three drifts, three detections

Data drift is a change in the distribution of inputs. Detectable directly, by comparing the live feature distribution to the training distribution, and detectable immediately because it needs no outcome data.

Concept drift is a change in the relationship between inputs and the thing being predicted. The inputs look normal and the model is simply wrong about what they mean. It is detectable only against outcomes, which means detection lags by however long an outcome takes to arrive. In claims that can be many months, and in credit it can be years.

Label drift is a change in how outcomes are recorded. A change in how a claim is coded as fraudulent, or a change in collections policy, changes the target without anything touching the model. It is detected by monitoring the outcome definition rather than the model, which is why it is usually missed: nobody is monitoring the definition.

The governance consequence of the lag is specific. Where outcomes arrive slowly, data drift monitoring is the only early warning available, and it has to be treated as a control rather than as diagnostics. A quarterly review of outcome accuracy on a system with a nine-month outcome lag is a review of a model that was retired two versions ago.

Article 72: a documented system, based on a plan

Article 72 requires providers to establish and document a post-market monitoring system, proportionate to the nature of the AI technology and the risks of the high-risk system. It must actively and systematically collect, document and analyse relevant data on performance throughout the system's lifetime, and it must be based on a post-market monitoring plan that forms part of the technical documentation in Annex IV.

That last clause is the one to build around. The plan is not an operational appendix; it is part of the technical documentation an authority can require. Two things follow. It has to be written at the same standard as the rest of the documentation, and it has to be kept current with the version actually running, because documentation that does not correspond to the deployed system is worse than none.

The plan should state the metrics collected and how, the data collected from deployers and other sources, the analysis cadence and who performs it, how continuous compliance is evaluated, how interaction with other AI systems is considered where relevant, the thresholds that trigger action, and the route from a monitoring finding into the risk management process under Article 9, which the Act frames as a continuous iterative process fed by post-market data.

Deployers are not passive here. Article 26 requires deployers to monitor operation in accordance with the instructions for use, to inform the provider where relevant, and to suspend use and notify where a risk is identified. A provider's post-market monitoring that has no channel from deployers is a plan that cannot work.

Retraining is a change, not maintenance

The common response to drift is retraining, and it is treated operationally as routine. It is not. A retrained model is a new model version: it needs the dataset record under Article 10, testing against the pre-declared thresholds, a fairness test, updated documentation, and a recorded link from the new version to the data behind it. Where the change is substantial, the Article 25 question arises for a deployer who retrains a vendor model.

Firms that automate retraining without wiring the governance artefacts into the pipeline end up with a production model that nothing documents. The fix is a release gate: the model cannot be promoted unless the record exists. Making the gate technical rather than procedural is the only version that survives a busy quarter.

Worked example: a bank detects drift it cannot confirm

A bank runs a small-business credit scoring model. Outcomes take eighteen months to mature, so concept drift cannot be measured in anything like real time.

The monitoring plan therefore rests on data drift and on intermediate signals. In month four, the input monitor fires: the proportion of applicants with less than two years of trading history has risen sharply. The model was trained on a population where that group was small, so its behaviour on the group is poorly evidenced.

The bank cannot yet say whether the model is wrong. It can say the population has moved outside the setting the data reflected, which is exactly the Article 10(4) point, and that the evidence supporting the model's performance does not cover the new population. That is enough to act on without waiting for outcomes.

The action taken was pre-agreed in the monitoring specification: applications from the affected segment are routed to manual assessment, the model's output is retained and recorded but not used to decide, and a validation exercise on the segment is scheduled. Retaining the unused output turns the next six months into an evaluation set, so when outcomes mature the bank has a direct comparison rather than a gap.

The monitoring plan is updated to add the trading-history feature as a standing KRI, and because the plan forms part of the technical documentation, that update is versioned with the documentation rather than made in a spreadsheet.

As of 24 September 2026.