AI governance, explained: what it means, what it doesn’t, and what actually goes in a program
Most organizations adopting AI have no one formally accountable for governing it. The gap is rarely a lack of willingness — it is that “AI governance” gets used to mean four different things, and nobody agrees which one they are being asked to build.
In this brief
- What AI governance actually means
- The three layers: law, standards, internal policy
- The instruments that matter right now
- What changed in 2026
- What an AI governance program contains
- Who owns it
- Where programs go wrong
- Where to start
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, it is not model safety research, and it is not a policy document. Those are inputs. Governance is the accountability structure around them.
1. What AI governance actually means
Four things get called AI governance, and conflating them is the most common reason programs stall before they start.
AI ethics asks whether a system should exist. It is 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 matters practically. 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.
2. 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. But the third layer — internal policy — is where the exposure actually lives, and it applies to everyone regardless of jurisdiction.
3. 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, and organized around four functions: Govern, Map, Measure, Manage. It is not a compliance standard and there is nothing to certify against. Its value is that it gives you a defensible structure when someone asks how you assessed a system. In practice it is the most usable starting point for organizations that are not yet sure what applies to them.
ISO/IEC 42001
An AI management system standard, certifiable, and built on the same architecture as ISO 27001. If you already run a certified ISMS, this is the least disruptive path to a formal program — 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.
4. 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 from 2 August 2027 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 also slipped. Organizations would have faced obligations without a 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, along with the general application of the Act and the start of enforcement.
So 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.
5. What an AI governance program contains
Stripped of framework language, a working program produces six things.
- An inventory. Every AI system in use, including the ones procured as features inside other software. This is 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, and which regulatory tier it falls into.
- A risk assessment. Documented, repeatable, and 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.
6. Who owns it
The honest answer is that it is genuinely contested, and organizations resolve it in 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 or equivalent, sitting across both. This is where large regulated organizations are landing, and it is 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.
7. Where programs go wrong
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 program. It is not. You have vendor management, change control, access management, risk assessment and records retention already. Most of this is a set of amendments to processes that exist, not a parallel structure.
Writing policy nobody can follow. A policy that prohibits 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.
8. 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, without 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 that carries regulatory weight in every framework I have named here.
Then name an owner, write down what is approved, and record the decisions from that point forward. Everything else — framework selection, certification, formal impact assessments — is easier once those three things exist and nearly impossible before.