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.

August 26, 202618 min readJakub Rusinowski

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
2 — The nine approaches, in one picture
3 — What each approach obliges you to do
4 — What the taxonomy does not settle
5 — The accountability chain
6 — The second chain: runtime to cost
7 — What the rulebooks already assume
8 — The evidence stack
9 — Six questions an auditor will ask
10 — Why this is an infrastructure decision
11 — Sovereign and critical AI
12 — What to do in the next 90 days

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

Nine ways to govern AI Ordered light-touch to more demanding — the bands below are our grouping lighter touch more demanding SET DIRECTION 1 · Principles-based Ethical, human-centric guidance for the whole AI lifecycle 2 · Standards-based Operational precision, plus a presumption of conformity 3 · Agile / experimentalist Sandboxes and supervised testing under a regulator SHAPE CONDITIONS 4 · Facilitating / enabling Capacity, infrastructure and skills so compliance is possible 5 · Transparency mandates The public can find out what a system is and what it does 6 · Adapting existing laws Data protection, labour, consumer and criminal law BIND CONDUCT 7 · Risk-based Obligations scale with the assessed risk in context 8 · Mandatory rights-based Enshrines new rights and binding duties to protect them 9 · Liability Responsibility and sanctions when something goes wrong Not mutually exclusive — UNESCO notes that AI laws and bills often combine two or more.

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.

ApproachWhat the brief says it doesExamples the brief citesThe artefact it demands
1 · Principles-basedOffers fundamental propositions guiding development and use through ethical, human-centric, human-rights-abiding processesUNESCO Recommendation on the Ethics of AI; OECD Recommendation on AI; Peru's Law 31814 (2023); the Philippines' HB 7913; the UK pro-innovation white paperA written policy — plus a mapping from each principle to a control
2 · Standards-basedUses technical standards as references to give operational precision to mandatory rules, and creates legal incentives such as a presumption of conformityEU AI Act Article 40; the UK's AI Standards Hub, which has catalogued nearly 500 AI-relevant standardsConformity evidence against a named standard — audited, not asserted
3 · Agile / experimentalistCreates flexible schemes — sandboxes and testbeds — for supervised testing under relaxed conditionsEU AI Act Article 57 and the Article 3 sandbox definition; South Korea's AI Act Article 19A sandbox record: what was tested, under which plan, with what result
4 · Facilitating / enablingBuilds capability in human capital, technology, infrastructure and institutionsJapan's AI Act, enacted 28 May 2025, Articles 11–15; South Korea's AI Act Articles 16–23; Peru's Law 31814 Article 2Evidence of capability — skills, infrastructure, institutional capacity
5 · Access to information and transparencyRequires transparency instruments letting the public access basic information about AI systemsFrance's Law No. 2016-1321 Article 6; EU AI Act Article 50; South Korea's AI Act Article 31A disclosure, a register entry, a machine-readable mark on generated output
6 · Adapting existing lawsAmends sector-specific and transversal rules instead of issuing a standalone AI actArticle 22 GDPR on automated decisions; Colombia's Law 2502 of 2025, adding an aggravating factor for impersonation using AIThe records the underlying law already demanded — now for AI decisions
7 · Risk-basedTailors obligations to the risk a system poses in its specific contextEU AI Act tiers — unacceptable, high, limited, minimal — with Article 5 prohibitions; South Korea's "high-impact AI" duties, Article 32A risk classification per system, plus lifecycle risk-management records
8 · Mandatory rights-basedEnshrines new rights and sets binding obligations to respect, protect and promote them across the lifecycleGDPR 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/2023A working route to contest a decision and get human review — and the log proving it ran
9 · LiabilityAssigns responsibility and sanctions, backed by criminal, administrative or civil liabilityEU AI Act Articles 99–101: up to EUR 35 million or 7% of worldwide annual turnover for prohibited practicesA 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

The accountability chain Regulation reaches the left. Your architecture has to produce the right. SPECIFIED BY REGULATION PRODUCED AT RUNTIME WHAT AN AUDITOR READS Policy Risk Decision Action Evidence Accountability approved use cases impact assessments policy-as-code verdicts runtime telemetry signed, timed records who answers for what The taxonomy tells you what must be true. Only the chain tells you whether it was.

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.
The chain nobody wrote into the regulation The telemetry that proves compliance is the same telemetry that prices the system Governance what is authorised, and for which purpose Runtime which model actually ran, at what version Usage who invoked it, under which mandate Consumption tokens, context, GPU-seconds Cost per team, per use case One unit carries both Every decode step is simultaneously an audit event and a line item. The same record answers "was this within its authorised boundary?" and "what did this cost, and who owes it?" model + version · quantisation · requester · governing policy · tokens in / out · bytes streamed · GPU-seconds

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 evidence stack What each layer emits — and the question it answers AUTHORISATION policy layer approved use cases, model allowlist, explicit boundary definitions What was permitted? ASSESSMENT risk + impact layer impact assessments, risk tier, documented mitigations What did we anticipate? ENFORCEMENT control layer allow / deny verdicts, redaction, routing and rate decisions What was enforced? TELEMETRY runtime layer model + version, tokens, tool calls, human overrides, latency, cost What actually happened? ATTESTATION assurance layer signed, tamper-evident, time-bounded records and retention proofs Can someone else verify it? Most organisations have the top two layers in good shape — and none of the bottom three.

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

1 · Identity. Which model, at which version and quantisation, served this specific request?
2 · Authority. Under which approved use case and risk tier was it allowed to run at all?
3 · Boundary. What data crossed which perimeter, and where did it come to rest?
4 · Oversight. Was a human in the loop — and is there a record of them actually intervening, not just being nominally present?
5 · Consumption. What did it cost, in tokens and GPU-seconds, and which budget carried it?
6 · Recall. Can you answer questions 1 to 5 for a request made five months ago — without asking a vendor?

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:

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 The evidence obligations Standards and methodologies The laws the brief cites (Annex 1)

Listed as illustrations of the typologies only — the brief makes no assessment of their alignment with international human rights law.

JurisdictionInstrument
BrazilBill: Projeto de Lei No. 2238/2023, on the use of artificial intelligence
ColombiaLaw 2502 of 2025, amending Article 296 of the Criminal Code (impersonation)
European UnionRegulation (EU) 2016/679 (GDPR); Regulation (EU) 2024/1689 (AI Act)
FranceLOI n° 2016-1321 du 7 octobre 2016 pour une République numérique
JapanAct on Promotion of Research and Development, and Utilization of AI-related Technology (enacted 28 May 2025)
KenyaData Protection Act, No. 24 of 2019
PeruLey N° 31814 of 13 June 2023, promoting AI for economic and social development
South KoreaFramework Act on the Advancement of Artificial Intelligence and the Establishment of Trust (promulgated 21 January 2025, effective 22 January 2026)
The PhilippinesBill: House Bill No. 7913, establishing an AI regulatory framework
On this site