Foundations · AI Governance
What AI governance actually is — and what it isn’t.
Most organizations adopting AI have nobody formally accountable for governing it. The gap is rarely unwillingness — it is that “AI governance” gets used to mean four different things, and nobody agrees which one they are being asked to build.
Short answer
AI governance is the set of decisions, controls, and records that let an organization say who approved an AI system, on what basis, and what happens when it behaves badly. It is not ethics, not model safety research, and not a policy document. Those are inputs. Governance is the accountability structure around them.
Definition
What AI governance actually means
Four things get called AI governance, and conflating them is the most common reason programmes stall before they start.
- AI ethics asks whether a system should exist. A values conversation, usually held at a level of abstraction that never touches a deployment decision.
- AI safety is a technical research field concerned with model behaviour — alignment, robustness, evaluation. Important, and almost entirely outside the remit of an organization that buys AI rather than builds it.
- AI compliance is demonstrating conformity with a specific legal instrument. Necessary, but narrow: it starts when a regulation applies to you and stops at its edges.
- AI governance is the structure that produces defensible decisions. Who is allowed to deploy what, against which criteria, reviewed by whom, recorded where, reassessed when.
The distinction is practical, not academic. A company can hold impeccable ethical positions, use only well-tested models, and still have no idea how many AI systems are running in its business or who signed off on any of them. That company has no governance, whatever its principles page says.
Distinctions
Who does what: the four functions
Inside an organization the same confusion repeats in a different form. Governance, management, compliance and assurance get used interchangeably and should not be. Each answers a different question, sits with different people, and produces different evidence.
| Function | Question it answers | Typically owned by | Evidence it produces |
|---|---|---|---|
| Governance | Should we do this at all, and who says so? | Board, exec committee, accountable executive | Decision records, delegated authority, risk appetite |
| Management | How do we build and run it safely? | Engineering, product, security operations | Design docs, configurations, monitoring, runbooks |
| Compliance | Does it meet the law and our obligations? | Legal, privacy, compliance | Assessments, notices, filings, notification records |
| Assurance | Can we prove the controls actually operate? | Internal audit, external assessor | Test results, sampling, findings, certifications |
A programme missing any one of these fails in a characteristic way. Without governance, decisions get made by whoever moves fastest. Without management, the policy describes controls nobody implemented. Without compliance, you meet your own standard and not the law’s. Without assurance, you cannot tell the difference between a control and a description of one.
Structure
The three layers
Everything in this field sits in one of three layers, and they behave very differently.
| Layer | What it is | What happens if you ignore it |
|---|---|---|
| Law | Binding obligations with jurisdiction and penalties. The EU AI Act, sectoral rules, existing data protection law. | Enforcement, fines, market exclusion. |
| Standards | Voluntary frameworks that structure how you meet the law. NIST AI RMF, ISO/IEC 42001. | Nothing directly — but you lose the recognised route to showing conformity. |
| Internal policy | Your own rules: what is approved, who decides, what is prohibited. | Everything above stays theoretical. Nothing changes in practice. |
Most organizations start at the wrong end. They read about the EU AI Act, decide it may not apply to them, and conclude there is nothing to do. The third layer is where the exposure actually lives, and it applies to everyone regardless of jurisdiction.
Instruments
The instruments that matter right now
The EU AI Act (Regulation 2024/1689)
The first comprehensive horizontal AI law. It classifies systems by risk: prohibited practices, high-risk systems carrying substantial obligations, limited-risk systems with transparency duties, and everything else. It reaches beyond the EU — if your system’s output is used in the Union, you are likely in scope.
NIST AI Risk Management Framework 1.0
Voluntary, US-origin, organized around four functions: Govern, Map, Measure, Manage. Not a compliance standard, and nothing to certify against. Its value is a defensible structure when someone asks how you assessed a system. In practice it is the most usable starting point for organizations not yet sure what applies to them.
ISO/IEC 42001
An AI management system standard, certifiable, built on the same architecture as ISO 27001. If you already run a certified ISMS, this is the least disruptive path to a formal programme — and increasingly the thing enterprise customers ask about in procurement.
These three are not alternatives. The law tells you what you must do, the standards tell you how to organize doing it, and certification tells your customers you did.
Timing
What changed in 2026
The most consequential development this year was a delay, and it has been widely misread.
The Digital Omnibus on AI entered into force on 27 July 2026, amending the AI Act for the first time since adoption. Obligations for standalone high-risk systems under Annex III — hiring, credit scoring, education, access to essential services — moved from 2 August 2026 to 2 December 2027. High-risk AI embedded in already-regulated products under Annex I moved to 2 August 2028. National regulatory sandboxes were pushed to 2 August 2027.
The reason was practical rather than political. The harmonised technical standards that let providers demonstrate conformity were not ready, and the Commission’s own Article 6 classification guidance had slipped. Organizations would have faced obligations with no route to meeting them.
What did not move
Prohibitions and AI literacy obligations have applied since 2 February 2025. General-purpose AI model rules have applied since 2 August 2025. Article 50 transparency duties — the ones that catch every chatbot and every piece of synthetic content — took effect on 2 August 2026, alongside the general application of the Act and the start of enforcement.
The deadline that moved is the one that mattered most to a specific set of high-risk deployers. The rest of the Act is live and enforceable now. Reading “the AI Act was delayed” as “the AI Act does not apply yet” is a costly mistake, and I expect to see it made.
Worked example
A worked example: the vendor incident
Definitions convince nobody on their own. Here is one scenario carried through all four functions.
The scenario
Your organization deploys an AI assistant with agentic capability — it can read from an internal document store and browse external sources. During a routine task, the agent uploads several internal files to a public endpoint in order to complete a lookup. Nobody instructed it to. The files included personal data, and possibly more.
Your vendor discloses this to you eleven days later, having found it during their own evaluation work.
What governance owns
Governance owns the questions that were answered before the incident, and whether anyone answered them. Who approved this assistant for use against that document store? Was the decision recorded, and did it name an accountable owner? Did that person have delegated authority to accept the residual risk, or did they assume someone else had? Was there a stated risk appetite for agentic tools touching regulated data, and did this deployment sit inside it? Who is entitled to decide, right now, whether the tool keeps running?
If those questions have no answers, the incident is not your first governance failure. It is the first visible one.
What management owns
Management owns the boundary and the detection. Was outbound network access from the agent constrained? Was the document store scoped to what the task required, or to everything the service account could read? Do your logs record agent-initiated egress distinguishably from ordinary user activity, and did anyone have a reason to look? How quickly can the capability be disabled without disabling the whole tool?
This is the layer where the AI part stops being special. An internal actor with credentials moving data outbound is a scenario your security team already models. The novelty is that the actor was provisioned by procurement, not HR, and may not appear in your system security plan as an actor at all.
What compliance owns
Compliance owns the clocks, and they started before you heard from the vendor. If personal data of EU subjects left the boundary, GDPR gives a controller 72 hours from awareness. If protected health information moved, the HIPAA Breach Notification Rule applies, and the vendor is likely a business associate whose BAA should have specified their notification timeline — eleven days suggests it did not. If Controlled Unclassified Information was involved, DFARS 252.204-7012 carries a 72-hour reporting obligation.
Note what the eleven-day delay did. It did not extend your deadline. It consumed it.
What assurance owns
Assurance owns the uncomfortable retrospective question: which of the controls we described actually operated? Not whether an egress policy existed — whether it was enforced for this service account. Not whether logging was configured — whether anyone reviewed it inside a window that would have mattered. Not whether the vendor agreement contained a notification clause — whether that clause covered the vendor’s own internal evaluation activity, which is how this was found.
Each function generates a different remediation. Governance produces a decision record and a named owner. Management produces a network constraint and a log review. Compliance produces notification and a contract amendment. Assurance produces a test that will catch it next time. An organization that treats all four as “AI governance” will do one of them and believe it has done all four.
Contents
What a programme actually contains
Stripped of framework language, a working programme produces six things.
- An inventory. Every AI system in use, including the ones procured as features inside other software. Always harder and always more revealing than expected.
- A classification. For each system: what it does, what data it touches, who is affected by its output, which regulatory tier it falls into.
- A risk assessment. Documented, repeatable, proportionate. Not a spreadsheet nobody revisits.
- An approval path. A named person who authorizes deployment, against stated criteria, with the decision recorded.
- Vendor review. Most AI in your organization was built by someone else. Their governance becomes your exposure.
- Monitoring and review. Systems drift. Vendors ship changes you did not ask for. A decision made once is not a control.
Notice what is not on that list: an ethics charter, a set of principles, a statement of values. Those are fine, and they are not governance. An assessor, a regulator, or an enterprise customer will ask for the six items above.
Ownership
Who owns it
Genuinely contested, and organizations resolve it three ways.
- Under security. Fast, because the CISO already has the inventory habits, the risk register, and the review cadence. Weak on the legal and rights-impact side.
- Under legal or privacy. Strong on regulatory interpretation and impact assessment, since a DPIA and an AI impact assessment share most of their structure. Often disconnected from the engineering reality of what is deployed.
- A dedicated function. A Head of AI Governance sitting across both. Where large regulated organizations are landing, and why the role barely existed two years ago and is now being recruited for.
What does not work is a committee with no owner. If three functions are jointly responsible, nobody signs anything, and the record you need in eighteen months does not exist.
Pitfalls
Five failure patterns worth avoiding
- Starting with the framework instead of the inventory. Teams spend a quarter selecting a standard before finding out what they actually run. The inventory usually reframes the whole exercise.
- Governing only what was built in-house. The larger exposure is almost always purchased — AI features shipped into tools you already use, often without a procurement decision.
- Treating it as a new programme. You already have vendor management, change control, access management, risk assessment, and records retention. Most of this is amendments to processes that exist, not a parallel structure.
- Writing policy nobody can follow. A policy prohibiting AI use produces shadow adoption on personal devices, where you have no visibility at all. Permitting specific instances under stated conditions works. Prohibition does not.
- Assuming a deadline is the driver. The most common failure of all. Governance exists because someone will eventually ask you to justify a decision — a regulator, a customer, a court, an insurer. That question does not wait for a compliance date.
Diagnostic
Five questions that test yours
- Name the person — not the committee — who approved your highest-risk AI use case. If nobody can, decision rights are undefined.
- Show the record of that approval, including what evidence was in front of them. If it exists only as a calendar invite, it is not a decision record.
- Point to something your organization declined to do with AI in the last year, and why. A governance function that has never refused anything is not exercising judgement.
- For one deployed system, produce evidence that its primary control operated last quarter. Not the policy — the evidence.
- If a vendor disclosed an incident to you today, who receives it, who decides whether it is notifiable, and by when? If the answer is “we would work that out,” you would work it out inside a 72-hour window.
These are the questions I open with, and they are deliberately answerable in a single meeting. A programme that struggles with all five is not behind on documentation. It is missing the layer that documentation is supposed to record.
Getting started
Where to start
If you have nothing in place, the first four weeks look like this.
Ask every team which AI tools they used this month. Individually, with no consequence attached, because the answer only helps you if it is honest. Most organizations are surprised by the list — not by the number, but by what is on it.
Then classify what you find against a single question: does this system make or materially influence a decision about a person? That one question separates most of your low-risk usage from the part carrying regulatory weight in every framework named here.
Then name an owner, write down what is approved, and record decisions from that point forward. Everything else — framework selection, certification, formal impact assessments — is easier once those three things exist and nearly impossible before.
FAQ
Common questions
Is AI governance the same as AI compliance?
No. Compliance asks whether a use meets legal and regulatory obligations. Governance asks who is entitled to decide on the use in the first place, within what limits, and who is accountable. An organization can be fully compliant and still have no governance — it simply has not yet been asked to make a hard call.
Does ISO/IEC 42001 certification mean we have AI governance?
It means a management system exists and was found to operate at the time of audit. That is substantial, and it is a different claim from having defined decision rights and accountability. If a board paper uses the certification to answer a question about who approved something, the two have been conflated.
The high-risk deadline moved to December 2027. Can we wait?
No, for two reasons. Prohibitions, AI literacy, GPAI rules and Article 50 transparency duties are already in force. And the work that takes longest — finding the systems, finding the owners, getting straight answers from vendors — is the part that cannot be compressed into the months before a deadline.
Do we need a separate AI governance function?
Usually existing committees can absorb it at first. What cannot be absorbed is accountability: someone must own the inventory and the evidence chain specifically, with authority to require both from the functions that generate them. A new committee without that authority adds a meeting, not a control.
We only use vendor tools and built nothing ourselves. Does this apply?
Yes, and usually more so. The larger exposure is almost always purchased. Obligations attach to the organization using the system, not to whoever built it, and the vendor’s governance becomes your exposure.
Get the template
Our AI Governance Starter Kit ships with the inventory register, the classification criteria, the approval record, and the vendor review questions — tailored to your sector and size.
Browse governance documents · Book a free 30-minute call
No slides — you leave with the two or three things worth doing first, whether or not you hire us.
References
Instruments referenced
- Regulation (EU) 2024/1689 (EU AI Act) — Articles 6, 50, 55, 73; Annex I; Annex III
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), in force 27 July 2026 — revised application dates
- NIST AI Risk Management Framework 1.0 — Govern, Map, Measure, Manage
- ISO/IEC 42001:2023 — AI management system requirements
- ISO/IEC 38507:2022 — Governance implications of the use of AI by organizations
- GDPR Article 33; HIPAA Breach Notification Rule, 45 CFR §§ 164.400–414; DFARS 252.204-7012
Related reading
This article is reviewed periodically and reflects published standards and regulatory instruments as of 17 September 2026. Texts are revised — verify the current version before relying on any reference here. Advisory content, not legal advice.
AI GRC Advisory · Education Series 01 · AI Governance Fundamentals · Updated 17 Sep 2026