AI Risk Management Framework UK: The Regulator Map

For many UK firms, the AI risk problem is first a mapping problem. The Bank of England and FCA's third survey of AI in UK financial services, published in November 2024, found that 75% of firms are already using AI, with a further 10% planning to within three years. Among firms using or planning to use AI, the same survey found that 46% have only partial understanding of the AI they use, against 34% reporting complete understanding, largely because so much of it arrives inside third-party models. Adoption has outrun the ability to say which rule governs which system.

The UK makes that harder than it looks, because there is no single AI rulebook to map against. The approach set out by the Department for Science, Innovation and Technology hands five principles to the existing sector regulators and asks each to apply them inside its own remit. A risk framework written generically, borrowed from a vendor template or a US standard, therefore tends to fail at exactly the point a supervisor tests it: the question of which regulator expects what evidence for which risk. This guide is written for the Chief Risk Officer or Chief Data and AI Officer who has to answer that question across more than one regulator.

The scope here is the regulator map itself: the five principles, which regulators published how they apply them, how the principles translate into the FCA's existing rulebook, and how to build a taxonomy whose rows each name an owning regulator. It deliberately cedes three neighbouring frames. The columns of an AI inventory belong to our guide to the AI tool inventory for the ICO, FCA and EU AI Act. The detail of the PRA's model inventory expectations belongs to the AI in UK banking hub. And board tolerance setting belongs to the risk appetite statement guide. The wider consulting picture sits in our enterprise AI consulting guide.

This guide is shipped by the team behind DATS, the five-stage AI consulting system DILR.AI runs for enterprises, delivered by senior practitioners who ship code, not decks. Or see AI operating model design, which covers governance, RACI and lifecycle, audit-ready by design.

What is an AI risk management framework in the UK context?

An AI risk management framework in the UK is the set of risk categories, owners, controls and evidence a firm uses to show that each AI system meets the duties of whichever regulators supervise it. Because the UK has no single AI regulator, the framework has to be organised around the five cross-sectoral principles that existing regulators interpret and apply, rather than around one statute or one certification.

Those principles come from the government's March 2023 AI regulation white paper, confirmed in its February 2024 response. The response describes "five cross-sectoral principles for existing regulators to interpret and apply within their remits". They are safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; and contestability and redress. Every row of a UK risk taxonomy should be traceable to at least one of the five.

The second fact that shapes the framework is legal status. In the same response the government said that "a non-statutory approach currently offers critical adaptability", and that it would keep the question under review. In practice that means the principles do not bind a firm directly. What binds a firm is the regulator's own rulebook, applied to AI: the FCA Handbook, the PRA's supervisory statements, UK GDPR as the ICO enforces it, the Equality Act 2010, and sector law. The principles are the organising frame; the duties live in the rules underneath them.

That distinction is where generic frameworks break. A framework that lists "fairness" as a risk with a bias test as its control has written down a principle. A framework that says the fairness risk on a retail lending model is owned by the Consumer Duty outcome monitoring team, evidenced by the outcomes data the FCA expects, and backed by an Equality Act review has written down a duty. Only the second kind can be tested against a rule. For how DILR.AI structures that work, see the DATS five-stage system.

Which UK regulators have published how they apply the principles?

Thirteen UK regulators published updates on their strategic approach to AI, collected by the Department for Science, Innovation and Technology on 1 May 2024: the Bank of England, CMA, EHRC, FCA, HSE, ICO, Legal Services Board, MHRA, Office for Nuclear Regulation, Ofsted, Ofcom, Ofgem and Ofqual. Each update was written in response to ministerial letters asking how the regulator applies the white paper principles.

The government's collection of regulators' strategic approaches to AI is the closest thing the UK has to an official regulator map, and it is the right starting point for a taxonomy. The government asked regulators to publish by 30 April 2024 and asked them to include four things: the steps they were taking in line with the white paper, their analysis of AI-related risks in the sectors and activities they regulate, their current capability against what they need, and a forward look of plans over the following 12 months. The same response announced funding to build regulators' AI capability and for the Digital Regulation Cooperation Forum's AI and Digital Hub.

Treat the collection as a dated 2024 round, not a live register. Positions have moved since. The FCA's AI Update was first published on 22 April 2024 and last updated on 3 December 2025. Ofsted's approach to AI is now marked withdrawn on GOV.UK, updated 21 October 2025. The ICO's guidance on AI and data protection, last updated on 15 March 2023, carries a notice that it is under review because of changes made by the Data (Use and Access) Act. A framework that cites a regulator's position needs a review date next to every citation, or it will quietly rot.

