The framework

Ten domains, fifty-seven control areas and two hundred and forty-one controls, all browsable. Each area answers one key question.

Search controls and areas

Tier

Type

Role

Flag

Domain 1 AI Governance

This domain sets out the structures, decisions, and responsibilities you must put in place to oversee every use of AI in your organisation — whether you buy it, embed it, or build it. Work through its eleven dimensions in the order that your situation demands, not necessarily in the order written: each one tells you what to establish, why it protects you, and what evidence proves it exists. Every control carries a tier tag — [Baseline] for the minimum any organisation must have, [Enhanced] for organisations with higher exposure or more capacity, [Advanced] for those building AI or operating in critical settings — and the tiers accumulate: each adds to the one below. Which controls apply to you is decided by your role (which controls are relevant) and by the criticality of each use and the rules that bind you (how deep they go); your size decides only how you implement them. None of this is a matter of preference.

What each tier adds

At Baseline — every organisation, however small, puts in place:

A one-page, values-based AI policy with data and autonomy red lines, an AI-interaction disclosure rule, and the discipline of documenting processes before automating them.
A single inventory of all AI — including AI embedded in purchased software — with a named owner for every system.
A recorded build-versus-buy decision and a written due-diligence questionnaire for every AI supplier.
A reversibility classification for every acting AI, with a human in the loop for every irreversible action.
An output-ownership policy, a prohibition on placing confidential material in unapproved tools, and stated consequences for bypassing governance.
Mandatory basic training — covering confident falsehood, data protection, and over-trust — and an explicit approval before any deployment.

At Enhanced — organisations with real exposure or capacity add:

A formal AI committee with HR and the data-protection officer at the table, workforce-impact review, stakeholder maps, and a full responsibility matrix.
Initiative charters with explicit out-of-scope boundaries, a sanctioned experimentation environment, and multi-party sign-off for high-risk systems.
Contracts that forbid training on your data, disclose where it is processed, warn you of model changes, and price the exit.
Origin and licence tracking for training sources and consulted collections, regime tags on assets, and data-lifecycle rules that reach derived stores.
A named, budgeted AI Security Program: builder training, an AI incident team, decay oversight, and a rehearsed disengagement-with-fallback policy.
An actionable indicator set, reporting on a fixed cycle to committee, risk, and board, with regulatory standing measured continuously.

At Advanced — large organisations and AI builders further add:

Federated governance across business units, with automated, continuous oversight and shadow-AI discovery.
Bills of materials for everything built or adapted, and screening of product-bound outputs for reproduced material.
A scheduled adversarial exercise programme and periodic independent audits.
Full integration of AI risk into enterprise risk management, with board reporting as a standing item.

Domain 2 Technical Security

Secure the AI you run against the failures ordinary IT security was never designed to catch. AI systems fail, and are attacked, in ways conventional software is not: they can be talked into disobeying you by instructions hidden in the content they read; the data they learn from or consult can be poisoned to steer their answers; the powers you give an autonomous system can be turned against you; their output can carry an attack into whatever consumes it; and the provider can change the model underneath you, silently altering behaviour you had tested and approved. This domain tells you how to harden each AI component, test it against the attacks that actually occur, constrain it while it runs, and recover when something gets through. It builds on the inventory and the ownership you established in the Governance domain — it does not repeat them. Where a concept here is unavoidably technical, it is explained in plain terms the first time it appears, because the people approving these controls are not always the people implementing them. Every control carries its tier tag, and the tiers accumulate as in every domain.

What each tier adds

At Baseline — every organisation running AI puts in place:

Exact model versions pinned in production, standing instructions under version control, and no secrets embedded in them.
Least-privilege access for every AI, with read and act separated and a human approving high-impact actions.
Origin and integrity verification for every model file downloaded.
Screening of what reaches the model and filtering of what it produces, as the basic guardrail pair.
Per-caller rate limits and quotas, and bounds on input size, output length, and per-request cost.

At Enhanced — organisations deploying AI into their own context add:

The approved-model list as the production gate, with hardening standards per component type.
A distinct identity per agent and connector, with short-lived credentials replacing embedded keys.
AI-specific vulnerability testing — hidden instructions, output paths, extraction — re-run on every model change.
Write-governance and screening on consulted collections, with tenant separation proven by test.
Action-level guardrails on a tuned review cycle, AI telemetry into security monitoring with AI-specific detections, and an incident playbook with rollback.
Written security standards for agents, tools, and MCP; for model management; and for retrieval — plus a written AI development lifecycle with security gates.
Multimodal injection testing, verification that AI-suggested dependencies exist, and preference for non-executable model formats with scanning of code-bearing files.
Hard spend limits with denial-of-wallet alerting, and restriction of extraction-enabling detail in responses.
Isolated, disposable execution environments for agents that run code or act on systems.

