How to monitor AI systems for drift

An AI risk assessment is a photograph. On the day it was signed it described the system, and every day afterwards the system and the world move while the photograph does not. Drift is the name for that widening distance. It deserves its own practice because the expensive AI failures are rarely systems nobody assessed. They are systems that kept running after their behaviour moved outside what was assessed, with the time between departure and detection deciding the size of the damage.

Four places drift comes from

The inputs. The data flowing into a system moves away from what the system was assessed and, where relevant, trained on. Customer profiles shift, upstream systems change formats, the world the data describes changes. Input drift is usually the earliest signal, arriving before output quality visibly degrades.

The outputs. Quality, error patterns and behaviour move against the standards the assessment assumed. Output drift is the kind people mean when they say a system “got worse”, and by the time humans notice it unaided, it has usually been happening for a while.

The usage. The system itself may be unchanged while the organisation’s use of it drifts towards new purposes, new populations and new stakes. A system assessed for internal drafting that quietly becomes the engine of customer-facing decisions has drifted as surely as if the model had changed, and no amount of model monitoring will catch it.

The vendor. For organisations that consume AI rather than build it, which is most organisations, the largest drift source is the model changing underneath you. Vendors update models, adjust defaults, deprecate versions and switch on features, sometimes announced, often not. The system you assessed is then not the system you run, and nothing in your own monitoring data announces the moment it happened. Two checks help. Compare the model your traffic actually reaches with the model your record says the system uses, and track what each provider publishes about the models you depend on.

Thresholds are a governance decision

Raw drift metrics are easy to produce and easy to ignore. The work that makes monitoring real is deciding, per system, what movement matters and who does what when it moves. The form that works is a sentence with an owner in it, along the lines of “if this signal passes this point, this person reviews, retests or escalates”. Setting the threshold is a governance decision in itself, because it encodes how far from its assessed behaviour your organisation is willing to let a system travel before anyone looks. For higher-risk systems that tolerance should be tighter and written down.

Scale the effort to the risk. Monitoring everything equally is a way of monitoring nothing well. The systems whose drift can hurt people or the organisation earn continuous signals and tight thresholds, while a low-stakes internal tool may earn a usage check at review time. The risk assessment is the instrument that tells you which is which.

Close the loop into the record

A drift signal that leads nowhere is trivia. The point of noticing that a system has moved outside what was assessed is that the governance responds. The assessment is revisited, a control is adjusted, a guardrail is tightened or the finding matures into an incident and is handled as one. That only happens reliably if what monitoring finds lands in the governance record, against the system it concerns, in front of the person who owns it. Monitoring that lives in an engineering dashboard while governance lives in documents produces two accounts of the same system that stop matching, which is drift of a second and more embarrassing kind.

What the frameworks say

The NIST AI Risk Management Framework treats post-deployment monitoring as part of its Manage function, with plans for monitoring deployed systems, capturing feedback and responding to change. ISO/IEC 42001 asks for AI systems to be monitored in operation and for the results to feed the management system’s review and improvement. In Australia, the Guidance for AI Adoption, published by the National AI Centre in the Department of Industry, Science and Resources, makes “test and monitor” one of its six essential practices.

Where Aicura fits

At Pro, Aicura tracks monitoring figures against the same AI systems on the register that the assessments cover. The data comes from small services that run inside your own environment and send figures back. Those figures include drift, error rate and a model mismatch check that flags when a system’s traffic reaches a different model from the one its record names. You set alert limits on any figure, and each alert waits for a person to accept, dismiss or defer it. Guardian, Aicura’s automatic response feature, can be set up to re-run the risk assessment or notify the owner when a condition you set holds.

For vendor drift, each model on the register shows the provider’s stated status, such as preview or deprecated, beside your own approval status for it. When a provider notice is published against a model, it reaches every system that uses that model, so the owner can record a response. The figures are counts and dates, not verdicts. What a moving indicator means for a system stays with the owner the alert reaches.

A note on this page

This guide describes the practice of monitoring AI systems for drift in governance terms. The right signals and thresholds depend on your systems and your risk, and the statistical detail of drift detection is its own field. It is general information, not advice.