The collection also tells a firm which regulators to expect at the table. A bank deploying a customer-facing model may face the FCA on conduct, the PRA on model risk, the ICO on personal data and the EHRC on discrimination. A medical technology firm adds the MHRA, whose policy paper on the impact of AI on the regulation of medical products was published on 30 April 2024. A platform business adds the CMA, whose AI strategic update was published the day before. For a sector view, our AI in UK healthcare hub maps the same regulators onto clinical deployments.

Fewer than four in ten of those firms report complete understanding, and that gap is the case for the regulator map. A firm that cannot say how a third-party model works can still say which regulator's rule governs its use, who owns that rule, and what evidence would satisfy it. That is a governance answer even when it is not yet a technical one, and it is worth settling before any new system is placed.

How do the five principles map to the FCA rulebook?

The FCA maps the five principles onto rules it already enforces rather than creating AI-specific ones. In its AI Update the FCA calls itself a technology-agnostic, principles-based and outcomes-focused regulator, and links safety to its systems, controls and operational resilience rules, fairness to the Consumer Duty, accountability to the Senior Managers and Certification Regime, and contestability to its complaints rules.

The detail is in the FCA AI Update itself, and it is the most complete worked example of the mapping any UK regulator has published. It is worth reproducing in summary, because it shows the pattern every other regulator's rows should follow: principle, existing rule, owner, evidence.

Two features of that table matter for the framework. First, the FCA states that its framework does not specifically address the transparency or explainability of AI systems. A firm that writes "FCA explainability requirement" into its taxonomy is citing a rule that does not exist; the honest row cites the consumer understanding outcome and UK GDPR instead. Second, the critical third parties regime appears under safety because the FCA notes that, although the regime is not specific to AI, the concept of a service a critical third party provides is broad enough to encompass considerations around the systemic use of a common AI model; systemic AI providers could come within scope if HM Treasury designated them. That makes concentration on one foundation model provider worth recording as a risk, not just as a procurement fact.

The ICO row sits beside the FCA's for any system that processes personal data. Automated decision-making is now governed by UK GDPR Articles 22A to 22D, which the Data (Use and Access) Act inserted in place of the old Article 22. Article 22A defines a decision as based solely on automated processing where there is no meaningful human involvement in taking it. That definition decides whether a human review step in the workflow is a real control or a rubber stamp, and it belongs in the taxonomy as an explicit test. Note that the FCA's AI Update, written in 2024, still refers to the old Article 22; a framework citing it should carry the current article numbers. Our post on voice AI auditability and explainability works through what meaningful human involvement looks like in a production workflow.

The same diagnostic logic underpins our AI operating model design, which covers governance, RACI and lifecycle, audit-ready by design.

Where does PRA SS1/23 sit in the map?

PRA Supervisory Statement SS1/23 sets five principles for model risk management, and it sits in the map as the prudential row for model risk. Its scope is narrow: it is relevant to UK-incorporated banks, building societies and PRA-designated investment firms with internal model approval to calculate regulatory capital, covering all model and risk types those firms use, including AI models.

That scope is easy to get wrong in a UK AI risk framework. SS1/23 was first published on 17 May 2023 and took effect on 17 May 2024, and the current version was published and took effect on 23 April 2026. It is a supervisory statement for a defined population of firms, not a cross-sector AI standard. A firm outside that population can borrow its structure, and many do, but the taxonomy should label the row as adopted good practice rather than as a binding requirement, because a supervisor reading the framework will notice the difference.

Within scope, SS1/23 changes the shape of the taxonomy in one important way: it treats AI as a model like any other. Its principles on model identification and risk classification, governance and independent validation therefore apply to a machine learning credit model and to a generative model used in a model-dependent process alike. The Bank of England and PRA's own AI update, published on 22 April 2024, sits alongside it. For the inventory columns and validation evidence a bank actually keeps, the banking hub linked in the introduction carries that detail, and this guide does not repeat it.

What should the risk taxonomy itself contain?

A UK AI risk taxonomy should contain one row per risk category, and each row should name the principle it serves, the regulator and rule that make it a duty, the accountable owner, the control, and the evidence a supervisor would ask to see. Build it in that order, because a row without a named regulator and owner cannot be tested, defended or audited.

The table below is a working structure. It is our framework, not a regulator's, and it is deliberately short: nine rows that cover the five principles for a typical regulated deployment. Each firm adds rows for its own sector, which is where the regulator collection above earns its keep.

Two rows deserve a note. Automated decisions appear under two principles because the duty sits in data protection law while the harm shows up as a contestability failure, and splitting the row would hide the link. Shadow AI appears because every other row assumes the firm knows the system exists; our guide to shadow AI governance covers how firms find the systems nobody registered.