At Advanced — AI builders and critical operators further add:

Machine-enforced deployment policy and default-deny outbound connections.
Signing of self-built models, screening of external model files for implanted behaviours, and robustness testing scoped to the use case.
Training-data lineage with poisoning detection in ingestion.
Security gates with refusal authority on high-risk releases, and bills of materials generated by the pipeline.
A rehearsed kill switch with a tested business fallback, and the recurring adversarial exercise programme.
Detection of model-extraction and cloning patterns on high-value models, and graceful degradation under load.

Domain 3 Privacy and Data Protection

Protect the personal information your AI touches — and start by finding it, because with AI it is almost never only where you think. Personal data enters an AI system in places ordinary privacy programmes never look: in the questions your staff type into it, in the records it consults to answer, in the logs it keeps of every interaction, and in the numeric representations it builds from data and then stores. A privacy programme that guards the database and ignores these is guarding the wrong door. This domain tells you where the data goes, how to limit it, how to protect it, and how to make deletion actually reach it. Where it uses a technical term, it explains it in plain language the first time, because the person accountable for privacy is rarely the person writing the code.

What each tier adds

At Baseline — any organisation whose AI touches personal data:

A per-system record of the personal data the AI processes, prompts and logs included.
A privacy impact assessment before deploying AI that processes personal data.
Minimisation of personal data before it reaches the model, as the default path.
Encryption and access control across the system, and retention limits on logs and histories.

At Enhanced — organisations with sensitive data or decisions about people add:

Derived numeric stores treated as personal data throughout — inventoried, protected, and erasable.
Assessment of the AI-specific exposure pathways, reassessed on material change.
Erasure that reaches derived stores, and contractual provider deletion with proof.

At Advanced — organisations with the most sensitive uses add:

Individual-protecting techniques applied where sensitivity and stakes justify their cost.

Domain 4 Explainability, Transparency and Fairness

Be able to say what your AI did and why — to the degree the stakes demand, and in terms the person affected can understand. “The system decided” is not an account a regulator will accept, a customer will tolerate, or a court will excuse; and “it is a black box” is a description of a problem, not a defence. This domain tells you how to decide how much explanation each use requires, how to document what each system is, how to explain a decision to the person it affects, how to trace an output back to what produced it, and how to make sure the explanations you give are actually true. Reject the black-box excuse from the outset: if a system’s decisions matter to people, you must be able to account for them.

What each tier adds

At Baseline — every organisation:

A per-use-case decision on how much explanation is required, made before building.
Where any use decides about people: written decision criteria in the prompt, no outcome-derived examples, protected attributes removed by DLP, a swap test before first use, review of the rejected, a periodic selection-rate check with the four-fifths rule, and notice to affected people with a route to human review.
A minimal decision record — system, version, date, human involvement — for every person-affecting output.
A one-page documented risk assessment per use case before approval.

At Enhanced — organisations whose AI affects people add:

System factsheets and data descriptions for significant systems, kept current.
Plain-language explanations to affected people, with a route to contest and human review.
Traceability from significant outputs back to input, version, and sources.

At Advanced — the highest-stakes uses add:

Validation that explanations are faithful and that their audiences can use them.

Technique guidance for this domain

Question:Which technique meets each explainability and fairness control for this system?

When to use it.Once Dimensions 1–6 have told you which controls of this domain apply to a system, use this guidance to decide how to meet them. It never adds or removes a control.

The controls of this domain say what must be explained and what must be tested; which technique meets them depends on the kind of model. For tabular and structured models, explain an individual decision through the contribution of each input — Shapley-value attribution or local surrogate explanation — and, wherever it can be computed, through a counterfactual explanation: what would have had to be different. That is the form of explanation the affected person actually understands, and the one to prefer for Dimension 3. For systems built on large language models neither method is meaningful, because the model’s inputs are tokens and its decision is not a function you can inspect. Meet the same controls through traceability of the sources the system consulted, decision criteria stated in the prompt, rationales requested from the model and checked against its output, and the swap test, which is the language-model counterpart of a fairness metric. Choose among fairness metrics as a recorded trade-off decision (Domain 9, Dimension 6), because they cannot all be satisfied at once, and validate every explanation (Dimension 5): an attribution or a rationale that does not reflect what the system did is worse than none. The table names methods and functions, never products.

