Search for "AI governance framework" and you will find two kinds of content. The first is abstract principle — fairness, transparency, accountability — restated at length and resolved into nothing. The second is the vendor checklist: twelve boxes, a maturity score, a sales call. Neither survives contact with the question a regulator, an auditor or a procurement team will actually ask, which is not "do you have a framework?" but "show me the framework operating."
A framework that can answer that question has a specific shape. It is five connected layers: principles (what you stand for), policy (what is allowed), controls (enforced in systems and process), evidence (what you can show), and assurance (who checks). Each layer is derived from the one above it and proven by the one below it. Most so-called frameworks fail not because a layer is missing but because the layers do not connect — a principle no policy implements, a policy no control enforces, a control no evidence shows operating. This post sets out what each layer is, who owns it, how the stack maps onto the UK's five regulatory principles and the two standards that matter, and a realistic sequence for standing it up in 90 days.
Key takeaways
- A working AI governance framework is five connected layers — principles, policy, controls, evidence, assurance — and the connections matter more than the layers: every policy sentence needs an enforcing control, every control needs dated evidence.
- The board owns the top and bottom of the stack (principles and assurance); the executive owns policy and the system's operation; delivery teams own controls and generate evidence.
- The UK has no AI statute — regulators apply five cross-cutting principles confirmed in the government response of 6 February 2024 — so each principle needs to resolve into a named control and an evidence artefact you can produce on request.
- ISO/IEC 42001 gives the stack its auditable spine and NIST AI RMF gives it a risk engine; neither is binding, but together they are the most concrete evidence of governance a UK board can point to.
- The common failure modes are predictable: paper frameworks, annual-review theatre, and governance bolted on after procurement has already let the AI in.
A framework is five connected layers, not a document
Strip away the diagrams and an AI governance framework that works has five layers.
- Principles — what you stand for. A small number of positions the board has actually adopted, in its own words. Not borrowed boilerplate: positions with consequences, such as "no AI system makes a final decision about a person without a human review route" or "we do not deploy AI we cannot explain to the person it affects." If a principle could not, in any circumstance, cost you a feature or a deal, it is decoration.
- Policy — what is allowed. The rules that implement the principles: which uses of AI are approved, which are prohibited, what approval a new use requires, what suppliers must disclose, what staff may and may not put into a public model. A policy is the translation layer between board intent and operational behaviour, and it should be short enough that people read it.
- Controls — enforced in systems and process. The mechanisms that make the policy true whether or not anyone is watching: an approval gate before a new AI use goes live, a human review route for significant decisions, access constraints built into the system itself, bias testing tied to release. A control that depends entirely on goodwill is a hope, not a control.
- Evidence — what you can show. The artefacts the controls throw off as they operate: a current AI system register, dated risk and impact assessments, approval records, test results, review minutes, decision logs. Evidence is the layer regulators and auditors actually examine, because it is the only layer they can.
- Assurance — who checks. The function that verifies the other four layers are real: management review at planned intervals, internal audit, and — where the destination is certification — an accredited external body.
The layers are easy to list. The discipline is in the connections. A useful test takes ten minutes at any board meeting: pick one sentence from your AI policy and ask which control enforces it; then pick one control and ask what evidence shows it operated last month. If either question has no answer, you have located the break in your framework — and so will an auditor.
Who owns what: board, executive, delivery
Frameworks fail by ownership as often as by design. The board cannot run the controls; the delivery teams cannot set risk appetite; and when everything is "owned" by a committee, nothing is owned at all. The division that works follows the layers.
| Layer | Owner | The board's question |
|---|---|---|
| Principles | Board | Have we adopted positions with consequences, in our own words? |
| Policy | Executive (a named owner) | Does the policy implement our principles, and is it current? |
| Controls | Delivery and operational teams | Which control enforces each policy rule, and who runs it? |
| Evidence | Generated by delivery, curated by the policy owner | Can we produce the artefact on request, dated? |
| Assurance | Board, via management review and audit | When did we last check, and what changed as a result? |
The board, in other words, owns the top and bottom of the stack. It sets the principles and the risk appetite, and it receives and acts on assurance. Everything in between is delegated — but delegated to named people, not to functions. This mirrors the logic of ISO/IEC 42001, whose leadership clause names top management explicitly: you can delegate the building, you cannot delegate the accountability.
There is an uncomfortable fact underneath this division. In April 2026, KPMG and the INSEAD Corporate Governance Centre published a set of AI governance principles for boards, spanning strategy, technology and security oversight, workforce transformation, trustworthy AI and the work of the board itself. The survey finding that accompanied the launch is the one to sit with: KPMG's Global AI Pulse Survey indicates that nearly three quarters of boards are perceived to have only moderate or limited AI expertise. That is the population designing these frameworks.
The conclusion is not that every board needs a technologist. It is that the framework must be designed so the board can govern through questions and evidence rather than technical review — which is precisely what the layered structure provides. A director does not need to understand a model's architecture to ask whether the bias test ran before release and what the dated record shows. The KPMG/INSEAD principles make the same point in their framing: the board's job is to strengthen oversight without stepping into management.
Map each UK principle to a control and an evidence artefact
The UK has no single AI Act. Its approach — set out in the March 2023 White Paper and confirmed in the government response of 6 February 2024 — asks existing regulators to apply five cross-cutting principles within their remits. We have written a full board guide to that landscape; the short version is that the principles are voluntary and deliberately abstract, while binding law already sits underneath them. Wherever your AI touches personal data, the ICO's guidance on AI and data protection applies under UK GDPR and the Data Protection Act 2018, and the Data (Use and Access) Act 2025 has reshaped the rules on automated decision-making through the new Articles 22A to 22D.
The gap between an abstract principle and a defensible position is closed by mapping. For each principle: one control that actually operates, one artefact that proves it did. Worked through the five UK principles, the mapping looks like this.
| UK principle | Example control | Evidence artefact |
|---|---|---|
| Safety, security and robustness | Pre-deployment testing gate; system constraints built in (for example, read-only database access for analytical models) | Dated test records; the access configuration itself |
| Appropriate transparency and explainability | AI use disclosed to the people it affects; model outputs must cite their sources | Published disclosure text; citation or traceability logs |
| Fairness | Bias testing on defined cohorts before go-live and on a schedule thereafter | Test results tied to the release decision they informed |
| Accountability and governance | A named accountable owner per AI system; an approval gate for every new use | The system register entry; approval records and minutes |
| Contestability and redress | A human review route for significant decisions, as Articles 22A–22D reinforce | A log of review requests, outcomes and response times |
Two notes on using the table. First, these are examples, not a template — the right control depends on what the system does and to whom. A chatbot answering product questions and a model informing decisions about tenants demand different controls under the same principle. Second, the evidence column is the one to be strict about. In our own delivery work the controls are built so the evidence generates itself: in a public-sector evidence workspace we built, every AI output traces to its exact source passage, so the transparency artefact exists by construction rather than by someone remembering to write it down. Wherever you can make evidence a by-product of the control operating, the framework gets cheaper to run and harder to fake.
Where ISO/IEC 42001 and NIST AI RMF fit the stack
Neither of the two frameworks boards ask about most is a law. Both are how you give the five-layer stack a recognised, auditable shape.
ISO/IEC 42001:2023, the first international AI management-system standard, is the spine. Its clause structure formalises the layers almost one for one: clause 5 (leadership) demands the principles and policy with top management named; clause 6 (planning) demands risk and impact assessment; Annex A is a menu for the controls layer; the documentation requirements throughout are the evidence layer; and clauses 9 and 10 (performance evaluation and improvement) are the assurance loop. We have set out what the standard asks of a board clause by clause, including the distinction that matters in external communications: you can align to the standard yourself, but only a UKAS-accredited body can certify you to it.
NIST's AI Risk Management Framework, published in January 2023, is the risk engine that runs inside that spine. Its four functions map onto the stack cleanly: Govern is the principles and policy layers; Map and Measure are where controls and evidence are specified per system; Manage closes the loop into assurance. NIST is voluntary and US in origin, but it has become the shared language for AI risk across UK, EU and US counterparties, which makes it useful in supplier conversations even if you never adopt it formally.
The artefact where the whole stack becomes visible is the AI risk register. It is the clause 4 inventory, the home of the principle-to-control mapping, and the record assurance reads first. It is also where frameworks most visibly die: a register reviewed annually is not evidence of governance, it is a record that governance once happened. The case for treating it as living evidence rather than a spreadsheet is one we have made in full elsewhere; for present purposes, the register's update history is the health check on your framework.
A realistic 90-day sequence
A five-layer framework sounds like a year of work. The standing-up is not; the sustaining is. A board that sequences the work can have a real, operating framework — narrow but genuine — in a quarter.
- Days 1–30: inventory, baseline, owner. List every AI system in use, including vendor features switched on by default and the tools teams adopted without sign-off. You cannot govern what you cannot list, and most organisations are surprised by their own inventory. Baseline your current position against the five principles — our Board AI Scorecard is a 15-minute way to do this — and put a named owner on the framework before the month ends. Not a committee. A person.
- Days 31–60: principles, policy, first mappings. The board adopts its principles and risk appetite in a minuted session. The owner drafts the policy — short, enforceable, specific about approval thresholds and prohibited uses; our AI policy generator produces a structured starting draft to edit rather than a finished article. Then map principles to controls for the highest-risk systems first: the ones making or informing decisions about people, money or safety. Resist mapping everything at once; depth on three systems beats a gesture at thirty.
- Days 61–90: first controls live, first review held. Implement the controls that close the largest gaps — typically an approval gate for new AI uses, a disclosure requirement, and a human review route for significant decisions. Check your EU exposure while you are at it: the EU AI Act catches UK organisations through their EU footprint, and although the high-risk application dates were pushed to December 2027 and August 2028 under amendments still completing the EU legislative process, scoping whether you are caught takes an afternoon now (our EU AI Act exposure checker walks through the questions). Close the quarter with the first management review: the board examines the register, the policy and the first evidence artefacts, and minutes what changes as a result.
Be honest about what 90 days buys. It stands the framework up; it does not finish it. The assurance layer in particular is a rhythm, not an event — ISO/IEC 42001's clauses 9 and 10 are read by auditors as dated records across time, and an empty period is a finding. The quarter's job is to make the framework real enough that sustaining it becomes the default rather than a campaign.
The three ways frameworks fail
The failure modes are so consistent that they are worth naming in advance, because each is detectable early.
The paper framework. A policy exists; nothing enforces it. The organisation has confused writing things down with governing. The detection test is the one from the first section — pick a policy sentence, name its control — and the fix is to stop writing and start enforcing: three operating controls outweigh thirty aspirational pages. Paper frameworks are the natural output of treating governance as a procurement item, which is why the vendor-checklist genre produces so many of them.
Annual-review theatre. The framework operated once, at standing-up, and is now re-performed yearly: the register gets a fresh date, the policy gets re-approved unread, the board minute says "reviewed and noted." The tell is that nothing ever changes as a result of review — no control amended, no system re-assessed, no finding logged. Real assurance leaves a trail of consequences. If the last three reviews changed nothing, either the organisation's AI is implausibly stable or the review is theatre.
Governance bolted on after procurement. The most common failure in practice, because AI now arrives embedded in products rather than through deliberate adoption. A supplier switches on an AI feature; a department subscribes to a tool; six months later the governance function discovers a system that was never scoped, assessed or registered. The fix is structural: the framework must catch AI at the point of entry, which means AI questions in procurement and supplier due diligence, contractual disclosure obligations on vendors, and the approval gate sitting before deployment, not after discovery. A framework that only governs the AI you chose deliberately governs a shrinking share of the AI you actually run.
All three failures share a root: the layers exist but the connections do not. Which is also why they are cheap to detect — every connection can be tested with one question and an answer that is either an artefact or an absence.
The test for your own organisation is correspondingly simple. Take one AI system you rely on today and trace it through the stack: which principle covers it, which policy rule applies, which control enforces that rule, what dated evidence shows the control operating, and when assurance last looked. If the trace runs clean, you have a framework. Wherever it snaps, you have found the work — and found it before a regulator, an auditor or a counterparty does it for you.
Last reviewed: 12 June 2026.
If you want a baseline before you build, the Board AI Scorecard gives you one in 15 minutes; if you want the gaps mapped and sequenced properly, our GovernIQ diagnostic (from £3,950) does exactly the five-layer trace described above — or see how we work.