For a firm with operations or customers in Europe, the EU AI Act can add a classification column to affected rows, which the EU AI Act section below explains. The table also leaves one thing out on purpose: risk scoring. Likelihood and impact scales belong to the firm's enterprise risk framework, and the programme risk register guide shows how a scored register sits beneath a taxonomy like this one.

How do you build the regulator map step by step?

Building a UK AI regulator map takes four steps: inventory every AI system in use, tag each one to the principles it engages, map each tag to the regulator and rule that make it a duty, then attach an owner and evidence to every control. The steps run in that order because mapping a system the firm has not inventoried produces a framework with gaps a supervisor finds first.

The first step is the one most firms underestimate, because AI now arrives inside software the firm already licenses. The Bank of England and FCA survey's finding on third-party models is a warning that the inventory has to reach embedded features in existing platforms, not only the systems a data science team built. The inventory guide linked above covers the fields; the point here is that the map is only as complete as the list feeding it.

The second step is a judgement call that should be recorded. A customer-facing chatbot engages transparency and fairness; a fraud model engages fairness, contestability and robustness; an internal coding assistant may engage only security and accountability. Recording why a principle was judged not to apply is as useful to a supervisor as recording why one does.

The third step is where the regulator collection does its work. Each tag becomes one or more rows naming the regulator, the specific rule, and the date the firm last checked that regulator's position. That date is not decoration: the Ofsted withdrawal and the ICO review notice both show positions changing inside two years.

The fourth step closes the loop. Every control needs an owner who can produce its evidence on request, and that evidence is strongest when it comes from the running system rather than being assembled afterwards for an audit. DILR.AI's AI execution office is its embedded delivery model, with production placements the client owns.

Where do NIST AI RMF and ISO 42001 fit beside a statutory duty?

The NIST AI Risk Management Framework and ISO/IEC 42001 fit beside a statutory duty as structure, not as substitutes for it. NIST describes its framework as intended for voluntary use, and neither it nor ISO 42001 is a UK regulator's rule. Both help a firm organise controls, but the duty a supervisor tests still comes from the FCA, PRA, ICO or sector regulator.

The NIST AI RMF was released on 26 January 2023, and NIST released a Generative AI Profile, NIST-AI-600-1, on 26 July 2024. NIST also states that the framework is being revised, so a taxonomy that cites it should record which version it maps to. Its value to a UK firm is vocabulary and completeness: it is a useful checklist for spotting a risk category the regulator map has missed. Its limit is jurisdiction. A row that cites only NIST has no UK owner who can be held to it.

ISO 42001 plays a different role. It is a management system standard, so it describes how an organisation runs AI governance rather than which risks matter in a given sector. Firms use it to give the framework an auditable operating rhythm. How to interrogate a vendor's ISO 42001 claim, and what a certificate does and does not prove, is covered in our ISO 42001 procurement guide, so this guide leaves it there.

The practical rule we apply is to cite a voluntary framework in the taxonomy only next to a statutory row, never instead of one. That keeps the framework honest about which controls a regulator can enforce and which the firm has chosen to adopt, a distinction that matters when the firm has to explain a gap. Evaluation and observability for production agents, one of the enterprise AI solutions DILR.AI names, is the kind of capability that produces evidence a supervisor can read.

Does the EU AI Act change a UK firm's risk map?

The EU AI Act changes a UK firm's risk map only where the Act reaches the firm. It applies to providers placing AI systems on the EU market and to providers and deployers outside the EU where the output produced by the system is used in the Union. A UK firm meeting either test adds the Act's risk classification to every affected row of its taxonomy.

The first question is therefore scope, settled by Article 2 of the AI Act. A UK lender with no EU customers and no EU-facing output may sit outside it; a UK insurer whose claims model produces decisions about EU policyholders may not. The answer belongs in the taxonomy as a recorded determination per system, with the reasoning, because it can change when a product launches into a new market.

Where the Act applies, it adds a classification layer. The European Commission's summary of the AI regulatory framework sets out four levels of risk: unacceptable, high, transparency and minimal. It lists nine prohibited practices, the ninth of which comes into effect in December 2026 and was introduced by the AI Omnibus, and the Commission records that the Act became applicable on 2 August 2026, with some exceptions. Minimal-risk systems, which the Commission says cover the vast majority of AI systems currently used in the EU, get no new rules.

The timing of the high-risk tier moved. Under the Digital Omnibus on AI, high-risk obligations for stand-alone Annex III systems are deferred to 2 December 2027, and to 2 August 2028 for AI embedded in regulated products. A taxonomy built in 2025 that carries the original August 2026 high-risk date is now wrong, which is another reason every regulatory row needs a review date. Our analysis of the EU AI Act omnibus delay covers what the postponement does and does not change.