Need (dimension)	Tabular and structured models	Systems built on language models	Tier and evidence
Explain one decision to the affected person (Dimension 3)	Counterfactual explanation; local feature attribution, rendered in plain terms	Decision criteria stated in the prompt; model-generated rationale validated against the output; cited sources	Enhanced — explanation records, validation samples
Trace a significant output to what produced it (Dimension 4)	Input, model version, attribution vector	Input, model version, prompt version, retrieved sources with identifiers	Enhanced — traceability log
Document what the system is and where it fails (Dimension 2)	Global attribution; performance per group; data description	Factsheet with intended and prohibited uses; evaluation-set results per group	Enhanced — factsheet, data description
Detect disparate treatment before use (Dimension 6, Baseline)	Swap test on the protected attribute; selection-rate check with the four-fifths (80%) threshold	Swap test on name, gender marker, age, photograph; criteria-only prompt; balanced or no examples in the prompt	Baseline — swap-test record, rate check
Measure fairness (Dimension 6, Enhanced)	Demographic parity, equalised odds, calibration; bias-mitigation techniques with re-measurement	Group-wise outcome rates on the evaluation set and in operation; batteries of counterfactual prompts	Enhanced — metric reports; chosen metric recorded under Domain 9, Dimension 6
Independent bias audit (Dimension 6, Advanced)	Third-party audit of selection or impact ratios per group	The same, on operational outcomes	Advanced — audit report; public summary where required
Validate explanations (Dimension 5)	Faithfulness tests (perturbation, ablation); user comprehension tests	Sampling of rationale–output consistency; comprehension tests	Advanced — validation reports

Domain 5 Accountability

Make sure that when AI causes a consequence, a named human answers for it, the decision can be reconstructed, and the person harmed can get it put right. Governance assigned the owners; this domain makes ownership real when something goes wrong — by keeping decisions reconstructable, by fixing responsibility across the supply chain so it cannot be lost between you and your provider, by settling who bears the cost of harm before the harm occurs, and by giving affected people a working route to challenge and remedy. Accountability that exists only on an organisation chart evaporates at the first hard case; this domain is what stops it evaporating.

What each tier adds

At Baseline — every organisation:

Ownership of every AI system, carried from Governance, as the foundation of accountability.

At Enhanced — organisations whose AI affects people or relies on providers add:

Tamper-resistant audit trails of significant decisions, including human involvement.
Contractual allocation of supply-chain responsibility, with retained accountabilities recorded.
Liability and insurance settled before high-risk deployment.
A working remediation and redress route for affected people.

At Advanced — the highest-stakes uses add:

Redress patterns fed back into risk and system improvement.

Domain 6 Human Oversight

Build the machinery that keeps a human genuinely in charge of the AI decisions that require one — not a human who rubber-stamps, but one who can see, judge, and stop. Governance set the policy: which actions an AI may take alone, which it may only prepare, and which a human must decide, driven by how reversible each action is. This domain builds what makes that policy real in daily operation — because a human oversight requirement that exists only on paper produces the worst outcome of all: the appearance of control without its substance, a person clicking approve on decisions they have no way to actually evaluate. Decide the oversight model, design the interface that makes oversight meaningful, build the means to intervene, and ensure the overseer is competent and empowered to use it.

What each tier adds

At Baseline — every organisation running acting AI:

Every organisation, whether its AI acts or not: the ability to stop using any AI system and return to the manual process within the same day.
Every organisation, whether its AI acts or not: a named person who verifies AI-generated content before it is published or delivered outside the organisation.
An assigned oversight position — human decides, human watches, or autonomous — for every acting use case, driven by reversibility.

At Enhanced — organisations with consequential decisions add:

Oversight interfaces that equip humans to override, with friction against automatic deference.
Reliable override and halt mechanisms, connected to a business-continuity fallback, with a rehearsed procedure.
Competent, empowered overseers with real authority to say no and the time to use it.

Domain 7 Monitoring and Auditability

Watch your AI in operation, because it does not stay the same after you approve it — the world drifts, the model degrades, and behaviour that was fine at launch quietly stops being fine. A system that was validated once and never watched again is a system whose current behaviour you are guessing at. This domain tells you what to watch for: the slow decay of accuracy as the world changes, the specific ways AI goes wrong in the moment, the records you need to keep to reconstruct and audit, the compliance you must track continuously rather than annually, and the incidents you must be able to detect and escalate. It works alongside the security monitoring of Technical Security — that domain watches for attack; this one watches for the broader failure of quality, drift, and compliance.

What each tier adds

At Baseline — every organisation running AI in operation:

Basic watching that the system is behaving — building toward the fuller monitoring below as stakes rise.
Basic interaction logging exported to your own storage, and a written definition of what counts as an AI incident with a named escalation contact.

