UNESCO's Nine Approaches to Governing AI — And What Comes After the Taxonomy
UNESCO's 2026 policy brief maps nine approaches lawmakers are using to regulate AI, from principles to liability, illustrated with real laws from Brazil to South Korea. The taxonomy is useful — but none of the nine, by itself, guarantees an organisation can demonstrate what actually happened across the AI lifecycle. Here is the map, read against the primary source, plus the gap it leaves and the operational architecture that closes it: Policy to Risk to Decision to Action to Evidence to Accountability, and Governance to Runtime to Usage to Consumption to Cost.
AI governance has stopped being a debate about whether to regulate. It is now a question of how, and the answers are multiplying faster than anyone can track them. UNESCO's 2026 policy brief, Governing AI: Nine Emerging Approaches for Lawmakers Worldwide, is the most useful map of that landscape published so far — not because it recommends one model, but because it lets a legislator, a regulator, or a compliance lead see which levers are actually in play and how they combine.
The taxonomy is the easy part. What matters is what happens after a country picks its approaches, and an organisation has to live inside them.
TL;DR
UNESCO's brief sorts AI regulation into nine approaches — principles, standards, agile/experimentalist, facilitating and enabling, access to information and transparency, adapting existing laws, risk-based, mandatory rights-based, and liability — deliberately ordered from light-touch to more demanding, and explicitly not mutually exclusive. Real laws combine several. But every one of the nine specifies what must be true about an AI system; none of them, on its own, produces the record showing what was true. That gap is closed by an operational governance architecture that carries Policy → Risk → Decision → Action → Evidence → Accountability, and increasingly Governance → Runtime → Usage → Consumption → Cost. The EU AI Act's logging duties, ISO/IEC 42001 and 42005, the NIST AI RMF and the Council of Europe's HUDERIA have all already moved in this direction: the deliverable is evidence, not documentation.
What this article covers
1. What UNESCO actually published
Governing AI: Nine Emerging Approaches for Lawmakers Worldwide (UNESCO, 2026) was authored by Juan David Gutiérrez, PhD, Associate Professor at the University of Los Andes, Colombia, with the publication led by Prateek Sibal at UNESCO. It was launched in the lead-up to the first Global Dialogue on AI Governance in Geneva — the platform established by the UN General Assembly to advance the commitments of the Global Digital Compact and the Pact for the Future. It is published open access under CC-BY-SA 3.0 IGO.It is not a model law and does not pretend to be. The brief states plainly that it "does not endorse a specific AI regulatory approach". It is a working tool for legislators and their advisory teams, built around one practical question the brief poses directly: what are the different approaches to AI governance? Its framing observation is that since 2016 many countries have passed laws explicitly mentioning AI, and that the volume of AI bills in legislative bodies has risen sharply in the last three years.
The document has real consultative weight behind it. It was informed by the Inter-Parliamentary Union's Assembly in Geneva (23–27 March 2024) and by three webinars for parliamentarians run jointly by the IPU, UNESCO and the Internet Governance Forum. A draft went out for public consultation in August 2024; between August and October, UNESCO received over 100 submissions from individuals and organisations in 36 countries and territories across Africa, the Americas, Asia, Europe and Oceania.
Four framing rules travel with the taxonomy, and they matter more than the labels:
- The order is deliberate. The nine are "deliberately structured to guide readers from light-touch regulatory measures to more demanding approaches."
- Intensity is not a ranking. The brief is explicit that the approaches "are not listed in order of importance or desirability" — the spectrum describes how much a tool constrains, not how good it is.
- They are not mutually exclusive. AI laws "often combine two or more". The EU AI Act alone is cited as an illustration under five of the nine — standards, agile, transparency, risk and liability.
- Approaches evolve. A jurisdiction may start with principles — which the brief describes as "a baseline and transversal approach" — and layer other approaches on top later.
That combination is what makes the brief a diagnostic tool rather than a menu. You do not pick one. You end up governed by a stack of them at once, in a particular order, with particular seams between them.
2. The nine approaches, in one picture
3. What each approach obliges you to do
The taxonomy reads like political science until you put a fourth column on it. Then it turns into a compliance work plan, because each approach implies a specific artefact somebody will eventually ask you to produce. The middle column below is the brief's own illustrations, not ours.
| Approach | What the brief says it does | Examples the brief cites | The artefact it demands |
|---|---|---|---|
| 1 · Principles-based | Offers fundamental propositions guiding development and use through ethical, human-centric, human-rights-abiding processes | UNESCO Recommendation on the Ethics of AI; OECD Recommendation on AI; Peru's Law 31814 (2023); the Philippines' HB 7913; the UK pro-innovation white paper | A written policy — plus a mapping from each principle to a control |
| 2 · Standards-based | Uses technical standards as references to give operational precision to mandatory rules, and creates legal incentives such as a presumption of conformity | EU AI Act Article 40; the UK's AI Standards Hub, which has catalogued nearly 500 AI-relevant standards | Conformity evidence against a named standard — audited, not asserted |
| 3 · Agile / experimentalist | Creates flexible schemes — sandboxes and testbeds — for supervised testing under relaxed conditions | EU AI Act Article 57 and the Article 3 sandbox definition; South Korea's AI Act Article 19 | A sandbox record: what was tested, under which plan, with what result |
| 4 · Facilitating / enabling | Builds capability in human capital, technology, infrastructure and institutions | Japan's AI Act, enacted 28 May 2025, Articles 11–15; South Korea's AI Act Articles 16–23; Peru's Law 31814 Article 2 | Evidence of capability — skills, infrastructure, institutional capacity |
| 5 · Access to information and transparency | Requires transparency instruments letting the public access basic information about AI systems | France's Law No. 2016-1321 Article 6; EU AI Act Article 50; South Korea's AI Act Article 31 | A disclosure, a register entry, a machine-readable mark on generated output |
| 6 · Adapting existing laws | Amends sector-specific and transversal rules instead of issuing a standalone AI act | Article 22 GDPR on automated decisions; Colombia's Law 2502 of 2025, adding an aggravating factor for impersonation using AI | The records the underlying law already demanded — now for AI decisions |
| 7 · Risk-based | Tailors obligations to the risk a system poses in its specific context | EU AI Act tiers — unacceptable, high, limited, minimal — with Article 5 prohibitions; South Korea's "high-impact AI" duties, Article 32 | A risk classification per system, plus lifecycle risk-management records |
| 8 · Mandatory rights-based | Enshrines new rights and sets binding obligations to respect, protect and promote them across the lifecycle | GDPR rules on automated decision-making; Kenya's Data Protection Act 2019 section 35; the Philippines' HB 7913 "AI bill of rights"; Brazil's Bill No. 2238/2023 | A working route to contest a decision and get human review — and the log proving it ran |
| 9 · Liability | Assigns responsibility and sanctions, backed by criminal, administrative or civil liability | EU AI Act Articles 99–101: up to EUR 35 million or 7% of worldwide annual turnover for prohibited practices | A causal record: who did what, when, on whose authority |
A caveat the brief states twice and we repeat: those laws appear "purely as illustrations of the typologies", and their inclusion "doesn't mean an assessment vis-à-vis the alignment of these laws with international human rights law."
Now read the right-hand column top to bottom. Only two of the nine — principles, and facilitating and enabling — are discharged by writing something down and funding it. The other seven need something that was generated by the system while it ran.
4. What the taxonomy does not settle
This is the part worth sitting with.
Regulation can define principles, obligations, rights and responsibilities. Standards can supply operational precision where legislation is deliberately vague. Risk frameworks can set proportional controls, so a spam filter is not treated like a triage system. Transparency mandates can create visibility into what exists.
None of these, by itself, guarantees that an organisation can demonstrate what actually happened across the AI lifecycle.
That is not a criticism of the taxonomy — UNESCO is mapping legislative instruments, and legislative instruments are exactly the wrong tool for producing runtime facts. But it does mean the map has an edge, and the edge is where most organisations currently are. A control that exists in a policy document and a control that emitted a signed record last Tuesday at 14:07 are not the same object, and only one of them survives contact with an auditor, a regulator, or a claimant's lawyer.
The brief gets to the same edge from the legislative side. Its closing section gives parliamentarians six considerations, and the last of them reads like a warning label on the other eight:
From the brief's conclusions
"Prepare for implementation challenges: Establishing objectives is not enough to achieve them; it is also necessary to address implementation challenges and consider context-specific solutions."
Alongside it: legislate against specific documented problems rather than one-size-fits-all rules, because "broad and lax regulation could foster a sense of false security without actually preventing or solving problems"; borrow good practice from other jurisdictions without "isomorphic mimicry" — transplanting foreign procedures that lack the institutional context supporting them; and monitor "the results and impacts of regulations", staying open to new iterations.
UNESCO, Governing AI: Nine Emerging Approaches for Lawmakers Worldwide (2026), section 3. CC-BY-SA 3.0 IGO.
A false sense of security produced by a rule nobody can verify compliance with is the same failure, seen from the legislature rather than the server room. The distance between the objective and its achievement is spanned by an operational governance architecture.
5. The accountability chain
Each link in that chain is a place where governance normally breaks:
- Policy → Risk. The policy names acceptable uses; the risk assessment has to be per-system and per-context, not per-company. Most organisations write one and skip the other.
- Risk → Decision. A risk tier is inert unless it changes what the system is allowed to do. If your "high-risk" classification does not alter a single runtime control, it is a label, not a control.
- Decision → Action. The gap between what was authorised and what was invoked. This is where shadow AI lives.
- Action → Evidence. The hardest link, and the one most stacks simply do not have. An action that produced no durable record did not happen, as far as any auditor is concerned.
- Evidence → Accountability. Evidence with no named owner is trivia. Someone has to be answerable for each system, and the record has to identify them.
6. The second chain: governance to cost
There is a second chain forming alongside the first, and it is the one that gets AI governance funded:
Governance → Runtime → Usage → Consumption → Cost.This is not a metaphor. A decode step reads a specific set of weights, at a specific quantisation, on specific hardware, for a specific requester, under a specific policy. The record that satisfies a regulator ("which model version served this decision, and was it authorised?") is the same record that satisfies a CFO ("what did that team's agent cost us in July?"). Organisations that build the two separately end up with two half-built systems and no reconciliation between them.
The practical implication: your governance telemetry schema should carry the model identity, the quantisation, the context length and the token counts — not just a request ID and a timestamp. On this site those are the same fields that drive the cost calculator and the VRAM calculator, because they are the fields that determine what the hardware actually did.
7. What the rulebooks already assume
The move from documentation to evidence is not speculative. It is already written into the instruments that implement several of UNESCO's nine approaches — and, tellingly, into the brief's own description of them.
The brief names the evidence obligation without dwelling on it. In the standards-based section, it lists what an AI Act Article 40 presumption of conformity actually covers. The list runs: a risk management system; high-quality training, validation and test data; technical documentation kept up to date; "ensuring traceability through automatic recording of events (logs)"; systems transparent enough for deployers to use correctly; effective human oversight; and adequate accuracy, robustness and cybersecurity. Four of those seven are satisfied only by something the running system produces. The same pattern shows up in the risk-based section, where South Korea's obligations for high-impact AI are quoted as "identifying, assessing, and mitigating risks throughout the AI lifecycle" and establishing "a risk management system to monitor and respond to AI-related safety accidents" — continuous verbs, not a filing requirement. The EU AI Act builds logging into the product. Article 12 requires high-risk systems to be designed with automatic event-logging that supports post-market monitoring and the detection of risky states. Article 19 obliges providers to keep those automatically generated logs for at least six months, and Article 26(6) places an independent six-month floor on deployers — the organisations merely using a high-risk system in their professional activity. That is a risk-based approach with an evidence obligation stapled to it. The standards ecosystem has closed the assurance loop. ISO/IEC 42001 defines a certifiable AI management system. ISO/IEC 42005 gives the method for AI system impact assessments across the lifecycle. ISO/IEC 42006 then sets requirements for the bodies that audit and certify against 42001 — which is the tell. When a standards body starts regulating the auditors, the market has moved from "write a policy" to "prove it to someone qualified to check". The US voluntary track says the same thing in different words. The NIST AI Risk Management Framework organises everything under GOVERN, MAP, MEASURE and MANAGE — and MEASURE is not satisfiable without instrumentation. The Generative AI Profile (NIST AI 600-1) extends it to twelve generative-specific risk categories, several of which (data provenance, confabulation) are only tractable with runtime records. The rights-based track has an assessment methodology now. The Council of Europe Framework Convention on AI — opened for signature on 5 September 2024 — is paired with HUDERIA, a structured methodology for assessing human rights, democracy and rule-of-law risks across the AI lifecycle.Note what happened in Europe in parallel: the Digital Omnibus on AI pushed the high-risk deadlines out to December 2027 and August 2028. The dates moved. The artefacts did not. Anyone treating the delay as a reason to postpone instrumentation has misread which half of the obligation is hard.
8. The evidence stack
Put the nine approaches, the logging duties and the assurance standards together and a five-layer architecture falls out. Each layer emits something, and each layer answers a different question.
The asymmetry at the bottom of that diagram is the whole problem. Policy and assessment are produced by people who write documents, on a schedule, in advance. Enforcement, telemetry and attestation are produced by systems, continuously, at runtime. Governance programmes staffed entirely by the first kind of work cannot deliver the second kind of output, no matter how good the documents are.
9. Six questions an auditor will ask
The demonstrability test
Question 6 is the one that fails. The EU AI Act's six-month log-retention floor means the window is longer than most observability stacks retain by default.
If the honest answer to question 6 is "we would have to open a support ticket", then the accountability chain terminates outside your organisation — at exactly the link where liability does not.
10. Why this is an infrastructure decision
There is a straightforward reason this matters on a site about running models locally: the evidence layer lives wherever inference lives.
If a model runs on infrastructure you operate, the log plane is yours by construction. You choose the retention period, the schema, the signing, and who can read it. Nobody can deprecate an endpoint and take your audit trail with it, and no contractual renegotiation stands between you and a record you are legally required to hold for six months.
That is a real structural advantage, and it is the honest version of the argument — not "self-hosting is compliant". Running your own GPUs makes you the operator of the log plane and the party responsible for it. You inherit the retention duty, the access controls, the tamper-evidence, and the cost of storing all of it. The trade is that the responsibility is now something you can discharge rather than something you have to ask for.
The practical questions this raises — where inference sits, what an air gap really buys you, what on-premise actually costs over three years — are the subject of a whole section here:
- Enterprise & Sovereign AI — the hub, covering deployment models and control
- What is sovereign AI? — the definition, and what it does and does not include
- The EU AI Act and on-premise AI — how deployment topology changes your obligations
- Air-gapped LLM deployment — when full isolation is warranted
- On-premise LLM total cost of ownership — the three-year arithmetic
- AI vendor evaluation checklist — what to ask before you sign
- EU AI Act compliance guide — the obligations in plain English
11. Sovereign and critical AI
For sovereign and critical infrastructure, this stops being a compliance concern and becomes a capability requirement.
A national health system, a grid operator, a defence ministry or a central bank cannot answer "was this AI system operating within its authorised boundaries?" with a vendor's word. The demonstrability requirement is structurally different at that level: the evidence must be producible under adversarial conditions, when the vendor is unavailable, the network is severed, or the vendor's own interests are adverse to yours.
That pushes toward architectures where the model, the control plane and the log plane are all under domestic operational control — which is precisely why "sovereign AI" has migrated in two years from a slogan to a procurement line item. The capability to prove continuous conformance becomes as important as the regulation that demands it, because it is the only thing that converts the regulation from an aspiration into a fact.
12. What to do in the next 90 days
None of this requires waiting for a deadline. Six concrete moves, in rough order of leverage:
- Inventory first. Every AI system in production, its business owner, its purpose, its risk tier. You cannot govern a population you have not enumerated, and most organisations underestimate theirs by a factor of two or three once agents and embedded features are counted.
- Decide where the log plane lives before you decide which model to run. This ordering is backwards almost everywhere, and it is expensive to reverse.
- Instrument the token, not just the request. Model identity, version, quantisation, context length, tokens in and out, GPU-seconds. These fields serve compliance and finance simultaneously; capturing them later means re-instrumenting.
- Write the boundary as machine-readable policy. A PDF listing approved use cases cannot deny a request. A policy object can. This is the difference between the Decision link existing and not existing.
- Run an evidence fire-drill. Pick a request from four months ago and try to reconstruct it end to end. Whatever breaks is your actual gap — and it will not be the layer you expected.
- Map your jurisdictions onto the nine. Which approaches apply to you, and what artefact does each one demand? The table in section 3 is a starting template; fill the right-hand column with a real system name and a real storage location.
The bottom line
UNESCO's brief is a genuinely good map, and its most valuable feature is the thing it states almost in passing: the nine approaches are not alternatives, they compose. Any organisation of consequence will end up governed by several at once, in a stack that varies by jurisdiction. The brief is also honest about its own limits — it declines to endorse an approach, and it closes by telling parliamentarians that setting objectives is not the same as achieving them.
But a map of regulatory instruments is a map of intent. Every one of the nine specifies something that must be true about an AI system. Not one of them, by itself, produces the record showing that it was true at 14:07 last Tuesday, for that request, under that authority, at that cost.
That record is an architecture, not a policy. And the strategic question is narrowing to a single sentence:
Can we prove, continuously and auditably, that this AI system operated within its authorised boundaries?The organisations that can answer yes will find the next decade of AI regulation to be a documentation exercise. The ones that cannot will find it to be something else entirely. UNESCO's taxonomy is not only a regulatory map — it is a signal that the next frontier is the operationalisation of AI governance.
This article is an analysis for people building and deploying AI systems — it is not legal advice. Regulatory details are summarised from the primary sources linked below; for anything that carries consequences, read the instruments themselves and take qualified counsel in your jurisdiction.Sources & further reading
The brief itself- UNESCO, Governing AI: Nine Emerging Approaches for Lawmakers Worldwide (2026) — the primary source for everything in sections 1 to 4 above. Authored by Juan David Gutiérrez; reference CI/DIT/AI/Gov2026; open access under CC-BY-SA 3.0 IGO.
- UNESCO — Consultation paper on AI regulation: emerging approaches across the world (2024) — the consulted draft it grew out of
- UNESCO — Artificial Intelligence and emerging technologies
- UNESCO — AI for the Public Sector
- UNESCO Recommendation on the Ethics of Artificial Intelligence
- UNESCO — Global Dialogue on AI Governance, Geneva, 6–7 July 2026
- United Nations — Global Dialogue on AI Governance FAQ
- ITU — Global Dialogue on AI Governance
- Inter-Parliamentary Union — Geneva AI Governance Week
- EU AI Act, Article 12 — Record-Keeping
- EU AI Act, Article 19 — Automatically Generated Logs
- EU AI Act, Article 26 — Obligations of Deployers of High-Risk AI Systems
- Regulation (EU) 2024/1689 — the AI Act on EUR-Lex
- European Commission — AI Act Service Desk
- ISO/IEC 42001:2023 — AI management systems
- ISO/IEC 42005:2025 — AI system impact assessment
- ISO/IEC 42006:2025 — Requirements for AIMS audit and certification bodies
- NIST — AI Risk Management Framework
- NIST AI 600-1 — Generative AI Profile (PDF)
- Council of Europe — Framework Convention on Artificial Intelligence
- Council of Europe — HUDERIA
- OECD AI Principles
Listed as illustrations of the typologies only — the brief makes no assessment of their alignment with international human rights law.
| Jurisdiction | Instrument |
|---|---|
| Brazil | Bill: Projeto de Lei No. 2238/2023, on the use of artificial intelligence |
| Colombia | Law 2502 of 2025, amending Article 296 of the Criminal Code (impersonation) |
| European Union | Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2024/1689 (AI Act) |
| France | LOI n° 2016-1321 du 7 octobre 2016 pour une République numérique |
| Japan | Act on Promotion of Research and Development, and Utilization of AI-related Technology (enacted 28 May 2025) |
| Kenya | Data Protection Act, No. 24 of 2019 |
| Peru | Ley N° 31814 of 13 June 2023, promoting AI for economic and social development |
| South Korea | Framework Act on the Advancement of Artificial Intelligence and the Establishment of Trust (promulgated 21 January 2025, effective 22 January 2026) |
| The Philippines | Bill: House Bill No. 7913, establishing an AI regulatory framework |