The AI Controls Library
A working reference of 40 AI risk controls across eight domains — the defined, evidenceable measures behind a defensible AI governance program. Each control is mapped to ISO/IEC 42001, the NIST AI RMF functions, and where applicable the EU AI Act, so risk, compliance, and audit teams can speak one control language across frameworks.
Last reviewed: 7 June 2026 · Mappings are indicative working references, not a conformity claim
Jump to a domain
New to the discipline? Start with the AI GRC pillar guide for how these controls fit into an operating model, and the free assessment to see which domains need attention first.
GOV · Governance & accountability
The controls that make AI someone’s job. Everything else in the library depends on these existing first.
AI policy
A board-endorsed policy stating what the organisation will and will not use AI for, who may approve new use cases, and the rules staff must follow. Reviewed on a defined cycle and whenever the regulatory position materially changes.
Maps to ISO 42001 A.2 · NIST AI RMF Govern · EU AI Act Art. 17
Accountable system owners
Every AI system in production has a named individual owner accountable for its performance, risk treatment, and compliance — not a team, a vendor, or “IT”.
Maps to ISO 42001 A.3 · NIST AI RMF Govern
Board oversight & reporting
AI appears on the board or risk-committee agenda on a defined cadence, with decision-useful reporting on the portfolio, top risks, incidents, and regulatory change.
Maps to ISO 42001 A.3 · NIST AI RMF Govern
AI risk appetite statement
A documented statement of the AI risk the organisation is willing to accept, by use-case category, against which proposals are triaged and escalations are judged.
Maps to ISO 42001 cl. 6 · NIST AI RMF Govern
AI inventory
A maintained register of every AI system, model, and material AI feature in use — including embedded vendor AI and approved staff tools — with owner, purpose, data, and risk tier recorded.
Maps to ISO 42001 A.4 · NIST AI RMF Map
AI literacy & training
Role-appropriate training: general staff on acceptable use, builders and approvers on risk and controls, and directors on enough technical substance to provide effective challenge.
Maps to ISO 42001 cl. 7 · NIST AI RMF Govern · EU AI Act Art. 4
RSK · Risk assessment
The controls that sort the AI estate by potential for harm, so effort lands where the stakes are.
Use-case risk tiering
Every proposed and existing use case is classified into risk tiers using defined criteria — impact on people, decision consequence, data sensitivity, autonomy, and regulatory exposure — with controls scaled to the tier.
Maps to ISO 42001 A.5 · NIST AI RMF Map · EU AI Act Art. 6
AI impact assessment
A structured assessment for higher-tier systems covering intended use, affected parties, failure modes, and mitigations, completed before deployment and refreshed on material change.
Maps to ISO 42001 A.5 · NIST AI RMF Map · EU AI Act Art. 9
Privacy & fundamental-rights screening
Use cases touching personal information or significantly affecting individuals trigger the applicable privacy impact assessment, and where in scope, a fundamental rights impact assessment.
Maps to ISO 42001 A.5 · EU AI Act Art. 27 · GDPR Art. 35
Pre-deployment risk acceptance
A named, sufficiently senior approver formally accepts residual risk before a higher-tier system goes live; the acceptance and its basis are recorded.
Maps to ISO 42001 cl. 6 · NIST AI RMF Manage · EU AI Act Art. 9
DAT · Data
The controls over what the system learns from and what you feed it. Most AI failures trace back here.
Training & input data governance
Documented standards for the selection, sourcing, and approval of data used to train, fine-tune, ground, or prompt AI systems, with named data owners.
Maps to ISO 42001 A.7 · NIST AI RMF Map · EU AI Act Art. 10
Data quality & representativeness
Defined quality criteria — accuracy, completeness, currency, and representativeness for the population the system affects — checked before use and re-checked when data is refreshed.
Maps to ISO 42001 A.7 · NIST AI RMF Measure · EU AI Act Art. 10
Provenance & lineage records
For material systems, records of where data came from, what consents or licences attach to it, and how it was transformed — sufficient to answer a regulator or court.
Maps to ISO 42001 A.7 · NIST AI RMF Map · EU AI Act Art. 10
Privacy & data minimisation
Personal information entering AI systems is limited to what the purpose requires, handled per the applicable privacy regime, and excluded from vendor training unless explicitly agreed.
Maps to ISO 42001 A.7 · Privacy law (GDPR / Privacy Act) · EU AI Act Art. 10
IP & licensing review
Inbound data and model licences are reviewed for restrictions on commercial use, and the IP position on AI outputs the organisation relies on is documented.
Maps to ISO 42001 A.7 · NIST AI RMF Map
MDL · Model lifecycle
The controls from design to retirement. Go-live is a milestone in the lifecycle, not the end of it.
Documented development standards
Builds and significant configurations follow documented standards covering design decisions, assumptions, limitations, and intended operating conditions — producing the technical documentation regulators expect.
Maps to ISO 42001 A.6 · NIST AI RMF Map · EU AI Act Art. 11
Pre-deployment validation & testing
Higher-tier systems pass defined acceptance tests for accuracy and reliability on realistic data, with results recorded and compared against documented thresholds before release.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 15
Bias & fairness testing
Systems affecting people are tested for performance differences across relevant groups before deployment and on a defined cycle after it, with thresholds and remediation paths agreed in advance.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 10
Robustness & adversarial testing
Higher-tier and externally exposed systems are stress-tested against adversarial and out-of-distribution inputs — including red-teaming for generative systems — before release and after material change.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 15
Versioning & change management
Model versions, prompts, and configuration are version-controlled; material changes — including silent vendor model updates where detectable — go through change approval and regression testing.
Maps to ISO 42001 A.6 · NIST AI RMF Manage · EU AI Act Art. 11
Decommissioning & retirement
A defined process for retiring AI systems: dependent processes identified, data handled per retention rules, and the inventory updated — so abandoned systems do not run ungoverned.
Maps to ISO 42001 A.6 · NIST AI RMF Manage
TPR · Third party & procurement
The controls for AI you buy rather than build — which, for most organisations, is now most of it.
AI vendor due diligence
Before signing, vendors answer a defined diligence set: training data and model provenance, security posture, data handling and retention, performance evidence, and incident history.
Maps to ISO 42001 A.10 · NIST AI RMF Govern · APRA CPS 230
Contractual controls
Contracts for material AI services secure rights to information, audit, and notification of material model changes and incidents, plus exit and data-return provisions.
Maps to ISO 42001 A.10 · APRA CPS 230
Concentration & fourth-party mapping
Material AI dependencies are mapped through to the cloud hosts and foundation-model providers behind your vendors, with concentration assessed and contingency plans for the critical ones.
Maps to ISO 42001 A.10 · NIST AI RMF Map · APRA CPS 230
Ongoing vendor monitoring
Material AI vendors are monitored through the relationship — service performance, control attestations, incident notifications — not only assessed at onboarding.
Maps to ISO 42001 A.10 · NIST AI RMF Manage · APRA CPS 230
SEC · Security
The controls against attacks that target AI specifically, layered on top of conventional information security.
AI threat modelling
Higher-tier and externally exposed systems are threat-modelled for AI-specific attack paths — prompt injection, training-data poisoning, model extraction, and sensitive-data leakage through outputs.
Maps to ISO 42001 A.6 · NIST AI RMF Measure · EU AI Act Art. 15
Access control for models & data
Models, weights, training data, prompts, and AI system configuration are covered by least-privilege access control and the same joiner-mover-leaver discipline as other crown-jewel assets.
Maps to ISO/IEC 27001 · EU AI Act Art. 15 · APRA CPS 234
Secure deployment & integration hardening
AI integrations are hardened: output handling that prevents injected instructions reaching downstream systems, constrained tool permissions for agents, and isolation of untrusted inputs.
Maps to ISO/IEC 27001 · EU AI Act Art. 15 · APRA CPS 234
AI-generated code review
Code produced with AI assistance passes the same review, testing, and dependency-scanning gates as human-written code, with no direct-to-production path.
Maps to NIST AI RMF Measure · APRA CPS 234
HUM · Transparency & human oversight
The controls that keep people informed and keep a human meaningfully in charge of consequential decisions.
Use disclosure & content labelling
People are told when they are interacting with an AI system, and AI-generated or materially AI-altered content is labelled where the law or the context requires it.
Maps to EU AI Act Art. 50 · NIST AI RMF Govern
Explainability proportionate to impact
For systems affecting people, the organisation can explain — at a level suited to the audience — what the system considers and why an individual outcome occurred.
Maps to NIST AI RMF Measure · EU AI Act Art. 13
Human oversight of consequential decisions
Decisions that significantly affect people retain meaningful human involvement: overseers have the information, authority, competence, and time to intervene — not a rubber stamp.
Maps to ISO 42001 A.9 · EU AI Act Art. 14 & 26 · NIST AI RMF Govern
Contestability & redress channel
A working route for affected people to question an AI-influenced outcome and have it reviewed by a human with authority to change it, with timeframes and records.
Maps to ISO 42001 A.8 · NIST AI RMF Govern
Instructions for use & deployer information
Systems ship with — or vendors are required to provide — clear documentation of capabilities, limitations, intended use, and oversight requirements, and that information reaches the people operating the system.
Maps to ISO 42001 A.8 · EU AI Act Art. 13
MON · Monitoring & incident response
The controls that catch degradation and failure in production — where AI risk actually materialises.
Performance & drift monitoring
Production systems are monitored against defined performance indicators with alert thresholds, so accuracy decay and data drift are detected by instrumentation rather than by complaint.
Maps to ISO 42001 cl. 9 · NIST AI RMF Measure · EU AI Act Art. 72
Output quality sampling
For generative and decision-support systems, a defined sample of outputs is periodically reviewed by qualified humans against quality and safety criteria, with results fed back into thresholds and training.
Maps to ISO 42001 cl. 9 · NIST AI RMF Measure
Logging & record-keeping
Material systems keep logs sufficient to reconstruct what the system did and why — inputs, outputs, versions, and overrides — retained per regulatory and evidentiary requirements.
Maps to ISO 42001 A.6 · EU AI Act Art. 12 & 26
AI incident definition & response runbook
The organisation has defined what counts as an AI incident, who responds, how systems are contained or rolled back, and how affected parties are informed — and has tested the runbook.
Maps to ISO 42001 cl. 10 · NIST AI RMF Manage
Serious-incident regulatory reporting
Obligations to notify regulators of serious AI incidents are mapped by jurisdiction, with thresholds, timeframes, and ownership assigned before an incident occurs.
Maps to EU AI Act Art. 73 · NIST AI RMF Manage
Post-incident review & control updates
Every material incident and near-miss produces a documented review, and the findings change something — a control, a threshold, a tier, or the inventory.
Maps to ISO 42001 cl. 10 · NIST AI RMF Manage
Using the library
Do not start at GOV-01 and work through all forty. Start with the inventory (GOV-05) and tiering (RSK-01), because they tell you which controls each system actually needs — proportionality is the difference between a defensible program and a paper one. Then build domain by domain in the order the gaps hurt: for most vendor-heavy organisations that means third-party (TPR) and usage controls early; for builders, the model lifecycle (MDL) and data (DAT) domains carry the weight.
For implementation depth, see the ISO 42001 implementation guide, how to audit AI systems, and AI vendor due diligence. Australian financial-services readers should read the library alongside APRA’s AI expectations.
Frequently asked questions
What is an AI control?
An AI control is a defined, repeatable, evidenceable measure that reduces a specific AI risk — for example, a maintained AI inventory, pre-deployment bias testing, or a human-oversight requirement for consequential decisions. Controls are the unit auditors and regulators work in: a policy states intent, a control is what you can show actually happens.
Do we need all 40 controls?
No. Proportionality is the point of risk tiering: an organisation using only vendor AI for low-stakes internal tasks needs a small subset, weighted toward governance, third-party, and usage controls, while an organisation deploying high-risk systems that affect people needs most of the library. The tiering controls (RSK-01 and RSK-02) exist precisely to tell you which of the others apply to each system.
How do the ISO 42001 mappings work?
ISO/IEC 42001 contains management-system clauses (4 to 10) and an Annex A control set organised into families covering policies, internal organisation, resources, impact assessment, the AI system life cycle, data, information for interested parties, responsible use, and third-party relationships. We map each control to the relevant clause or Annex A family. The mappings are indicative working references, not a conformity claim — certification requires assessment against the standard itself.
Are these controls legally required?
It depends on what you deploy and where. The EU AI Act makes specific controls binding for providers and deployers of high-risk systems — risk management, data governance, logging, human oversight, post-market monitoring, and serious-incident reporting among them — and APRA expects regulated Australian entities to apply existing prudential standards to AI. Outside those scopes, the controls are good practice that regulators, customers, and courts increasingly treat as the reasonable-steps baseline.
How do we evidence controls for an auditor or regulator?
Each control should produce artefacts as a by-product of operating it: the inventory itself, tiering decisions, completed impact assessments, test results against recorded thresholds, signed risk acceptances, vendor diligence packs, monitoring dashboards, and incident reviews. If a control generates no artefact, it will be treated as not operating. Our guide to auditing AI systems covers how to structure that evidence.
Related glossary terms
Controls are only as good as the gaps they close
Benchmark your organisation first, then come back to the library with a shortlist. The assessment takes minutes and maps directly onto these eight domains.
This library is general information and a working reference, not legal, financial, or compliance advice, and the framework mappings are indicative rather than a statement of conformity. Standards and regulatory requirements change and depend on your circumstances; always verify against the primary texts — ISO/IEC 42001, the NIST AI RMF, the EU AI Act, and your sector rules — and obtain advice from your own qualified counsel.