At Enhanced — organisations whose AI drives real decisions add:

Continuous performance monitoring against real outcomes, with thresholds that trigger action.
Detection of confident falsehood, anomaly, and abuse, routed into correction.
Logging proportionate to the stakes, governed as personal data; continuous compliance monitoring.
Defined AI incidents, detected and escalated to the AI incident team.

At Advanced — the highest-stakes and fastest-changing uses add:

Automated, real-time monitoring and detection feeding governance and risk on a standing basis.

Domain 8 Sustainability

Treat the environmental cost of AI as a real cost, and manage it — because AI’s energy and carbon footprint is large, growing, and, unlike most software, driven by choices you make deliberately: which model you run, how big it is, where it runs, and how you built it. This domain is not an appeal to conscience; it is a set of decisions that usually reduce cost and exposure at the same time as they reduce impact, because the same oversized model that burns unnecessary energy also burns unnecessary money and creates unnecessary dependency. Choose the right-sized model, procure from efficient providers, apply the techniques that make models cheaper to run, and account for the cost across the whole life of the system.

What each tier adds

At Baseline — every organisation:

Choosing the smallest sufficient model by default, rather than the largest available.

At Enhanced — organisations procuring or running AI at scale add:

Environmental questions in supplier due diligence and lower-carbon location choices where possible.

At Advanced — AI builders and large-scale operators add:

Model-efficiency techniques applied with measured trade-offs, and full lifecycle environmental accounting folded into initiative evaluation.

Domain 9 AI Risk Management

Run a continuous cycle that identifies what could go wrong with your AI, judges how bad and how likely, treats it in proportion, and watches for what changes — because AI risk is not a document you produce once but a state you manage constantly. This is the integrating domain: it draws the specific risks named across every other domain into one place, weighs them against how much risk your organisation has said it will accept, and makes the hard trade-offs between the eleven dimensions explicit rather than leaving them to chance. Identify the risks, assess them including their impact on people, model the threats before building, treat each in proportion and prove the treatment works, monitor continuously, report upward, and — the part unique to AI — manage deliberately the tensions between the things you are trying to protect at once.

What each tier adds

At Baseline — every organisation:

A basic identification of the AI risks it carries, drawn from the other domains — building toward the full cycle as exposure rises.

At Enhanced — organisations with real AI exposure add:

A maintained AI risk catalogue and assessments scoring harm to the business and to people.
A rights-impact assessment gating person-affecting systems, and threat modelling before building.
Proportionate treatment with named residual-risk acceptance, continuous refresh, and reporting upward.
Explicit, recorded resolution of the trade-offs between the dimensions.

At Advanced — AI builders and high-stakes operators add:

Adversarial validation of high-stakes mitigations, and proportionality-calibrated balancing across the full set of dimensions, fully integrated with enterprise risk management.

Domain 10 Proportionality and Lifecycle

Two principles run through every domain of this framework rather than sitting in one, and this closing domain makes them explicit so they are applied on purpose. The first is proportionality: what you must do is scaled to who you are and what you are doing, so that a small organisation buying a chatbot is not held to the obligations of a bank training its own model, and neither is let off the ones that genuinely apply to it. The second is lifecycle coverage: the obligations are not a one-time gate at launch but a continuous responsibility that begins before a system is built and ends only when it is properly retired. Neither is a set of new controls; both are the logic by which every control already stated is dialled to the right level and sustained across time.

What each tier adds

At every tier:

The organisational profile is determined across the six factors and drives every tier decision, with the Baseline never waived.
The obligations of every domain are carried across the full lifecycle — from design to retirement — and do not lapse once a system is live.
Both are re-derived and re-applied when the organisation’s role, rules, or systems materially change.
On retirement, data deleted or returned and credentials and connections revoked; above Baseline, the applicability map and the per-system resolution of regimes.

Where to start — find your path through BONSAI

You do not read this framework from cover to cover, and you do not calculate anything. You answer a short set of questions — a few about your organisation, once, and a few about each AI system you run — and write the answers on a path card. The answers give you, for each system, a letter: B, E or A. Then you walk through the domains. Every area opens with a gate that tells you whether to enter it and how far to go, and inside the area you implement only the controls that match your answers and your letter. Different organisations, and different systems within the same organisation, take different paths through the same framework.

Four ideas behind the questions.What you do with each system decides which kinds of obligation you have. What the system can do or harm, and the rules that bind you, decide how far you must go. Your size decides only how you implement each control — never whether. And every answer you give is recorded, so that anyone can later see why your path looks the way it does.

