The National AI Governance Playbook · Part I · Chapter 3

The four functions of AI governance

National AI governance involves four kinds of work: setting the standards, testing models, checking deployed systems, and regulating use. This chapter defines the four functions, sets out what each asks of government and what each costs, and closes with a short exercise for mapping a program portfolio against them.

By Myriam Ayada · MindXO · July 2026

In brief

National AI governance covers four functions: setting the standards models are held to, testing models against them, assuring the systems organisations deploy, and regulating how AI is used in each sector. The four differ in what they cover, whom they address and what they cost, and leading jurisdictions keep them in separate hands. Mapping a program portfolio against the four functions early in the design stage is a short exercise, and it shows where programs overlap and which work has no owner.

What national AI governance must cover

Governing AI at national level involves four kinds of work: defining what a safe and secure model looks like (the properties that matter, the ways to measure them, the documentation expected of developers); testing models against those definitions; checking that deployed systems meet the applicable requirements; and setting the rules for how AI is used in finance, health, energy and public services, where the benefits and the harms materialise.

The names vary from one strategy to another; the four kinds of work recur. This playbook refers to them as the four functions: standard-setting, evaluation and testing, assurance, and use-regulation. Where one of the four is left out, the gap tends to surface later, usually as an incident with no owner. Each function raises its own design questions, taken in turn below.

The four functions

F1. Standard-setting

Standard-setting produces the reference points the rest of the system tests, assures and regulates against: definitions, safety and security properties, testing methods, documentation norms. Little of it is authored nationally. The operative texts are international (ISO/IEC 42001 for management systems, the NIST AI Risk Management Framework and its Generative AI Profile for risk vocabulary), so the national work consists mainly of adoption, adaptation and committee representation.

Design questions. Which standards to adopt and which to author; which international committees to hold seats on, and with what mandate; and through which channels standards acquire force (procurement, certification or regulatory reference).

F2. Evaluation and testing

Evaluation and testing measures model behaviour against those reference points: capability thresholds, safety properties, security robustness. It is the youngest of the four functions and the most demanding to build, since it requires scarce technical talent, access to models and compute, and methods that are still stabilising. Its product is evidence. Evidence creates no obligation by itself, and its credibility rests on independence from the developers it measures and from the regulators who act on its findings.

Design questions. What triggers an evaluation (pre-deployment, post-incident or periodic); how independence is protected institutionally; and which results are published, since publication is the channel through which evidence becomes market pressure.

F3. Assurance

Assurance verifies that deployed systems meet the applicable requirements and that claims made about them hold. Mature versions operate as markets: private assessors deliver audits and certifications under a public accreditation scheme, as conformity assessment does under Regulation (EU) 2024/1689 and as the United Kingdom's assurance guidance anticipates. The state's role concentrates on accreditation and on defining what assurance must demonstrate; direct provision by the state is the exception.

Design questions. Who accredits the assessors, and against which scheme; for which uses assurance becomes mandatory; and how liability attaches to an assurance opinion that proves wrong.

F4. Use-regulation

Use-regulation sets and enforces the rules for how AI is used in context, and it is the only function that is legitimately sectoral. The same model presents different risks in a bank, a hospital and a power grid, and the supervisors of those sectors already hold the inspection powers, sanction regimes and institutional knowledge the function requires. The design question is coordination, since sectoral rules drift apart without a shared national framework.

Design questions. Whether rules arrive horizontally or sector by sector, the sequencing question of Chapter 7; how sectoral rules remain coherent with the national framework, the coherence question of Chapter 6; and which authority covers uses that fall outside any regulated sector.

Sheet 03 of 13, the four functions and how they sort: standard-setting (governs the model and its making, addresses developers and assessors, technical force by reference, home in a standards body), evaluation and testing (governs model behaviour, addresses developers, evidentiary force, home in an institute and labs), assurance (governs deployed systems, addresses deployers via assessors, contract and regulation, home with accredited assessors), use-regulation (governs use in context, addresses deployers, legal force, home with sectoral regulators). The first three concern the model and are largely sector-agnostic; they sort into the safety and security regime. The fourth concerns use and is sectoral; it sorts into the usage-based regime. Chapter 4.

What each function costs

