AI Model Risk Management Under PRA SS1/23: What COOs and CROs Actually Need to Do

The PRA published SS1/23 in May 2023 as the UK's definitive supervisory statement on model risk management. It replaced a patchwork of earlier guidance and, for the first time, gave UK-regulated firms a single framework for how the supervisor expects models to be governed across their full lifecycle. For firms deploying AI at scale, SS1/23 is the document that determines whether your model risk posture is defensible or not.

And yet, of the COOs and CROs we work with across Tier 1 and Tier 2 banks, most of them will tell you the same thing: SS1/23 landed, the model risk function read it, and the organisation has not yet fully reconciled its AI portfolio against the new expectations. The gap between "we have read the supervisory statement" and "we could walk the PRA through our AI governance with full evidence" is, in most firms, measured in years.

This post is a practical guide to closing that gap. Not the theory of model risk management, but the specific things a COO or CRO needs to have in place to satisfy SS1/23 when the supervisor asks.

What SS1/23 actually requires

SS1/23 is built around the concept of a model risk management framework (MRMF) that covers the entire model lifecycle: development, validation, deployment, monitoring, and retirement. The supervisory expectations are structured around five areas:

1. Model identification and inventory. The firm must have a complete, accurate, and current inventory of all models in use, including AI and ML models. This sounds straightforward. In practice, most firms have a model inventory that covers their pricing and market risk models but does not include the AI tools that have been deployed in operations, customer service, fraud detection, or regulatory reporting.

2. Model development standards. Models must be developed according to documented standards that cover data quality, methodology selection, testing, and documentation. For AI models, this means the firm must be able to explain what data the model was trained on, what methodology was used, what testing was performed, and what the model's limitations are.

3. Independent model validation. Every material model must be independently validated before deployment and on a periodic basis thereafter. The validation function must be genuinely independent of the development function. For AI models, validation means more than checking that the model performs well on a test set. It means assessing bias, fairness, explainability, and robustness.

4. Model performance monitoring. Models in production must be monitored continuously for performance degradation, drift, and unexpected behaviour. The monitoring framework must include defined thresholds for escalation and remediation. For AI models, this is where most firms are weakest: they deploy a model and do not have continuous monitoring in place.

5. Board and senior management accountability. The board must approve the MRMF and receive regular reporting on model risk. Senior management must be accountable for the models in their area under SMCR. This means that the COO or CRO who owns an AI-driven workflow is personally accountable for the model risk it generates.

The PRA's full supervisory statement is worth reading in its entirety. It is unusually clear for a supervisory document.

Where most firms are stuck

Based on the AI enablement engagements we have run inside FTSE 100 banks and large insurers, the gaps cluster in three areas:

The model inventory is incomplete

Most firms have a model inventory that was built for traditional models (credit risk, market risk, pricing) and has not been updated to include the AI and ML models that have been deployed across operations in the last three years. Fraud detection models, customer chatbots, document classification systems, alert triage tools, and GenAI assistants are often not in the inventory at all, or are classified as "tools" rather than "models" to avoid the governance overhead.

The PRA does not distinguish between "models" and "tools" in SS1/23. If it takes data, applies logic, and produces an output that informs a business decision, it is a model. The first step in any AI enablement engagement is to build the honest inventory and triage every item against SS1/23.

Validation is not independent

For traditional models, the validation function (typically second-line model risk) has years of experience and established methodology. For AI models, the validation function often does not have the technical skills to assess an ML model independently. In many firms, the AI team "validates" its own models by running standard ML evaluation metrics and presenting the results to second-line risk. That is not independent validation under SS1/23.

The fix is structural: the model risk function needs AI-literate validation specialists, or the firm needs to engage an external model risk specialist to provide independent validation. Our AI Governance and Model Risk course covers the detailed mechanics of what independent validation looks like for AI models.

Monitoring is absent or ceremonial

The hardest part of SS1/23 compliance for AI models is continuous monitoring. Traditional models are monitored on a periodic basis (quarterly or annually). AI models, particularly those operating in production on real-time data, need continuous monitoring: drift detection, override rate tracking, decision log analysis, and anomaly detection.

Most firms do not have this. They deploy a model, check it once at validation, and then leave it running until someone notices a problem. Under SS1/23, this is not defensible. The action-data layer architecture we use in AI enablement engagements is designed to make monitoring a by-product of the workflow rather than a separate activity.

The governance machinery that actually works

Based on our experience across banking, insurance, and asset management, the governance machinery that satisfies SS1/23 has four structural features:

1. Embedded second-line risk from day one

The second-line model risk specialist is part of the AI project team from the design phase, not a reviewer who shows up at a deployment gate. This means model risk requirements shape the data layer, the decision rights, and the monitoring stack from the start. Evidence is captured as a by-product of build rather than retrofitted for review.

2. Decision logs as the primary evidence artefact

Every decision the AI system makes is logged with the inputs, the model output, the human override (if any), and the rationale. These logs are queryable on demand and form the primary evidence base for the PRA review. This is what we mean by evidence as a by-product of the workflow.

3. Continuous monitoring with defined escalation thresholds

The monitoring framework is not a quarterly report. It is a continuous system that tracks model performance, drift, override rates, and anomaly patterns in real time. When a threshold is breached, the system escalates to the model owner, the second-line risk partner, and (for material models) the CRO. The AI Enablement Maturity Diagnostic assesses this dimension as one of the five enablement pillars.

4. Board reporting that is substantive, not ceremonial

The board receives a model risk report that goes beyond "we have X models in the inventory and Y were validated this quarter." The report covers which models are compounding value, which are plateauing, which have elevated risk indicators, and which are approaching the need for retraining or retirement. This is the kind of reporting that the Bank of England expects to see.

What the PRA will ask you

When the PRA conducts a supervisory review of your AI governance, the questions will follow a predictable pattern:

1. Can you show me your complete model inventory, including all AI and ML models?
2. For your highest-risk AI model, walk me through the development process, the validation, and the monitoring.
3. Who is the senior manager accountable for this model under SMCR?
4. What happens when the model drifts or produces an unexpected outcome?
5. How does the board oversee model risk?

If you cannot answer these questions with documentary evidence today, you have a gap. The good news is that SS1/23 is clear enough that the gap is addressable. The bad news is that addressing it requires structural work on the model risk framework, the data layer, the monitoring stack, and the operating model, not just a policy document.

How to start

The first step is an honest assessment of where you are. Our AI Pilot Compounding Audit scores any AI initiative against the structural conditions for compounding, including the governance dimension. If the audit shows governance gaps, the next step is a focused diagnostic engagement that maps your current model inventory against SS1/23 and produces a defensibility memo you can use in supervisory dialogue.

For a deeper treatment of how governance fits into the broader AI enablement work, see our pillar essay on what AI enablement actually means and the FS sector playbook.

The firms that figure out SS1/23 compliance earliest will deploy AI with confidence into use cases their competitors are afraid to touch. The ones that do not will spend the next five years explaining to the PRA why nobody owned the model when it went wrong.