Part A — Your organisation (answer once)

A1. Where do you operate, and which rules bind you there?

Only general data-protection law applies to our use of AI. → Rules letter B
Sector regulation applies to us, or rules for organisations that use AI in regulated decisions (such as employment, credit or access to services). → Rules letter E
We provide AI systems or models to others under rules for high-risk or general-purpose AI. → Rules letter A
We operate in more than one jurisdiction. → Take the highest letter any jurisdiction gives you; the applicability map (Domain 10, Dimension 3) records which rules reach each system, and any genuine conflict

A2. How large is the organisation, and which dedicated functions does it have (security, legal, privacy, compliance)?

Micro or small, with no dedicated functions. → Mode: light
Medium, with some dedicated functions. → Mode: standard
Large, with dedicated functions. → Mode: full

A3. Which controls are already in place and evidenced?

Mark them as you walk the domains. → This orders your plan; it never removes a control

Part B — Each AI system (answer once per system)

B1. What do you do with this system?

We use it exactly as delivered — an assistant, a software-as-a-service tool, an AI feature inside software we bought. → Consumer: controls tagged all and consumer
We integrate or configure someone else’s model into our own processes — through an API, connectors, retrieval over our documents, or agents. → Deployer: controls tagged all and deployer+
We train, fine-tune or substantially adapt a model. → Developer: controls tagged all, deployer+ and developer

B2. Does it score, rank, select or decide about people?

Yes. → Controls flagged person-affecting apply to this system

B3. Does it take actions on its own — send, pay, change, delete, execute — rather than only answer?

Yes. → Controls flagged agentic apply to this system

B4. Does it process personal data?

Yes. → Controls flagged personal-data apply to this system

B5. If it goes wrong, how serious is the harm, can it be undone, and how many people are affected?

Minor, easily undone, few people. → Use letter B
Significant, or hard to undo, or many people. → Use letter E
Severe, or irreversible, or a very large number of people. → Use letter A
Take the worst of the three answers. → A single serious answer is enough

How to read B5.The three questions are answered by judgement, not by a formula. These examples anchor each level; record the answer and the reason on your path card.

Harm.Minor: an inconvenience or an error corrected in the normal course of work. Significant: a financial loss, a service denied or delayed with a route of appeal, or internal information exposed. Severe: harm to health or safety; the loss of a job, a home, credit or legal standing; or sensitive personal data exposed.

Undoing.Easily: the effect is reversed within the same process and leaves no lasting trace. With difficulty: it needs an appeal, a manual correction, or weeks to repair. Irreversible: it cannot be reversed, or the person never learns that it happened.

People.Few: a handful of internal users or customers. Many: a whole team, a customer segment, or an applicant pool. A very large number: the general public, or all the customers of a large organisation.

B6. Is it used in employment, education, credit, insurance, housing, health care, essential public services, legal standing, or the safety of critical infrastructure?

Yes. → Use letter A, whatever B5 said

Your letters

System letter =the highest of B, your rules letter (A1) and your use letter (B5–B6). Organisation letter = the highest of B and your rules letter. Use the system letter in areas about a specific system and the organisation letter in organisation-wide areas (strategy, committee, training, security programme, reporting). A single demanding system raises the obligations attached to that system; it does not by itself oblige a small organisation to build the structures of a large one.

Your path card

System	Role	People	Acts	Personal data	Use	Letter	Mode
(example) Candidate screening assistant	Consumer	Yes	No	Yes	A	A	Light
(example) Customer chatbot	Consumer	No	No	Yes	B	B	Light

How to walk the domains

At the start of every area there is a gate. It tells you whether to enter the area for a given system (depending on your answers to B1–B4) and from which letter the area begins.
Inside the area, implement the controls whose tier is within your letter — with B, the Baseline controls; with E, Baseline and Enhanced; with A, all three — and whose tags match your answers: your role (all, consumer, deployer+, developer) and, if a control carries a flag, the property you answered yes to.
Implement each control in your mode. Where the light mode differs, Domain 10 says how a small organisation meets the control.
Your first stage is every Baseline control that matches your answers: the universal Baseline that applies to everyone, the minimum for your role, and the controls of the properties you answered yes to. Start there; then extend each system to its letter.
Re-answer the questions whenever something changes: you begin to integrate or train, a provider changes the model, a new use appears, a rule changes, or an incident occurs.

How to read a control

Tier — [Baseline] / [Enhanced] / [Advanced]. Cumulative; the Baseline is never waived.
Control type — Preventive (stops a failure before it happens), Detective (makes it visible), Corrective (limits or reverses it). All three are controls.
Role — all / consumer / deployer+ / developer. A control with no role tag applies to every role. Controls that do not match your role stay visible so that you can see what you would take on if your role changed.
Scope — organisation (met once) / system (met once per system). Flag — person-affecting / agentic / personal-data: the control applies only to systems with that property.