The functions also differ in what they cost and how they scale, and funding decisions inherit those differences. Evaluation is capital- and talent-intensive, with most of its cost incurred upfront, before any fee or sanction can offset it. Standard-setting is inexpensive and slow, and its return arrives through leverage: a seat held early on the right committee shapes texts a country would otherwise import unchanged. Assurance scales through private provision once accreditation exists, and largely finances itself through the market. Use-regulation operates through supervisory machinery that already exists, so its marginal cost lies in training and coordination more than in new institutions.

A program that merges the four functions therefore also merges four incompatible funding profiles, and a single funding classification will misstate at least one of them. Chapter 10 returns to the evaluation capability, where the funding question is sharpest.

Where leading jurisdictions converge

No leading jurisdiction assigns all four functions to one entity. The benchmark below summarises how the United Kingdom, the United States, the European Union and Singapore organise the four functions, drawn from public instruments.

Function	United Kingdom	United States	European Union	Singapore
Standard-setting (properties a model must meet; technical, the reference for the rest)	BSI	NIST	CEN-CENELEC JTC 21	ITSC
Evaluation and testing (how a model performs and behaves; flags risks, informs the others)	AI Security Institute; independent labs	NIST CAISI; AI Consortium; METR, MLCommons	national institutes (INESIA); SaferAI	AI Verify; Digital Trust Centre
Assurance (whether deployed systems keep behaving; ongoing oversight, audit)	DSIT ecosystem under guidance; accredited auditors	market-led	notified bodies under the AI Act	AI Verify; accredited testers
Use-regulation (lawful, fair use within a sector; legal, binding)	Ofcom, FCA, ICO, CMA	FDA, CISA	AI Act tiers; sectoral law	IMDA; MAS

Leading jurisdictions place the functions in separate entities that collaborate. Standard-setting is coordinated within the national standards body and the international committees behind it. Frontier evaluation sits in a dedicated body, an institute or a designated centre, complemented by independent and non-profit labs. Assurance is delivered by accredited third parties, while sectoral regulators govern use, coordinated through a framework of principles or law. Labels vary with administrative tradition; the separation recurs across all four jurisdictions.

Mapping a program portfolio against the four functions

A useful early step in the design stage is to test the program portfolio against the four functions. The exercise is short, and its one-page output tends to become the working document the design keeps returning to.

List. Each program's scope is read and every claim in it is written down, in the program's own words.
Tag. Each claim is matched to one of the four functions, with its addressee and the force it implies. A claim that fits two functions at once is usually two claims fused together, worth splitting.
Compare. The tags go on a single page, programs as rows, functions as columns. Overlaps show up as functions claimed by several programs. Gaps show up as functions claimed by none, with critical-infrastructure risk the most frequent gap.
Hold. The findings wait for Part III. Allocation changes shape once the two-regime architecture of Chapter 4 is on the table.

The result rarely exceeds a page, and it converts the symptoms of Chapter 2 from impressions into findings that a design stage can act on.

Common failure mode. One mandate, four functions. A single program assigned all four functions concentrates technical, evidentiary and legal force in one entity and merges four incompatible funding profiles. The arrangement reads as efficient at strategy stage; at implementation, each function pulls toward a different addressee and a different kind of authority, and the overlaps of Chapter 2 reappear inside a single institution.

Chapter 4 builds directly on this grouping. Three of the four functions share their object and travel across sectors, while one is bound to context. Grouped that way, they form two coherent governance regimes, and Chapter 4 develops that architecture.

Three questions for every government

Which of the four functions does each governance program claim, for whom, and with what force?
Which functions appear in more than one program, and which appear in none?
Which claims will carry legal force, through which instrument, and which will operate as technical or evidentiary practice?

Selected public sources

ISO/IEC 42001, AI management systems, ISO/IEC, 2023
AI Risk Management Framework and Generative AI Profile, NIST, 2023 and 2024
A pro-innovation approach to AI regulation, white paper and government response, United Kingdom, 2023 and 2024
Introduction to AI assurance, UK Department for Science, Innovation and Technology, 2024
Regulation (EU) 2024/1689 (AI Act), European Union, 2024
AI Verify, IMDA and AI Verify Foundation, Singapore, 2022
Designation of the Digital Trust Centre as Singapore's AI safety institute, IMDA, 2024
Consultation Paper on Guidelines on Artificial Intelligence Risk Management, Monetary Authority of Singapore, 2025