Older than AI, and built for it

Banks have been managing model risk formally since at least the US Federal Reserve's SR 11-7 guidance in 2011, because a mispriced derivative or a miscalibrated credit model can lose money quietly for years before anyone notices. The discipline that grew up around that problem has four parts: an inventory of every model in use, an independent validation of each before and during use, a tiering of models by materiality so that effort goes where the exposure is, and named ownership with reporting to the board.

That is a remarkably good fit for AI, and UK regulators have said so explicitly. The PRA's supervisory statement SS1/23, *Model risk management principles for banks*, took effect on 17 May 2024 and treats AI and machine learning models as models, with the same five principles applied and some specific points about their opacity, their data dependence and the difficulty of validating them. It also requires a board-approved model risk appetite, which is the closest thing UK regulation has to a mandated AI risk appetite.

The five principles, and what AI does to each

SS1/23 organises the discipline into five principles. Each survives contact with a language model, and each gets harder.

  • Model identification and classification. You cannot manage what you have not listed. An AI model embedded in a vendor product, or a general-purpose model reached through an API, is still a model and still goes in the inventory; see AI inventory. Materiality tiering has to account for a model that touches many decisions lightly rather than one decision heavily.
  • Governance. The board owns the framework and the appetite. Senior management owns the models. For AI this means someone accountable for a model they did not build and cannot fully inspect, which is the third-party risk problem in a governance frame.
  • Model development, implementation and use. Documentation of what the model is for, its limitations and its intended use, so that misuse is recognisable. A model card is the AI-native form of this.
  • Independent model validation. Someone other than the developer tests it before use and periodically after. For a probabilistic model this is testing AI systems against a fixed evaluation set with a threshold, repeated on every version, including the vendor's silent ones; see model versioning.
  • Model risk mitigants. Compensating controls for known weaknesses: human review at material decisions, output validation, monitoring for drift, and a plan for what happens when the model has to be switched off.

What changes for generative and third-party models

Three things in particular strain a traditional MRM framework, and every firm applying SS1/23 to AI has had to answer them.

The model is not yours. A foundation model reached through an API cannot be validated in the classical sense; its training data, weights and update schedule are the provider's. Validation becomes a test of the assembled system in the firm's own use, against the firm's own evaluation set, with the provider's own claims treated as due diligence input rather than evidence.

The model changes without telling you. Provider updates alter behaviour without a version number the firm controls. The mitigant is the firm's own regression suite run on a schedule, and a contractual right to notice; see performance regression.

The output is not a number. Classical validation compares predictions to outcomes. Generated text has no ground truth in the same sense, so validation has to be built from structural checks, sampled human review and, where the use case allows, a deterministic specification the output can be tested against.

Outside banking

The frame travels. Insurers, asset managers and payment firms in the UK are not formally in scope of SS1/23 but are asked the same questions by the FCA under the Consumer Duty and by the Senior Managers regime, which attaches personal accountability to the outcomes of an AI-enabled process. Outside financial services, MRM is the most mature template available for the inventory-validate-monitor-own cycle that ISO/IEC 42001 and the NIST AI RMF both describe in more general language, and a governance team that adopts its vocabulary inherits fifteen years of practice.

Where it sits in the register

AI lifecycle controls gap is what an MRM framework exists to close, and AI model drift and degradation and untested AI failure scenarios are the two failures independent validation is meant to catch. Unclear AI ownership and accountability is the governance principle stated as its absence. On the control side: the ownership and accountability framework, AI system monitoring and logging, third-party model due diligence, and incident response and rollback for the day a model has to come out of service.