What is our process for model drift monitoring?

A model that passes all pre-deployment testing may behave differently in production as the world changes around it. Data drift happens when the data coming into the model changes over time, for example when a new customer segment starts applying. Concept drift happens when the real-world link between the inputs and the right answer changes, often because the thing the model was trained to predict has itself changed. Both can cause a previously compliant model to become inaccurate, biased, or harmful without any change to the model itself.

Regulatory frameworks including the EU AI Act and NIST AI RMF explicitly address post-deployment monitoring requirements. For high-risk systems, the EU AI Act requires post-market monitoring plans and logging of system operation. The regulatory expectation is that governance is ongoing, not a one-time pre-deployment exercise.

Monitor the pattern of outputs: are the model's results shifting over time? A credit scoring model that is approving an increasing proportion of applications, or a hiring model that is rejecting more candidates in a particular category, may be exhibiting drift. Standard statistical checks can flag when the pattern of outputs moves outside its expected range.

Monitor input data quality: is the data the model relies on behaving as expected? Missing values, out-of-range inputs, and shifts in key data fields are early signs of drift. Where you later learn the real outcome (whether a loan was repaid, whether a flagged transaction was fraud), compare it to what the model predicted. Track overall accuracy, how often the model's flags are wrong, how often it misses real cases, and fairness measures for each group.

Establish monitoring cadences proportionate to risk. High-risk systems in rapidly changing environments may require weekly or even daily monitoring. Lower-risk systems in stable environments may be adequately served by monthly or quarterly reviews.

Assign explicit ownership for post-deployment monitoring to a named role or team. Without ownership, monitoring activities are consistently deprioritized in favor of new deployments. The owner is responsible for running monitoring checks, reviewing results, escalating anomalies, and initiating retraining or retirement processes when drift is detected.

Define response thresholds in advance: at what level of detected drift does the system get flagged for review? At what level is it paused pending investigation? At what level is it retired? These thresholds should be calibrated to the risk level of the system and documented before deployment, not determined on the fly when something goes wrong.

The Financial Stability Board's consultation report on responsible AI adoption sets out 12 practices that apply to banks, insurers, and other regulated financial entities. On post-deployment monitoring specifically, the FSB expects institutions to conduct regular performance reviews that include drift detection and outcome fairness assessments, and to embed human review mechanisms at high-impact decision points. These expectations align closely with model risk management frameworks already familiar to financial firms, so institutions should map their drift monitoring programs to existing model validation and independent review processes rather than treating AI monitoring as a separate discipline.

Third-party AI systems require particular attention under the FSB guidance. If a model producing decisions is sourced from an external vendor, the institution remains responsible for ongoing monitoring and must support that obligation through contractual provisions and due diligence. Documentation requirements span the full AI lifecycle, meaning drift monitoring logs, threshold decisions, and escalation records should be retained as part of the model's lifecycle record, not discarded after each review cycle.