AI GRC: governance, risk and compliance for AI
AI GRC is the discipline of running artificial intelligence the way regulated organisations run every other material risk: structures that make AI someone’s accountable job, processes that find and treat AI-specific harms, and controls that evidence conformity with the laws and standards that apply to you. This page is the map — what the discipline covers, why your existing GRC program will not stretch over AI unmodified, and how the major frameworks fit together.
Last reviewed: 7 June 2026
The three pillars
Each pillar exists in enterprise GRC already. What changes with AI is the subject matter: systems that behave probabilistically, learn from data you may not control, and sit inside supply chains you cannot fully see.
Governance
The structures that make AI someone’s job: board oversight, accountable owners for each AI system, an AI policy, decision rights for approving or retiring use cases, and the AI literacy needed for executives to challenge what they are shown rather than accept vendor summaries.
Risk
The processes that find and treat AI-specific harms before they land: a maintained AI inventory, use-case risk tiering against a stated risk appetite, impact assessments for consequential systems, and treatment of risks that traditional registers miss — bias, drift, hallucination, prompt injection, and supplier concentration.
Compliance
The controls and evidence that demonstrate conformity with the obligations that apply to you — the EU AI Act, sector rules such as APRA’s prudential standards, privacy law, and voluntary standards like ISO/IEC 42001 — so that what you claim about your AI can be shown, not just asserted.
For the underlying concepts, see what AI governance is, AI risk management, and AI compliance.
Why traditional GRC breaks on AI
Mature organisations are tempted to file AI under existing technology risk and move on. Five properties of AI systems defeat that approach — and explain most of the AI governance failures now appearing in enforcement actions and supervisory letters.
AI is probabilistic, not deterministic
Traditional GRC assumes software behaves the same way every time, so you can test once and rely on the result. AI systems produce different outputs for similar inputs and degrade silently as the world changes, which makes point-in-time testing insufficient and continuous monitoring a control in its own right.
The supply chain is opaque
Most organisations now consume AI through vendors built on foundation models they did not train, hosted on infrastructure they do not control. Accountability does not transfer with the contract — regulators including APRA expect you to map the fourth parties behind your AI vendors, not just the vendors themselves.
Regulation is moving faster than policy cycles
The EU AI Act, US state laws, and supervisory expectations from financial regulators are landing on different timelines with different definitions. An annual policy review cannot keep pace; AI GRC needs a standing process for regulatory horizon scanning and impact analysis.
Adoption outruns the register
Employees adopt AI tools faster than procurement and risk teams can record them. Shadow AI means the gap between the systems you govern and the systems you actually run is usually wider than leadership believes — which is why an enforced inventory is the first control, not a later one.
Agentic AI blurs accountability
When AI agents take multi-step actions — querying systems, sending messages, executing transactions — the question shifts from “was the output accurate?” to “who is accountable for what the system did?”. Existing delegation and authorisation frameworks were not written for non-human actors.
Related reading: shadow AI, model risk management, and agentic AI.
The AI GRC operating model: eight components
Programs differ in maturity and scale, but a defensible AI GRC capability reduces to eight components. They are sequenced deliberately: each one depends on the ones before it.
An AI inventory: every system, model, and material AI feature in use, with an accountable owner. You cannot govern what you have not catalogued.
Risk appetite and use-case tiering: a stated position on what the organisation will and will not use AI for, and a triage that sorts use cases into risk tiers with proportionate controls.
An AI policy and acceptable-use rules: the organisation-wide rules for procuring, building, and using AI, written so that staff can actually follow them.
Lifecycle controls: requirements at design, pre-deployment validation and testing, change management for model updates, and deliberate decommissioning — not just controls at go-live.
Third-party and vendor management: due diligence before signing, contractual rights to information and audit, and mapping of concentration and fourth-party dependencies.
Monitoring, logging, and incident response: drift and performance monitoring in production, retained logs, a definition of an AI incident, and a tested response runbook including regulatory reporting.
Assurance: independent validation of high-risk systems, internal audit coverage of AI, and second-line capability that can challenge probabilistic models — the three lines of defence applied to AI.
Board reporting and literacy: regular, decision-useful reporting on the AI portfolio and its risks, supported by enough director-level AI literacy to provide effective challenge.
Each component decomposes into specific, evidenceable controls. We maintain those as a working reference: the AI Controls Library maps forty controls across eight domains to ISO/IEC 42001, the NIST AI RMF, and the EU AI Act.
How the major frameworks fit together
These are complements, not competitors: a law tells you what you must do, a standard gives you a certifiable way to organise doing it, and a framework gives you the thinking structure. Most mature programs draw on several at once.
| Framework | What it is | Use it for |
|---|---|---|
| ISO/IEC 42001 | Certifiable management-system standard (published December 2023) | Building an auditable AI management system; its Annex A control set is the closest thing to a common control language for AI. |
| NIST AI RMF | Voluntary framework (1.0, January 2023; Generative AI Profile, July 2024) | Structuring risk work around the Govern, Map, Measure and Manage functions; widely referenced in US procurement and policy. |
| EU AI Act | Binding law (Regulation (EU) 2024/1689), phased obligations through 2027 | Legal obligations by role and risk tier — including risk management, data governance, human oversight, and post-market monitoring for high-risk systems. |
| APRA prudential standards | Binding for APRA-regulated entities in Australia (CPS 230, CPS 234, CPS 220, CPS 510 applied to AI) | Operational resilience, information security, and supplier risk expectations for banks, insurers, and superannuation trustees using AI. |
| AIRA Framework | Implementation methodology | Sequencing the build: turning the standards above into a practical, staged AI governance program. |
For who enforces what, see our regulator profiles and the EU AI Act timeline. Penalties are material: prohibited practices under the EU AI Act carry fines of up to €35 million or 7% of global annual turnover.
Where to start
Three moves create most of the early value. First, build the inventory and tier it — an honest list of what is actually in use, ranked by potential for harm. Second, set the rules: an AI policy that staff can follow and a risk appetite the board has actually endorsed. Third, put assurance on the highest tier: audit your highest-risk AI systems against the controls you claim to have.
For sequencing the full build, see the 90-day implementation roadmap and the maturity model; if you sit in a risk or compliance function, the GRC teams hub collects everything relevant to your seat.
Frequently asked questions
What is AI GRC?
AI GRC is governance, risk and compliance applied to artificial intelligence. It is the combination of structures that assign accountability for AI systems (governance), processes that identify and treat AI-specific harms such as bias, drift, and misuse (risk), and controls plus evidence that demonstrate conformity with laws and standards such as the EU AI Act, ISO/IEC 42001, and the NIST AI RMF (compliance).
How is AI GRC different from AI governance?
AI governance is one of the three pillars: the accountability structures, policies, and oversight around AI. AI GRC is the broader operating discipline that joins governance with risk management and compliance so the three work as one program — the same relationship enterprise GRC has to corporate governance. In practice the terms overlap heavily, and many organisations use “AI governance” to mean the whole program.
What does an AI GRC program actually include?
At minimum: an AI inventory with accountable owners, use-case risk tiering against a stated risk appetite, an AI policy, lifecycle controls from design to decommissioning, third-party and fourth-party management, production monitoring with incident response, independent assurance, and board reporting. Each component decomposes into specific controls — our AI Controls Library maps forty of them to ISO 42001, the NIST AI RMF, and the EU AI Act.
Should we start with ISO 42001 or the NIST AI RMF?
They answer different questions and are commonly used together. NIST AI RMF is a free, flexible way to structure risk thinking and is a good first scaffold; ISO/IEC 42001 is a certifiable management-system standard that suits organisations needing to demonstrate conformity to customers, regulators, or boards. Many start by organising work around the NIST functions, then formalise into an ISO 42001 management system when certification or customer assurance becomes valuable.
Do we need AI GRC if we only use vendor AI and build nothing in-house?
Yes — most AI risk now enters organisations through procurement, not development. You remain accountable for decisions made with vendor AI, for the data you put into it, and under regimes like the EU AI Act deployers carry their own obligations including human oversight and input-data relevance. A vendor-only estate changes the control emphasis toward due diligence, contracts, usage policy, and monitoring; it does not remove the need for the program.
What are AI GRC tools, and do we need one?
AI GRC platforms automate parts of the program: inventory and registration workflows, risk-tiering questionnaires, control libraries, evidence collection, and regulatory mapping. They are useful at scale, but they are an accelerant, not a substitute — a tool cannot set your risk appetite, assign accountability, or make the board literate. Most organisations should stand up the operating model first, on spreadsheets if necessary, and buy tooling once the process it would automate actually exists.
Related glossary terms
Find out where your program actually stands
The free assessment benchmarks your organisation against the eight components above and shows where the gaps are. The Controls Library gives you the concrete control language to close them.
This page is general information about AI governance, risk, and compliance practice, not legal, financial, or compliance advice, and not a substitute for advice tailored to your circumstances. Regulatory requirements and standards change frequently; always confirm the current position against primary sources and obtain advice from your own qualified counsel before relying on anything here.