The Baseline, by component

Component	Controls	Applies when
Universal Baseline (35)	Policy and disclosure, inventory and owner, escalation path, sourcing decision and supplier questionnaire, training and secure-use guide, prohibition of confidential material in unapproved tools, output ownership, consequences for bypass, least privilege, input screening and output filtering, rate and cost limits, the DLP boundary, basic logging, incident definition, one-page risk assessment, the manual fall-back, human verification of AI-generated content before it leaves the organisation, profile, retirement hygiene	Every system
Consumer minimum (2)	Provider data settings; following provider change notices (1.6)	B1 = consumer
Deployer minimum (5)	Version pinning and versioned instructions (2.1); credentials outside code and prompts (2.2); integrity of downloaded models (2.4); integration validation (2.7)	B1 = deployer or developer
Developer minimum (6)	Training-data provenance (1.9); separated datasets (2.5); model versioning (2.1); acceptance criteria and change traceability (2.7); minimal training record (4.2)	B1 = developer
Person-affecting (10)	The seven fairness controls (4.6); explanation-level classification (4.1); minimal decision record (5.1); oversight position (6.1)	B2 = yes
Agentic (5, one shared)	The three reversibility controls (1.10); in-the-moment approval (2.2); oversight position (6.1)	B3 = yes
Personal-data (5)	Personal-data record (3.1); privacy impact assessment (3.2); minimisation (3.3); encryption (3.4); retention of inference logs (3.5)	B4 = yes

A consumer system that neither decides about people nor acts nor processes personal data begins with 37 Baseline controls; a developer system that does all three begins with 65. The first stage is the result of your answers, not a checklist that is the same for everyone.

Meeting the technical Baseline without specialists

Question:How do we meet the technical Baseline controls without specialist staff?

When to use it.As soon as you know your first stage. The table covers only the Baseline controls that involve technology; use the rows whose controls are in your first stage.

Every Baseline control is meant to be achievable without specialist AI-security expertise. The table shows what that looks like, for an organisation of around ten people that uses AI services supplied by third parties, for the Baseline controls that involve technology. It names the function you need, never a product: most of these functions are already available in the settings of the AI service itself or in the productivity and security suites you already license. Effort is indicative — low means hours, medium days, high weeks. The governance Baseline controls are not listed, because they require documents and decisions rather than tools. In the first column, 2.1 means Domain 2, Dimension 1.

Dim.	Baseline control	What a small organisation does	Function to look for	Effort
2.1	Pin exact model versions	Select a fixed model version in the provider console or API call; record it in the inventory	Provider configuration	low
2.1	Standing instructions under version control, no secrets	Keep system prompts in a versioned repository or document with change history; scan them for keys	Repository; secret scanner	low
2.2	Least privilege, read and act separated; human approval for high-impact actions	Grant assistants and connectors read-only scopes by default; enable approval prompts for send, pay, delete	Identity provider; connector settings of the provider	low–medium
2.4	Verify origin and integrity of model files	Download only from the publisher’s official channel; check the published checksum; record it	Checksum verification	low
2.6	Screen what reaches the model	Enable the prompt-injection and personal-data filters of the provider or gateway on inputs and retrieved content	Input classifier; AI gateway	low–medium
2.6	Filter what the model produces	Enable output filters for personal data, credentials, toxic content; add a groundedness check where the system answers from documents	Output classifier	low–medium
2.9	Per-identity rate limits; bounds on request size and cost	Set quotas and spend caps per user and per application in the provider console; alert on anomalies	Provider quotas; billing alerts	low
3.3	Remove personal data not required before it reaches the model	Configure redaction of identifiers in the data path or gateway	Redaction; data-loss prevention	medium
3.3	Data-loss-prevention boundary with external AI tools	Enable policies that detect confidential material, personal data, and protected attributes in uploads and prompts to AI services; block or redact; log	Data-loss prevention (often included in the productivity suite)	medium
3.4	Encrypt personal data at rest and in transit, including derived stores	Use the provider’s defaults; verify for any vector store or log you run yourself	Platform encryption	low
3.5	Retention limits on inference logs and conversation histories	Set retention in the provider console and in any gateway; disable training on your data	Provider settings	low
4.6	Swap test before use on real people	Prepare paired inputs that differ only in the protected attribute; run; compare; record	Manual or scripted test	low
4.6	Selection-rate check across groups	Count outcomes per observable group each period; apply the four-fifths rule; record	Spreadsheet	low
6.3	Stop using any AI system and return to the manual process within the same day	Keep the manual procedure written down and known to someone; name who may decide to stop without further approval; know how to suspend the tool’s access	Documented procedure; provider console	low
7.3	Basic interaction logging	Enable the provider’s audit logs; export them to your own storage	Provider logs	low
10.2	Retirement hygiene	Delete or export data; revoke keys and connectors; record	Provider console; identity provider	low

