Model risk management for AI: from validation to live monitoring

Model risk management (MRM) is the set of controls a firm uses to govern the models behind its decisions. It covers how a model is designed, how it is validated before use, and how it is monitored once live. The aim is to catch error, bias and drift before they reach a customer.

The UK baseline is the PRA's model risk management principles (SS1/23), which set five expectations:

1. Model identification and a model inventory.
2. Governance, with clear ownership and oversight.
3. Development, implementation and use standards.
4. Independent validation.
5. Risk mitigation, including monitoring and controls.

Crucially, those principles apply regardless of the technology and cover vendor models as well as ones built in-house. That matters, because AI is about to test every one of them.

Most model governance was designed around models that change on a fixed release cycle: you validate at deployment, then revisit annually. AI does not behave that way. As the Mills Review puts it, general-purpose and frontier models "can introduce challenges including opacity, model drift, data bias, hallucinations and emergent behaviours that are not always well addressed through traditional point-in-time validation approaches."

Three features drive the problem. Models update continuously, so the thing you validated is not the thing running next quarter. They draw on third-party inputs the firm "did not create or build," so control sits partly upstream. And they are probabilistic, so the same input can produce different outputs. A once-a-year review cannot see any of that in time.

The Review is explicit that governance has to move. Model risk management should extend "beyond validation at the point of deployment towards live monitoring, tracking drift, model degradation and outliers," supported by "end-to-end controls across the AI lifecycle." It expects the FCA, with the PRA, to support more effective approaches to AI model risk as AI becomes a core operational capability.

That last phrase matters. The Review treats AI governance and model risk management not as a compliance overhead but as "a core capability" firms need to deploy AI at all. It is the same argument we make in why compliance is becoming a competitive advantage: the firms that can govern their models get to use them with confidence, and the firms that cannot move slower. None of this requires new rules; the Review builds on existing frameworks. For the wider picture, see what the Mills Review is.

The Review frames AI governance across the familiar three lines. In the first line, AI supports customer operations and delivery. In the second, it supports risk, compliance and monitoring. In the third, it supports internal audit, assurance and testing. Across all three, it notes, "AI can increase speed and scale, but it also requires stronger evidence of control."

For model risk that means each line needs to see the model, not just its outputs. The first line needs to know when to override. The second needs live signals, not quarterly samples. The third needs an auditable record of how the model behaved and changed. Explainability is the connective tissue: a control the three lines cannot interpret is not really a control.

Live monitoring is where MRM for AI actually differs from the old model. Instead of a validation report filed at go-live, the firm watches the model as it runs: tracking whether its decisions stay within the tested baseline, whether error rates creep up on particular segments, and whether outputs start to skew in ways that suggest bias or degradation.

Data quality is the foundation under all of it, which is why the CCAF found data quality to be the single biggest barrier to AI adoption, cited by 66% of vendors. A model is only as reliable as the inputs it runs on, and in lending those inputs are messy: photos, scans, protected PDFs and emails. Catching a problem early depends on running the check on every case as it moves, the argument behind real-time compliance monitoring, rather than discovering it in a sample months later.

Consider a lender using an AI model to pre-assess affordability. Under the old approach, the model is validated at launch and reviewed next year. Under the approach the Mills Review points to, the lender monitors it continuously: every case the model touches is logged, its decisions are checked against the validated baseline, and an alert fires when behaviour drifts, for example if approval rates shift for a particular applicant profile.

When a provider updates the underlying model, the lender does not assume the old validation holds. It re-tests against real cases and records the result. The output is a living evidence trail rather than a document in a drawer, which is exactly what a supervisor, or an accountable senior manager, now needs to see. Whether to build or buy that capability is its own decision, covered in building or buying AI.

1. Inventory every AI model touching a regulated decision, and record its owner and provider.
2. Validate before deployment against real, representative cases, not just vendor benchmarks.
3. Monitor continuously for drift, degradation and out-of-bounds behaviour, rather than annually.
4. Set data-quality controls, because a model is only as reliable as the inputs it runs on.
5. Keep lifecycle evidence: versions, changes, overrides and outcomes, ready for supervision.