How to bring your AI models under the PRA's SS1/23 model risk rules

A firm brings its AI models under the PRA's SS1/23 by treating each model as a governed asset: registering it in one model inventory, classifying it by materiality, documenting how it was built and tested, and subjecting it to independent validation before and during use. The five principles map onto AI cleanly when the model runs on infrastructure the firm owns, because every input, output and version is captured and cryptographically sealed at source rather than reconstructed from a cloud vendor's logs. SS1/23 has applied since 17 May 2024 to firms with internal model approval permissions and expressly covers artificial intelligence and machine learning.

This matters in 2026 because AI adoption in regulated finance has outrun the governance built for it. Firms deploy models for credit decisions, financial crime triage and customer correspondence, then find that public cloud AI services cannot answer a supervisor's simplest question: show the exact model, input and output behind this decision, and prove none of it changed. SS1/23 asks whether the firm can identify a model, validate it independently and account for it. Architecture, not policy, decides whether that is possible.

Which rule makes this necessary, and who does it bind?

SS1/23 is the PRA's supervisory statement on model risk management principles for banks. It took effect on 17 May 2024 and sets out five principles: model identification and risk classification, governance, model development and implementation, independent validation, and model risk mitigants. It binds firms with internal model approval permissions, and the PRA treats the same principles as good practice for the wider sector. SS1/23 defines a model broadly enough to capture AI and machine learning, including third-party and vendor models, so a large language model used for financial crime triage sits squarely in scope.

How do you build a model inventory that satisfies Principle 1?

Principle 1 requires a complete, current inventory of every model in use, each classified by materiality and risk. For AI models this is a matter of control, not just discipline, because a model reached over an API can be retrained, reweighted or retired by the vendor without notice, breaking the inventory the moment it is written. A defensible entry records, for each model: its version, owner, risk tier, permitted uses, data lineage and last validation date. When the model runs on hardware the firm controls, the version is fixed until the firm changes it, so the entry stays true. When the model is a public cloud AI service, the firm is describing a moving target.

What does independent validation look like under Principle 4?

Principle 4 requires validation by a function independent of model development, covering conceptual soundness, data quality, testing and ongoing performance monitoring. For AI the hard part is reproducibility: a validator cannot sign off a model whose behaviour cannot be reproduced. Independent validation needs three things a public cloud service rarely provides: a frozen version to test against, the exact inputs and outputs from live use, complete and untampered, and assurance that the model examined is the model that ran in production. Sealed capture on owned hardware delivers all three by construction.

How does running models on your own hardware make this straightforward?

Mickai is a Sovereign Intelligence Operating System, a SIOS that runs entirely offline on hardware the operator owns. Every model, every input and every output stays inside a zero-egress inbound perimeter, so nothing leaves the estate and no external service can alter what ran. Each action is written to an append-only audit ledger, signed with post-quantum digital signatures under FIPS 204, the ML-DSA standard, with FIPS 205 as a stateless-hash alternative. Identity is hardware-attested and bound into the same audit chain, so every entry names the person, the device and the model version behind it. Where a decision is material, cross-model consensus records whether several models agree on the same input. The architecture behind this is the subject of 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, and remains patent pending.

“Model risk management is only as strong as your ability to prove which model ran, on what input, and with what result, and that proof is an architectural property, not a policy statement.”

What can a PRA supervisor or internal auditor actually check?

A supervisor or internal auditor should be able to verify governance directly. On a sealed SIOS the checks are concrete:

• Pull the full model inventory and confirm each live model has an owner, a tier and a current validation date.
• Select any past decision and retrieve the exact model version, input and output that produced it.
• Re-run that input against the frozen model version and confirm the output matches.
• Verify every ledger entry's post-quantum signature and confirm the chain is unbroken.
• Confirm no model, input or output ever left the perimeter, because the perimeter permits no outbound egress.

We call the third of these the replay test: same version, same input, same output, or the discrepancy is logged.

How does SS1/23 sit with DORA, NIS2 and the EU AI Act?

SS1/23 does not stand alone. DORA has applied since January 2025 and holds financial entities accountable for the resilience of their ICT, including third-party AI services. NIS2 extends security and incident duties, and GDPR governs the personal data these models process. The US CLOUD Act is why data held by a US-owned cloud provider can be compelled wherever it sits, a direct problem for a UK firm's SS1/23 evidence. On the EU AI Act, the high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk systems moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. Sealing models now strengthens a firm's SS1/23 evidence and pre-positions it for the AI Act's high-risk regime.

Frequently asked questions

Does SS1/23 apply to AI and machine learning models?

Yes. SS1/23 defines a model broadly, and the PRA has been clear that AI and machine learning models are in scope. Any AI system used for a decision that affects the firm's risk must be identified, classified and validated like any other model.

What is a model inventory under SS1/23?

A model inventory is a single, current register of every model the firm uses, recording each model's owner, version, risk tier, permitted uses, data lineage and last validation date. Under Principle 1 it must be complete and kept up to date, which AI models complicate when they run on external services that can change version without notice.

Can we use a public cloud AI service and still meet SS1/23?

Public cloud AI services can be used, but they weaken SS1/23 evidence. The provider controls the version, holds the logs and can be compelled to disclose data under the US CLOUD Act, so the firm cannot independently prove which model ran or that its inputs and outputs are intact. Sealing models on owned hardware removes that dependency.

What is independent model validation under SS1/23 Principle 4?

Independent validation is review by a function separate from the team that built the model, covering conceptual soundness, data quality, testing and ongoing monitoring. For AI it depends on reproducibility: the validator needs a frozen model version and the exact inputs and outputs from live use. Without sealed capture, the validator is assessing something that cannot be reliably reproduced.

When do the EU AI Act high-risk rules apply now?

The high-risk obligations under Annex III, originally due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027. High-risk systems embedded under Annex I move to 2 August 2028, while the Article 50 transparency duties are largely unchanged. The governance a firm builds for SS1/23 now is the same evidence the AI Act will later require.