The 57 areas at a glance

Question:Which areas will I walk through, and which of them apply to each of my systems?

Each area answers one key question. The third column repeats, in short form, the gate at the start of the area: for whom it is entered and from which letter. B, E and A give the number of controls of the area at each tier. Areas that have no Baseline controls are entered only by systems, or organisations, whose letter reaches their lowest tier; all others are entered at every letter. Use the table to see your route before you start, then walk each area you enter in full.

Area	Key question	Enter when	B	E	A
Domain 1 — AI Governance
1.1	Strategy and Direction — Why do we use AI?	Organisation, once	3	4	1
1.2	Roles and Responsibilities — Who decides what?	Organisation, once	2	3	1
1.3	AI Committee — Who oversees AI?	Organisation, once, letter E or A	0	5	1
1.4	AI System Inventory — What AI exists in our organisation — including the AI we did not realise we had?	Every system	4	4	2
1.5	Lifecycle and Decisions — How is an AI approved?	Every system	2	4	1
1.6	Sourcing and Third-Party Management — Should we build or buy — and who controls our AI providers?	Every system	4	5	1
1.7	Competence and Awareness — Does the organisation know how to use AI?	Organisation, once	3	3	1
1.8	Oversight and Reporting — How do we know it is working?	Organisation, once	1	4	1
1.9	Intellectual Property, Provenance and Output Ownership — Who owns what goes in, and what comes out?	Every system	3	2	2
1.10	Reversibility and Permitted Autonomy — If the AI gets it wrong, can we undo it — and how much autonomy does that justify?	Every system	3	2	0
1.11	AI Security Program — Who owns AI security as a program, and what happens when it is ignored?	Organisation, once	1	5	1
Domain 2 — Technical Security
2.1	Secure AI Architecture and Model Hardening — What are we allowed to run, and how is it locked down?	Every system	3	4	2
2.2	Identity, Access and Secrets for AI — Who — and what — can the AI act as?	Every system	3	4	2
2.3	AI-Specific Vulnerability Assessment — What can break this AI that would not break ordinary software?	Deployer or developer systems (B1), letter E or A	0	5	1
2.4	Adversarial Robustness and Model Integrity — How does the model behave under deliberate attack — and can we trust the model file we loaded?	Deployer or developer systems (B1)	1	1	4
2.5	Data Pipeline and Retrieval Security — Can the data that feeds the model be tampered with — or read by the wrong people?	Deployer or developer systems (B1)	1	5	2
2.6	Runtime Guardrails — What stands between the model and harm while it is running?	Every system	2	3	1
2.7	Secure Development Lifecycle for AI — Is the way we build and ship AI secure by construction?	Deployer or developer systems (B1)	3	6	3
2.8	AI Security Operations and Incident Response — Can we detect an attack on the AI — and recover when one lands?	Every system, letter E or A	0	3	2
2.9	Resource Abuse and Model Extraction — Can someone run up your bill, exhaust your service, or clone your model through the front door?	Every system	2	2	2
Domain 3 — Privacy and Data Protection
3.1	Know What Personal Data Your AI Touches — Whose information does this system see, and where does it go?	Every system	1	2	0
3.2	Assess the Privacy Impact Before You Deploy — How could this system harm people’s privacy — and have we checked before launch?	Every system	1	2	0
3.3	Minimise What Goes In — Are we sending the AI more personal data than the task needs?	Every system	2	1	0
3.4	Protect the Data in Proportion to Its Sensitivity — Are the protections around this data matched to how sensitive it is?	Every system	1	0	1
3.5	Make Retention and Deletion Reach Where AI Hides Data — When someone’s data must be deleted, does the deletion actually reach everywhere the AI put it?	Every system	1	2	0
Domain 4 — Explainability, Transparency and Fairness
4.1	Decide How Much Explanation Each Use Demands — How much do we need to be able to explain here?	Every system	1	1	0
4.2	Document What Each System Is and What It Cannot Do — If someone had to understand this system in ten minutes, what would we hand them?	Every system	1	3	0
4.3	Explain a Decision to the Person It Affects — Can we tell the person affected why, in a way they can actually understand?	Every system, letter E or A	0	2	0
4.4	Trace Every Significant Output Back to What Produced It — Six months from now, can we reconstruct why the system said what it said?	Every system, letter E or A	0	2	0
4.5	Check That the Explanations Are True — Does our explanation actually reflect what the system did?	Every system, letter A	0	0	2
4.6	Fairness and Non-Discrimination in Person-Affecting Uses — Could this system treat people differently because of who they are — and would we know?	Systems that decide about people (B2)	7	2	1
Domain 5 — Accountability
5.1	Make Every Significant AI Decision Reconstructable — If we had to prove what happened and who was responsible, could we?	Every system	1	2	0
5.2	Fix Accountability Across the Supply Chain — When a third party’s model is involved, who answers for the outcome?	Every system, letter E or A	0	2	0
5.3	Settle Liability and Insurance Before High-Risk Deployment — If this AI causes real harm, who bears the cost — and are we covered?	Every system, letter E or A	0	2	0
5.4	Give Affected People a Way to Put Things Right — When the AI gets it wrong about someone, how do they get it fixed?	Every system, letter E or A	0	1	1
Domain 6 — Human Oversight
6.1	Decide the Oversight Model for Each Use — For this decision, is the human deciding, checking, or absent — and is that right?	Every system	2	1	0
6.2	Design the Interface So Oversight Is Real — Does the person overseeing this actually have what they need to judge it?	Every system, letter E or A	0	2	0
6.3	Build Reliable Means to Intervene and Stop — When the human needs to step in, can they — quickly and reliably?	Every system	1	2	0
6.4	Ensure the Overseer Is Competent and Empowered — Does the person overseeing this understand it — and are they allowed to say no?	Every system, letter E or A	0	2	0
Domain 7 — Monitoring and Auditability
7.1	Watch for the Model Drifting Away From What You Validated — Is the system still as good as it was the day we approved it?	Every system, letter E or A	0	2	0
7.2	Detect the AI Behaving Wrongly — Would we notice if the system started producing nonsense, or being abused?	Every system, letter E or A	0	2	0
7.3	Log Enough to Reconstruct and Audit — No More — Can we reconstruct what the system did, without creating a new privacy problem by doing so?	Every system	1	2	0
7.4	Monitor Compliance Continuously — Are we still compliant this month, or only as of last year’s review?	Every system, letter E or A	0	1	0
7.5	Detect and Escalate AI Incidents — When something goes seriously wrong, will we know, and will the right people?	Every system	1	3	0
Domain 8 — Sustainability
8.1	Choose the Smallest Model That Does the Job — Are we using a far larger model than this task actually needs?	Every system	1	1	0
8.2	Favour Efficient Providers and Regions — Do we know the environmental cost of where and with whom we run our AI?	Every system, letter E or A	0	2	0
8.3	Apply the Techniques That Make Models Cheaper to Run — Could this model do the same job while consuming far less?	Developer systems (B1), letter A	0	0	1
8.4	Account for the Cost Across the Whole Life of the System — Do we know what our AI costs the environment, from training to retirement?	Every system, letter A	0	0	2
Domain 9 — AI Risk Management
9.1	Identify the Risks Specific to AI — What can actually go wrong here that ordinary risk management would miss?	Every system, letter E or A	0	1	0
9.2	Assess the Risks, Including the Impact on People — How bad, how likely — and who gets hurt?	Every system	1	2	0
9.3	Model the Threats Before You Build — Have we deliberately imagined how this could be attacked or misused — before it ships?	Every system, letter E or A	0	3	0
9.4	Treat Each Risk in Proportion, and Prove the Treatment Works — Have we actually reduced the risks we said we would — and checked?	Every system, letter E or A	0	1	1
9.5	Monitor Risk Continuously and Report It Upward — Is our picture of AI risk current — and does it reach the people who own the consequences?	Every system, letter E or A	0	2	0
9.6	Manage the Trade-offs Between the Dimensions Deliberately — When protecting one thing weakens another, who decides the balance — and on what basis?	Every system, letter E or A	0	1	1
Domain 10 — Proportionality and Lifecycle
10.1	Scale What You Do to Who You Are and What You Are Doing — Are we doing more — or less — than our situation actually requires?	Every system	2	1	0
10.2	Carry the Obligations Across the Whole Life of the System — Do our controls cover the system before it exists and after it is switched off — or only while it runs?	Every system	1	2	0
10.3	Resolve the Regimes Per System — Which rules apply to which system, and what do we do when they differ?	Every system, letter E or A	0	2	0
Total: 57 areas, 241 controls	67	133	41