The important discipline is to keep the EU column separate from the UK rows rather than merging them. The EU Act binds providers and deployers in defined roles; the UK rows bind the firm through its own regulators. Merging them produces controls nobody can attribute to a duty, which is the failure this whole exercise is meant to prevent. The compliance library collects our other regulator-led guides.

Who should own the framework inside the firm?

The framework should be owned by a named senior individual whose existing responsibilities already cover the systems and risks involved, not by a new AI committee with no accountability. In financial services the FCA records that respondents saw existing governance structures and the Senior Managers and Certification Regime as sufficient to address AI risks, without a dedicated senior manager for AI.

The FCA's AI Update gives the default allocation for the firms it covers. In PRA-authorised banking and insurance firms under SM&CR, and in FCA Enhanced firms, technology systems normally sit with SMF24, the Chief Operations function, while SMF4, the Chief Risk function, normally holds overall management of the firm's risk controls. The update notes that Core and Limited Scope firms are not covered by that allocation, so smaller firms need to make it explicit in their own responsibilities map. Firms outside financial services have no SM&CR, which makes a written allocation more important, not less.

Ownership has three layers in practice. The board sets tolerance, which the risk appetite guide linked in the introduction covers. A senior owner answers for the framework and its regulator map. And each system has an operational owner who produces the evidence for its rows. The UK university AI governance guide shows the same three layers working in a sector with very different regulators, which is a useful test that the structure is not finance-specific.

The common failure is a framework owned by the team that wrote it. That team can maintain the document, but it cannot answer to a regulator for a model in another division. Tying each row to an existing accountable owner is what makes the framework survive a reorganisation, and it is the core of how we approach AI governance through the operating model.

What is the best way to build an AI risk management framework in the UK in 2026?

The best way to build a UK AI risk management framework in 2026 is to start from the regulators that supervise the firm, map the five principles onto their existing rules, and treat NIST and ISO 42001 as structure. The right partner depends on scale: large multinational groups often need a Big Four firm, while mid-sized regulated firms usually need delivery capacity more than a methodology.

Five criteria separate a framework that survives supervision from one that does not:

• Every row names a regulator and a rule. Not a principle alone, and not a voluntary standard alone.
• Every citation carries a review date. Regulator positions moved in 2025 and 2026, and will move again.
• Scope determinations are recorded. Especially for SS1/23 and the EU AI Act, where scope is easy to get wrong.
• Ownership follows existing accountability. Under SM&CR where it applies, and by explicit allocation where it does not.
• Evidence comes from the running system. A control whose evidence is assembled for an audit is a control that fails between audits.

Against those criteria the choice of partner turns on scale and on where the gap is. For a global group whose framework has to reconcile regulators across many countries, a firm with a presence in each of those countries, such as Deloitte, PwC, EY, KPMG or Accenture, is often the better fit, and DATS does not claim to match that breadth. Where the gap is model evaluation, a specialist AI firm such as Faculty is an option worth testing. DATS, delivered by senior practitioners who ship code, suits a firm whose framework exists on paper but whose systems are not yet producing the evidence it promises.

There is also a case for building in-house. A bank with a mature model risk function already running SS1/23 may need only a mapping exercise, not an engagement, and should say so to any adviser who proposes more. Whichever route a firm takes, the test is the same: pick any row at random and ask who owns it, which rule makes it a duty, and where the evidence is. Read about our approach to placing AI inside enterprise systems.

Frequently asked questions

Is the UK AI framework a legal requirement?

The UK AI framework of five principles is not itself a legal requirement. The government's February 2024 response set the principles on a non-statutory basis, applied by existing regulators through their existing powers. What is legally binding is each regulator's own rulebook, such as the FCA Handbook, UK GDPR or the Equality Act 2010, applied to the firm's use of AI.

That is why the regulator map matters more than the principles alone: a firm is supervised against the rules underneath them. The FCA's governance expectations for voice AI show the same logic applied to one deployment type.

Does PRA SS1/23 apply to every bank using AI?

PRA SS1/23 does not apply to every bank using AI. It is relevant to UK-incorporated banks, building societies and PRA-designated investment firms with internal model approval to calculate regulatory capital, and within those firms it covers all model and risk types, AI included. Other firms can adopt its principles as good practice, but should label them as adopted rather than required.

For an in-scope bank that also has EU entities, the operational resilience view of AI dependencies is a useful companion to the model risk row.

Want a regulator map built against your own systems? Read how DATS AI consulting places governed AI, see the embedded execution office where placements stay client-owned, learn more about DILR.AI, or browse the AI strategy library for the operating questions behind the map.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.