Reading routes: compliance leads start at Part II (EU AI Act) and Part IV (organizational duties); policy readers at Parts I and III; engineers at Part V, then back to Chapter 1 of this site. Tables scroll horizontally on small screens.
The handbook as a treemap — click a cell to jump
Area is proportional to the amount of text in each chapter; columns are the five parts plus front and back matter.
How to use this handbook
Read for a decision, not only for a definition. Each chapter combines explanation, application material, practical checks, and questions for oversight. The original chapter sequence and substantive analysis are retained; repeated passages and drafting-stage notes have been consolidated.
Three layers, three different questions
| Principles |
Which interests and values are at stake? |
Affected people, alternatives, and the reasoning behind trade-offs. |
| Law |
Which duties apply to this actor and deployment? |
Operative provision, scope, date, exception, and responsible reviewer. |
| Practice |
Do the safeguards work in the deployed workflow? |
Versioned tests, authorization, monitoring, intervention, and redress. |
Choose a reading route
| Board and executive |
Introduction; Chapters 18, 21–23 and 25; conclusion. |
| Legal and compliance |
Chapters 6–14 and 21; check the current operative instruments. |
| Product, engineering and risk |
Chapters 1, 4–5, 17–20 and 23–25; worked decision file. |
| Research and learning |
Read in sequence; use the source register to distinguish instruments from editorial guidance. |
Evidence, examples, and scope
Named public instruments are distinguished from illustrative scenarios. A scenario is not a reported incident, a benchmark, or a finding about the behavior of real organizations. Program thresholds, meeting cadences, internal risk tiers, and implementation templates are editorial suggestions unless a specific legal basis is identified.
Selected time-sensitive statements were reviewed against primary sources on 16 September 2026. This is not a line-by-line legal validation of every retained passage. The EU amendment notes and Chapter 11 control the timeline reading; the UK chapter remains explicitly historical. ISO discussion uses the public overview. Recheck operative law, local rules, and licensed standards before relying on a specific interpretation.
Source identifiers such as [S04] link to the source register; source titles there open the original publication. Chapter titles and return links provide internal navigation. Keep each governance artifact dated, owned, versioned, and accessible to the people responsible for review.
Introduction: The Governance Imperative
Why AI governance became law, the three-layer model, and the scope of this book
Overview
Key point: AI governance combines voluntary principles, binding obligations, and operational controls. This handbook examines how those layers apply to foundation models and agentic systems. The practical question is whether an organization can explain the authority it delegates, support its decisions with evidence, and respond when a system fails.
This introduction explains why that shift happened, the three-layer model used throughout the book (principles → law → practice), and how to read the chapters that follow. Primary anchors: OECD AI Principles (2019, updated May 2024); UNESCO Recommendation on the Ethics of AI (November 2021); NIST AI RMF 1.0 (January 2023) and NIST AI 600-1 (July 2024); EU Regulation 2024/1689 (AI Act); U.S. Executive Orders 14110 (30 October 2023), 14179 (23 January 2025), and 14365 (December 2025); ISO/IEC 42001:2023.
Learning Objectives
After this introduction you should be able to:
Explain why voluntary AI ethics was not enough for regulators after generative AI scaled.
Use the three-layer model (principles, law, practice) to place any new rule or standard.
Name the main public instruments this book relies on—and what each is for.
Tell a board, in one minute, what changed between 2023 and 2026 for EU and U.S. operators.
Choose a reading path (legal, risk, product, or policy) without reading the whole book first.
Core Analysis
Why governance became law
Soft principles came first. The OECD Recommendation on Artificial Intelligence (May 2019) gave governments a shared vocabulary: inclusive growth, human rights and democratic values, transparency, robustness and safety, accountability—plus policy recommendations on investment, ecosystems, governance interoperability, skills, and international cooperation. UNESCO’s Recommendation (adopted November 2021 by 193 Member States) grounded the same agenda in human rights and dignity, with policy areas spanning data, education, culture, labour, health, and the environment.
These recommendations supply a common vocabulary but do not themselves create the same enforceable duties as domestic legislation. The following analysis considers three features of AI deployment that complicate governance: scale, distribution of responsibility, and differences across jurisdictions.
Scale. Large language models and multimodal systems reached mass consumer and enterprise use within months, not years. Outputs look authoritative even when wrong. Synthetic media can impersonate people. Tool-using agents can act, not only answer.
Asymmetry. A small set of providers train general-purpose models that thousands of deployers embed in products. Harm often appears downstream—in hiring, credit, education, health, or public services—while capability and documentation sit upstream.
Jurisdictional differences. Organizations may face EU system and model duties, US federal and state requirements, China’s service-specific measures, and UK sectoral regulation. A shared technical description can support comparison, but each applicable legal test remains separate.
The result is not one global statute. It is a stack: principles that still guide soft law and procurement; hard law with timelines and fines in the EU; executive and state dynamics in the U.S.; management frameworks (NIST, ISO) that translate both into controls.
The three-layer model
| Principles |
Shared “why” and minimum values |
Ethics theater; no shared language with regulators or partners |
| Law |
Binding “must” with dates and penalties |
Surprise bans, delayed launches, personal liability for officers where law allows |
| Practice |
Repeatable “how” across the lifecycle |
Paper policies; no inventory, no metrics, no incident path |
Principles (Chapters 2–3) remain the common grammar. OECD’s May 2024 update added sharper language on generative AI, information integrity, misuse, safety overrides, environmental sustainability, and interoperable governance—while keeping the five value principles and five policy recommendations structure. UNESCO keeps the human-rights spine and tools such as readiness and ethical impact assessment for states.
Law (Chapters 6–14) turns risk classes into duties. The EU AI Act (Regulation 2024/1689) entered into force on 1 August 2024 and applies in stages: prohibited practices and AI literacy from 2 February 2025; general-purpose AI (GPAI) model rules from 2 August 2025; transparency and much of the enforcement architecture from 2 August 2026; high-risk system obligations on a later schedule that has been subject to legislative adjustment (see Chapter 11—cite the Official Journal text in force for your launch date). The Act reaches providers and deployers whose AI outputs are used in the Union even when they are established elsewhere—extraterritorial by design.
In the United States, Executive Order 14110 established a broad federal AI agenda in October 2023. Executive Order 14148 revoked it on 20 January 2025. Executive Order 14179 followed on 23 January 2025 and directed an AI Action Plan and review of actions taken under the revoked order. These are distinct legal steps. Subsequent policy initiatives and state-law developments should be tracked by their specific legal mechanism rather than treated as a single exemption from existing law. [S10][S11]
Practice (Chapters 4–5 and 17–25) is how organizations survive both layers. NIST AI RMF 1.0 (NIST AI 100-1, 26 January 2023) is voluntary and use-case agnostic: Govern, Map, Measure, Manage. NIST AI 600-1 (26 July 2024) profiles generative AI risks—including CBRN information risks, confabulation, data privacy, copyright, and others—mapped to RMF actions. ISO/IEC 42001:2023 specifies an AI management system (AIMS) in Plan-Do-Check-Act form. None of these replace the AI Act or U.S. statutes; they supply evidence language boards and auditors understand.
Foundation models and agentic systems change the control plane
Classic software governance assumed relatively fixed behavior, versioned releases, and human-paced actions. Foundation models are general-purpose: the same weights power chat, code, search, and agents. GPAI rules in the EU target that upstream layer (documentation, copyright policy, training-data summaries; extra duties if systemic risk is presumed—e.g., training compute above the Article 51(2) threshold of 10^25 floating-point operations, or Commission designation under Annex XIII criteria).
Agentic systems add planning, tool use, browsing, code execution, and sub-agent spawning. Failures move from wrong answers to wrong actions: unauthorized API calls, data exfiltration, memory poisoning, unsupervised workflows. Soft principles still apply. Hard law still classifies systems by risk and use. Practice must add runtime controls—identity, permission gating, logging, kill switches—not only pre-release model cards. Chapter 23 develops that frontier; The foundational chapters establish the legal and framework vocabulary is solid first.
What “interoperable governance” means here
Interoperability does not mean identical rules worldwide. It means:
Shared definitions (AI system, lifecycle, GPAI) so contracts and filings translate.
Mapped controls (RMF ↔︎ ISO 42001 ↔︎ AI Act articles) so one evidence set serves multiple regimes.
Honest gaps (U.S. federal flux; state AI laws; China’s content and filing model; UK principles-via-regulators) so boards do not assume EU compliance equals global clearance.
OECD’s 2024 update explicitly asks jurisdictions to promote interoperable governance environments. That is the north star of this book’s conclusion—not a claim that convergence is finished.
Scope and limitations
This book covers:
Definitions and trustworthy-AI criteria (Ch 1).
Ethical and OECD foundations (Ch 2–3).
NIST RMF and GenAI profile (Ch 4–5).
EU AI Act architecture through enforcement (Ch 6–10).
U.S. executive trajectory and state/federal tension (Ch 11–12).
Chapters 13–25: China, UK, summits, institutions, ISO 42001, boards, assessments, data, liability, audit, agents, sectors, and a 500-day program.
This handbook distinguishes descriptions of public instruments from editorial implementation guidance. It preserves uncertainty where a legal interpretation, local rule, or system-specific outcome has not been established.
Each chapter combines explanation, practical questions, and application material. Worked scenarios are teaching examples unless a named public event or instrument is identified. A recommended control is not presented as a universal statutory duty.
One-minute board brief (template)
“AI is no longer only an ethics topic. The EU AI Act is binding with staged dates: bans and literacy already live; GPAI duties from August 2025; transparency and penalties architecture from August 2026; high-risk duties on the schedule in force when we launch. NIST gives us the control language (Govern–Map–Measure–Manage) and a GenAI profile for confabulation, CBRN, and IP risks. In the U.S., federal policy shifted from EO 14110’s broad trust program to EO 14179’s acceleration agenda and a national-framework push against state patchwork—while California and other states still regulate transparency and training-data disclosures. Our job: inventory systems, classify risk, assign owners, and map evidence once for many regimes.”
Documented instrument example
Documented instrument sequence. NIST released AI 600-1 in July 2024 as a generative-AI profile accompanying its voluntary AI Risk Management Framework. EO 14148 revoked EO 14110 in January 2025; EO 14179 subsequently directed review of earlier agency actions. The NIST publications remain separately identifiable technical resources. Do not confuse the status of an executive order with the status or usefulness of every publication produced during its operation. [S04][S05][S10][S11]
Practical implication. Keep an inventory of which controls address law, contract, voluntary commitments, or operational risk. A policy change should trigger a review of those rationales, not an automatic deletion or retention of every control.
Practical Checklist
Name your three-layer map: which principles you endorse, which laws bind you, which practice frameworks you use.
Inventory AI systems and GPAI dependencies (vendor models, fine-tunes, agents with tools).
Flag any use that could be prohibited under AI Act Article 5 (even if you are outside the EU but serve EU users).
Assign a single accountable executive for AI risk (title may vary; ownership must not).
Adopt NIST RMF vocabulary in board papers so metrics survive staff turnover.
Diary key dates: 2 Feb 2025, 2 Aug 2025, 2 Aug 2026, and the high-risk date applicable to your Annex I / Annex III products under the text then in force.
Separate “model provider” duties from “deployer” duties in contracts and RACI charts.
Require vendors to state whether their models are treated as GPAI with systemic risk under Article 51.
Stand up an incident path for AI harms (wrong decision, leak, deepfake, agent runaway)—not only cyber incidents.
Brief the board quarterly with one page: inventory change, near misses, regulatory date risk, budget for evaluation.
Board Questions
Which AI systems could ban us from an EU market tomorrow if Article 5 applies?
Who owns GPAI documentation if we fine-tune or heavily integrate a third-party foundation model?
If EO-level U.S. policy flips again, which of our controls still stand because they are good engineering—not political compliance?
Do we have a single inventory, or five shadow lists in product, IT, marketing, HR, and vendors?
What is our story to a regulator who asks how we manage confabulation in customer-facing GenAI?
Are agentic workflows allowed to call external tools without human approval above a defined impact threshold?
How do we evidence AI literacy for staff who deploy or oversee AI (AI Act Article 4)?
Which state AI laws (California transparency / training-data rules, Colorado, others) already touch our products?
Is ISO/IEC 42001 certification on our roadmap as evidence—or are we mistaking a certificate for legal clearance?
What decision will this board refuse to delegate to an AI system this year—and is that written down?
How the foundational chapters are organized
Chapters 1–3 fix vocabulary and values. Without a shared definition of an AI system, contracts misclassify tools as “analytics” and skip duties. Without UNESCO and OECD, ethics statements float free of rights and policy recommendations that procurement teams can cite.
Chapters 4–5 give the U.S.-origin practice language that global firms already use in board packs: the AI RMF’s four functions, then the generative profile’s risk list. Even EU-first compliance programs borrow NIST wording for measurement and governance because it is concrete and voluntary.
Chapters 6–10 are the EU AI Act deep dive. Architecture and scope (Ch 6) come before risk tiers (Ch 7), high-risk obligations (Ch 8), GPAI rules (Ch 9), and timeline/penalties (Ch 10). Read them in order if you are building a conformity file; jump to Ch 10 if you only need date risk for a launch committee.
Chapters 11–12 cover the U.S. trajectory and the federal–state fight. They matter even for EU-headquartered firms: U.S. customers, cloud regions, and content rules still shape product design. They also show why “one global policy PDF” fails—political cycles move faster than management-system audits.
Reading discipline for practitioners
When a vendor claims “AI Act compliant,” ask: compliant as provider or deployer? For which risk tier? Against which application date? When a consultant claims “NIST aligned,” ask: which function outcomes, and where is the evidence? When a press release cites “7% of global turnover,” open Article 99 and read the tiers of fines—prohibited practices sit at the top; other infringements sit lower. Precision beats panic.
When you are unsure of a figure in secondary commentary—especially after the 2026 Digital Omnibus adjustments to some AI Act dates—prefer the consolidated regulation text and Official Journal amendments over blogs. This book flags that issue in Chapter 11 and refuses fake precision elsewhere.
Limits of this introduction
This chapter does not replace legal advice. It does not cover China’s filing regime, the UK’s five principles, or summit commitments in depth—these are covered in Chapters 13–15. It does not invent survey percentages about agent failures; where such figures appear in older outline drafts, treat them as unverified until a named public source is attached. Agentic risk is real; the control response belongs in practice chapters with careful sourcing.
What this introduction does claim, and will defend: AI governance is now a three-layer operating problem; foundation models and agents raised the stakes; EU law and U.S. executive/state dynamics are both material in 2026; and boards need inventory, classification, owners, and evidence—not slogans.
A short history of the turn to hard law (2019–2026)
2019–2021 — Soft law crystallizes. OECD principles (2019) and UNESCO’s ethics recommendation (2021) create a shared moral and policy vocabulary. Companies publish principle pages. Few can show inventories.
2022–2023 — Generative shock. Consumer LLMs and image generators force executives to confront confabulation, IP, and brand misuse. NIST releases AI RMF 1.0 (26 January 2023). The U.S. issues EO 14110 (30 October 2023). The EU legislative process races toward a horizontal AI Act.
2024 — Statutes and profiles. The EU AI Act is signed and enters into force (1 August 2024). OECD updates principles (3 May 2024). NIST publishes AI 600-1 (26 July 2024). California and other states pass transparency-oriented AI bills; California vetoes SB 1047.
2025 — Distinct implementation events. The EU AI Act’s initial general provisions and prohibitions applied from 2 February, followed by GPAI obligations from 2 August. In the United States, EO 14148 revoked EO 14110 on 20 January; EO 14179 directed an action plan three days later. These events concern different instruments and legal effects. [S09][S10][S11]
2026 — Transparency, enforcement architecture, and federal–state conflict. Article 50 and related enforcement themes apply on the Act’s schedule; Omnibus amendments adjust some high-risk dates. EO 14365 (December 2025) intensifies national-framework pressure on state AI laws. Boards in September 2026 inherit a world where EU bans are already live and U.S. patchwork is contested—not a world waiting for a future theoretical law.
Three failure stories (composite patterns, not invented statistics)
Failure A — Inventory blindness. Marketing launches a customer GenAI advisor. Security discovers months later it stores prompts containing personal data in a vendor region that breaks policy. No AI inventory meant no privacy review gate.
Failure B — Tier blindness. HR adds “AI ranking” to an internal search tool. Legal classified the old tool as low risk. The new feature is employment-related high-risk territory. Classification was never re-run.
Failure C — EO blindness. A federal contractor dismantles evaluation programs when EO 14110 is revoked, then fails a commercial customer’s diligence that still asks for GenAI testing evidence. Political compliance was mistaken for risk management.
These patterns motivate every checklist in the foundational chapters.
How to argue for budget
Frame AI governance spend as:
Market access — EU sales and enterprise procurement questionnaires.
Loss avoidance — incidents, deepfakes, wrongful automated decisions.
Speed — reusable evidence binders shorten future launches.
Trust — measurable quality (confabulation rates) as a product feature.
Avoid framing the entire budget as “regulatory tax.” Pair each control with a product or trust benefit.
Note on authorship and claims
This is a collaborative research and practitioner manuscript. It is intended to support informed review, not to imply regulatory authority, professional certification, or a system-specific legal opinion.
Field Notes for Implementation Leads
Use the foundational chapters before applying the agentic controls in Chapter 23: establish the system boundary, affected population, applicable duties, and decision authority first.
Chapter 25 provides the 500-day roadmap. Adapt its sequence to the organization’s exposures and external deadlines; an internal plan does not extend a legal deadline.
Synthesis for Busy Readers
The central framework has three layers: principles, law, and practice. The following chapters develop each layer, then connect them to management systems, assessments, sector applications, and agentic controls. Reuse evidence where it answers the same question, while retaining jurisdiction-specific requirements and unresolved limitations.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Primary-source route: S01 OECD · S03 UNESCO · S04 NIST · S06 European Union | Return to contents
Part I — Foundations and frameworks (Ch. 1–5)
Chapter 1: Defining AI and Trustworthy AI
Definitions across OECD 2024, EU AI Act Article 3, NIST, and technical taxonomies
Overview
Key point: If your organization cannot say what counts as an “AI system,” you cannot inventory it, classify its risk, or assign duties. Regulators and standards bodies now share more definitional DNA than in 2019—especially via the OECD—but they are not identical. Boards that confuse a spreadsheet rule with a general-purpose model, or “trustworthy AI” with a marketing seal, build the wrong controls.
This chapter compares the main public definitions, unpacks “trustworthy AI” as used by NIST, and gives a practical taxonomy you can put in a policy without waiting for perfect global harmony.
Learning Objectives
State the OECD AI-system definition and why EU and other instruments reuse it.
Contrast OECD, EU AI Act Article 3, and NIST’s framing of AI systems and actors.
List NIST’s trustworthy-AI characteristics and map each to a control question.
Separate narrow systems, generative systems, GPAI models, and agentic systems in an inventory.
Write a one-page internal definition annex your counsel and engineers can both sign.
Core Analysis
Why definitions are a control, not a philosophy debate
Classification triggers obligations. Under the EU AI Act, whether something is an AI system at all is the gate to the regulation’s scope (with stated exclusions). Whether a model is a general-purpose AI model opens Chapter V duties. Whether a system is high-risk opens Articles 8–15-type obligations. In voluntary regimes, NIST’s “AI actors” language decides who must do Govern versus Measure work.
A vague definition produces two failure modes: over-inclusion (every script becomes a compliance project) and under-inclusion (chatbots and ranking models hide as “search” or “personalization”). The cure is a written annex: definition, examples in, examples out, escalation path when unsure.
OECD definition (the interoperability anchor)
The OECD Recommendation on Artificial Intelligence—updated 3 May 2024—centers on an AI system as a machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. Different AI systems vary in their levels of autonomy and adaptiveness after deployment.
Why boards should care: the EU, Council of Europe work, and multiple national guides lean on this lineage. Using OECD language in contracts and model cards reduces translation loss when you face EU documentation requests or partner due diligence.
The 2024 update also sharpened lifecycle and actor thinking and stressed interoperable governance. Definitional convergence is deliberate policy, not accident.
EU AI Act Article 3
Regulation (EU) 2024/1689 Article 3 defines key terms for binding use, including AI system in the OECD-aligned sense (machine-based system inferring how to generate outputs that can influence environments, with varying autonomy and adaptiveness). The Act also defines provider, deployer, importer, distributor, general-purpose AI model, and related roles.
Practical distinctions:
| Provider |
Places an AI system or GPAI model on the market / puts into service under its name |
Design, documentation, conformity, QMS |
| Deployer |
Uses an AI system under its authority |
Use instructions, human oversight, impact assessment where required |
| GPAI model provider |
Supplies a model usable across many purposes |
Transparency, copyright policy, training summary; extra if systemic risk |
Article 3 is not a technical standard. It is a legal sorting hat. Engineers should still keep ML taxonomies; counsel should map those taxonomies onto Article 3 roles before launch.
NIST’s approach: systems, actors, and trustworthiness
NIST AI RMF 1.0 (NIST AI 100-1, 26 January 2023) does not replace legal definitions. It frames AI risk and trustworthy AI for voluntary management. Trustworthiness characteristics in the RMF include: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair—with harmful bias managed.
Treat each characteristic as a question, not a slogan:
| Valid & reliable |
Does it meet stated performance in the deployed context—not only a benchmark leaderboard? |
| Safe |
What harms are in scope, and what is the fail-safe? |
| Secure & resilient |
Can adversaries poison data, extract models, or hijack agents? |
| Accountable & transparent |
Who is responsible, and what can we disclose without theater? |
| Explainable & interpretable |
Can the right human get a useful explanation for this use case? |
| Privacy-enhanced |
Are training and inference data minimized and lawful? |
| Fair (bias managed |
Which groups can be harmed, and how do we test? |
NIST also stresses that AI risks differ from traditional software risks (feedback loops, emergent behavior, data dependence). That is definitional in effect: if your GRC tool treats an LLM like a static binary, your definition is wrong in practice.
A working technical taxonomy for inventories
Use four buckets in the asset register. They overlap; pick the highest relevant bucket for governance intensity.
Narrow / task-specific AI — fraud score, demand forecast, spam filter. Fixed objective, limited output types. Still “AI” under OECD/EU if it infers outputs from inputs; risk depends on use context (credit vs. inventory).
Generative AI systems — systems that produce text, images, audio, video, or code. NIST AI 600-1 addresses risks distinctive to or amplified by this class (confabulation, IP, synthetic content, etc.).
General-purpose AI models (foundation models) — models trained for broad competence, adaptable to many tasks. EU Chapter V applies to GPAI models as such; integrating them into a high-risk system can stack duties.
Agentic systems — systems that plan and act via tools, APIs, browsers, or sub-agents. Definitional tell: autonomy over actions, not only content. Inventory must capture tool permissions and identity, not only model name.
Add metadata: provider vs. deployer; training vs. inference location; personal data involved; human-in-the-loop pattern; customer-facing or internal; EU user impact.
“Trustworthy AI” vs. compliance vs. certification
Trustworthy AI (NIST) — multi-characteristic aspiration and risk lens.
Compliance (EU AI Act / state law) — mandatory duties for roles and risk tiers.
Certification (e.g., ISO/IEC 42001) — management-system conformity; useful evidence, not a legal shield by itself.
Marketing that collapses these three into a green badge is a governance defect. Put the distinction in your public AI policy.
Review-dependent note on evolving definitions
Thresholds and guidance evolve (for example, Commission power to adjust GPAI systemic-risk compute presumptions under Article 51). Definitions of “AI system” are more stable than thresholds. When unsure, document your interpretation, cite the versioned legal text, and escalate—do not silently redefine to avoid process.
Documented definition comparison
OECD definition reuse in the EU AI Act. Policymakers intentionally aligned the AI Act’s AI-system concept with the OECD lineage so that firms and governments are not stuck with incompatible dictionaries. The May 2024 OECD update then reinforced interoperable governance as a policy recommendation.
Takeaway: When your U.S. subsidiary writes “automated decision system” and your EU entity writes “AI system,” run a crosswalk workshop. Misaligned dictionaries create false negatives in the inventory—the most expensive definitional error.
Practical Checklist
Adopt a written AI-system definition citing OECD + EU Article 3 (as applicable) in the AI policy annex.
List ten “in” examples and ten “out” examples from your real estate (include edge cases: RPA, rules engines, classic stats).
Tag every inventory item: narrow / generative / GPAI / agentic (multi-tag allowed).
Map provider vs. deployer vs. importer roles per product line.
Attach NIST trustworthy characteristics as review prompts in design gates.
Ban the phrase “trustworthy AI certified” unless a named standard and scope are stated.
Require vendors to declare whether offerings are GPAI models and whether systemic-risk classification is claimed or presumed.
Revisit the definition annex at least annually or when Article 3 / OECD text changes.
Train product managers on the difference between model, system, and agent.
File unresolved classification questions in a log with owner and due date.
Board Questions
What is our official definition of AI—and which public source does it cite?
How many systems in production are uninventoried because someone called them “analytics”?
Who decides borderline cases, and in what SLA?
Do we score trustworthy characteristics, or only recite them?
Where could agentic tool use create actions we still classify as “just a chatbot”?
Are GPAI dependencies visible to the audit committee?
Does marketing use “trustworthy” in ways counsel cannot defend?
Which third-party models would reclassify our product’s risk tier if integrated deeper?
Mapping definitions into contracts and SOWs
Procurement language often lags legal definitions by years. Update standard clauses:
Scope clause — “AI system” means the Article 3 / OECD definition, including generative and agentic systems; excludes purely deterministic rules engines without inference only if counsel agrees in writing for that SKU.
Role clause — Vendor is provider of [system/model]; customer is deployer unless customer substantially modifies and places under its own name (then re-assess).
GPAI clause — Vendor warrants whether the model is a GPAI model; discloses known systemic-risk presumption or designation status; commits to update within a set number of days after classification changes.
Documentation clause — Vendor supplies instructions for use, limitations, and evaluation summaries sufficient for the deployer’s oversight duties.
Change clause — Material model swaps, tool-enablement, or autonomy increases trigger re-classification review before production use.
Without these clauses, your inventory will be accurate on paper and wrong in the contract file—the version regulators and plaintiffs read.
Common false friends
| “It’s just statistics” |
Many AI systems are statistical learners; OECD/EU look at inference and influence, not branding. |
| “No personal data, so not AI risk” |
Safety, manipulation, and GPAI duties are not only privacy duties. |
| “Open-source, so out of scope” |
Open distribution can change how duties apply; it does not magically erase risk tiers for deployers. |
| “Human clicks approve, so low risk” |
Oversight must be meaningful; rubber-stamp UI can fail Article 14-style expectations. |
| “NIST means we’re compliant with the AI Act” |
NIST is voluntary practice; the Act is binding law. Map them; do not equate them. |
Building the one-page definition annex
Keep it to one page so product teams actually read it:
Definition (3–4 lines, cited).
In scope examples (bullets from your real systems).
Out of scope examples (with “when in doubt, escalate”).
Roles (provider/deployer/GPAI).
Taxonomy tags (narrow/generative/GPAI/agentic).
Owner of the annex and review cadence.
Attach NIST trustworthy characteristics as a second page used at design review—not in the legal definition itself—so engineers do not confuse characteristics with legal scope.
Connecting Chapter 1 to later chapters
Definitions feed Chapter 4’s Map function (context and intended use), Chapter 5’s GenAI profile (which risks apply), Chapter 7’s risk tiers (prohibited vs high-risk vs GPAI), and Chapter 9’s foundation-model duties. If Chapter 1 is weak, every later control inherits garbage. Invest here once.
Workshop agenda: 90-minute definition alignment
0:00–0:10 — Legal presents OECD + Article 3 definitions.
0:10–0:25 — Product demos five ambiguous systems.
0:25–0:45 — Breakout: tag narrow/generative/GPAI/agentic; provider vs deployer.
0:45–1:05 — Debate edge cases; escalate unresolved to log.
1:05–1:20 — Agree annex wording and examples.
1:20–1:30 — Assign owners for inventory updates.
Output: signed annex + updated inventory tickets.
Trustworthiness scoring without fake precision
Use a qualitative scorecard per system (High/Med/Low confidence):
Validity evidence quality
Safety case completeness
Security test recency
Transparency to affected users
Oversight effectiveness
Privacy design
Fairness evaluation depth
Do not average into a single vanity “trust score” for marketing. Present the vector to the risk committee.
Interaction with open-source models
Open weights change distribution and modification patterns. Definitions still apply. Questions to add:
Who is the provider when we fine-tune and redistribute?
Do we inherit safety evaluations from upstream?
Can we patch or deactivate if misuse spikes?
Are tool-plugins enabling agentic behavior the community did not evaluate?
Document answers before enterprise rollout.
Glossary seed for the handbook
AI system — OECD/EU machine-based inferential system influencing environments.
GPAI model — general-purpose model usable across many tasks.
Deployer — uses a system under its authority.
Provider — places on market / puts into service under its name.
Confabulation — confidently false generated content (NIST AI 600-1 term).
Systemic risk (GPAI) — Article 51 classification for high-impact GPAI models.
High-risk AI system — classified under AI Act Annex I/III rules.
Agentic system — AI that plans and executes tool-mediated actions.
Keep the glossary versioned beside the definition annex.
Practitioner FAQ
Q: Is a rules engine AI?
A: Purely deterministic business rules without inference usually fall outside OECD/EU AI-system concepts—but hybrid systems that learn thresholds can qualify. Escalate hybrids.
Q: Is spellcheck AI?
A: Many modern checkers use learned models. Apply the definition; do not rely on product category names.
Q: Do we inventory shadow IT chatbots?
A: Yes. Unapproved tools are still AI systems affecting the enterprise. Discovery beats denial.
Q: Can marketing say “human-level”?
A: Avoid unverifiable anthropomorphic claims. They create trust and consumer-protection risk.
Sample definition annex (illustrative)
“For purposes of this Policy, AI System means a machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments, consistent with the OECD AI Principles (updated May 2024) and Article 3 of Regulation (EU) 2024/1689 where applicable. Generative systems, general-purpose AI models, and agentic systems that plan or execute tool-mediated actions are included. Classic deterministic rules engines without inference are excluded unless Legal determines otherwise in writing.”
Customize with counsel. Keep examples list updated quarterly.
Metrics for definition hygiene
% of production systems with completed classification tags
Age of oldest unclassified system
Number of escalations resolved per quarter
Contract templates updated with definition clauses (Y/N)
Report these beside model-performance metrics so engineering culture sees definition work as real work.
Definition we use: [OECD/EU cite]
Inventory size: [N systems]
Unclassified: [N]
GPAI dependencies: [list]
Agentic systems with write actions: [N]
Top decision this month: [classification or kill]
Ask of the board: [budget / policy approval]
Field Notes for Implementation Leads
Put the definition annex in onboarding for PMs, data scientists, and sales engineers. A definition unused by sales will be contradicted in RFPs.
On each architecture review board agenda, include a standing item: “Any system requiring re-definition or re-tier?” Ten minutes prevents months of cleanup.
Synthesis for Busy Readers
Definitions are controls. Use OECD/EU Article 3 language for AI systems; separate provider and deployer roles; tag narrow, generative, GPAI, and agentic systems; treat NIST trustworthy characteristics as review questions, not seals. Update contracts so vendors declare GPAI and systemic-risk status. Ban marketing that collapses trustworthy AI, legal compliance, and ISO certification into one badge. Run a 90-minute alignment workshop and keep a living escalation log for edge cases. Without Chapter 1 discipline, every later chapter inherits garbage inventory.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Primary-source route: S02 OECD · S04 NIST · S06 European Union | Return to contents
Chapter 2: Ethical Foundations – UNESCO and Global Values
Human rights, dignity, sustainability, fairness, and what boards can actually implement
Overview
Key point: Law lags technology; values should not. UNESCO’s Recommendation on the Ethics of Artificial Intelligence (adopted November 2021 by 193 Member States) is the broadest intergovernmental ethics instrument on AI. It is not a fine schedule. It is a rights-based checklist that procurement, public-sector partners, and many national strategies still cite. Firms that ignore it look tone-deaf when a regulator, journalist, or employee asks “what values constrain this model?” Firms that only quote it—without data, labor, gender, and environmental practices—perform ethics theater.
This chapter turns UNESCO’s values and policy areas into board-usable questions, without inventing compliance obligations the Recommendation does not create.
Learning Objectives
Explain what the UNESCO Recommendation is (and is not) as a legal instrument.
Name the core values/principles clusters: human rights and dignity, living in peace and justice, ensuring diversity and inclusiveness, environment and ecosystem flourishing—plus operational principles such as proportionality, safety, fairness, transparency, and human oversight.
Connect UNESCO policy chapters (data, education, culture, labour, health, economy, gender, environment) to corporate functions.
Distinguish ethics commitments from EU AI Act duties and NIST controls.
Draft an ethics-to-controls crosswalk of no more than two pages.
Core Analysis
Instrument type: recommendation, not regulation
UNESCO Recommendations are soft law addressed to Member States. The 2021 text asks states to apply provisions voluntarily through appropriate measures, consistent with constitutional practice and international human rights law, and to engage business and other stakeholders. It also speaks to AI actors across sectors.
Implication for companies: You will rarely be “fined under UNESCO.” You will meet UNESCO language in: national AI strategies, public procurement questionnaires, ESG narratives, university and NGO partnerships, and employee expectations. Treating it as irrelevant because it is non-binding is a stakeholder failure, not a legal analysis.
Human rights and dignity as the spine
The Recommendation’s center of gravity is that AI must respect, protect, and promote human rights and fundamental freedoms and human dignity. That framing does work other “ethics lists” skip:
It ties AI harm to existing rights law (privacy, equality, freedom of expression, due process)—not only to novel “AI principles.”
It supports prohibitions and red lines (for example, social scoring and mass surveillance are addressed as incompatible with the Recommendation’s approach)—aligned in spirit with later hard-law bans such as AI Act Article 5, though the instruments differ in legal force and detail.
It insists on human oversight and the possibility of human determination in consequential contexts.
For boards: start ethics reviews from which rights could be impaired, not from which slogan sounds modern.
Values and principles boards can operationalize
Without reproducing the entire instrument, practitioners should lock these operational ideas:
Proportionality and do-no-harm. Choose AI intensity that matches the problem. Not every workflow needs an opaque model. Document less-invasive alternatives considered.
Safety and security. Ethics includes secure design against misuse—not only fairness dashboards.
Fairness and non-discrimination. Test for disparate impacts in context; fairness is domain-specific (hiring ≠ content moderation ≠ clinical triage).
Transparency and explainability. People affected should know when AI is used and have access to meaningful information; depth scales with impact.
Responsibility and accountability. Name humans who answer for outcomes. Ethics without owners is PR.
Privacy and data governance. Go beyond baseline notice: agency and control over personal data, especially in large-scale training and profiling.
Multi-stakeholder and adaptive governance. Invite affected voices early; revisit as capabilities change.
Environmental and ecosystem flourishing. Energy, water, and hardware footprints of training and inference are ethical issues, not only cost issues—the OECD’s 2024 update also elevated environmental sustainability in the principles ecosystem.
Gender equality. Explicit policy attention to gender bias and representation—not a footnote under “diversity.”
Policy action areas → corporate owners
UNESCO’s policy chapters are a gift to RACI designers:
| Data governance |
CDO / DPO |
Can individuals exercise agency over training and inference data uses? |
| Education |
CHRO / L&D |
Do we build AI literacy and critical understanding—not only prompt tips? |
| Culture |
Brand / content |
How do we protect cultural diversity and creators’ rights in generative use? |
| Labour |
CHRO / operations |
Are workers consulted on AI that evaluates or replaces tasks? |
| Health |
Clinical / quality |
Is clinical AI validated for intended use with clear human responsibility? |
| Economy |
CFO / strategy |
Do we assess concentration, dependency, and SME access impacts? |
| Gender |
DEIB / product |
Are evaluation sets and UX tested for gendered harms? |
| Environment |
Sustainability |
Do we measure and disclose energy/water intensity for major training runs? |
If your “Responsible AI” committee has only lawyers and ML engineers, UNESCO’s map says you are understaffed.
Relationship to OECD, EU law, and NIST
UNESCO — rights and values baseline; state-facing; broad policy menu.
OECD — trustworthy AI principles + policy recommendations; interoperability and economic policy; updated 2024 for GenAI and information integrity.
EU AI Act — binding risk rules, bans, GPAI duties, fines.
NIST AI RMF — voluntary risk management functions and trustworthy characteristics.
Ethics instruments justify why a use is unacceptable even when a loophole might exist. Law sets must. NIST/ISO set how to evidence. Healthy programs keep all three visible; unhealthy programs collapse them into one vague “responsible AI” paragraph.
Avoiding ethics theater: five tells
Values poster with no inventory of high-impact systems.
“Fairness” claimed without defining protected groups or metrics for that use case.
Human oversight that is a checkbox after the model already decided.
Environmental claims with no measurement method.
Gender and labour impacts never reviewed because the system is “only internal.”
Theater is detectable. Regulators may not prosecute UNESCO text, but customers, employees, and courts of public opinion will.
Public-sector and dual-use sensitivity
UNESCO’s rights frame is especially sharp for biometric surveillance, social scoring logics, and manipulative systems. Even where your firm is private-sector, selling into governments imports these expectations. Export controls and dual-use regimes may add hard law on top; ethics review should flag “state client + biometric or scoring capability” early.
Documented adoption example
Adoption moment, November 2021. UNESCO Member States adopted the Recommendation at the 41st General Conference (text adopted 23 November 2021; public communications around 25 November 2021). It became the first global standard-setting instrument dedicated to AI ethics at that scale of membership.
Why it still matters in 2026: Hard law proliferated afterward (EU AI Act; national measures). Yet multinational firms still need a global values citation that is not EU-only. UNESCO remains that citation—especially for operations in regions without an AI Act analogue—provided you translate it into owners and controls.
Practical Checklist
Cite UNESCO 2021 explicitly in the corporate AI ethics statement (with date).
Map each major AI use case to rights at risk (privacy, equality, expression, due process, etc.).
Assign owners for data, labour, gender, and environment AI reviews—not only model performance.
Require worker consultation notes when AI evaluates employees or automates substantial tasks.
Add energy/water estimates to approval packets for large training or always-on inference fleets.
Ban social-scoring-like products in the ethics red-line list even if a target market lacks a ban.
Include creator/cultural rights checks before scraping or bulk synthetic media deployment.
Run an annual “ethics theater” audit: posters vs. evidence.
Align public ESG AI language with internal incident logs (no contradiction).
Crosswalk UNESCO themes to OECD principles and to AI Act Article 5 red lines.
Board Questions
Which human rights could our top five AI systems impair, and who tested that?
Is labour consulted before AI rates, schedules, or replaces workers?
What environmental metrics do we accept for foundation-model spend?
Where is gender impact assessed beyond a single bias chart?
Do we have red lines that go beyond “follow local law”?
How would we answer a UNESCO-aligned public procurement ethics questionnaire tomorrow?
Which committee owns ethics when it conflicts with launch pressure?
Are we using UNESCO as decoration or as a design constraint?
Ethical impact assessment — lightweight corporate version
UNESCO encourages ethical impact assessment thinking for states; companies can borrow the spirit:
Describe the system, purpose, and stakeholders (including non-users).
Rights scan — which rights could be limited or promoted?
Proportionality — is AI necessary? What milder options exist?
Inclusion — who was consulted (workers, impacted communities)?
Environment — material resource impacts?
Gender and equality — specific harms and mitigations?
Oversight and remedy — how can people challenge outcomes?
Decision — proceed / proceed with limits / stop.
Monitor — what signals trigger re-assessment?
Keep assessments short enough to finish before launch pressure invents excuses.
Procurement questions inspired by UNESCO
Provide your human-rights due diligence process for AI.
How do you engage workers when AI evaluates performance?
What environmental metrics do you track for model training?
How do you prevent exclusion of linguistic and cultural minorities in GenAI?
Describe redress channels for people harmed by your AI outputs.
Score vendors on evidence quality, not on adjective density.
Red-line catalog (ethics layer)
Even where local law is silent, many boards adopt ethics red lines:
Social scoring of individuals for access to essential services.
Real-time remote biometric identification in public spaces for commercial behavioral ads.
Emotion inference to manipulate vulnerable users.
Undisclosed human impersonation in counselling or debt collection.
Training on stolen personal datasets knowingly obtained.
Write red lines down. Vague “we act ethically” fails under pressure.
Teaching ethics without boredom
Replace abstract lectures with incident tabletop exercises: deepfake CFO; biased hiring shortlist; chatbot giving dangerous medical advice; agent purchasing spam APIs. Ask teams which UNESCO values were breached and which control would have helped. Adults learn ethics through decisions, not posters.
Connecting UNESCO to Article 5 and corporate red lines
UNESCO’s rights-based approach and the AI Act’s prohibited practices are different instruments with overlapping moral targets (social scoring logics; manipulative systems; certain surveillance patterns). Corporations can maintain a unified red-line register with columns: ethics basis (UNESCO theme); legal basis (Art 5 / state law / none); enforcement (hard ban / ethics veto). This prevents ethics and legal teams from maintaining contradictory lists.
Gender and AI — operational checklist
Evaluation datasets checked for gendered representation where relevant
Voice assistants and imagery models reviewed for stereotyping
Workplace AI assessed for disparate impacts on caregivers and gendered roles
Complaint channels safe for reporting gendered harms
Leadership metrics include gender-aware AI incident reviews
UNESCO’s explicit gender policy area justifies budget when teams claim “fairness generally” is enough.
Environment — what “good enough” looks like early
Start with: estimate energy for major training runs; prefer efficient models when quality is comparable; set idle/shutdown policies for GPU clusters; disclose methodology caveats honestly. Perfect LCA is not required to begin. Silence is worse than approximate measurement with stated uncertainty.
Culture and creators
Generative tools trained on cultural works raise consent and remuneration debates. Ethics programs should include creator consultation for products that remix styles at scale, and legal coordination on licensing—not only after a lawsuit.
Board education module (30 minutes)
What UNESCO Recommendation is (soft law; 193 Member States; Nov 2021).
Rights spine vs slogan ethics.
Policy areas mapped to our functions.
Red-line register walkthrough.
One tabletop: social-scoring-like product proposal—should we kill it?
Vote on funding for labour consultation and environmental metrics.
Capture minutes. Ethics without board minutes is optional in practice.
Civil society engagement
UNESCO emphasizes multi-stakeholder governance. Companies can: host office hours with affected communities for high-impact tools; publish plain-language system summaries; fund independent evaluations; respond publicly to credible critiques. Engagement is not surrender of IP; it is early warning.
Field Notes for Implementation Leads
Ethics programs die in the gap between statements and sprint boards. Assign every UNESCO-mapped theme a Jira (or equivalent) epic: Data agency; Labour consultation; Gender evaluation; Environmental metrics; Cultural/creator rights; Remedy channels. Require each epic to have a definition of done that produces an artifact—not a meeting.
When entering a new country, ask: does the state have a UNESCO readiness assessment narrative or national AI ethics strategy citing the Recommendation? If yes, expect procurement questionnaires to echo it. Prepare answer banks.
For M&A diligence, request the target’s ethics red-line register and incident log. Absence is a finding. A beautiful principles page with no register is also a finding.
Internal audit can test ethics theater by sampling three AI launches: were rights scans completed before code freeze? Were workers informed? Were environmental notes present for large training? Publish scores to the AI council.
Finally, keep UNESCO citations dated (November 2021 adoption). Undated “UNESCO principles” claims look sloppy beside precise AI Act article cites and undermine the very credibility ethics seeks.
Synthesis for Busy Readers
UNESCO’s November 2021 Recommendation is soft law with hard cultural force: 193 Member States, rights and dignity at the center, policy areas spanning data, labour, gender, culture, health, economy, and environment. It does not fine companies, but it shapes procurement, ESG, and red lines. Operationalize it with owners, ethical impact light assessments, and a red-line register aligned to Article 5 themes. Avoid ethics theater—posters without inventories. Cite the instrument with dates; connect it to OECD and NIST without conflating soft law and hard law.
Mapping UNESCO themes to NIST trustworthy characteristics
| Human rights / dignity |
Fairness; privacy; accountability |
| Proportionality / do no harm |
Safe; valid & reliable |
| Transparency |
Accountable & transparent; explainable |
| Human oversight |
Accountable; safe |
| Sustainability |
(Organizational Map of environmental impacts; emerging in OECD 2024 too) |
| Gender equality |
Fairness with harmful bias managed |
| Multi-stakeholder governance |
Accountability processes; Map stakeholders |
Use the map in training so ethics and risk teams share vocabulary. Differences remain: UNESCO is rights-first soft law; NIST is risk-management practice.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Linking ethics to remedy
UNESCO’s accountability spirit requires remedy pathways: channels to contest automated outcomes; human review on request where appropriate; public corrections when GenAI systems spread falsehoods about people; cooperation with authorities. Ethics without remedy is unfinished.
Primary-source route: S03 UNESCO | Return to contents
Chapter 3: The OECD Principles – 2019 to 2024 Update
Evolution, adherents, information integrity, and interoperability
Overview
Key point: The OECD AI Principles are the closest thing practitioners have to a global soft-law baseline that finance ministries, trade officials, and regulators all recognize. Adopted in May 2019 and revised on 3 May 2024, they now speak directly to generative AI, misuse, information integrity, safety overrides, environmental sustainability, and interoperable governance. If your international policy narrative still quotes only the 2019 brochure, you are a generation behind the instrument governments actually endorsed.
This chapter explains the structure (five value principles + five policy recommendations), what changed in 2024, why “47 adherents” matters for market access narratives, and how to use OECD language in board papers without confusing soft law with the EU AI Act.
Learning Objectives
Recite the five principles for trustworthy AI and the five recommendations for policymakers.
Describe the material 2024 updates (GenAI, information integrity, misuse, safety, environment, interoperability).
Explain how OECD definitions support legal interoperability with the EU AI Act and other frameworks.
Use OECD text in vendor diligence and public-policy engagement accurately.
Build a gap list: where your program claims OECD alignment but lacks evidence.
Core Analysis
Origin and legal character
The OECD Recommendation on Artificial Intelligence (OECD/LEGAL/0449) was the first intergovernmental standard on AI. Recommendations are not EU-style regulations. Adherents commit politically and institutionally to promote the principles. That still moves markets: national strategies, G7 language, and corporate policy often copy OECD wording because it is negotiated, translated, and stable enough to cite.
As of the OECD’s own communications around the 2024 update, 47 jurisdictions adhere, including the European Union as an adherent alongside countries. Exact roster membership can change; when you cite a number in external filings, verify the current OECD.AI adherents list rather than recycling a memorized figure.
The five principles (values layer)
Plain-language paraphrase for operators (always check the official text for formal quotes):
Inclusive growth, sustainable development and well-being — AI should benefit people and planet, not only model metrics.
Respect for the rule of law, human rights and democratic values, including fairness and privacy — rights are not optional extras.
Transparency and explainability — people need to understand AI’s role and receive meaningful information.
Robustness, security and safety — systems should work reliably and be protected against compromise; undesired behavior should be manageable.
Accountability — organizations and individuals must answer for AI outcomes.
These map cleanly to board oversight themes: strategy (1), legal/compliance (2), disclosure (3), risk/security (4), governance (5).
The five policy recommendations (state and ecosystem layer)
Investing in AI R&D.
Fostering an inclusive AI-enabling ecosystem.
Shaping an enabling interoperable governance and policy environment for AI (language strengthened in the update cycle).
Building human capacity and preparing for labour-market transformation.
International co-operation for trustworthy AI.
Companies are not “regulated by” these recommendations, but they feel them through: skills programs, sandbox policies, research funding, and cross-border regulatory cooperation that reduces or increases compliance friction.
What the May 2024 update changed
The OECD Council meeting at Ministerial level revised the Recommendation on 3 May 2024 to reflect technological and policy developments, including generative AI. Official materials describe aims such as:
Addressing misinformation and disinformation and safeguarding information integrity in the GenAI context, with mechanisms where technically feasible, while respecting freedom of expression.
Addressing uses outside intended purpose, intentional misuse, or unintentional misuse.
Clarifying transparency and responsible disclosure expectations for AI actors.
Strengthening safety expectations so systems that risk undue harm or undesired behavior can be overridden, repaired, or decommissioned safely through human interaction.
Underscoring interoperable governance as national AI rulebooks multiply.
Introducing clearer reference to environmental sustainability.
Board translation: Your GenAI program is incomplete if it only covers bias and privacy. OECD now expects attention to synthetic media integrity, misuse pathways, kill/override capacity, and environmental impact—alongside the classic five principles.
Information integrity is not “content moderation” alone. For enterprises it includes:
Labeling or disclosing synthetic content in customer channels where required or promised.
Controls against employees pasting confidential text into consumer GenAI tools (data integrity and secrecy).
Evaluation for confident falsehoods (see NIST’s “confabulation” language in Chapter 5)—false citations in board decks are an integrity failure.
Brand impersonation and deepfake incident response.
OECD’s framing legitimizes budget for these controls as governance, not only as marketing or security side quests.
Interoperability: the practical prize
OECD definitions of AI system and lifecycle are widely reused. The EU AI Act’s conceptual approach sits in that family. NIST’s voluntary framework and ISO management standards can be crosswalked to OECD principles for international subsidiaries.
A working interoperability stack for a multinational:
| Shared dictionary |
AI system + lifecycle |
EU Art. 3; national guides |
| Values narrative |
Five principles |
UNESCO rights spine |
| Risk operations |
Robustness, accountability |
NIST RMF; ISO 42001 |
| GenAI integrity |
2024 integrity/misuse language |
NIST AI 600-1; AI Act transparency |
| Policy engagement |
Recommendations 2.3–2.5 |
Trade associations; OECD.AI tools |
Using OECD in corporate artifacts (without overclaiming)
Good: “We align our AI principles to the OECD AI Principles (2019, updated May 2024), including information integrity and safety override expectations.”
Bad: “We are OECD certified / OECD compliant.”
Good: Vendor questionnaire cites each principle with evidence pointers (model card, eval report, incident SOP).
Bad: One checkbox labeled “OECD aligned.”
Review-dependent claims—handle with care
Adherent counts change; verify before publishing.
Secondary blogs sometimes invent “new principles” numbered differently; stick to OECD.AI and the legal instrument text.
OECD does not set the EU fine schedule—never imply that.
Illustrative governance scenario
Illustrative governance scenario. An organization retains its 2019 principles statement without reviewing it after the OECD’s 2024 update. Its next review compares the revised principles with existing controls and records any gaps. This example demonstrates a review method; it is not an empirical claim about how frequently organizations updated their policies. [S01]
Practical implication. Assign an owner for framework changes and assess whether a revision changes the evidence needed for a specific use. Updating a policy title without reviewing the underlying controls is not a completed assessment.
Practical Checklist
Replace 2019-only citations with “2019, updated May 2024” in policies.
Map each of the five principles to a control owner and a metric.
Add an information-integrity control set for GenAI (disclosure, deepfake response, confabulation evaluation).
Document human override / decommission paths for high-impact systems.
Include environmental impact notes in large-training approval memoranda.
Crosswalk OECD principles to NIST trustworthy characteristics (one page).
Brief government-affairs team on Recommendation policy items 2.3–2.5 before major consultations.
Ban “OECD compliant” phrasing in marketing.
Verify adherent-count citations against OECD.AI before annual reports.
Re-read the official Recommendation text annually—do not rely on slide summaries.
Board Questions
When were our published AI principles last updated against the May 2024 OECD revision?
Who owns information integrity for synthetic media we create or host?
Can we override or decommission our top AI systems safely under time pressure?
Do we fund environmental measurement for AI, or only carbon offsets narratives?
How do we evidence accountability when a GenAI answer harms a customer?
Are international subsidiaries using the same OECD-aligned dictionary?
What misuse scenarios have we actually red-teamed this year?
Where does OECD language appear in our public affairs positions—and is it accurate?
Principle-by-principle evidence examples
Boards ask for proof. These examples are illustrative patterns—not mandated OECD templates:
Inclusive growth / well-being. Product accessibility reviews; SME pricing tiers for API access; assessment of automation impacts on entry-level roles with transition plans.
Human rights, fairness, privacy. DPIA/FRIA-style assessments where applicable; prohibited-use lists; lawful basis registers for training data; accessibility of complaint channels.
Transparency. User notices when interacting with AI; model documentation for enterprise buyers; limits disclosures (“not for medical diagnosis”).
Robustness, security, safety. Adversarial testing; rate limits; secret management for agents; safety evaluation before enabling tool use; rollback plans.
Accountability. Named executive owner; incident severity matrix including AI harms; board reporting cadence; contractual flow-down to vendors.
Connecting OECD to the EU AI Act without conflation
OECD helps you explain why your program exists internationally. The AI Act tells you what is mandatory in the Union. Example: OECD transparency principle supports a culture of disclosure; AI Act Article 50 sets specific transparency triggers for certain interactions and synthetic content. Example: OECD robustness supports safety engineering; AI Act high-risk rules demand a risk-management system and human oversight with legal particularity.
Training for staff should use two columns: “OECD expectation” vs “AI Act article / NIST subcategory.” Mixing columns produces both under-compliance and over-claiming.
Diligence questionnaire seed (vendors)
Confirm alignment approach to OECD Principles (2019/2024) with document links.
Describe information-integrity measures for generated content.
Describe misuse monitoring and response.
Describe human override and decommission procedures.
Disclose known environmental metrics methodology for training/inference (even if qualitative).
Identify accountable executive for AI risk.
State whether models are GPAI and any systemic-risk status under EU rules (separate legal question, asked in the same packet for efficiency).
What “shaping interoperable governance” means for multinationals
Recommendation language on interoperable policy environments is aimed at governments, but companies can reinforce it: prefer standards that crosswalk (NIST↔︎ISO↔︎AI Act), avoid inventing unique internal jargon for the same concept, and participate in consultations that reduce contradictory obligations. Interoperability is a cost strategy, not only idealism.
Chapter bridge
Chapter 2 gave rights ethics (UNESCO). Chapter 3 gives the economic-organization soft law most cited in capitals (OECD). Chapter 4 turns values into the NIST operating system of Govern–Map–Measure–Manage.
2019 vs 2024 — side-by-side for policy teams
| Core five principles |
Established |
Retained as backbone |
| GenAI |
Limited explicit treatment |
Explicit technological driver for revision |
| Information integrity |
Less central |
Explicit mechanisms where feasible |
| Misuse |
Implied in safety |
Explicit intentional/unintentional misuse |
| Safety override |
Robustness/safety |
Clearer override/repair/decommission language |
| Environment |
Well-being framing |
Explicit sustainability reference |
| Interoperability |
Cooperation themes |
Stronger interoperable governance recommendation |
Use this table in public-affairs briefings when stakeholders ask “what actually changed?”
Measuring accountability (principle 1.5)
Suggested indicators (choose few, measure well):
% of AI systems with named accountable owner
Median days to resolve AI incidents of severity ≥ X
% of high-impact launches with recorded residual-risk acceptance
Number of unmet evaluation gates overridden—and by whom
If overrides are frequent, Govern is failing.
International cooperation as corporate practice
OECD recommendation 2.5 is for states, but firms practice a miniature version: share anonymized incident patterns with ISACs where appropriate; participate in standards bodies; align taxonomies with partners. Hoarding failure knowledge increases systemic risk.
Common misquotes to avoid
“OECD requires conformity assessment like the AI Act.” — False.
“OECD certification exists.” — False.
“47 adherents forever.” — Verify current list.
“2024 replaced the five principles with new ones.” — Misleading; updates refined and added emphasis within the Recommendation structure.
Accuracy protects credibility in regulatory meetings.
OECD.AI hosts principles text, policy observatories, and related tools. Use them to brief executives and to compare national strategies. Do not treat dashboard summaries as a substitute for reading the Recommendation when making formal commitments.
Synthetic media labeling in owned channels
Provenance technology where feasible
Executive deepfake verification SOP
Employee guidance against pasting secrets into public GenAI
Evaluation for false citation rates in enterprise assistants
Crisis comms templates for impersonation scams
Coordination with trust & safety for user-generated AI content
Map each control to OECD 2024 integrity language in your crosswalk.
Labour-market recommendation → corporate practice
Recommendation 2.4 pushes states on skills and transition. Companies mirror it with: AI literacy curricula; reskilling funds for roles automated; advance notice to works councils where required; joint design of AI tools with frontline staff. These practices also reduce deployment failure—workers reject tools designed without them.
Interoperability scorecard for the enterprise
Score 1–5: shared definitions; shared inventory IDs across subsidiaries; shared evaluation methods; mapped controls to EU/US/UK; common incident taxonomy. Low scores predict duplicated spend and contradictory disclosures.
Field Notes for Implementation Leads
Update the public AI principles page within 60 days of any OECD revision. Public pages that still scream 2019 while your lawyers cite 2024 create impeachment material.
In investor ESG Q&A, distinguish OECD alignment from legal compliance. Sophisticated investors now ask follow-ups about information integrity and environmental metrics—prepare evidence, not adjectives.
Synthesis for Busy Readers
OECD AI Principles (2019; revised 3 May 2024) remain the interoperable soft-law baseline across dozens of adherents. Five value principles plus five policy recommendations guide both states and corporate narratives. The 2024 update elevates generative AI, information integrity, misuse, safety overrides, environmental sustainability, and interoperable governance. Use OECD language accurately—never claim “OECD certified.” Refresh public principles pages and diligence questionnaires. Crosswalk to NIST and the AI Act in two columns so staff do not confuse expectations with obligations.
Sample board resolution language (illustrative)
“Resolved, that the Company aligns its Artificial Intelligence Principles to the OECD Recommendation on Artificial Intelligence (2019, revised 3 May 2024), including commitments to human rights and democratic values, transparency, robustness and safety (including override and decommission capability), accountability, information integrity controls for generative AI, and environmental sustainability considerations for material training and inference workloads; and that management shall report annually on evidence mapped to each principle.”
Counsel should localize. The point is to authorize evidence, not adjectives.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Policy engagement hygiene
When responding to OECD or national consultations, align corporate submissions with actual product controls. Lobbying for lighter rules while lacking basic inventory invites reputational harm if exposed. Consistency between advocacy and operations is part of accountability.
Primary-source route: S01 OECD | Return to contents
Chapter 4: NIST AI Risk Management Framework 1.0
Govern, Map, Measure, Manage — and how to run them without theater
Version note
This chapter explains AI RMF 1.0. NIST’s official resource page states that the framework is being revised. Preserve the version used for each assessment; revision activity is not itself a new mandatory standard. [S04]
Overview
Key point: NIST’s Artificial Intelligence Risk Management Framework (AI RMF 1.0, NIST AI 100-1), released 26 January 2023, is the dominant voluntary vocabulary for AI risk in U.S. boardrooms and increasingly in global enterprises. It will not satisfy the EU AI Act by itself. It will give your committees a shared language for outcomes: Govern, Map, Measure, Manage. Organizations that skip Map and Measure and jump to glossy Manage policies fail audits and real incidents alike.
This chapter explains each function, how the Playbook and AI Resource Center help, and how to wire RMF into product lifecycle gates.
Learning Objectives
Explain the RMF’s voluntary, rights-preserving, use-case-agnostic design intent.
Describe Govern as a cross-cutting function, not a one-time policy.
Run a minimal Map→Measure→Manage loop for one high-impact system.
Use Playbook-style actions without treating them as a checklist to game.
Crosswalk RMF functions to EU risk management and QMS expectations at a high level.
Core Analysis
NIST states the AI RMF is voluntary, rights-preserving, non-sector-specific, and use-case agnostic. It aims to help organizations manage risks to individuals, organizations, and society while enabling trustworthy AI. It was developed through a consensus process with public input under the National AI Initiative Act lineage.
Implication: Buying software that outputs “RMF aligned” stickers is not the same as achieving subcategory outcomes. The Core is organized as functions → categories → subcategories with outcomes. Evidence lives in artifacts: policies, inventories, evaluations, decision logs, incident records.
Function 1 — Govern (cross-cutting)
Govern is meant to infuse the other functions. It covers culture, policies, accountability structures, workforce diversity of skills, and processes that make mapping/measuring/managing possible.
Failure mode: A 40-page AI policy with no budget for evaluation or no authority to block launches.
Minimum viable Govern:
Written AI risk appetite linked to enterprise risk management.
Named accountable executive and escalation path.
Inventory requirement and change control for AI systems.
Training for staff who build or deploy AI (literacy is also an EU Article 4 theme).
Whistleblowing / concern channel that understands AI harms.
Vendor governance integrating AI-specific questions.
Govern is continuous. Revisit after major model introductions, M&A, or regulatory shifts (for example, U.S. EO changes that alter federal expectations while private RMF use continues).
Function 2 — Map
Map establishes context: intended purpose, deployment environment, affected stakeholders, legal requirements, and foreseeable misuse. Many AI harms are context harms—the same model is low risk in a grammar assistant and high risk in parole or medical triage.
Map outputs you should keep:
System card / use-case brief: purpose, users, forbidden uses.
Stakeholder map: who is affected, including non-users.
Data map: sources, rights, retention.
Harm scenarios: ranked by severity × plausibility (qualitative is fine initially).
Interdependencies: model provider, plugins, agents, critical APIs.
If Map is skipped, Measure becomes random benchmarking theater.
Function 3 — Measure
Measure uses quantitative, qualitative, or mixed methods to analyze, assess, benchmark, and monitor AI risk. Metrics must match the context from Map. Leaderboard scores rarely equal deployed trustworthiness.
Measure themes:
Performance validity in the deployment distribution.
Robustness and security tests (prompt injection, data poisoning, jailbreaks—as relevant).
Fairness analyses appropriate to the domain.
Human factors: can reviewers actually oversee outputs?
Environmental and cost metrics where material.
Drift and incident precursor monitoring after deployment.
Document method limitations. A fairness metric that ignores the actual protected classes in your market is worse than a qualitative assessment with clear caveats.
Function 4 — Manage
Manage prioritizes risks from Map/Measure and allocates resources to respond, recover, and communicate. It includes deciding not to deploy, to restrict features (no tool use; no open browsing), or to require human approval above thresholds.
Manage without theater:
Risk acceptance recorded by someone with authority.
Treatment plans with owners and dates.
Incident response playbooks including AI-specific events (confabulation cascades, deepfakes, agent runaway).
Post-incident learning fed back into Govern and Map.
Profiles, Playbook, and Resource Center
Profiles tailor the Core to sectors or technology classes. NIST AI 600-1 (Chapter 5) is the generative AI profile.
Playbook suggests actions per subcategory—use as prompts, not as a score-maximization game.
AI Resource Center aggregates guidance; useful for finding crosswalks and companion documents.
Expect evolution: NIST has signaled RMF revision work in connection with broader U.S. AI policy shifts. Track versioning in your references (AI RMF 1.0 vs later revisions).
Wiring RMF into the product lifecycle
| Idea / intake |
Govern + Map |
Use-case brief; go/no-go vs red lines |
| Design |
Map + Measure plan |
Data/evals plan; oversight design |
| Pre-production |
Measure |
Evaluation report; residual risk |
| Launch |
Manage + Govern |
Acceptance; monitoring config |
| Operate |
Measure + Manage |
Drift alerts; incident reviews |
| Major change |
Map refresh |
Re-classification; new evals |
Crosswalk notes (high level, not a substitute for counsel)
EU high-risk risk-management and quality obligations (Chapter 8) demand systematic risk processes, data governance, documentation, and human oversight. RMF can structure how you evidence those themes, but AI Act articles define whether you must and what conformity looks like. Keep a crosswalk matrix; do not claim “RMF = AI Act compliant.”
Common anti-patterns
Govern-only program — policy PDFs, no eval budget.
Measure vanity — metrics that cannot change a launch decision.
Map once — never updated after tool-enablement turns a chatbot into an agent.
Manage by PR — incident comms without technical containment.
Tool worship — GRC platform configured, inventory empty.
Documented publication example
Documented publication. NIST released AI RMF 1.0 on 26 January 2023 through a multi-stakeholder development process. The framework is voluntary and is organized around Govern, Map, Measure, and Manage. NIST’s resource page notes that version 1.0 is being revised; this chapter explains the 1.0 baseline rather than asserting that it is an immutable rulebook. [S04]
Executive-order changes and technical resources should be tracked separately. EO 14148 revoked EO 14110; EO 14179 directed a subsequent policy review. The editorial control pattern here is to retain a documented rationale for each risk-management activity, then reassess that rationale when an applicable requirement changes. [S10][S11]
Practical Checklist
Adopt RMF function names in AI committee agendas.
Fund Map and Measure explicitly in product budgets.
Create a use-case brief template mandatory for new AI.
Select evaluation methods per use case; ban one-size-fits-all scorecards.
Record risk acceptances with named authority.
Link incidents to subcategory improvements.
Maintain a version pin: “We implement NIST AI RMF 1.0 (Jan 2023)” plus any profiles.
Crosswalk to ISO/IEC 42001 clauses if certification is planned.
Train product managers on Map—not only engineers on Measure.
Review Playbook actions for your top three systems only (depth over breadth).
Board Questions
Which RMF function is weakest in our program—and what budget fixes it?
Can we show a Map artifact for our highest-impact AI system?
Which metrics actually gate launches?
Who may accept residual AI risk above our appetite?
How fast do we re-Map when a chatbot gains tools?
Is RMF referenced because customers ask, or because we run it?
What changed in our Govern structures after the last AI incident?
Are vendors required to provide Measure evidence, or only marketing one-pagers?
Subcategory thinking without drowning
The Core’s subcategories are numerous. Do not implement all at equal depth on day one. Pick the systems with highest severity first. For each, choose a thin vertical slice: Govern accountability + Map context + two Measure methods + Manage treatments. Expand sideways after the slice works.
Internal audit can test whether outcomes exist—not whether every Playbook bullet is ticked. Ticking without outcomes is the failure mode NIST warns against when it says actions are not a checklist.
Integrating with enterprise risk management (ERM)
AI risk belongs on the ERM register with clear taxonomy codes (model risk, conduct risk, operational risk, cyber, legal). RMF functions then become the operating method under those codes. Dual reporting—AI council and risk committee—should share the same inventory IDs to avoid shadow registers.
Staffing the four functions
| Govern |
Policy, ethics, legal, org design |
| Map |
Product, UX research, domain experts, threat modeling |
| Measure |
Evaluation science, security testing, statistics, socio-technical review |
| Manage |
Incident response, risk owners, communications, engineering leads |
If Measure is staffed only by the model builders without independent challenge, independence is weak. Consider separation of duties for high-impact systems.
Documentation that survives turnover
Store: use-case briefs, eval reports, acceptance memos, monitoring configs, incident postmortems, vendor attestations. Tag each with system ID and RMF function. Future you—and regulators—will need the trail more than the slide deck.
Bridge to Chapter 5
Chapter 4 is technology-agnostic. Chapter 5 specializes Measure and Manage for generative AI via NIST AI 600-1’s risk categories, including confabulation and CBRN information risks.
Govern deep dive — culture signals that predict failure
Watch for: launches celebrated with no eval mention; messengers shot for raising bias issues; security invited after press releases; vendors chosen solely on demo wow; legal involved only at contract signature. Each signal means Govern is decorative.
Positive signals: product OKRs include risk tasks; eval engineers have veto paths; near-misses praised; budget lines for red-teaming survive downturns.
Map deep dive — misuse brainstorming method
Run a 45-minute misuse workshop:
Intended user journey (10 min).
“How could this harm someone in 90 days?” sticky notes (15 min).
Cluster: privacy, safety, fairness, fraud, IP, security, labour (10 min).
Pick top five; assign Measure tests (10 min).
Store the board photo or digital board export in the binder. Regulators and auditors love contemporaneous Map evidence.
Measure deep dive — choosing methods
| Does it work here? |
Held-out real data; shadow mode |
| Does it invent facts? |
Confabulation suites |
| Is it fair enough for this use? |
Disaggregated metrics; error analysis |
| Can it be attacked? |
Red team; prompt injection; poisoning tests |
| Can humans oversee it? |
Usability study of override flows |
| Is it drifting? |
Population stability; performance monitors |
Match method intensity to harm severity. A cookbook chatbot and a loan model should not share identical Measure budgets.
Manage deep dive — decision vocabulary
Use explicit decisions: Deploy, Deploy with restrictions, Pilot only, Do not deploy, Rollback. Ban “launch and monitor” without named monitors and thresholds. Restrictions examples: no tool use; geo limits; human approval above amount X; retrieval-only answers.
Playbook use without checkbox fraud
Pick twelve Playbook actions relevant to your top system. Assign owners. At quarter end, show outcome evidence—not “completed” toggles. Rotate actions next quarter. Depth beats coverage theater.
Crosswalk starter to ISO/IEC 42001
RMF Govern ↔︎ leadership/planning clauses in 42001.
RMF Map ↔︎ context and risk assessment themes.
RMF Measure ↔︎ performance evaluation themes.
RMF Manage ↔︎ operation, improvement, incident themes.
Keep a one-page crosswalk if certification is planned (Chapter 17).
First 100 days implementing RMF
Days 1–20: Adopt function vocabulary; appoint accountable executive; draft risk appetite.
Days 21–40: Inventory top 20 systems; complete Map briefs for top 5.
Days 41–70: Run Measure plans for top 5; stand up incident categories.
Days 71–100: Manage decisions recorded; board report; expand to next 15 systems.
Resist boiling the ocean. Five deep Maps beat fifty empty templates.
Challenge culture in Measure
Independent challenge means someone other than the model developer can fail a launch. Options: separate eval team; risk review board; external red team for frontier systems. Document dissenting views even when overridden—overrides teach appetite.
Third-party mapping
Extend Map to vendors: what system, what data leaves, what residual rights, what eval evidence, what subprocessors, what model swap rights. Vendor Map failures become your incidents.
RMF and agile
Add a “risk story” type in the backlog: Map update, Measure test, Manage treatment. Give story points. If risk stories never make sprints, Govern is lying.
Field Notes for Implementation Leads
Rename meetings: “AI Govern,” “AI Map review,” “AI Measure readout,” “AI Manage decisions.” Vocabulary shapes behavior. If every meeting is still called “AI ethics sync,” RMF is not live.
Fund Measure as a product capability. Teams that beg for red-team budget each time will skip under pressure.
When adopting tools marketed as “RMF automated,” require them to export artifacts mapped to your system IDs. Tools that only produce dashboards without binder exports create audit pain.
Synthesis for Busy Readers
NIST AI RMF 1.0 (26 January 2023) gives voluntary functions—Govern, Map, Measure, Manage—that board committees understand. Govern is cross-cutting culture and accountability; Map sets context; Measure evaluates; Manage treats and accepts risk. Use the Playbook as prompts, not checkbox fraud. Wire functions into lifecycle gates. Crosswalk to EU duties without equating them. RMF outlives executive orders when embedded in ERM. Start with five deep systems, not fifty empty templates. Staff Measure with independent challenge.
Mapping RMF to a single system story (fraud model)
Govern: Model risk policy; owner in risk committee; vendor standards.
Map: Intended to score payment transactions; harms include false declines harming customers and false clears enabling fraud; stakeholders include customers, merchants, regulators.
Measure: Precision/recall on recent distribution; fairness across geographies; adversary tests for feature manipulation; drift monitors.
Manage: Thresholds tuned; human review queue for borderline scores; rollback plan; incident playbook for model failure.
Repeat this story format for GenAI and agents; only the Measure tools change.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Resource Center habit
Assign someone to check NIST AI Resource Center updates monthly and summarize deltas for the AI council. Profiles, crosswalks, and playbook tweaks appear without press fanfare. Quiet updates still change expectations in customer questionnaires.
Primary-source route: S04 NIST | Return to contents
Chapter 5: Generative AI Profile NIST AI 600-1
July 2024 profile — GenAI-specific risks, actions, and evidence
Overview
Key point: Generative AI fails differently from a fraud classifier. It invents citations, imitates voices, lowers barriers to dangerous knowledge, and scrapes into copyright fights. NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, published 26 July 2024, lists risk categories distinctive to or amplified by GenAI and maps suggested actions onto AI RMF functions. Boards that only apply generic model-risk templates will miss confabulation, synthetic content, and CBRN information pathways.
This chapter is a practitioner’s reading of the Profile—not a substitute for the PDF. Use it to redesign evaluation, monitoring, and launch gates for GenAI and for agents built on GenAI.
Learning Objectives
Explain what a NIST “profile” is relative to AI RMF 1.0.
Describe key GenAI risk categories in AI 600-1 terms, including confabulation and CBRN information or capabilities.
Connect profile actions to GOVERN / MAP / MEASURE / MANAGE evidence.
Design a minimum evaluation pack for customer-facing LLM applications.
Separate voluntary NIST profile use from EU GPAI legal duties (Chapter 9).
Core Analysis
What AI 600-1 is
AI 600-1 is a cross-sectoral companion profile to AI RMF 1.0. It was produced pursuant to the then-applicable Executive Order 14110 mandate for generative-AI guidance. Even after EO 14110’s revocation by EO 14179 (23 January 2025), the Profile remains a public NIST technical resource. Its value is methodological, not statutory.
A profile does not replace the Core. It tells you which risks and actions deserve emphasis for a technology class—here, generative AI (GAI).
Risk categories that change the conversation
NIST identifies multiple GenAI risks (commonly summarized as a set of twelve categories in secondary explainers; always confirm against the Profile’s own list when building controls). Two deserve board-level fluency because they are easy to under-fund:
Confabulation
NIST uses confabulation for confidently stated erroneous or false content—also called hallucination or fabrication. Outputs may diverge from prompts, contradict earlier context, or invent plausible citations and logic. The mechanism is statistical generation approximating training distributions, not a database lookup.
Why it matters commercially: Users trust fluent answers. In health-adjacent chat, legal research assistants, financial advice UX, or safety procedures, confabulation becomes operational risk and potential liability. In internal knowledge bots, it becomes decision risk.
Control directions suggested by profile-style thinking:
Grounding with retrieval from approved corpora where appropriate.
Ground-truth evaluation sets for high-stakes intents.
Documented fact-checking workflows.
UI design that avoids false certainty (calibrated language; citations that can be verified).
Intake for user-reported errors tied to model version and prompt context.
Human review thresholds for consequential outputs.
CBRN information or capabilities
The Profile flags eased access to or synthesis of information or design capabilities related to chemical, biological, radiological, or nuclear (CBRN) weapons or dangerous agents. Much information may already be public; GenAI can lower expertise barriers by structuring and combining it. Specialized design tools raise additional concerns.
Control directions:
Acceptable-use policies and staged capability access.
Evaluation for risky scientific assistance beyond toy jailbreak demos.
Escalation paths to security and compliance when tools enter bio/chem design assistance.
Vendor diligence on frontier model safety evaluations.
Clear refusal and monitoring strategies proportional to model capability.
Do not invent unpublished threat statistics. Treat CBRN as a capability-tier issue: the more capable and tool-enabled the system, the more formal the review.
Other GenAI risk themes practitioners must budget for
Without reducing the Profile to a slogan list, programs typically also need coverage for:
Data privacy risks from training and prompt logs (sensitive data entered by users).
Copyright / IP issues in training and in outputs that resemble protected works.
Human-AI interaction harms (over-reliance, automation bias).
Toxicity / harmful content generation.
Obscuring or degrading human agency through persuasive or manipulative patterns.
Synthetic content enabling fraud, non-consensual imagery, or election integrity harms (coordinate with information-integrity programs from OECD 2024 themes).
Homogenization and value-lock concerns at societal scale (more relevant for large platforms).
Environmental impacts of training and large-scale inference.
Supply-chain / third-party model risks when you did not train the base model.
Security risks unique to LLMs (prompt injection, data exfiltration via tools, model theft).
Exact labels and numbering belong to the Profile document—use NIST’s wording in formal crosswalks.
Mapping actions to RMF functions (operating view)
| Govern |
Policies for acceptable use; disclosure; training data provenance expectations; escalation for CBRN-class capabilities; marketing claims control |
| Map |
Intended use vs. foreseeable misuse; whether tools/browsing/code-exec are enabled; affected populations; jurisdictional disclosure rules |
| Measure |
Confabulation evals; red-teaming; IP sniff tests; privacy tests on logs; agent permission tests |
| Manage |
Feature flags; grounding requirements; human approval gates; incident classes for synthetic fraud; kill switches for agents |
Minimum evaluation pack for a customer-facing LLM app
Task performance on your real intents (not only public leaderboards).
Confabulation probes with graded severity (fabricated citations; false policy statements).
Safety policy tests aligned to your acceptable-use policy.
Prompt-injection / tool-abuse tests if tools exist.
Privacy tests (secret canaries in prompts; log retention checks).
Accessibility and UX certainty review (does the UI overclaim?).
Change tests when models or prompts swap.
Store results with model hash/version, date, dataset ID, and decision (ship / ship with restrictions / no-ship).
Agents amplify every GenAI risk
When GenAI plans and calls tools, confabulation can become erroneous actions. Prompt injection can become data theft. Memory features can be poisoned. Map must capture tool scopes; Measure must include end-to-end action traces; Manage must include authorization and rate limits. Chapter 23 goes deeper; Chapter 5 insists you do not profile “chat only” if production is agentic.
Relationship to EU GPAI rules
NIST AI 600-1 ≠ EU Chapter V compliance. GPAI providers face documentation, copyright policy, and training-summary duties under the AI Act, with extra obligations for systemic-risk models (Articles 51–55). The Profile can inspire evaluation content that later supports those files, but legal thresholds (including the Article 51(2) compute presumption) are EU law, not NIST guidance.
Review-dependent notes
Secondary articles sometimes list “12 risks” with slight naming differences—prefer the Profile PDF for authoritative labels.
EO 14110’s revocation does not delete NIST publications; it changes federal tasking. Pin the document ID and date in your references.
Do not invent CBRN incident rates.
Documented publication example
Documented publication. NIST released AI 600-1 on 26 July 2024. It provides a voluntary profile for generative-AI risk management. The publication establishes the profile’s content and date; it does not establish that particular companies achieved a competitive advantage by adopting it earlier. [S05]
Practical implication. Select the profile’s relevant risks, translate them into tests for the actual deployment, and document why each result changes—or does not change—the release decision.
Practical Checklist
Download and pin NIST AI 600-1 (26 July 2024) in the controlled document library.
Add confabulation evaluation to launch criteria for any customer-facing GenAI.
Classify GenAI apps by tool autonomy (answer-only vs. retrieval vs. write-actions).
Create an incident category for synthetic-content fraud and deepfake impersonation.
Review training/fine-tune data for privacy and IP provenance issues.
Require vendors to describe GenAI risk mitigations using RMF function language.
Set marketing claim review for performance and safety assertions.
Establish a CBRN/dual-use review trigger for scientific-assistant features.
Log model versions with every production prompt class that is audited.
Re-run Measure after each base-model swap—even if the vendor calls it “drop-in.”
Board Questions
Where has confabulation already caused a customer or employee error?
Which GenAI systems can take actions without a human in the loop?
Do we evaluate IP and privacy risks of GenAI, or only toxicity?
What is our dual-use review for scientific or cyber-capable assistants?
Are we still citing EO 14110 as if it were in force?
How do we monitor synthetic impersonation of our executives?
Which metrics would make us turn a GenAI feature off this quarter?
Is AI 600-1 in our audit universe, or only AI RMF posters?
Deep dive: confabulation governance lifecycle
Before launch. Build a labeled set of questions whose answers are known for your domain. Include adversarial phrasings. Score not only accuracy but also whether the system admits uncertainty. Test citation faithfulness if you display sources.
At launch. Configure refusals and escalation for high-risk intents. Consider retrieval grounding with allowlisted corpora. Disable web browse if you cannot supervise sources.
After launch. Track user corrections and “thumbs down” with root-cause tags: retrieval miss, model invention, stale policy, prompt bug. Feed tags into retraining or prompt fixes. Report rates to the AI risk committee.
Procurement. Ask model vendors for published evaluation methodologies relevant to confabulation and for known failure modes. Discount flashy demos without eval cards.
Deep dive: synthetic content and fraud desk
Stand up a joint playbook among security, fraud, communications, and legal:
Verification channel for executive video/audio (out-of-band callbacks).
Customer warnings for known scam patterns using your brand.
Preservation steps for evidence.
External reporting paths where required.
Product labeling strategies aligned to AI Act Article 50 themes and to U.S. state transparency laws where applicable (Chapter 12).
OECD’s 2024 information-integrity emphasis and NIST’s synthetic-content concerns converge here.
Evidence binder structure for GenAI
Use-case Map brief.
Model/vendor card + version pins.
Evaluation reports (confabulation, safety, security, privacy).
Acceptable-use + marketing claim approvals.
Monitoring config + sample alerts.
Incident postmortems.
Crosswalk to AI 600-1 risk categories (table).
Crosswalk to legal duties if EU-facing (pointer to Chapters 8–10).
Chapter bridge
Chapter 4 gave the generic RMF operating system. Chapter 5 specialized it for GenAI. Chapters 6–10 move from voluntary U.S. practice language into binding EU architecture.
Building a confabulation severity scale
| S1 |
Harmless invented fun fact in casual chat |
Log; periodic review |
| S2 |
Wrong product policy that confuses customers |
Fix retrieval; notify support |
| S3 |
Fabricated legal/medical citation used internally |
Quarantine feature; retrain review |
| S4 |
Confabulation drives external action (payment, medical step, legal filing) |
Incident response; human gate |
Tune to your domain. Publish the scale so employees escalate consistently.
CBRN-adjacent feature gate
Before enabling scientific assistants, chemistry tools, or bio sequence features:
Capability description and user population.
Independent safety review (not only the product manager).
Rate limits and monitoring for suspicious query patterns.
Refusal policies tested, not assumed.
Executive acceptance if residual risk remains.
If you cannot staff the gate, do not ship the feature.
Prompt injection as GenAI security measure
When tools or browsing exist, treat prompt injection like SQLi for LLMs. Tests should include: indirect injection via retrieved documents; tool exfiltration attempts; privilege escalation through agent memory. Manage responses: sanitize tool outputs; strict allowlists; human approval for irreversible actions.
Copyright and output filters
Profile-driven IP risk management may include: training data provenance reviews; output filters for known copyrighted canvases; complaint intake; legal hold for disputed outputs. Coordinate with Chapter 9’s EU copyright policy duty if you are a GPAI provider.
Reporting GenAI risk to boards
One slide: top GenAI apps; confabulation S3+ count; injection test status; synthetic fraud incidents; model swaps this quarter; decisions pending. Leave philosophy to the appendix.
GenAI acceptable-use policy skeleton
Allowed uses (drafting, summarization of permitted data, coding assist with review)
Forbidden uses (automated legal advice to customers without counsel; medical diagnosis; covert human impersonation; scraping personal data into prompts)
Data handling (no secrets in consumer tools; enterprise tool logging rules)
Disclosure expectations
Oversight requirements by use class
Enforcement and exception process
Link policy to AI 600-1 risks in an appendix table.
Evaluation dataset governance
Version datasets; prevent contamination with production secrets; refresh for new product intents; include adversarial and minority-language cases where you operate; peer-review labels. Bad eval sets create false confidence—sometimes worse than no evals.
Multi-model routing risks
Enterprises increasingly route queries across models. That multiplies confabulation and security surfaces. Map must capture routers; Measure must test end-to-end; Manage must pin versions and fallbacks. “The router decided” is not an accountability story.
Customer-facing uncertainty UX
Prefer: “I’m not sure—here’s how to verify” over false precision. Calibrated uncertainty reduces S3/S4 confabulation harm. Train brand and UX teams that hedging can be a safety feature, not a tone failure.
Field Notes for Implementation Leads
Pin AI 600-1 in the same library as AI RMF 1.0 with checksum/date. Train new PMs on confabulation before they launch customer bots.
Create a shared “S3+ confabulation” incident tag in your ticketing system. If the tag does not exist, the risk will be miscategorized as generic bug reports.
For agentic products, require a tool-permission matrix review as part of Map before enabling write actions. Chat-only profiles are insufficient.
Synthesis for Busy Readers
NIST AI 600-1 (26 July 2024) profiles generative AI risks atop the RMF—confabulation and CBRN information risks among others. Build severity scales, dual-use gates, injection tests for tools, and synthetic-fraud playbooks. Keep the Profile even though EO 14110 was revoked; it remains technical guidance. Do not confuse it with EU GPAI legal duties. Agents amplify every GenAI risk by turning wrong text into wrong actions. Report S3+ confabulation and model swaps to boards in one slide.
Mapping AI 600-1 to product OKRs
Good OKRs: reduce S3 confabulation rate in support bot; complete injection test suite before enabling tools; ship synthetic media labeling; close vendor documentation gaps. Bad OKRs: “be responsible”; “align to NIST” without metrics. Profile risks become OKRs when they have owners and numbers (even qualitative baselines that improve).
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Red-team cadence for GenAI
Quarterly external or independent internal red teams for top GenAI apps; continuous lightweight probes for injection and confabulation on changes. Store findings with severity and fix-by dates. Unfixed critical findings block Manage approval for expanded tool rights.
Primary-source route: S05 NIST · S04 NIST | Return to contents
Part II — The EU AI Act (Ch. 6–10)
Chapter 6: EU AI Act – Architecture and Scope
Regulation (EU) 2024/1689 — who is caught, how the rulebook is built, extraterritorial reach
Amendment-aware reading
Read the EU chapters with the revised timeline in Chapter 11. The Commission identifies changes beyond dates, including literacy and registration provisions. References to original Article 4 wording describe the historical baseline unless explicitly updated. Competence and training remain operational controls; their current legal basis must be identified separately. [S08][S09]
Overview
Key point: The EU Artificial Intelligence Act is the first comprehensive, horizontal hard law for AI systems and general-purpose AI models at continental scale. It entered into force on 1 August 2024 as Regulation (EU) 2024/1689. If your model outputs are used in the Union, you may be in scope even with no EU office. Misreading architecture—mixing provider duties with deployer duties, or treating GPAI like a chatbot feature flag—creates false comfort.
This chapter explains the Act’s structure, territorial reach, key roles, and how risk-based logic organizes later chapters. Detailed tiers, obligations, GPAI rules, and dates follow in Chapters 7–10.
Learning Objectives
Identify the Act’s official name, number, and entry-into-force date.
Explain extraterritorial triggers at a plain-language level.
Distinguish providers, deployers, importers, distributors, and GPAI model providers.
Sketch the Act’s risk-based architecture (prohibited, high-risk, transparency, GPAI).
Know what is out of scope at a high level and when to escalate to counsel.
Core Analysis
What kind of law this is
The AI Act is an EU regulation—directly applicable in Member States—not a directive that needs local transposition to take effect (though national authorities, sandboxes, and penalties administration still require domestic setup). It amends and interacts with other Union acts; practitioners should treat it as part of the product-safety and market-surveillance family as well as a digital rulebook.
It is horizontal (across sectors) but risk-based (duties scale with risk and role). Sector rules (health, aviation, finance) still apply; the Act adds AI-specific layers.
Architectural map
Think in five shelves:
General provisions — subject matter, scope, definitions (Articles 1–3 area), AI literacy (Article 4).
Prohibited practices — Article 5 red lines.
High-risk AI systems — classification rules, Annexes, obligations for providers/deployers, conformity, registration themes.
Transparency — Article 50 duties for certain interactions and synthetic content.
GPAI models — Chapter V (Articles 51–56 area): baseline and systemic-risk tiers, codes of practice, AI Office oversight interface.
Governance chapters create the AI Office, Board, national authorities, and enforcement/penalty frameworks. Later chapters of this book unpack shelves 2–5.
Territorial reach (plain language)
The Act is designed to protect people in the Union. Triggers include placing AI systems on the market or putting them into service in the EU, and situations where output produced by AI is used in the Union—even if the provider is established elsewhere. Exact legal tests are fact-specific; counsel must apply Article 2 to your topology.
Operating heuristic for product leads: If EU users can be affected by the system’s outputs, run an applicability analysis—do not wait for an EU subsidiary to appear on the org chart.
Roles that change duties
| Provider |
Develops / places on the market / puts into service under its name or trademark |
| Deployer |
Uses the system under its authority |
| Importer / distributor |
Supply-chain roles with their own checks |
| GPAI model provider |
Places general-purpose models on the market |
| Authorized representative |
For non-EU providers as required |
A company can be provider for one product and deployer of another vendor’s tool. Fine-tuning and rebranding can shift who is “provider.” Document role analysis per product SKU.
Risk logic in one paragraph
Unacceptable risks are banned (Chapter 7). High-risk systems face heavy ex-ante duties (Chapters 7–8). Limited-risk situations emphasize transparency (Article 50). GPAI models face upstream transparency and, if systemic risk applies, evaluation and incident duties (Chapter 9). Minimal-risk AI remains largely free of AI Act-specific ex-ante burdens but still faces other law (GDPR, consumer, product liability).
Exclusions and careful edges
The Act contains scope edges (for example, certain national-security contexts, and research nuances that must be read in the official text). Free and open-source pathways receive specific treatment in places—not a blanket exemption from all duties, especially when high-risk or GPAI systemic-risk conditions apply. Escalate edge cases; do not learn exclusions from marketing blogs.
Relationship to GDPR and product law
GDPR remains the privacy backbone. High-risk AI often implicates automated decision-making and DPIA practice. Product-safety legislation may apply in parallel for embedded AI (Annex I logic). The AI Act does not erase those regimes; it adds AI-specific obligations and market surveillance.
Institutional cast
AI Office (European Commission) — central role especially for GPAI supervision themes.
European Artificial Intelligence Board — Member State coordination.
National competent / market surveillance authorities — domestic enforcement for many system-level duties.
Notified bodies — conformity assessment where required for certain high-risk cases.
Codes of practice — especially relevant for GPAI compliance pathways (Chapter 9).
Applicability memo per product (Article 2 analysis).
Role memo (provider/deployer/GPAI).
Risk-tier memo (Chapter 7).
Obligations backlog with dates (Chapter 11).
Evidence binder (Chapters 8–9).
Authority engagement plan (who speaks if contacted).
Review-dependent / amendment watch
The Commission’s updated implementation timeline reflects the 2026 AI Omnibus. Chapter 11 distinguishes the original milestones from the revised high-risk application dates. Before operational reliance, check the applicable amended legal text, actor role, and transition provisions. [S08][S09]
Illustrative case study
Extraterritorial surprise pattern. A U.S. SaaS provider with no EU entity ships an HR screening assistant used by an EU customer’s hiring team. Outputs influence employment decisions in the Union. Applicability and deployer/provider analyses become unavoidable; “we only sell to a U.S. parent” is not a strategy. Early role mapping and contractual allocation of AI Act duties prevent last-minute shutdowns.
Practical Checklist
Confirm Regulation 2024/1689 is listed in the legal register with entry-into-force date 1 Aug 2024.
Complete Article 2 applicability memos for top products.
Assign provider vs deployer labels per SKU.
Identify GPAI model dependencies and upstream providers.
Create an architecture one-pager for executives (five shelves).
Align privacy, product safety, and AI Act workstreams—one steering group.
Name counsel owners for AI Office vs national authority contacts.
Watch Official Journal amendments affecting dates (Chapter 11).
Update customer contracts with role and cooperation clauses.
Train sales engineers not to promise “full AI Act certification” casually.
Board Questions
Which products could be in scope solely because outputs are used in the EU?
Who is legally the provider for our rebranded or heavily fine-tuned models?
Do we have a single steering group across GDPR, product safety, and AI Act?
What is our plan if a national authority requests documentation in 30 days?
Are open-source components wrongly treated as “no duty”?
How do we monitor amendments to application dates?
Is the AI Office vs national authority distinction understood by our exec team?
Which customer contracts already allocate AI Act roles—and which are silent?
Reading the Act without drowning
Start with Articles 1–3 (scope/definitions), Article 5 (bans), Article 6 and Annex III (high-risk classification), Chapter V (GPAI), Article 50 (transparency), Articles 99 and 101 (penalties), Article 113 (timeline). Recitals help interpretation but operative articles control. Keep a controlled PDF of the consolidated version.
Market access as strategy
The Act is often compared to GDPR’s extraterritorial gravity. Expect “EU AI readiness” to become a buyer questionnaire theme worldwide. Being able to show role analysis, risk tier, and evidence map is a sales asset—not only a cost center.
Bridge
Chapter 7 details risk tiers. Chapter 8 details high-risk obligations. Chapter 9 details GPAI. Chapter 11 details dates and fines. Do not skip Chapter 7’s classification step; wrong tier wastes the rest.
Article 2 applicability scenarios (teaching set)
Scenario 1. Model trained in Asia, API sold globally, EU startup calls API for chatbot used by EU consumers → strong applicability analysis needed.
Scenario 2. Purely internal HR tool for U.S. employees only, no EU deployment → likely outside AI Act, still other laws.
Scenario 3. Open-source model weights posted online, EU firm fine-tunes and sells as “AcmeHire AI” → EU firm likely provider of resulting system; upstream GPAI issues still matter.
Scenario 4. EU hospital deploys U.S. vendor device with embedded AI → Annex I / medical interplay; importer/distributor roles may appear.
Teach scenarios annually; refresh with case law and guidance.
Documentation architecture for multinationals
Maintain three layers:
Global AI policy (principles + RMF).
EU AI Act playbook (roles, tiers, dates, binders).
Product technical files (per high-risk / GPAI item).
Do not bury Act duties only inside GDPR records. Authorities will ask for AI-specific files.
Working with notified bodies and standards
High-risk conformity may require harmonized standards and, in some cases, notified-body assessment. Track standardization progress; delays in standards are a program risk equal to engineering delays. Budget time for document cycles, not only model training.
Sales engineering guardrails
Forbidden phrases unless counsel approved: “fully AI Act certified,” “EU approved algorithm,” “compliant with all AI regulations worldwide.” Allowed: “We operate an AI Act compliance program; applicability and tier assessed per product; documentation available under NDA.”
Coordination with the AI Board and national authorities
Member State authorities will differ in tone and speed. Keep a jurisdiction contact sheet. For GPAI-centric issues, prepare an AI Office engagement file: model cards, compute class, evaluation summaries, incident contacts.
Provider vs deployer decision tree (plain)
Do we place the system on the market under our name/trademark? → Provider analysis.
Do we substantially modify a system and place it as ours? → Provider analysis likely.
Do we only use a system supplied by another under their instructions? → Deployer analysis.
Do we train/provide a GPAI model? → Chapter V analysis in parallel.
Are we importing into the EU a system from abroad? → Importer duties may apply.
Record answers per SKU. Revisit on rebranding and M&A.
Interplay with contractual flow-downs
EU customers will demand AI Act cooperation clauses. Prepare a standard pack: role statement; risk tier; documentation sharing terms; incident notice SLAs; audit rights scoped to AI files. Negotiating from a pack is faster than inventing per deal.
Sandboxes and real-world testing
The Act contemplates regulatory sandboxes and certain testing regimes. Treat sandbox participation as a project with entry criteria, data protections, and exit reports—not as a PR stunt. Counsel should confirm whether sandbox use changes marketing claims you may make.
Common architectural mistakes
Treating GPAI obligations as optional because “we are a deployer only” while fine-tuning heavily
Ignoring Article 4 literacy as “training fluff”
Assuming CE-mark experience automatically covers AI Annex documentation
Splitting GDPR and AI Act teams with no shared inventory
Fix with joint steering and shared IDs.
Field Notes for Implementation Leads
Create an “AI Act war room” channel with legal, product, security, privacy, and a program manager. Post every Official Journal amendment link there. Ban unofficial timeline memes as authority.
For each product line, maintain a one-page applicability & role card stored next to the privacy ROPA entry. Auditors should find AI and privacy artifacts cross-linked within two clicks.
When translating the Act for engineers, never say “the Act bans AI.” Say “the Act bans listed practices and heavily regulates high-risk uses while imposing upstream duties on GPAI.” Precision reduces both panic and complacency.
If you operate through resellers, map distributor/importer touchpoints early. Surprise supply-chain roles delay launches more often than model quality issues.
Budget a yearly “architecture refresh” workshop after major guidance drops from the AI Office or Commission. Treat guidance as operational input, not optional reading.
Worked Walkthrough: First-Week EU Applicability Sprint
Monday. Export product list from inventory; mark EU user impact unknown/yes/no.
Tuesday. Legal trains PMs on Article 2 heuristics and roles.
Wednesday. Fill applicability & role cards for top ten revenue products.
Thursday. Flag GPAI dependencies; send vendor documentation requests.
Friday. Steering group reviews cards; opens backlog tickets for bans screen and classification clinic; reports amber items to exec sponsor.
One week cannot finish conformity—but it ends denial. Architecture literacy begins with knowing who is caught.
Synthesis for Busy Readers
Regulation (EU) 2024/1689 entered into force 1 August 2024. It is horizontal, risk-based, and extraterritorial when outputs affect the Union. Learn the five shelves: general provisions/literacy; prohibitions; high-risk; transparency; GPAI—plus institutions and penalties. Role analysis (provider/deployer/GPAI) is SKU-specific. Keep a controlled consolidation for amendments. Architecture mistakes—ignoring literacy, mishandling open source, splitting GDPR from AI files—create false comfort. Chapter 6 is the map; Chapters 7–10 are the terrain.
Watch CEN/CENELEC and Commission standardization requests for AI Act harmonized standards. Gaps in standards create uncertainty for conformity assessment. Program managers should track standards timelines beside engineering timelines. Where standards lag, document alternative specifications carefully with counsel—do not invent “equivalent” claims casually.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
SME and startup notes
Small teams should not ignore the Act; they should sequence ruthlessly: Article 5 screen first, literacy second, role/tier third, then only the obligation stack that applies. Use Commission and AI Office Q&As when published. Join a trade association for code-of-practice updates if you are a GPAI provider. Avoid paying for “guaranteed compliance certificates” from unknown vendors—certificates are not the Act’s primary conformity story.
Glossary of Act institutions (pocket)
AI Office — Commission function for GPAI-centered supervision and guidance.
AI Board — Member State coordination body.
National competent authorities / market surveillance — domestic enforcement for many system duties.
Notified bodies — conformity assessment entities where required.
Scientific panel — expertise inputs including systemic-risk alerts pathways.
Know which door matches which problem before a crisis.
One thing to do this week
Pick the single highest-revenue or highest-risk product affected by this chapter. Complete one artifact (vendor letter, timeline row, EO tracker update, state matrix row, or applicability card). Send it to the AI program manager the same week. Momentum beats perfect plans.
Primary-source route: S06 European Union · S07 European Commission · S08 European Commission | Return to contents
Chapter 7: Risk Tiers – Prohibited, High-Risk, GPAI
Article 5 bans, Annex III high-risk categories, and systemic-risk GPAI thresholds
Overview
Key point: The EU AI Act does not treat all AI equally. Wrong classification is the most expensive early mistake: you either over-engineer a low-risk feature or under-control a high-risk or banned use. Classification is also where product, legal, and ethics must sit in one room—because “employment,” “biometrics,” and “general-purpose model” are legal categories, not engineering nicknames.
This chapter gives a working map of prohibited practices, high-risk systems (especially Annex III), transparency-tier logic, and GPAI systemic-risk classification under Article 51—including the 10^25 FLOP presumption—without replacing counsel’s Annex reading.
Learning Objectives
Explain Article 5’s role as hard red lines already applicable from 2 February 2025.
Navigate Annex III’s high-risk area logic at category level.
Distinguish high-risk systems from GPAI models.
Apply Article 51’s systemic-risk presumption and Annex XIII designation criteria conceptually.
Build a classification worksheet your PMs can complete before legal review.
Core Analysis
Tier mental model
| Prohibited |
Unacceptable risk — banned |
Do not build / kill / contractual ban |
| High-risk |
Significant risk to health, safety, fundamental rights |
Full obligation stack (Ch 8) |
| Transparency / limited risk |
Risk of confusion or manipulation via opacity |
Disclose / label (Art. 50) |
| GPAI models |
Upstream general capability |
Ch V duties; extra if systemic risk |
| Minimal |
Not specially regulated by AI Act ex ante |
Still other laws apply |
A single product can combine tiers (a GPAI model embedded in a high-risk employment system). Stack duties; do not average them.
Prohibited AI practices (Article 5)
Article 5 bans certain practices. Exact list and exceptions (especially for law-enforcement uses of remote biometric identification) are tightly drafted—read the article. Themes include:
Harmful manipulative or deceptive AI that materially distorts behavior and causes significant harm.
Exploitation of vulnerabilities (age, disability, socio-economic situation) to distort behavior causing significant harm.
Social scoring by public authorities (and related scoring logics as specified).
Certain biometric categorisation and emotion-recognition uses in sensitive contexts as specified.
Untargeted scraping of facial images for recognition databases as specified.
Real-time remote biometric identification in publicly accessible spaces for law enforcement, subject to narrow exceptions.
From 2 February 2025, prohibited practices and AI literacy (Article 4) apply. Boards should treat Article 5 as live law—not a 2026 problem.
Product implication: Maintain a written red-line list mapped to Article 5 themes. Require legal sign-off for biometric, emotion, scoring, and manipulative UX patterns.
High-risk classification
High-risk status arises mainly through:
Annex I pathway — AI that is a safety component of (or itself) products already covered by specified Union harmonization legislation (machinery, medical devices, aviation, etc.), under the Act’s classification rules.
Annex III pathway — stand-alone use cases in listed areas.
Annex III areas (category-level; always verify the Annex text and any amendments) cover domains such as:
Biometrics (where not prohibited).
Critical infrastructure management and operation.
Education and vocational training.
Employment, workers’ management, access to self-employment.
Access to essential private and public services (including creditworthiness themes as specified).
Law enforcement uses as listed.
Migration, asylum, border control management as listed.
Administration of justice and democratic processes as listed.
Important: Being in an Annex III area is the start of analysis. The Act includes classification rules and possible derogations where a system does not pose significant risk of harm to health, safety, or fundamental rights (conditions are legal-technical—do not self-exempt casually).
Transparency tier (preview)
Article 50 requires transparency for certain AI interactions and synthetic content (chatbots that people might think are human; deepfakes; emotion recognition/biometric categorisation notices as specified). Transparency is not a substitute for high-risk compliance when both apply.
GPAI vs high-risk systems
GPAI model — capable of performing generally applicable functions; trained at scale; can be integrated into many systems.
High-risk AI system — a system used in a high-risk context/classification.
Providers of GPAI models have Chapter V duties even if a particular downstream use is not high-risk. Deployers/providers of high-risk systems have Chapter III duties even if the underlying model is third-party GPAI. Contracts must allocate both stacks.
Systemic-risk GPAI (Article 51)
A GPAI model is classified as a GPAI model with systemic risk if:
It has high-impact capabilities evaluated with appropriate technical tools/methodologies; or
The Commission designates it based on Annex XIII criteria (parameters, data, compute, modalities, benchmarks/capabilities, market reach—including a presumption related to large numbers of business users—and end-user numbers, as set out in the Annex).
Presumption: Under Article 51(2), a model is presumed to have high-impact capabilities when cumulative training compute exceeds 10^25 floating-point operations (FLOP). The Commission may update thresholds by delegated act as technology evolves (Article 51(3)).
Operator response: Ask vendors for compute class / systemic-risk status; track Commission designations; if you train models near frontier scale, prepare Article 55-class controls early (Chapter 9).
Classification worksheet (fields)
Product name / version
EU user impact? (Y/N/unclear)
Roles (provider/deployer/GPAI)
Article 5 screen (pass/fail/escalate)
Annex I product-safety hook?
Annex III category (if any) + derogation analysis owner
Article 50 triggers?
GPAI model involved? Systemic risk claimed/presumed/designated?
Residual other-law risks (GDPR, consumer, IP)
Sign-off (legal + product + risk)
Review-dependent notes
Annex III wording is precise; category paraphrases above are navigational aids.
High-risk application dates have seen legislative adjustment discussions/amendments in 2026—classification logic and date logic are separate (Chapter 11).
Do not invent additional FLOP thresholds.
Illustrative case study
Employment chatbot vs employment decision system. A company ships an internal LLM that answers HR policy questions (transparency and confabulation risks) and later adds a feature that ranks candidates for hiring managers. The second feature pushes Annex III employment analysis. Same model family; different tier. Classification must follow use, not model brand.
Practical Checklist
Run Article 5 screening on all biometric, scoring, emotion, and dark-pattern UX.
Tag inventory items with Annex I / Annex III / neither.
Separate GPAI model inventory from high-risk system inventory.
Collect vendor attestations on Article 51 status.
Forbid self-derogation from high-risk without written legal analysis.
Link classification outcomes to obligation backlogs automatically.
Re-classify when features add decision influence (ranking, eligibility, scoring).
Train PMs on the worksheet before sprint planning.
Include classification summary in board AI risk reports.
Monitor Official Journal for Annex III amendments (Article 7 mechanism).
Board Questions
Have we shipped anything that could be an Article 5 prohibited practice?
Which systems touch employment, credit, education, or biometrics?
Which upstream models could be systemic-risk GPAI—and what if a vendor is wrong?
Who signs classification worksheets?
Do we re-classify after feature flags flip?
Are transparency labels covering for missing high-risk controls?
What is our kill plan for a product that fails Article 5 review?
How many inventory items are still “unclassified”?
Worked examples (illustrative, not legal advice)
Example A — Warehouse computer vision counting boxes. Likely not Annex III employment evaluation if it only counts inventory; still cyber and safety issues; check if used to discipline workers (then employment analysis).
Example B — Consumer photo filters. Transparency/synthetic media issues; usually not high-risk; watch biometric categorisation features.
Example C — Bank creditworthiness model. Expect Annex III essential-services / credit themes; high-risk obligation stack; GDPR automated decision rules in parallel.
Example D — Frontier base model API. GPAI provider duties; systemic-risk analysis via compute/designation; downstream high-risk uses by customers need contractual clarity.
Example E — Emotion analysis in call centers. Article 5 and transparency analyses required; high risk of prohibited or restricted patterns—escalate early.
Governance ritual
Create a weekly “classification clinic” (30 minutes) with legal, product, and security. Review new features and unclear cases. Publish decisions to the inventory. This ritual prevents silent tier drift.
Bridge
Once classified high-risk, Chapter 8’s obligation stack applies. Once classified GPAI (especially systemic risk), Chapter 9 applies. Dates and fines are Chapter 11.
Article 5 program — first ninety days
Days 1–15: Inventory biometric, emotion, scoring, scraping, and manipulative UX features.
Days 16–45: Legal memo mapping each to Article 5; kill or redesign fails.
Days 46–75: Contractual bans for vendors; sales playbook updates.
Days 76–90: Internal audit sample; board report on residual ambiguous cases.
Literacy (Article 4) runs in parallel: role-based training with completion evidence.
Annex III employment — common tripwires
Resume ranking and predictive promotion tools
Task allocation systems that discipline via AI scores
Productivity surveillance with automated consequences
Chatbots that effectively decide eligibility for roles
HR “copilots” that only draft job ads are different from systems that filter candidates. Document intended purpose tightly; prevent silent feature creep.
GPAI systemic risk — questions for CFOs
Training toward frontier scale is a compliance event, not only a research event. Budget for evaluations, cyber, incident response, and documentation before crossing presumptive thresholds. Surprises at 10^25 FLOP are governance failures.
Transparency tier traps
Labeling a deepfake studio as “transparent” does not legalize prohibited manipulative uses. Transparency is additive. Classification clinics should ask both “Art 5?” and “Art 50?” every time.
Record of classification decisions
Store: worksheet PDF, attendees, date, version of Annex text consulted, outcome, review date. When staff turn over, the record prevents re-litigating settled tiers—and shows good faith if challenged.
Classification quality assurance
Sample 10% of “minimal risk” tags quarterly. Look for employment, credit, biometric, education, or essential-service influence hidden in product copy. Reward finders of mis-tags; do not punish teams for honest past errors when they self-report.
Annex I vs Annex III program split
Annex I products live in existing product-safety worlds (devices, machinery). Their AI Act path intersects notified bodies and sector rules. Annex III stand-alone software often surprises pure SaaS firms. Staff differently: Annex I needs regulatory affairs veterans; Annex III needs digital product counsel plus rights impact skills.
Systemic-risk monitoring beyond FLOP
Compute is a presumption trigger, not the only story. Annex XIII criteria include users, modalities, and capabilities. A model under the FLOP line could still be designated. Track Commission decisions and scientific panel alerts via a watching brief.
Field Notes for Implementation Leads
Mis-tiering is usually social, not intellectual: teams fear high-risk labels because they fear delay. Leadership must reward accurate classification. Consider a metric: % of systems with classification refreshed in last 180 days.
Build a visual poster of Article 5 themes for product studios—not to replace legal review, but to trigger early escalation. Designers should recognize emotion inference and biometric categorisation cues in mockups.
For GPAI systemic risk, involve FinOps and infra teams: they see compute graphs first. A silent training run that crosses presumptive thresholds without compliance notification is an org-design bug.
Keep a “tier drift” log: feature flags that changed influence on people’s access to jobs, credit, education, or essential services. Drift logs feed the weekly clinic.
Worked Walkthrough: Feature Creep Re-Tier
Before. Helpdesk FAQ bot—transparency concerns; not high-risk.
Change. PM adds “auto-close ticket and deny refund under policy” action without legal review.
Detection. Classification clinic weekly review catches changelog.
Re-tier. Essential-services / consumer rights impact analysis escalated; possibly high-risk or at least heightened consumer-law risk; Article 5 manipulative-design screen run.
Manage. Feature flag off until oversight and documentation exist.
Tiering is a continuous control. Changelogs are classification inputs.
Synthesis for Busy Readers
Wrong tier costs more than slow engineering. Article 5 bans are live from 2 February 2025. Annex III and Annex I pathways create high-risk duties; Article 50 covers transparency; Chapter V covers GPAI, with Article 51’s 10^25 FLOP presumption for systemic risk. Use worksheets, weekly clinics, and drift logs when features gain decision power. Employment, credit, biometrics, and essential services are classic tripwires. Stack duties when GPAI sits inside high-risk systems. Paraphrases aid navigation; annex text controls.
Teaching Annex III with product archetypes
| Hiring ranker |
Employment |
| Exam proctoring AI |
Education |
| Credit scoring |
Essential services |
| Intrusion detection for energy grid |
Critical infrastructure |
| Border document checker |
Migration/border (specialist counsel) |
| Court scheduling optimization |
Justice admin (specialist counsel) |
| Face unlock for phone |
Biometrics (plus Art 5 screen) |
Archetypes accelerate triage; they do not replace annex reading.
Additional practice notes
Document decisions in writing when interpreting ambiguous guidance. Prefer conservative classifications when launch revenue does not justify uncertainty. Revisit decisions when Official Journal text, AI Office guidance, or agency FAQs change. Share anonymized lessons across business units to prevent repeated mistakes. Keep external counsel memos versioned beside engineering binders so the two sources of truth do not diverge. Schedule semi-annual tabletop exercises that combine legal date pressure with technical incident response—because real crises arrive entangled. Measure program health with leading indicators (inventory coverage, classification freshness, binder completeness) rather than lagging indicators alone (fines, headlines). Celebrate engineers who delay a launch for missing evidence; culture is the real QMS.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Change-control trigger list (re-classify when…)
Adding automated decisions affecting jobs, credit, education outcomes, or essential services
Enabling biometric identification or emotion inference
Turning a chatbot into an agent with write permissions
Rebranding or fine-tuning a third-party model as yours
Expanding from internal use to EU public offerings
Crossing frontier training scale that may implicate Article 51
Wire these triggers into release management checklists.
Tier decision record template
Date / Product / Version / Participants / Art5 result / Annex path / Art50 triggers / GPAI status / Outcome / Review-by / Sources consulted (OJ version). Store PDF in binder. Reject oral-only tier decisions for high-impact products.
Primary-source route: S06 European Union · S07 European Commission | Return to contents
Chapter 8: Obligations for High-Risk Systems
Risk management, data, documentation, transparency to users, human oversight, accuracy/robustness/cybersecurity, and QMS
Overview
Key point: If a system is high-risk under the AI Act, slogans end and engineering evidence begins. Providers face a stack commonly associated with Articles 8–15 themes: risk management, data and data governance, technical documentation, record-keeping, transparency to deployers, human oversight design, and accuracy/robustness/cybersecurity—plus quality management system expectations and conformity assessment pathways. Deployers have their own duties (instructions, oversight, monitoring, fundamental rights impact assessment in specified cases). Missing one pillar can sink conformity.
This chapter translates the stack into buildable workstreams. Always match article numbers to the consolidated regulation text for your counsel’s memo.
Learning Objectives
List the main provider obligation pillars for high-risk AI systems.
Explain why risk management is continuous, not a one-off PDF.
Specify data governance expectations in plain language.
Design human oversight that is meaningful, not theatrical.
Separate provider vs deployer obligation owners in a RACI.
Core Analysis
Provider pillars (practical bundle)
Risk management system. Identify, estimate, evaluate, and mitigate risks known and reasonably foreseeable across the lifecycle. Iterate when systems, data, or uses change. Feed incidents back into design. This pairs naturally with NIST Map/Measure/Manage—but legal requirements control.
Data and data governance. Training, validation, and testing data should be relevant, sufficiently representative, and as free as possible of errors for the purpose—with attention to bias that could affect health, safety, or fundamental rights. Document provenance and preparation choices.
Technical documentation. Enough for authorities to assess conformity: system design, intended purpose, interactions, data, metrics, oversight measures, etc. (see Annexes on documentation). Version it with the product.
Record-keeping / logs. Automatic recording of events to support traceability appropriate to the system—retention aligned to legal requirements.
Transparency and information to deployers. Instructions for use that enable deployers to meet their duties: capabilities, limitations, performance, human oversight measures, and maintenance.
Human oversight. Design measures so natural persons can understand, monitor, interpret, and intervene—including stop buttons where appropriate. Oversight must match residual risk.
Accuracy, robustness, cybersecurity. Declare metrics; achieve appropriate levels; manage feedback loops; secure against unauthorized alterations and adversarial attacks relevant to AI.
Quality management system (QMS). Policies and procedures integrating the above into organizational practice—not a parallel paper system.
Conformity assessment, CE marking logic where applicable, registration, and post-market monitoring complete the provider journey. Exact pathways depend on Annex I vs Annex III and whether notified-body involvement is required.
Deployer pillars (practical bundle)
Deployers must use systems per instructions; assign human oversight to competent people; ensure input data relevance where they control inputs; monitor operation and report serious incidents as required; keep logs under their control; and, for specified public-body and certain private deployers, conduct fundamental rights impact assessments before deploying certain high-risk systems.
Employers deploying workplace AI face worker information duties as specified. Credit and other essential-service contexts can trigger transparency to affected persons.
Building the evidence binder
| Risk management |
Risk register, mitigation proofs, review minutes |
| Data |
Datasheets, collection protocols, bias analyses |
| Documentation |
Technical file aligned to Annex requirements |
| Logs |
Logging design, retention schedule, sample extracts |
| Instructions |
Deployer guide, limitation statements |
| Oversight |
UX flows, training records for overseers, escalation SOPs |
| Performance/security |
Eval reports, pen tests, robustness studies |
| QMS |
Process map, internal audit, corrective actions |
| Post-market |
Monitoring plan, incident tickets, update records |
Meaningful human oversight (anti-theater rules)
Overseers understand failure modes and have time/UI to act.
They can override or stop without heroic effort.
They are not measured only on throughput that punishes overrides.
Automation bias is trained and tested.
“Click approve to continue” under a 2-second SLA is not oversight.
Integration with GDPR and FRIA
High-risk AI often processes personal data. Coordinate DPIA and FRIA-like analyses to avoid duplicate workshops with contradictory conclusions. One harm scenario workshop can feed both files if counsel structures it carefully.
Review-dependent notes
Article numbering for deployer obligations and FRIA sits around the mid-20s articles; confirm in your consolidated text before citation in contracts.
Application dates for high-risk obligations may differ for Annex I vs Annex III and may have been amended—see Chapter 11.
QMS does not require inventing a non-ISO system if ISO/IEC 42001 or existing ISO 9001 integration can be mapped—but mapping ≠ automatic conformity.
Illustrative case study
Hiring ranker documentation gap. A provider builds a CV-ranking high-risk system with strong model accuracy decks but weak instructions for deployers on known demographic performance gaps and required human review. A deployer treats outputs as final scores. Both parties face exposure: provider for inadequate transparency/oversight design; deployer for improper use and weak oversight assignment. Fixing the instructions and contractual oversight clauses is cheaper pre-launch than post-incident.
Practical Checklist
Open a high-risk evidence binder per system ID.
Appoint risk-management process owner and meeting cadence.
Create datasheets for training/validation/testing sets.
Draft deployer instructions including limitations and misuse examples.
Design oversight UX with stop/override; test with real staff.
Define accuracy metrics tied to intended purpose—not vanity leaderboards.
Run AI-relevant cybersecurity tests (model/data/tooling).
Map QMS procedures to each pillar.
Align DPIA/FRIA calendars with AI Act documentation.
Negotiate provider↔︎deployer RACI into the master services agreement.
Board Questions
For each high-risk system, where is the evidence binder?
Which deployer instructions would embarrass us if published?
Do overseers have practical authority to stop the system?
What bias and representativeness work exists beyond a single chart?
Who owns post-market monitoring metrics?
Are we prepared for conformity assessment timelines?
How do we handle a serious incident notification clock?
Is QMS real practice or a binder that only appears before audits?
Implementation sequence (180-day sketch)
Days 1–30: Confirm classification; freeze intended purpose; stand up binder; gap assessment vs pillars.
Days 31–90: Close data and risk-management gaps; draft instructions; design oversight; begin eval suite.
Days 91–150: Security/robustness testing; QMS procedure integration; deployer training materials; contract updates.
Days 151–180: Internal audit of binder; residual risk acceptance; monitoring go-live; readiness review with counsel.
Adjust to the legal application date that applies to your Annex path.
Vendor-heavy architectures
If a third-party model sits under your high-risk system, you still need documentation sufficient for your conformity story. Flow down evaluation rights, change notices, and incident cooperation. Dual-use of NIST AI 600-1 evals can help Measure, but EU documentation annexes set the legal bar.
Bridge
Chapter 9 turns to upstream GPAI duties that often feed these systems. Chapter 11 places the obligation stack on the calendar and explains penalty tiers.
Risk management system — operating rhythm
Weekly: new residual risks from feature changes.
Monthly: mitigation status; overdue actions.
Quarterly: full register review with deployer feedback and incident lessons.
On incident: extraordinary review within set SLA.
Minutes must capture decisions, not only attendance. Link each risk ID to Measure evidence and Manage treatments.
Data governance — practical minimums for high-risk
Written data requirements for the intended purpose
Source licenses and collection methods
Cleaning and labeling protocols
Representativeness analysis relative to affected populations
Bias risk analysis tied to fundamental rights harms
Versioned datasets with hashes
Retention and deletion rules
Access controls separating production from experimental data
If you cannot explain how a dataset was built, you are not ready for documentation annexes.
Technical documentation — anti-bloat tips
Authorities need navigability. Use a controlled table of contents mirroring Annex layout. Put model cards and eval reports as appendices with IDs. Avoid dumping entire Jupyter notebooks without narrative. Include known limitations prominently—hiding them is worse than disclosing them.
Logging design choices
Decide: what events, what identifiers, what retention, who can access, how integrity is protected. Over-logging personal data creates GDPR risk; under-logging destroys traceability. Document the tradeoff.
Human oversight training curriculum
Modules: system purpose; failure modes; automation bias; when to escalate; how to stop; recording rationale; discrimination red flags; privacy. Assess competence before assigning oversight duty. Refresh after major model changes.
Post-market monitoring metrics examples
Override rate and reasons
Performance by subgroup where lawful/appropriate
Drift alarms triggered
User complaints tagged AI
Serious incidents and near misses
Vendor model changes received
Tie metrics to risk register items.
Checklist before external assessment: binder complete; QMS internal audit done; residual risks accepted by authorized person; instructions validated with a real deployer pilot; cybersecurity findings closed or accepted; registration plan ready if required.
Instructions for use — content outline
Provider identity and contact
Intended purpose and forbidden uses
Performance characteristics and metrics methodology
Human oversight measures required
Known limitations and residual risks
Data expectations for inputs
Maintenance and update process
Incident reporting contacts
Logging and retention guidance for deployers
Version history
User-test instructions with a non-author employee. If they cannot oversee from the doc, rewrite.
Accuracy claims control
Every public or deployer-facing accuracy number needs: dataset description; date; version; confidence intervals or caveats; owner. Ban screenshot metrics from research blogs in sales decks without traceability.
Cybersecurity for AI-specific threats
Include: model theft; training-data poisoning; adversarial examples; prompt injection; supply-chain compromise of weights; insecure tool plugins. Classical AppSec remains necessary but insufficient.
Field Notes for Implementation Leads
Stand up a technical file editor role (can be part-time) who understands both Annex structure and engineering reality. Engineers write appendices; the editor ensures navigability and completeness.
Run a “deployer dry run”: give instructions to a sister team and watch them try to oversee the system. Record friction. Fix UX and docs before external deployers suffer.
For FRIA/DPIA coordination, use a shared harm workshop with privacy, rights, and product. Duplicate workshops produce contradictory residual-risk statements—an authority red flag.
Track supplier SLAs for eval evidence. If a model vendor cannot provide robustness and limitation data, your high-risk file will have a hole you own.
Worked Walkthrough: High-Risk Employment Assistant
Imagine a provider offers “RankCo,” an AI system that ranks applicants for customer hiring managers. Classification lands in Annex III employment territory. Here is how the obligation stack becomes work.
Week 1–2 — Freeze intended purpose. RankCo assists human shortlisting; it must not auto-reject without human review. Forbidden uses: emotional inference from video interviews; covert scraping of social media beyond candidate-supplied materials. Write this into instructions and product flags.
Week 3–6 — Data governance. Document training sources (licensed job/resume corpora; customer historical hiring data processed under contracts). Run representativeness analysis for roles and geographies sold. Measure error rates across demographic groups where lawful. Fix or restrict where gaps are severe.
Week 7–10 — Risk management & Measure. Risks: discriminatory ranking; opaque criteria; over-reliance by hurried recruiters; data leakage of candidate PII. Mitigations: feature constraints; explainability views for recruiters; mandatory human confirmation; encryption and access control; evaluation harness.
Week 11–14 — Oversight UX. Recruiter UI shows top factors, uncertainty cues, and a forced review checklist before advancing candidates. Training certification required for overseers. Throughput KPIs revised so overrides are not punished.
Week 15–18 — Documentation & QMS. Technical file assembled; deployer instructions user-tested; QMS procedures link change control to re-eval. Shadow deployment with one design partner.
Week 19–20 — Manage decision. Deploy with restrictions (no auto-reject; geo limits; monitoring dashboard). Residual risk accepted by named executive.
This walkthrough is pedagogical—not a conformity guarantee—but it shows why pillars must be staffed as a program, not as a weekend policy edit.
Synthesis for Busy Readers
High-risk means evidence: risk management, data governance, technical documentation, logs, deployer instructions, meaningful human oversight, accuracy/robustness/cybersecurity, and QMS—plus deployer duties and FRIA themes where required. Build binders per system ID. Test oversight against theater. Coordinate DPIA/FRIA. Sequence a 180-day close-the-gap plan toward your applicable date. Vendor models do not erase your documentation burden. Instructions must be usable by real deployers, not only authored by lawyers.
| Risk management system design |
A/R |
C |
| Use per instructions |
C |
A/R |
| Assign competent overseers |
C (design) |
A/R (staffing) |
| FRIA where required |
C |
A/R |
| Technical file |
A/R |
I |
| Serious incident notice |
R as specified |
R as specified |
| Input data relevance |
C |
A/R when controlling inputs |
RACI prevents mutual assumption that “the other party handles compliance.”
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Internal audit test ideas
Pick a high-risk system; locate the binder in <15 minutes.
Verify deployer instructions match the running software version.
Interview an overseer: can they stop the system?
Trace one risk register item to a Measure report.
Confirm QMS change records for the last model swap.
Failed tests become corrective actions with dates—not slideware.
Version pinning discipline
Every eval report and instruction set must pin model version, prompt templates, tool schemas, and dataset IDs. Unpinned evidence is non-evidence when incidents occur months later. Make pinning a pipeline requirement, not a documentation afterthought.
Primary-source route: S06 European Union · S08 European Commission | Return to contents
Chapter 9: GPAI and Foundation Model Governance
Transparency, copyright, systemic risk, codes of practice, and the AI Office
Overview
Key point: Foundation models concentrate capability—and compliance duty—upstream. The EU AI Act’s Chapter V creates obligations for providers of general-purpose AI models, with a second tier for models with systemic risk. If you train or substantially modify such models, or if you depend on them, GPAI rules shape your contracts, documentation, and evaluation budget. Codes of practice and the AI Office are part of the compliance pathway, not optional theater.
This chapter separates baseline Article 53-type duties from Article 55 systemic-risk duties, explains the Article 51 classification gate, and shows deployers how to diligence vendors.
Learning Objectives
Define GPAI model vs AI system in operational terms.
List baseline provider obligations (documentation, copyright policy, training-data summary).
Explain systemic-risk extras (evaluation, adversarial testing, incident reporting, cybersecurity).
Use codes of practice appropriately without treating them as law themselves.
Draft vendor diligence questions that expose GPAI gaps.
Core Analysis
Why GPAI gets its own chapter in the Act
High-risk rules target uses. GPAI rules target capability platforms that power many uses. Without upstream transparency, thousands of downstream providers cannot meet their own duties. Chapter V is the Act’s answer to foundation-model economics.
Classification gate (recap from Chapter 7)
Article 51 classifies systemic-risk GPAI via high-impact capabilities or Commission designation (Annex XIII criteria). Article 51(2) presumes high-impact capabilities above 10^25 training FLOP. Providers should monitor both compute class and designation decisions.
Notification and procedural duties accompany classification (see Article 52 area)—counsel should diary deadlines when a model crosses the line.
Baseline obligations for GPAI providers (Article 53 themes)
Plain-language bundle (confirm in text):
Technical documentation sufficient to understand capabilities/limitations and help downstream integrators—detail elements appear in annexes (e.g., Annex XI/XII themes in practitioner guides).
Copyright policy compliance processes for Union copyright law—especially regarding rights reservations and lawful access to training content.
Publicly available summary of training content at a meaningful level of detail (template expectations may be refined via implementing practice / Office guidance).
Cooperation with the AI Office and downstream providers as specified.
Open-source pathways may modulate some documentation duties under conditions—not a free pass for systemic-risk models. Read the conditions carefully.
Systemic-risk extras (Article 55 themes)
Providers of systemic-risk GPAI models face additional expectations commonly summarized as:
Model evaluation, including adversarial testing designed to identify systemic risks.
Assessment and mitigation of systemic risks along the lifecycle.
Tracking, documentation, and reporting of serious incidents.
Cybersecurity protection of the model and physical infrastructure as specified.
These map culturally to frontier-safety practices discussed at international summits (Chapter 15), but the AI Act makes them legal duties for classified models.
Codes of practice (Article 56)
Codes of practice are meant to help providers demonstrate compliance, especially during implementation windows. Adherence can be a practical pathway; it does not rewrite the statute. Track AI Office-endorsed codes and their updates. If you diverge, document equivalent measures.
AI Office interface
The European Commission’s AI Office is central for GPAI supervision themes: guidance, codes, systemic-risk oversight interfaces, and coordination. National authorities remain critical for many system-level issues. Know which door to knock on.
Downstream integrators and deployers
Even if you never train a frontier model:
You need documentation from the GPAI provider to build high-risk technical files.
Contracts should require update notices when systemic-risk status changes.
Fine-tuning may create provider obligations—analyze before you rebrand a model as yours.
Agent frameworks that wrap GPAI with tools can create new system-level classifications even when the base model is unchanged.
Copyright and training-data summaries — governance reality
Copyright policy is not a slogan. It needs process: source allowances, rights-reservation respect where required, complaint handling, and legal review of scrapers. Training summaries should be accurate enough to be useful without dumping trade secrets unlawfully—follow Office templates when issued.
Review-dependent notes
Exact annex numbers for documentation elements should be verified in your consolidation.
Codes of practice evolve; pin versions in compliance files.
Do not invent FLOP figures for competitor models; use vendor declarations and public designations.
Illustrative case study
Integrator blind spot. An EU scale-up builds a medical documentation assistant on a third-party GPAI API. It focuses on medical-device/AI Act high-risk analysis but never obtains GPAI documentation or copyright policy attestations from the upstream provider. Conformity stalls because the technical file cannot explain model limitations. Lesson: start upstream diligence the same week as clinical validation planning.
Practical Checklist
Inventory all GPAI models used or trained; record compute class if known.
Collect Article 53 artifact set from vendors (docs, copyright policy, training summary).
Determine Article 51 status; diary notification duties if you are the provider.
If systemic risk applies, fund evaluation + incident + cyber workstreams now.
Map fine-tunes that could flip you into provider status.
Track AI Office codes of practice; decide adhere vs equivalent measures.
Add GPAI change-notice clauses to MSAs.
Align copyright complaints process with content and legal teams.
Separate GPAI evidence binders from high-risk system binders, with cross-links.
Brief the board on upstream concentration risk (single-model dependency).
Board Questions
Which foundation models are single points of failure for our products?
Do we have written GPAI documentation from each upstream provider?
Could our fine-tunes make us a GPAI provider?
What is our systemic-risk posture if a model we train crosses 10^25 FLOP?
Who interfaces with the AI Office if contacted?
Is copyright policy operational or aspirational?
How fast will vendors notify us of designation changes?
Are codes of practice in our compliance calendar?
Evaluation program for systemic-risk candidates
Even before a formal designation, frontier providers should assume Article 55-class expectations:
Capability evaluations for dangerous assistance (cyber, bio coaching beyond public basics, autonomous replication themes as relevant).
Red-team exercises with independent challenge.
Documented mitigations and residual risk.
Serious incident definitions and 24/7 reporting paths.
Security controls for model weights, training pipelines, and insider threat.
NIST AI 600-1 risk categories can inform what to test; EU law informs whether you must and to whom you report.
Contract clause seeds (plain language)
Vendor represents whether the model is a GPAI model under Regulation 2024/1689.
Vendor states current systemic-risk classification/presumption status and updates within X days of change.
Vendor provides documentation and training summary sufficient for customer’s lawful compliance.
Vendor maintains a copyright policy addressing Union law requirements.
Vendor cooperates with serious incident investigations affecting customer deployments.
Customer’s fine-tune/rebrand rights clarified re: provider status.
Bridge
Chapter 11 places GPAI duties on the August 2025 application peg and explains penalty exposure under Articles 99 and 101.
Upstream concentration risk register
For each critical GPAI dependency record: vendor; model IDs; status under Article 51; documentation received (Y/N); exit options; fine-tune ownership; tool/agent wrappers; contractual notice period for safety changes. Review in the same meeting as cloud concentration risk.
Training-content summary — quality bar
A useful summary helps downstream parties and the public understand categories of sources (e.g., licensed, publicly available web, user data) without dumping proprietary scrapers wholesale. Follow AI Office templates when available. Avoid both opacity and chaotic data dumps.
Serious incident readiness for systemic-risk models
Define triggers (e.g., discovered dangerous capability emergence; large-scale malicious use campaign; major security breach of weights). Pre-write notification templates. Run a tabletop with legal, security, comms, and executive decision-makers. Diary Article 55 reporting expectations with counsel.
Codes of practice — governance choice memo
Write a one-page memo: which code version; adhere or equivalent; gaps; executive signer; review date. If you claim adherence publicly, internal reality must match—marketing cannot outrun engineering.
Fine-tune that flips provider status — warning signs
Releasing a renamed model under your trademark
Substantial modification altering capabilities
Offering the fine-tune as a service at scale
Marketing as your foundation model
Escalate early; budget for Chapter V artifacts before launch PR.
Research vs placement on the market
Research exemptions and open-source conditions are nuanced. Before assuming “research only,” ask counsel whether access patterns already constitute making available. Quiet internal forks sometimes become public APIs without a compliance gate.
Downstream documentation request letter (seed)
“Under our compliance program for Regulation (EU) 2024/1689, please provide: (a) confirmation whether [model] is a general-purpose AI model; (b) systemic-risk status under Article 51; (c) technical documentation sufficient for integrators; (d) copyright policy description; (e) public training-content summary; (f) notice commitment for status changes; (g) serious incident cooperation terms.”
Track responses. Missing packs block high-risk launches that depend on the model.
Safety evaluation public summaries
Frontier providers increasingly publish safety frameworks. Read them critically: what was tested; what was out of scope; what thresholds exist; what independent review occurred. Public summaries help deployers but do not replace contractual documentation rights.
Field Notes for Implementation Leads
GPAI compliance is a supply-chain sport. Add model providers to your critical-vendor list alongside cloud and payments. Require exit plans.
If you train models, create a threshold watch: projected FLOP, date of possible crossing, budget for Article 55 controls, executive decision meeting pre-scheduled. Do not discover thresholds retrospectively.
Copyright policy operations need a ticket queue with legal SLAs—not a PDF. Measure time-to-acknowledge rights complaints.
When using codes of practice, assign a control owner per code commitment. Orphan commitments become false statements.
Worked Walkthrough: Integrator Buying a Frontier API
Day 0. Product wants to launch an EU customer-support copilot on VendorX’s GPAI API with retrieval tools.
Day 1–3. Send documentation request letter (Chapter 9 seed). Parallel: Article 2 applicability yes; role likely deployer of system / not GPAI provider unless fine-tune/rebrand flips status.
Day 4–10. Vendor returns partial docs. Missing training summary and unclear Article 51 status. Escalate to procurement: “No launch without pack.”
Day 11–20. Vendor provides pack. Model not designated systemic-risk; compute class stated below presumption—or vendor states systemic-risk and shares evaluation summary. Copyright policy received.
Day 21–40. Build system-level Map/Measure: confabulation on policy answers; injection via retrieved tickets; PII leakage tests. Decide: retrieval-only; no arbitrary web tools.
Day 41–50. Contracts updated with change-notice and incident cooperation. Support runbooks include AI hallucination escalation.
Day 51. Launch limited beta in one Member State. Monitoring live.
Without the upstream pack, the project would still look “done” in engineering demos while failing documentation reality. GPAI governance is the difference.
Synthesis for Busy Readers
GPAI rules target upstream foundation models. Baseline duties center on documentation, copyright policy, and training-content summaries; systemic-risk models add evaluation, incident, and cyber expectations. Codes of practice and the AI Office shape pathways. Integrators must demand packs before launch; fine-tunes can flip provider status. Treat model vendors as critical suppliers with exit plans. Threshold watches prevent silent FLOP crossings. Chapter 9 pairs with Chapter 5’s eval methods and Chapter 11’s August 2025 peg.
Open-source GPAI — special diligence
Ask: license terms; published evals; known jailbreaks; who maintains weights; how updates ship; whether systemic-risk designation could apply to derivatives; whether your hosted API offering of an open model makes you the provider. Open weights reduce some barriers and create others—especially modification and redistribution. Document the analysis before enterprise support commitments.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Multi-model portfolio governance
Enterprises often use several GPAI vendors. Standardize: intake questionnaire; documentation escrow; status watch; eval minimums; concentration limits (e.g., no single vendor for >X% of critical workflows without exit drill). Portfolio governance prevents serial one-off deals that recreate the same compliance gaps.
Incident taxonomy starter for GPAI providers
Dangerous capability discovery in evals
Large-scale malicious use campaign enabled by the model
Weights or training pipeline compromise
Systemic bias incident with rights impact at scale
Copyright enforcement crisis tied to training policy failure
Pre-agree severity and notice clocks with counsel referencing Article 55 expectations.
Reader exercise
Write a one-page memo applying this chapter to a real product in your portfolio. Include: facts, primary-source cites, open questions for counsel, and three concrete next actions with owners and dates. If you cannot name a product, your inventory is the first action. Share the memo in the AI council packet; revise after feedback. Repeating this exercise quarterly turns handbook reading into operational muscle.
One thing to do this week
See also the Introduction’s three-layer model and Chapter 11’s myth-busting table when briefing executives.
Primary-source route: S06 European Union · S07 European Commission | Return to contents
Chapter 10: Enforcement Timeline and Penalties
Staged application dates, Omnibus adjustments, and fine tiers under Articles 99 and 101
Legal snapshot — 16 September 2026
The implementation calendar below follows the Commission’s current timeline. It does not resolve every legacy-system or model transition. Use the operative amended text for a binding classification or deadline determination. [S08][S09]
Overview
Key point: The AI Act has several application dates, not a single compliance deadline. Requirements already applicable must be distinguished from future high-risk milestones. Penalties have different statutory bands and qualifications; a published maximum is not an expected or automatic fine.
This chapter uses the Commission’s amendment-aware implementation timeline reviewed on 16 September 2026. It is a selective orientation, not a consolidated legal opinion or an exhaustive transition analysis. [S08][S09]
Learning Objectives
Recite the core staged dates: 1 Aug 2024; 2 Feb 2025; 2 Aug 2025; 2 Aug 2026; and high-risk dates applicable to your path.
Explain why high-risk dates may differ for Annex III vs Annex I after amendments.
Distinguish Article 99 penalty tiers and Article 101 GPAI fines at a plain level.
Build a compliance calendar with owners.
Avoid citing obsolete timelines from 2024 blogs.
Core Analysis
Original milestones and the amended implementation calendar
| 1 August 2024 |
AI Act entered into force. [S09] |
| 2 February 2025 |
Initial general provisions and prohibitions applied; subsequent amendments must be checked. [S09] |
| 2 August 2025 |
GPAI obligations and governance milestone, subject to applicable transitions. [S09] |
| 27 July 2026 |
AI Omnibus entered into force. [S08] |
| 2 August 2026 |
Article 50 transparency and enforcement milestone for applicable rules. [S09] |
| 2 December 2026 |
New specified synthetic-sexual-content prohibitions and transition for certain earlier systems under Article 50(2). [S09] |
| 2 August 2027 |
Member-State regulatory sandbox milestone. [S09] |
| 2 December 2027 |
Annex III high-risk application milestone. [S09] |
| 2 August 2028 |
Relevant Annex I product-related high-risk application milestone. [S09] |
The Commission reports that the AI Omnibus entered into force on 27 July 2026. Its updated timeline sets 2 December 2027 for Annex III high-risk rules and 2 August 2028 for relevant high-risk systems embedded in Annex I products. Earlier GPAI and transparency milestones remain separately relevant. The table above distinguishes those stages. [S08][S09]
Legal-text caution. The Omnibus changes more than dates: the Commission identifies amendments to literacy, registration, governance, and other provisions. Do not treat the original 2024 wording reproduced in an older source as consolidated law. Check the precise amendment, transition, and national implementation relevant to the deployment. [S08]
How to use dates operationally
Pin a controlled timeline memo with citations to Art. 113 and any amending regulation.
Separate workstreams for prohibitions, competence and literacy, GPAI, transparency, Annex III high-risk systems, and Annex I product-related systems. Record the operative provision, relevant transition, and accountable reviewer for each.
Do not delay Article 5 compliance because high-risk dates moved.
For each GPAI model, record when it was placed on the market and which transition provision applies; do not infer that one date resolves every legacy-model case.
Product roadmap gates should include “legal date risk” as a ship criterion.
Penalties — Article 99 tiers (plain map)
Article 99 sets administrative fines with tiers commonly summarized as:
Prohibited-practice band in the published Article 99 architecture: up to €35 million or 7% of worldwide annual turnover, subject to the applicable statutory comparison and enterprise-size rules. Confirm the amended text before calculation. [S06]
Middle tier: up to €15 million or 3% for various non-compliance with obligations as listed.
Lower tier: up to €7.5 million or 1% for supplying incorrect/misleading information to authorities as listed.
These are maximum bands, not an estimate of the fine in a particular case. The applicable infringement, enterprise classification, turnover rule, and enforcement circumstances require legal review. Use the operative amended Article 99 text rather than this summary for a calculation. [S06]
GPAI fines — Article 101
Separate fine architecture addresses GPAI model providers (commonly discussed with significant ceilings for non-compliance with Chapter V duties). Confirm amounts and bases in Article 101 of your consolidation. AI Office involvement is material for GPAI enforcement narratives.
Enforcement actors
National market surveillance / competent authorities for many system duties.
AI Office for GPAI-centered supervision themes.
Cooperation mechanisms across Member States.
Possible interaction with other regulators (data protection, consumer, sector).
Building a dated backlog
Fields: obligation ID; article; product; role; application date; owner; status; evidence link; residual risk if late.
Review monthly at the AI council. Escalate anything slipping inside 90 days of its application date.
Review-dependent claims
Omnibus changes: use the Commission’s current timeline for orientation and the operative amended legal text for a specific decision. [S08][S09]
Fine percentages: use statutory tiers; do not invent “average fine” statistics.
A future high-risk application date does not postpone every prohibition, GPAI duty, transparency rule, or obligation under other law. [S09]
Illustrative case study
Illustrative scenario. A deployer postpones all preparation after hearing that some high-risk dates moved. A separate transparency duty may already apply to its synthetic-content service. The response is an obligation-level register that records the actor, trigger, date, evidence, and reviewer—not a single organization-wide “AI compliance date.” [S09]
Practical Checklist
Maintain a controlled timeline memo with OJ citations.
Confirm Article 5 inventory screen is complete (live duty).
Confirm AI literacy program exists and is evidenced.
GPAI providers: Aug 2025 readiness review archived.
Transparency workstream funded for Art. 50 dates.
High-risk workstream dated per Annex path + amendments.
Penalty tier summary in board deck (without scare-fiction).
Authority contact tree tested (who answers the phone).
Ban obsolete 2024 timeline slides from sales decks.
Re-read consolidation each quarter for amendments.
Board Questions
What AI Act duties already bind us today?
Which products are on the critical path for the next application date?
Do we understand fine tiers—or only the “7%” headline?
Who owns the controlled timeline memo?
Are sales teams using outdated date claims?
What is our exposure if GPAI documentation is late?
How do Omnibus deferrals change budget—not ambition?
When did the board last see a dated compliance backlog?
Calendar template (example fields)
2025-02-02 | Art 4 literacy | All staff deploying AI | L&D+Legal | Evidence: course completion
2025-02-02 | Art 5 bans | Product red lines | Legal+Product | Evidence: screen log
2025-08-02 | GPAI Arts 51–56 | Model providers | Model gov | Evidence: binder
2026-08-02 | Art 50 transparency | Affected products | Product+Comms | Evidence: UX labels
High-risk date (verify) | Arts 8–15 etc. | High-risk SKUs | Compliance | Evidence: technical files
Interaction with contracts and insurance
Notify insurers of AI Act date risk if policies require. Update customer DPAs/MSAs with cooperation on incidents and authority requests. Avoid indemnity clauses you cannot price.
Bridge
Chapters 6–10 covered the EU stack. Chapters 11–12 shift to U.S. executive trajectory and state/federal conflict—different instruments, same need for dated owners.
Myth-busting timeline slide (replace in all decks)
| “Nothing until 2027” |
Arts 4–5 live Feb 2025; GPAI Aug 2025 |
| “Omnibus cancelled the Act” |
Adjustments to some dates ≠ repeal |
| “Open source is exempt from everything” |
Conditions apply; systemic-risk not free |
| “7% for any mistake” |
Tiers exist; read Art 99 lists |
| “Only providers are fined” |
Deployers have duties too |
Penalty governance — board education
Directors should understand: turnover base is worldwide for the undertakings rules as specified; groups structures matter; ability to pay arguments are not a plan; cooperation and compliance programs may influence authority discretion but are not a shield. Seek counsel for enterprise-specific exposure estimates—do not invent numbers in this handbook.
Authority engagement protocol
Single intake email/phone monitored.
Preserve evidence; issue legal hold.
Acknowledge receipt within internal SLA.
Counsel-led response; no informal engineer emails to authorities.
Parallel customer communication plan if products affected.
Post-engagement lessons into QMS.
Linking dates to engineering milestones
Example: if Art 50 labeling applies on a date, UX freezes two sprints prior; localization of disclosures completes one sprint prior; production verification gates the release train. Treat legal dates like dependency deadlines in the roadmap tool—not like footnotes in a PDF.
SME proportionality — still prepare
Smaller organizations may benefit from proportionate enforcement language, but Article 5 bans and literacy still apply. “We are small” does not authorize prohibited biometric scraping. Prioritize bans and high-impact uses first.
Program PERT-style dependencies
Literacy training → Article 5 screening → classification clinic → obligations backlog → evidence binders → conformity / registration → monitoring. Skipping early nodes creates rework. Omnibus date changes may relax the last nodes’ calendar without forgiving early nodes already live.
Financial provisioning discussion
Finance should discuss contingent operational costs (eval, documentation, labeling) as planned OPEX. Legal reserves for fines are a separate, counsel-driven topic—this handbook does not prescribe reserve amounts. Do not conflate “we budgeted compliance engineering” with “we expect to be fined.”
Field Notes for Implementation Leads
Put legal dates in the same roadmap tool as engineering dates with a distinct color. If product managers never see Art 50 or GPAI pegs beside feature pegs, date risk remains theoretical.
Run a quarterly “myth purge” of sales and customer-success decks for obsolete timelines. Wrong dates in customer hands create contractual and trust problems.
Practice an authority request drill: 48-hour document production for a sample system. Time the drill; fix bottlenecks (access to binders; encryption keys; vendor delays).
Explain fine tiers to executives with a simple pyramid graphic citing Article 99—no invented enforcement statistics required.
Worked Walkthrough: Building the Dated Backlog
Step 1 — Extract obligations. From classification worksheets, list each article-duty pair per product.
Step 2 — Attach dates. Use controlled timeline memo: literacy/bans; GPAI; transparency; high-risk Annex path dates per consolidation.
Step 3 — Owners. Each row needs a human, not a committee. Committees review; humans deliver.
Step 4 — Evidence links. Empty evidence columns are risks. Prefer URLs to binders over “TBD.”
Step 5 — RAG status. Red if <90 days and incomplete; amber if 90–180; green if evidenced.
Step 6 — Board extract. Top ten red/amber rows only. Directors cannot digest 200 rows.
Step 7 — Myth purge. After backlog exists, delete obsolete slides claiming “2027 only.”
Example rows (illustrative):
| L-01 |
Art 4 literacy |
All |
2025-02-02 |
L&D |
Green |
| B-04 |
Art 5 screen |
VisionSense |
2025-02-02 |
Legal |
Amber |
| G-02 |
Art 53 docs |
Model Orion |
2025-08-02 |
ModelGov |
Green |
| T-07 |
Art 50 label |
MediaForge |
2026-08-02 |
Product |
Red |
| H-12 |
Arts 9–15 file |
RankCo |
[verify] |
Compliance |
Amber |
Re-verify high-risk date cells whenever amendments publish.
Synthesis for Busy Readers
Implementation summary. Separate current prohibitions, GPAI and transparency duties from the updated Annex III and Annex I high-risk milestones. Confirm relevant transitions and amended literacy rules. Keep a dated legal register and an evidence owner for each applicable duty; penalty ceilings do not substitute for that analysis. [S06][S08][S09]
Communication templates (internal)
To product: “Feature X cannot ship before [date] without [artifact]. This is an AI Act application-date constraint, not a preference.”
To sales: “Do not quote 2027 as our only deadline. Bans/literacy and GPAI dates already bind relevant activities.”
To board: “Penalty headline is 7%/€35M for top-tier infringements under Article 99; our near-term operational risk is [specific product date].”
Templates reduce improvisation under pressure.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Relating penalties to product insurance and customer contracts
Discuss with brokers whether AI Act fines and defense costs have any coverage—and assume many will not. In customer contracts, avoid uncapped indemnities for regulatory fines where local law makes them fraught; allocate cooperation duties instead. Finance, legal, and risk must meet before sales invent unsustainable promises.
Dependency on standards timelines
Even when legal dates are fixed, missing harmonized standards can bottleneck conformity. Track standards delivery as a program risk with mitigations (alternative documentation strategies approved by counsel). Date risk ≠ standards risk, but both can block shipping.
One thing to do this week
See also the Introduction’s three-layer model and Chapter 11’s myth-busting table when briefing executives.
Primary-source route: S08 European Commission · S09 European Commission, AI Act Service Desk · S06 European Union | Return to contents
Part III — National and international regimes (Ch. 11–16)
Chapter 11: US Trajectory – From EO 14110 to Acceleration
EO 14110 → revocation by EO 14148 → EO 14179 and the subsequent action-plan process
Overview
Key point: US federal AI policy combines executive direction with agency action, legislation, state law, and sectoral supervision. EO 14148 revoked EO 14110 on 20 January 2025. EO 14179, issued three days later, directed an action plan and a review of earlier agency actions. A change in executive policy does not by itself determine the status of separate statutes or state requirements. [S10][S11]
The analysis below distinguishes an instrument’s stated objectives, its legal mechanism, and the practical questions it creates for organizations.
Learning Objectives
Date and summarize EO 14110’s purpose and major workstreams at a high level.
Distinguish the revocation made by EO 14148 from the action-plan and review directions in EO 14179.
Describe the Action Plan’s acceleration posture and implications for federal agencies.
Separate durable practice (NIST, private controls) from EO-contingent tasks.
Brief a board on U.S. federal volatility without freezing EU compliance work.
Core Analysis
EO 14110 — Safe, Secure, and Trustworthy AI (30 October 2023)
EO 14110 directed a broad federal agenda spanning safety and security (including standards work via NIST, dual-use/CBRN concerns, synthetic content authenticity), innovation and competition, workforce, equity and civil rights, consumer protection, privacy, federal government use of AI, and foreign policy/leadership themes. It catalyzed agency reports, OMB memoranda on federal AI use, and NIST’s generative profile work (AI 600-1).
Corporate impact while it was in force: Vendors selling to the federal government tracked OMB M-24-10 / M-24-18 themes; frontier labs engaged safety reporting expectations; civil-rights and employment AI drew agency attention; NIST guidance gained further prominence.
EO 14179 — Removing Barriers (23 January 2025)
EO 14179 followed the revocation of EO 14110 by EO 14148. It directed preparation of an AI Action Plan within 180 days and review of agency actions under the revoked order. Section 5 also directed review of specified OMB memoranda, subject to the order’s terms and applicable law. Read the operative provisions rather than inferring their effect from the title. [S10][S11]
Corporate impact: Federal procurement and agency AI governance expectations began shifting. International partners saw a U.S. tone change from “trustworthy AI governance” branding toward “acceleration and leadership.” Private-sector legal duties under statutes (civil rights, consumer protection, sector rules, state laws) did not vanish with the EO.
America’s AI Action Plan (July 2025)
The Action Plan—issued under the EO 14179 process—emphasized:
Reducing bureaucratic barriers to AI innovation and adoption.
Reviewing federal regulations that hinder AI.
Considering states’ AI regulatory climates in certain federal funding contexts—while claiming not to erase all state prudence.
Broader competitiveness, infrastructure, and security themes consistent with an acceleration agenda.
Read the Plan as policy direction for agencies, not as a substitute for statutes or as automatic preemption of state law (Chapter 12 addresses the later EO 14365 push).
What survived the churn (durable layer)
| NIST AI RMF 1.0 / AI 600-1 |
Voluntary technical frameworks; still useful evidence language |
| Sector regulators (FTC, FDA, CFPB, EEOC, etc.) |
Organic statutes remain |
| State AI laws |
Independent of federal EOs until validly preempted |
| EU AI Act for EU-facing products |
Unaffected by U.S. EO revocation |
| Tort, contract, IP litigation risk |
Continues |
What was EO-contingent (re-check after revocation)
Specific federal reporting programs created only by EO 14110 tasking.
Agency guidance expressly grounded in revoked EO authorities (review case by case).
Federal internal AI use rules tied to revised OMB memoranda.
Diplomatic talking points and voluntary commitments framed under the old EO.
Operating model for U.S. federal volatility
Dual track: Track EO/Action Plan changes in a “federal policy” lane; keep “enterprise AI risk” lane on NIST + inventory + evals.
Customer segmentation: Federal customers may impose contract clauses mirroring current administration priorities—version those questionnaires.
Do not pause EU work because U.S. tone softened.
Document why controls exist: “safety engineering / customer trust / EU law / state law,” not only “EO 14110 said so.”
Horizon scan quarterly for new EOs (Chapter 12’s EO 14365 is an example of continued executive activity).
Review-dependent notes
Agency-by-agency unwind status varies; verify before claiming a federal requirement is dead or alive.
Action Plan PDFs are policy documents—cite them as such, not as statutes.
Avoid invented “EO 14110 fine amounts”—EOs were not the EU penalty schedule.
Documented instrument example
Documented instrument example. The NIST generative-AI profile and the executive orders have separate publication histories. A change in the executive-order framework calls for an assessment of the particular control’s legal and operational basis; it does not establish that every associated technical practice must be abandoned. [S04][S05][S10][S11]
Practical Checklist
Record EO 14110 as revoked by EO 14148 on 20 January 2025; record EO 14179’s subsequent directions separately. [S10][S11]
Re-map federal customer obligations to current OMB/agency rules.
Keep NIST RMF/600-1 in the control library with non-EO justifications.
Brief board on acceleration policy vs enduring legal risks.
Segment questionnaires: federal vs commercial vs EU.
Assign owner for Action Plan / EO horizon scanning.
Review marketing claims that still cite EO 14110 as if binding.
Maintain EU timeline ownership independently of U.S. politics.
Check insurance disclosures for AI governance representations.
Update employee AI policies to remove obsolete EO references.
Board Questions
Which of our controls existed only because of EO 14110—and which remain justified?
What do federal customers require from us this quarter?
Are we incorrectly assuming deregulation means lower litigation risk?
How do we explain U.S./EU divergence to investors?
Who tracks new executive orders affecting AI?
Did we pause any eval programs during the policy transition?
Are OMB memo references in our federal playbooks current?
What acceleration opportunities are real vs hype for our sector?
Briefing note structure for directors (one page)
Then: EO 14110 trustworthy agenda (Oct 2023).
Now: EO 14179 revocation + Action Plan acceleration (2025).
Still binding: statutes, state laws, EU Act if in scope, contracts.
Our stance: durable RMF controls; dated federal tracker; no pause on EU.
Ask: approve continued funding for Measure/Manage despite political tone shift.
International signal risk
Allies and customers read U.S. EO churn as instability. Multinationals should avoid whipsawing global policy every time Washington changes tone. Keep a global baseline (OECD/UNESCO values + NIST method + local hard law overlays).
Bridge
Chapter 12 examines state AI laws—especially California’s transparency and training-data measures—and EO 14365’s national-framework push against state obstruction, including litigation and funding levers.
Agency unwind tracker (template fields)
Agency | Instrument (memo/rule/guidance) | EO 14110 origin? | Status under EO 14179 review | Residual obligation via statute? | Owner | Next check date
Update monthly for federal go-to-market teams.
Federal vs commercial customer messaging
Federal: mirror current administration questionnaires; avoid fighting political tone in RFP responses; emphasize security, competitiveness, and measurable performance.
Commercial: emphasize risk management, evaluation quality, EU readiness if relevant, and state-law compliance.
Global: keep OECD/NIST baseline stable.
Different decks; same underlying control system.
Workforce and civil rights continuity
EO revocation does not repeal Title VII, ADA, FCRA, ECOA, state FEHA analogues, or FTC Act Section 5. Hiring algorithms, credit models, and unfair/deceptive GenAI claims remain live risk. Acceleration narratives do not retire civil-rights testing.
Export controls and national security adjacency
U.S. trajectory includes national-security tools beyond EOs (export controls on advanced compute, inbound investment screening themes). Product and research leaders should keep a separate national-security compliance lane from “AI ethics” marketing.
Scenario planning for the next EO
Assume another swing is possible. Pre-commit: inventory and eval programs continue; only EO-specific reporting modules toggle. Write that pre-commitment into AI committee charter so future panic has a counter-document.
Timeline card for U.S. federal AI policy (executive layer)
| 2023-10-30 |
EO 14110 |
Broad trustworthy AI agenda |
| 2024-07-26 |
NIST AI 600-1 |
GenAI profile (EO-driven origin; lasting resource) |
| 2025-01-20 |
EO 14148 |
Revokes EO 14110 [S10] |
| 2025-01-23 |
EO 14179 |
Directs Action Plan and review after EO 14148 revocation |
| 2025-07 |
America’s AI Action Plan |
Deregulatory / leadership emphasis |
| 2025-12 |
EO 14365 |
National framework vs state obstruction themes |
Keep this card updated; retire obsolete employee FAQs.
What “acceleration” means for risk teams
Acceleration is not permission to skip evaluation. It is a political preference for fewer federal process hurdles. Risk teams should translate: remove non-value bureaucracy; keep Measure gates that prevent customer harm; document the distinction for auditors and boards.
Field Notes for Implementation Leads
Maintain two FAQs: employee-facing (“what changed with EO 14179?”) and customer-facing (“what still governs our AI?”). Update within two weeks of major federal moves.
Do not delete NIST-based controls during political transitions. Tag controls with justification codes: SAFETY, CUSTOMER, EU, STATE, FEDERAL_EO. Filters help you toggle EO-only tasks without burning the forest.
For federal sales, keep a living binder of current agency AI requirements. Version it. Old binders lose deals and create False Claims risk if you certify obsolete controls.
Worked Walkthrough: Surviving an EO Transition
Illustrative transition exercise. EO 14148 revokes EO 14110; EO 14179 directs the subsequent policy review. The program owner distinguishes duties that changed from controls retained for independent legal, contractual, or operational reasons. [S10][S11]
T+1 day. AI executive issues holding statement: enterprise RMF controls continue; federal tracker opens; no deletion of evals.
T+1 week. Filter control library by justification codes. EO-only reporting tasks paused pending agency unwind clarity. SAFETY/CUSTOMER/EU/STATE controls untouched.
T+1 month. Federal customer questionnaire updated to current administration language; commercial questionnaire unchanged except removed obsolete EO cites.
T+1 quarter. Board receives dual-track report: durable risk metrics (confabulation S3+, inventory coverage) vs federal policy watch items (OMB memo revisions; Action Plan impacts).
Outcome. No whiplash deletion; continued EU readiness; credible story to customers who feared politicized compliance.
The walkthrough’s lesson: pre-tag justifications before the next transition—because there will be one.
Synthesis for Busy Readers
Chapter synthesis. Separate EO 14148’s revocation from EO 14179’s policy-review process. Maintain an instrument-specific legal register and a reason for each control. Assess changes to federal requirements without assuming an automatic change to unrelated state, sectoral, or international duties. [S10][S11]
Comparing EO eras for control designers
| NIST RMF adoption |
Encouraged |
Still rational |
| Federal AI use memos |
Expanding |
Under revision |
| Safety reporting expectations |
Rising |
Recalibrating |
| State law posture |
Parallel growth |
Federal pushback rising (Ch 12) |
| EU compliance |
Independent |
Independent |
Designers should read the right column without deleting the left column’s useful engineering.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
Talent and org design through policy swings
Hire AI governance talent for durable skills (evaluation science, policy analysis, product counsel), not only for EO-specific filing experience. Job descriptions should cite NIST/EU/state competencies. During acceleration eras, keep these roles—cutting them is how organizations relearn painful lessons each cycle.
Investor Q&A cheat sheet
Q: Did the U.S. deregulate AI?
A: Federal executive priorities shifted toward acceleration; statutes and state laws remain; EU duties unchanged for in-scope products.
Q: Are you still investing in AI governance?
A: Yes—inventory, evaluation, and EU readiness are durable; EO-only tasks are toggled via justification tags.
One thing to do this week
See also the Introduction’s three-layer model and Chapter 11’s myth-busting table when briefing executives.
Primary-source route: S10 United States, Federal Register · S11 The White House · S04 NIST | Return to contents
Chapter 12: Federal Preemption and State Laws
EO 14365, California’s AI statutes, patchwork compliance, and litigation risk
Overview
Key point: State requirements and federal initiatives must be assessed separately. California’s enacted transparency measures differ from bills that were vetoed. The December 2025 executive order directs federal action concerning state AI laws, but a policy objective is not itself a determination that every state requirement is displaced. Track the actual instrument, effective date, implementing action, and any relevant court decision. [S12]
Learning Objectives
Explain why state AI laws proliferated.
Describe California exemplars (training-data transparency; AI transparency/synthetic content) at a plain level.
Note SB 1047’s veto as a policy signal, not as enacted law.
Summarize EO 14365’s tools (evaluation, funding conditions, FTC policy, legislative ask) without claiming completed preemption.
Design a state-patchwork compliance approach for product and counsel teams.
Core Analysis
The patchwork problem
States regulate what they can reach: employment tools, consumer disclosures, deepfakes in elections and intimate imagery, children’s protections, and generative-AI transparency. Multistate operators face inconsistent triggers, definitions of “AI,” and enforcement styles. Waiting for Congress has not frozen statehouses.
California exemplars (check statutes for operative dates)
Training-data transparency (AB 2013 lineage; Civil Code Title 15.2 themes). Developers of generative AI systems made available to Californians face documentation duties about data used to train systems/services (with staged deadlines in the statute—verify current operative text). This is a transparency duty, not a full EU-style high-risk regime.
California AI Transparency Act (SB 942 lineage; Business & Professions Code Chapter 25 themes). Covered providers face AI detection tool and disclosure/latent disclosure expectations for certain GenAI content, with operative timing (commonly cited as operative 2 August 2026 for core duties—confirm in code). Hosting and licensing flow-downs appear in the design.
Other 2024 California measures addressed deepfakes, digital replicas, and related issues across a multi-bill package. Treat California as a bundle, not a single act.
SB 1047 (Safe and Secure Innovation for Frontier Artificial Intelligence Models Act) was vetoed in 2024. It would have imposed frontier safety obligations (critical harm mitigation, evaluations, incident reporting themes). Veto ≠ permanent bar on future bills; it does mean SB 1047 is not current law. Do not cite it as binding.
Other states (illustrative, not exhaustive)
Colorado’s SB26-189, signed on 14 May 2026, repeals and reenacts the earlier framework with requirements for covered automated decision-making technology. The enacted summary identifies developer documentation duties starting 1 January 2027, together with notice, records, correction, and human-review provisions. Coverage and exceptions require separate review. Other state and municipal rules must still be mapped to the actual use; this chapter is not a fifty-state survey. [S13]
EO 14365 (December 2025) — national framework push
Executive Order 14365 (Ensuring a National Policy Framework for Artificial Intelligence, Federal Register publication mid-December 2025) directs actions such as:
A task force / referral pathway for challenging state AI laws viewed as unconstitutional or preempted.
Commerce evaluation of state AI laws, including those seen as compelling alteration of truthful outputs or problematic disclosures.
Potential conditioning of certain broadband/BEAD-related funding eligibility on state regulatory climate themes.
FCC consideration of conflicts with communications authority.
FTC policy statement work on unfair/deceptive practices and circumstances where state laws mandating alterations to truthful AI outputs may be preempted by federal deception law.
Preparation of legislative recommendations for a uniform federal framework with preemption features and discussed carveouts (e.g., child safety, data centers, state government use—per public summaries).
Critical board message: An EO can mobilize agencies and litigation strategy; it does not by itself erase duly enacted state statutes. Preemption outcomes will turn on statutes, court decisions, and possible future federal legislation. Plan for litigation noise and lingering state duties.
Compliance strategy under conflict
Inventory triggers by state for each product (CA transparency; employment tools; political deepfake rules).
Compare applicable disclosure requirements and identify a reusable technical baseline where the duties are compatible. Preserve differences in scope, recipients, and exceptions rather than assuming that one disclosure satisfies every jurisdiction.
Geo-fence only when necessary—and document why.
Track EO 14365 agency actions as they publish evaluations and policy statements.
Avoid public claims that “federal preemption means we ignore California.”
Align with EU Article 50 labeling where it also satisfies state transparency goals—one engineering change, multiple regimes.
Litigation and political risk
Litigation may affect the status of a particular requirement. Do not build a product decision on an assumed future court outcome. Record the currently operative position and design changes so they can be implemented without losing the decision history.
Review-dependent notes
State law operative dates change via amendments—verify on legislature sites.
EO section numbers and funding mechanisms should be confirmed from the Federal Register text when citing in filings.
Do not invent fine amounts for California AI bills without reading each statute’s penalty clause.
Illustrative case study
Illustrative comparison. A team tracking California AI law separates a vetoed bill from enacted transparency measures. It creates an obligation record only after checking enacted text and application dates. The example illustrates status control; it does not establish how companies allocated lobbying or implementation resources.
Practical Checklist
Build a state AI matrix for markets you serve (start CA, CO, NY/NYC, UT, TX as relevant).
Assign counsel owner per priority statute.
Implement GenAI training-data documentation plan for CA applicability.
Implement synthetic content disclosure/detection capabilities where SB 942-class rules apply.
Feature-flag disclosures for rapid jurisdictional changes.
Monitor EO 14365 agency deliverables (Commerce evaluation; FTC policy).
Align EU Art. 50 and CA transparency engineering where possible.
Update sales guidance: no “federally preempted, ignore states” claims.
Preserve evidence of compliance efforts if litigation subpoenas arrive.
Revisit matrix quarterly.
Board Questions
Which state AI laws already apply to our products in production?
Are we prepared for CA training-data and transparency duties on their operative dates?
What is our posture if EO 14365-driven challenges succeed—or fail?
Do we have feature flags for disclosure regimes?
Who owns the multi-state matrix?
Are we over-indexing on vetoed SB 1047 narratives?
How do state rules interact with our EU labeling roadmap?
What litigation holds or document-retention steps are active?
Practical patchwork architecture
Central policy: AI Acceptable Use + Transparency Standard (global baseline).
Annexes: State-specific deltas (CA docs URL; employment-tool audit rules; election deepfake bans).
Engineering: Content Credentials / latent disclosure capability; public training-data page generator; geo policy service.
Legal: Preemption watch memo monthly after EO 14365.
Comms: Holding statements that do not overclaim preemption.
Connections to the US and organizational chapters
Acceleration policy (Ch 11) plus preemption fights (Ch 12) can coexist with strict EU duties (Ch 6–10). Global firms should assume multi-regime operation through 2030, not imminent single rulebook.
Transition to national and operational approaches
Chapters 13–25 continue with China, UK, summits, institutions, ISO 42001, corporate governance, assessments, data, liability, audit, agents, sectors, and the 500-day program—practice layers that make patchwork survivable.
California implementation skeleton
Training-data transparency: identify covered generative systems; gather dataset category documentation; publish required web documentation by statutory deadlines; refresh on substantial modifications.
Transparency Act duties: build detection tool capability; manifest/latent disclosure options; contract flow-downs to licensees and hosts; calendar operative date.
Deepfake/political/intimate imagery rules: map product surfaces; add abuse reporting; legal review of generation tools.
Project-manage like a product launch, not like a memo.
Multi-state matrix columns
State | Statute | Trigger | Role caught | Operative date | Penalty cite | Product IDs | Status | Counsel owner
Start with states where you have users, employees, or servers. Expand as sales expands—not after a subpoena.
Watchful compliance — keep complying with state law; track agency evaluations.
Association litigation support — via trade groups if aligned.
Engineering flexibility — feature flags.
Public policy engagement — comment on federal legislative proposals carefully.
Avoid — shipping features that only work if preemption already succeeded.
Boards should pick explicitly; silence defaults to chaos.
Municipal and state employment-AI rules (bias audits, notices) often bite before comprehensive AI acts. HR tech vendors need a dedicated track. NYC Local Law 144 remains a cautionary tale for underestimating local law.
Documentation for adversarial settings
If you anticipate discovery in preemption or enforcement litigation, keep contemporaneous records of compliance efforts, classification analyses, and disclosure designs. Sloppy Slack jokes about “ignoring California” become exhibits. Train staff accordingly.
Incident: conflicting disclosure rules
Suppose EU Article 50 and a state law both require synthetic content disclosure but with different technical formats. Engineering should implement a flexible disclosure service (manifest text, metadata, watermark) configurable per jurisdiction. Legal maintains the rules table; engineering owns the switch. This is cheaper than forking the entire media pipeline per state.
When to geo-fence
Geo-fencing is appropriate when a feature is unlawful or high-risk in a jurisdiction and redesign is slow. It is a poor long-term substitute for transparent design when disclosure would suffice. Document geo-fence rationale to avoid accusations of evasive noncompliance.
Field Notes for Implementation Leads
Assign a “state AI law product owner” in engineering who implements disclosure switches, plus counsel who owns the rules table. Split ownership fails when both think the other ships the label.
Subscribe to legislative trackers for your top five states. Budget hours—not only outside counsel emergencies.
In board packs, show a heat map: states × products × operative dates. Heat maps beat prose for directing attention.
If EO 14365 evaluations name your sector’s practices, prepare a response memo before journalists call. Silence during preemption fights looks like unpreparedness even when your compliance is solid.
Worked Walkthrough: Shipping Disclosure Under Patchwork
Product. Image studio that generates marketing assets; users in CA, NY, EU.
Legal rules table. EU Art 50 synthetic disclosure; CA Transparency Act latent/manifest duties on operative dates; other state deepfake rules for political content (feature not offered).
Engineering. Implement content-credentials metadata + optional visible label + detection tool endpoint for covered provider duties. Config service maps user jurisdiction → disclosure mode.
Program dates. Calendar CA operative date and EU Art 50 date; freeze UI strings two sprints prior to each.
EO 14365 watch. Policy team tracks Commerce evaluation and FTC statement; no assumption that CA duties disappear. Feature flags remain.
Sales. Playbook forbids “federally preempted” claims. Offers “disclosure controls configurable by market.”
Result. One pipeline; multiple regimes; reversible if law changes. Patchwork becomes configuration, not chaos.
Synthesis for Busy Readers
State AI laws create patchwork; California’s signed transparency and training-data bills matter; vetoed SB 1047 is not law. EO 14365 (Dec 2025) mobilizes evaluation, funding, FTC policy, and legislative preemption asks—but does not itself erase state statutes. Comply, feature-flag, track litigation; never market “ignore states.” Align EU and CA disclosure engineering. Heat-map states × products × dates for the board. the later chapters will add other jurisdictions and management-system depth.
Discovery readiness checklist
Preserve classification memos and state-law matrices
Preserve disclosure design decisions and feature-flag configs
Train staff not to joke about “dodging California” in written channels
Align public policy statements with actual compliance posture
Track EO 14365 agency publications in the legal register
Litigation over preemption will dig into contemporaneous intent. Good compliance hygiene is also good litigation hygiene.
Handoff to the next chapter
Chapter output. Keep the decision, accountable owner, supporting evidence, and next review trigger in the shared governance register.
International companies touching U.S. states
If you are EU-headquartered but process Californians’ GenAI use, state transparency duties may still apply. Mirror the EU extraterritorial mindset: follow the user impact, not only the HQ address. Add U.S. state rows to the same matrix used for Member State AI Act surveillance authorities.
Policy scenario planning (three boxes)
Status quo patchwork — continue multi-state matrix.
Partial preemption — some disclosure/model rules preempted; child safety/etc. carveouts remain.
Failed preemption / state strengthening — more state bills; higher compliance load.
Build engineering for (1) with flags ready for (2) or (3). Do not bet the product on a single Supreme Court fantasy.
One thing to do this week
See also the Introduction’s three-layer model and Chapter 11’s myth-busting table when briefing executives.
Primary-source route: S12 The White House · S13 Colorado General Assembly | Return to contents
Chapter 13: China’s Algorithmic Governance
Recommendation algorithms (2021/2022), deep synthesis (2022/2023), and Interim Generative AI Measures (2023)
Later measures
The 2025 labelling measures took effect on 1 September 2025. The 2026 interim measures for human-like interactive AI services took effect on 15 July 2026. These introduce additional scope questions; a companion-style service should not automatically be treated as equivalent to every enterprise tool-using agent. English descriptions here are explanatory paraphrases of the Chinese texts. [S15][S16]
Overview
Key point: China’s AI governance uses several service-specific instruments rather than one universal filing rule. The chapter’s historical baseline covers recommendation algorithms, deep synthesis, and the 2023 Interim Measures for Generative AI Services. Public-facing scope and particular assessment or filing triggers matter. Later labelling and human-like interaction measures are noted below. [S14][S15][S16]
Learning Objectives
Name the three core instruments and their effective dates at a checkable level.
Explain why filing and assessment attach to services with public-opinion / social-mobilization attributes.
Distinguish recommendation-algorithm duties from deep-synthesis labeling and GenAI training-data duties.
Design a China-market compliance map for product, legal, and trust-and-safety teams.
Review before reliance filing counts and secondary “how many models” claims until verified on CAC announcements.
Core Analysis
Design logic: content order, user rights, and industrial policy together
China’s stack is not a carbon copy of the EU AI Act. It grew from internet information-service governance (Cybersecurity Law, Data Security Law, Personal Information Protection Law) and targets online services that rank, recommend, synthesize, or generate content at scale. Information integrity and social stability themes sit alongside consumer and labor protections (for example, algorithmic recommendation rules addressing excessive price discrimination and worker scheduling themes in public summaries). Boards should read the stack as sector-shaped internet regulation for AI-enabled services, not as a horizontal product-safety code alone.
Algorithmic Recommendation Provisions (effective 1 March 2022)
Public comparative sources describe issuance by CAC together with MIIT, MPS, and SAMR, with publication around early January 2022 and effectiveness 1 March 2022. Scope covers generation-synthesis, personalized push, ranking/selection, search-filtering, and scheduling-decision algorithms used in internet information services.
Operational themes for compliance teams (plain English):
| Algorithm registry / filing |
Creates a reusable filing pathway later reused by deep synthesis and GenAI rules |
| User controls |
Includes a strong user-facing expectation to turn off personalized recommendation (Article 17 themes in public explainers) |
| Fairness / anti-discrimination |
Limits certain manipulative commercial practices in recommendation |
| Labor / scheduling |
Scheduling-decision algorithms (delivery, ride-hailing themes) face governance expectations |
| Security / content |
Providers must manage illegal content risks and maintain management systems |
Board takeaway: If you operate recommendation, ranking, or dispatch AI for China-facing apps, you are in this regime even if you never ship a chatbot.
Deep Synthesis Provisions (effective 10 January 2023)
CAC published the Deep Synthesis Provisions on 11 December 2022, stating effectiveness from 10 January 2023, with MIIT and MPS concurrence. “Deep synthesis” covers generation-synthesis technologies producing text, images, audio, video, and virtual scenes (deep learning, virtual reality, and related techniques).
Core practice requirements (from official text themes):
Management systems for user registration, algorithm mechanism review, ethics review, information release review, data security, personal information protection, anti-fraud, and emergency response.
Training-data security and personal-information compliance when training data include personal information.
Regular review/assessment/validation of generation-synthesis algorithm mechanisms.
Labeling expectations for synthetic content (conspicuous labels are a defining feature in policy analyses).
Providers with public-opinion or social-mobilization capability must complete algorithm filing under the Algorithmic Recommendation Provisions pathway; technical supporters have parallel filing duties.
New products/apps/functions with those attributes require security assessment under national rules.
App stores must verify assessment/filing status before distribution.
Why this exists: Deepfakes and synthetic media risk—fraud, reputation harm, and information integrity—drove the instrument. Generative chat arrived almost immediately after finalization, which is why the 2023 GenAI Measures followed quickly.
Interim Generative AI Measures (effective 15 August 2023)
CAC published the Interim Measures on 13 July 2023 (text states deliberation 23 May 2023 and multi-ministry agreement), effective 15 August 2023. Scope focuses on generative AI services provided to the public inside China. R&D that does not provide services to the domestic public is treated differently in public explainers—confirm current administrative guidance for your fact pattern.
Provider duties (plain map):
Training data: lawful processing for pretraining and optimization; security and IP/personal-information compliance themes in Articles governing training activities.
Content and labeling: align with Deep Synthesis labeling for images/video and related outputs.
Security assessment + algorithm filing when the service has public-opinion or social-mobilization attributes (explicit cross-reference to Algorithmic Recommendation Provisions).
Supervision cooperation: explain training-data sources, scale, types, annotation rules, and algorithm mechanisms when authorities request.
Licensing / FDI: where other laws require permits, obtain them; foreign investment must follow FDI rules.
The Measures also encourage infrastructure, public training-data platforms, and international exchange—industrial policy language that sits beside control language. Do not read encouragement clauses as exemptions from filing.
Filing reality for operators
CAC maintains a public algorithm filing system (beian.cac.gov.cn per official notices). Deep-synthesis filings are announced in numbered batches. Generative AI “model filing / registration” practice for public-facing large models has become a distinct operational track in industry guidance (self-assessment reports, corpora rules, keyword intercept lists, test sets). Review before reliance: secondary articles cite cumulative GenAI filing/registration counts that change by batch and by whether they count “services” versus “apps/functions.” Prefer the latest CAC announcement over any fixed number in a handbook.
What global firms must decide
| China-user product with ranking + GenAI |
Full stack: recommendation + deep synthesis + GenAI Measures |
| API sold only outside China |
May fall outside “services to domestic public”—verify; partner localization can pull you back in |
| Joint venture / China cloud host |
Filing and assessment often sit with the China operating entity; contracts must allocate evidence duties |
| Open-weight model used by China partners |
Trace who is “provider” of the public service |
Open questions for counsel memos
Exact article-by-article English translations: use a verified translation (e.g., China Law Translate lineage) plus Chinese official text.
Filing counts and “how many models approved”: batch-dependent; do not freeze a single figure in board packs without a CAC cite and date.
Penalty ceilings: derive from Cybersecurity Law / related statutes and the Measures’ referral clauses—do not invent euro-style percentage fines.
Interaction with PIPL automated-decision rules: map separately; recommendation Provisions implement overlapping themes.
Comparison without cloning EU chapters
China leads with ex ante service filing and content controls. The EU AI Act leads with risk-tier product obligations and GPAI model duties. The UK leads with sector-regulator principles. A multinational needs all three maps if it ships everywhere. Interoperability is partial: labeling and documentation help everywhere; filing IDs are China-specific.
Lifecycle controls that actually get audited
Chinese regulators and platforms inspect process evidence, not only policies. Treat the following as a minimum operating system for any China-facing generative or recommendation product:
Corpus hygiene. Document lawful sources, licensed content, and personal-information handling for pretraining and fine-tuning. Keep annotation rulebooks that separate functional labels from safety labels.
Mechanism review. Periodically re-validate ranking, recommendation, or generation mechanisms when features change (new tools, new modalities, new social graph signals).
Release gates. Security assessment before public launch of covered services; change-control when “new products, apps, or functions” with public-opinion attributes go live.
Runtime content controls. Keyword and classifier intercepts, human review for high-risk categories, emergency takedown playbooks, and fraud/telecom-fraud cooperation themes where applicable.
User-facing controls. Recommendation opt-out where required; clear labeling of synthetic media; accessible channels for complaints.
Third-party and store diligence. Verify counterparties’ filing status; refuse silent redistribution of unfiled deep-synthesis apps through your store or SDK.
These six items map cleanly onto an ISO 42001-style Statement of Applicability later (Chapter 17), but ISO certification does not substitute for 备案.
How “public opinion / social mobilization” becomes a design constraint
The trigger phrase appears across Deep Synthesis and GenAI Measures. It is not a marketing slogan. Product managers should treat features that amplify reach, enable coordinated messaging, or shape public discourse—open social posting of model outputs, viral sharing defaults, influencer tooling, political or news-adjacent assistants—as high scrutiny. Private enterprise tools with closed user groups may still need analysis; do not self-exempt without counsel. When in doubt, document a written attribute analysis before launch and refresh it when distribution channels expand.
Contract patterns that survive diligence
China AI compliance fails in vendor contracts more often than in policy PDFs. Useful clauses:
Role allocation: who is the public-facing provider vs. technical supporter vs. API supplier.
Filing cooperation: timelines, bilingual document delivery, and audit support for CAC or local cyberspace administration requests.
Labeling flow-down: synthetic-content labels must survive remixing, API wrapping, and white-label skins.
Change notice: model swaps, corpus refreshes, and new modalities require re-assessment triggers.
Exit assistance: orderly de-filing / service wind-down if partnership ends.
Evidence escrow: store assessment reports and filing numbers where the board can retrieve them under privilege protocols.
Interaction with data localization and cross-border transfer
Generative services often pull prompts, logs, and embeddings across borders. China’s Data Security Law and PIPL cross-border transfer rules can bind the same launch that triggers GenAI Measures. Build a joint matrix: AI filing duties × personal-information transfer mechanism × critical-information-infrastructure overlays if applicable. Separating “AI team” from “privacy team” creates contradictory promises to regulators and customers.
Multinational playbook: one product, three annexes
A realistic handbook posture for a global assistant:
| China |
Filing, assessment, labeling, content security, recommendation opt-out |
| EU |
Risk tier / GPAI duties, Art. 50 transparency, technical documentation |
| US states |
Training-data transparency, synthetic disclosure, sector rules |
Shared engineering investments that pay twice: content credentials / visible labels, training-data category documentation, evaluation harnesses, and incident response. China-unique investments: 备案 ownership, Chinese-language safety corpora and intercept lists, offline assessment readiness.
Common failure modes
Shipping a global model card and calling it a China security assessment.
Assuming API-only distribution avoids provider duties when a China partner white-labels your model to the public.
Ignoring app-store takedown risk after a competitor’s filing appears in a CAC batch and yours does not.
Treating Deep Synthesis labeling as “video only” while shipping unlabeled synthetic images in ads.
Freezing an outdated “N models filed” statistic in an ESG report.
Metrics that are honest (and ones that are not)
Honest: percent of China-facing AI services with current filing where required; time-to-complete assessment packs; labeling defect rate in QA; number of change-triggered re-reviews.
Not honest: inventing maturity scores; claiming “full compliance” without entity-level evidence; citing unverified filing totals as proof of market leadership.
Review-dependent enforcement texture
Public reporting on administrative interviews, rectification orders, and app removals exists, but fine amounts and case facts vary and are easy to misstate in English secondary sources. For board risk heat maps, prefer qualitative severity (service suspension, store removal, criminal referral pathways under Cybersecurity Law for serious cases) unless counsel attaches a primary decision. This chapter deliberately omits invented penalty tables.
Worked example: labeling and filing calendar
Assume a China-facing short-video app adds AI filters that rewrite faces and generate voice-overs. Legal tags the filters as deep synthesis. Product must: (1) ship conspicuous labels before public release; (2) complete algorithm filing if public-opinion attributes apply; (3) run security assessment for the new function; (4) update training-data and mechanism-review records; (5) notify the app store with filing proofs. Marketing cannot A/B-test unlabeled synthetic ads “quietly.” The program manager owns a calendar with assessment submission, filing acknowledgment, store resubmission, and post-launch monitoring. This is product operations, not a one-time legal memo.
Coordination with export-control and national-security overlays
Some model weights, chips, and technical services sit under export-control or national-security review regimes outside the CAC stack. Keep a separate track so AI filing work does not accidentally create conflicting statements in export questionnaires. Review before reliance specific control-list classifications; escalate to trade counsel.
Evidence pack template for China GenAI launch
Create a bilingual binder (Chinese primary for authorities; English for global board):
Service description and user geography
Public-opinion / social-mobilization attribute memo
Algorithm filing forms and acknowledgment
Security self-assessment report
Training-data source and annotation rule summary
Keyword/intercept list version hash
Labeling UX specification and screenshots
Emergency response and complaint handling SOP
App-store correspondence
Change log linking model versions to re-assessment triggers
Store under legal hold protocols. Refresh hashes when corpora or intercept lists change. This pack is what turns “we take compliance seriously” into something an authority or partner can inspect.
Illustrative case study
A global consumer app adds an in-feed generative assistant for China users. Product wants EU Art. 50-style watermarking only. Counsel maps: (1) recommendation Provisions if the feed ranks/personalizes; (2) Deep Synthesis labeling and mechanism review for synthetic media; (3) GenAI Interim Measures for public generative service—security assessment and algorithm filing if public-opinion attributes apply; (4) app-store verification of filing status. The launch plan adds a China entity owner for 备案, a bilingual evidence pack (training-data categories, intercept lists, labeling UX), and a kill-switch if assessment fails. Lesson: EU labeling is necessary but not sufficient for China public GenAI.
Practical Checklist
Inventory China-facing AI: recommenders, deep synthesis, GenAI chat, scheduling algorithms.
Identify the China legal entity responsible for filing and assessment.
Confirm whether services have public-opinion / social-mobilization attributes (document the analysis).
Build labeling UX for synthetic text/image/audio/video consistent with Deep Synthesis + GenAI Measures.
Prepare training-data legality and security evidence (categories, sources, annotation rules).
Complete algorithm filing via the CAC system when required; display filing number where mandated.
Align app-store submission packs with assessment/filing proofs.
Contract flow-downs for APIs, fine-tunes, and technical supporters.
Review before reliance any public filing-count KPIs; cite CAC batch notices if used.
Refresh the map after each new CAC batch notice or measure amendment.
Board Questions
Which of our products serve the Chinese public with generative or recommendation AI today?
Who is the accountable China entity for 备案 and security assessment?
Are synthetic-content labels shipped and tested in Chinese UX?
Do contracts with China hosts and app stores allocate filing evidence duties?
Are we citing stale filing-count figures in investor materials?
How do China duties interact with our EU Art. 50 and US state transparency roadmaps?
What is our exit plan if assessment is refused or revoked?
Have we briefed the board on PIPL automated-decision overlap?
Operator architecture sketch
Policy: China AI Service Annex (separate from EU AI Act annex).
Owners: China counsel + Trust & Safety + Product.
Evidence vault: filing certificates, assessment reports, labeling screenshots, training-data memos, intercept-list change logs.
Monitoring: CAC batch announcements; Deep Synthesis / GenAI amendment watch.
Escalation: public-opinion attribute change (new social features) triggers re-assessment.
Bridge
Chapter 14 contrasts the UK’s non-statutory principles model. Chapter 15 places China’s participation in summit diplomacy beside domestic hard law. Practice chapters later show how ISO 42001 documentation can support—but not replace—China filing packs.
Primary-source route: S14 Cyberspace Administration of China · S15 Cyberspace Administration of China · S16 Cyberspace Administration of China | Return to contents
Chapter 14: UK Pro-Innovation Model
March 2023 White Paper, five principles, sector regulators, and the February 2024 response path
Historical policy baseline
The White Paper and government response explain the 2023–2024 approach. They are not an exhaustive statement of UK law or later developments. Use current legislation and sector-regulator material for a deployment decision. [S17]
Overview
Key point: The United Kingdom chose not to pass an EU-style horizontal AI Act. The March 2023 White Paper A pro-innovation approach to AI regulation set five cross-sector principles for existing regulators to apply in context: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; and contestability and redress. Principles began on a non-statutory footing. The government promised central support functions, regulator guidance, and a later option to place a “have due regard” duty in statute when parliamentary time allows. For boards, the UK is a multi-regulator compliance problem (FCA, ICO, Ofcom, MHRA, Equality and Human Rights Commission, and others)—not a single AI agency filing.
Learning Objectives
State the five White Paper principles in plain language.
Explain why a context-specific, regulator-led model differs from the EU AI Act’s risk tiers.
Identify how sector regulators become the primary AI interlocutors in the UK.
Map UK principles to NIST / ISO vocabulary without claiming equivalence.
Review before reliance statutory “due regard” timing until primary legislation appears.
Core Analysis
Why “pro-innovation” is a design choice, not a slogan
The White Paper (published March 2023 under the 2022–2024 Conservative government) argues that rigid, premature horizontal rules could freeze innovation and age poorly as capabilities change. The framework’s self-described characteristics include pro-innovation, proportionate, trustworthy, adaptable, clear, and collaborative. Four structural elements matter:
Define AI by distinctive characteristics to help regulators coordinate (adaptivity, autonomy themes)—without pretending one perfect definition ends debate.
Context-specific regulation—risk depends on use, sector, and affected people.
Five cross-sector principles as a shared vocabulary.
Central functions to support coherence (monitoring, horizon scanning, supporting innovation, facilitating interoperability).
Initially, principles are not hard law. Regulators interpret them inside existing remits (financial conduct, data protection, online safety, medical devices, equality law). That is both the UK’s flexibility and its coordination risk.
The five principles (board card)
| Safety, security & robustness |
Systems behave safely under expected and adversarial conditions |
Threat models, red-team notes, reliability tests |
| Appropriate transparency & explainability |
People know when AI is used and can get suitable explanations |
User notices, model docs, decision narratives scaled to risk |
| Fairness |
Comply with equality and data-protection law; avoid unfair outcomes |
Bias tests, Equality Act analysis, DPIAs |
| Accountability & governance |
Clear ownership of outcomes |
RACI, board reports, vendor clauses |
| Contestability & redress |
Routes to challenge harmful AI-influenced outcomes |
Appeals, human review, complaint SLAs |
“Appropriate” and “context-specific” are load-bearing words. A chatbot FAQ needs different explainability than a credit decision. Copy-pasting EU high-risk technical documentation into every UK use case wastes money; ignoring FCA or ICO expectations because “the UK has no AI Act” creates enforcement risk under existing law.
Sector regulators as the real AI Act
Expect AI issues to arrive through familiar doors:
FCA / PRA: model risk, consumer duty, operational resilience, financial promotions with AI content.
ICO: UK GDPR automated decision-making, fairness, transparency, DPIAs.
Ofcom: online safety and media-adjacent AI uses as remits evolve.
MHRA: AI as medical device / software pathways.
EHRC / employment regulators: discrimination risk in hiring and workplace tools.
CMA: competition and consumer-protection angles around foundation-model markets (monitor evolving market studies).
Your UK AI program should therefore be a router: inventory use cases → map regulator → map principle → map control owner. A single “AI compliance officer” without sector counterparts will miss fines that never say “AI Act” on the cover sheet.
February 2024 government response and implementation guidance
Following consultation, the government published a response and continued implementation work in 2024, including guidance for regulators on implementing the principles. Public guidance emphasizes that principles remain voluntary for regulators to interpret within discretion, especially for technology-agnostic regimes that already cover AI-related harms. Treat “Feb 2024 response” as a policy continuation milestone, not as enactment of a UK AI Act. Review before reliance any claim that a statutory duty already binds all regulators until you cite the Act of Parliament that creates it.
Central functions and the coordination problem
The White Paper’s central functions aim to reduce fragmentation: shared risk analysis, support for innovators (including sandboxes where appropriate), and international engagement. In practice, firms still face multi-letter inquiries. Build a UK regulatory relationship map and a single narrative pack that can be retargeted: system description, data flows, human oversight, testing, incident history, and principle-by-principle controls.
Comparison with EU, US, and China (short, non-cloned)
| UK |
Principles via sector regulators; existing law |
Map use cases to regulators; evidence principles |
| EU |
Horizontal AI Act + GPAI + PLD |
Classify risk; technical files; CE/conformity themes |
| US |
EO + agencies + states |
Patchwork + federal acceleration/preemption fights |
| China |
Service filing / assessment / labeling |
备案 and content security for public services |
Interoperability tip: NIST AI RMF Govern/Map/Measure/Manage and ISO/IEC 42001 produce artifacts UK regulators understand even without mandating those standards.
What “proportionate” means in budget terms
Proportionate does not mean “do nothing until harm.” It means scale documentation and testing to impact. A marketing copy assistant and a loan-decisioning model should not share the same assurance budget. Write tiering rules inside your UK annex: Tier A (regulated decisions / safety-critical), Tier B (customer-facing GenAI with brand risk), Tier C (internal productivity). Attach principle evidence expectations to each tier.
Open questions
Timing of any future statutory “due regard” duty.
Exact machinery of government after elections—regulator remits can be reshuffled; principles language has shown continuity themes but verify current GOV.UK pages.
Do not invent UK AI Act fine percentages analogous to EU Article 99.
Building a UK evidence pack (reusable)
Use-case register with regulator tags.
Principle control matrix (five rows × control columns).
DPIA / equality impact assessments where triggered.
Consumer-duty / fairness testing summaries for financial services.
Transparency UX screenshots and explanation templates.
Contestability playbooks (who reviews, SLA, remediation).
Vendor questionnaires aligned to principles, not only to EU Annex IV.
Failure modes unique to the UK model
Waiting for a horizontal statute while ICO or FCA enforces today.
Assuming “pro-innovation” equals permission for dark-pattern personalization.
Running separate AI ethics theater disconnected from regulated-firm SMCR-style accountability.
Over-producing EU Annex-style files for low-risk UK tools while under-producing contestability routes.
Mapping principles to familiar control families
Boards already fund cybersecurity, model risk, privacy, and conduct programs. The White Paper is clearest when treated as a translation layer:
| Safety/security/robustness |
Secure SDLC, operational resilience |
Prompt injection, model theft, evals for catastrophic misuse where relevant |
| Transparency/explainability |
Customer communications |
AI-use notices; explanation depth matched to impact |
| Fairness |
Conduct + equality compliance |
Dataset and outcome testing for AI features |
| Accountability/governance |
Senior manager regimes / GRC |
Named owners for models and GenAI tools |
| Contestability/redress |
Complaints handling |
Human review triggers when AI materially affects outcomes |
If your firm is dual-regulated (e.g., bank with EU branches), keep a delta register: UK principle evidence vs. EU AI Act articles vs. US state disclosures. Do not maintain three unrelated PowerPoints.
International interoperability without pretending unity
UK policymakers repeatedly stress interoperability with OECD principles, G7 Hiroshima Process themes, and partner jurisdictions. That helps multinational documentation strategy: OECD vocabulary in contracts, NIST functions in engineering, ISO 42001 for management-system audits, and UK principle matrices for domestic regulators. Still, interoperability is not mutual recognition. A UK principle pack will not clear EU high-risk conformity assessment.
Practical operating rhythm
Quarterly: refresh use-case register and regulator tags.
Semiannual: principle-effectiveness review (incidents, complaints, audit findings).
On material model change: re-run Tier A fairness and robustness tests.
On GOV.UK policy update: counsel delta memo within 10 business days.
Review-dependent political note
UK AI institutional arrangements (central units, safety institute relationships, industrial strategy branding) evolve with administrations. Cite current departmental pages when naming units. This chapter anchors on the March 2023 White Paper principles, which remain the clearest public statement of the domestic regulatory philosophy for practitioner planning.
Worked example: multi-regulator narrative
A UK insurer uses GenAI to draft claim summaries for human adjusters and a separate ML model to prioritize investigations. ICO cares about personal data in prompts and logs. FCA cares about customer outcomes, outsourcing, and operational resilience. The firm prepares one system description with two annexes: privacy (lawful basis, retention, DPIA) and conduct (fairness testing, human decision authority, complaint pathways). Controllers answer both regulators from the same inventory ID. That is the White Paper working as intended: context first, shared facts, different emphasis.
SME and startup posture
Smaller firms rarely staff an AI governance office. Minimum viable UK posture: inventory; tiering; principle checklist; DPIA when required; human review for material decisions; vendor due diligence. Buy ISO 42001 consulting only when customer RFPs demand it—not as a substitute for ICO basics.
Procurement and public-sector spillover
Even private firms feel UK public-sector AI expectations through tenders: algorithmic transparency questions, fairness assurances, and human-oversight commitments. Treat major public RFPs as de facto regulation. Keep a reusable answer library aligned to the five principles.
Skills and accountability
Principles fail without named humans. Require each Tier A system to list: executive sponsor, model owner, data owner, and appeal owner. Tie into existing senior-manager accountability cultures in financial services where they already exist. Outside financial services, invent the same clarity without waiting for identical statutes.
Measuring whether the UK approach is working for your firm
Useful internal indicators: regulator inquiry response time; percentage of Tier A systems with current fairness tests; complaint overturn rates involving AI; number of use cases lacking a regulator tag; employee reporting of shadow AI tools. Avoid vanity metrics such as “number of ethics workshops.”
Cross-border product planning from a UK base
Many UK firms ship to the EU. Keep a dual-track calendar: UK principle evidence continuous; EU AI Act staged obligations as applicable. A UK-only program that ignores EU deployer/provider roles will fail first enterprise procurement outside Britain. Conversely, EU technical documentation can be summarized into UK principle language for domestic regulators—summarize, do not dump.
Principle deep-dive: contestability that customers can find
Contestability fails when it exists only in policy. Publish in-product links to human review for material decisions; train contact-center staff to recognize AI-involved outcomes; measure time-to-resolution; report patterns to the accountable executive. If customers cannot find the path, you do not meet the spirit of the fifth principle—even if a regulator has not yet written AI-specific guidance.
Principle deep-dive: transparency without dumping weights
“Appropriate” transparency rarely means publishing model weights. It usually means: disclose AI involvement; explain factors at a suitable level; provide documentation to regulators on request; avoid deceptive anthropomorphism. Match depth to harm. A product recommender and a benefits-eligibility tool should not share identical explanation templates.
You do not need a bespoke “UK AI Act platform.” You need: an inventory database; policy + principle matrix; link-outs to DPIAs and fairness tests; complaint tags for AI involvement; vendor records; and a regulator correspondence log. Spreadsheet plus disciplined owners beats unused GRC software. Upgrade tools when inventory exceeds what sheets can safely manage.
Conduct and consumer-duty interactions (financial services)
For FCA-regulated firms, AI features sit inside Consumer Duty outcome tests: products and services, price and value, consumer understanding, and consumer support. GenAI that confuses customers, buries fees, or steers vulnerable consumers poorly is a conduct problem first. Frame AI controls as duty evidence. That vocabulary lands better with UK boards than abstract ethics principles alone.
Equality Act practicality
Fairness principle implementation should include: identify protected characteristics relevant to the use case; choose testing methods proportionate to data availability; document limitations; decide human review thresholds; and record residual risk acceptance. Perfect demographic data is rare—document the limitation rather than fabricating certainty.
Sandboxes and live testing
Where regulators offer sandboxes or innovation pathways, use them for novel high-impact uses—not as a PR tour. Enter with clear test plans, consumer safeguards, and exit criteria. Review before reliance any assumption that sandbox participation creates a permanent license.
Detailed operating model for multi-regulator firms
Create a living register with columns: use-case ID; description; business owner; AI techniques; personal data (Y/N); customer impact (high/med/low); primary UK regulator; secondary regulators; principle controls linked; assessment IDs; last review date; next review date. Require updates before production changes. Export a monthly PDF for the Executive AI Council. When FCA, ICO, or another regulator asks a question, answer from the register—do not invent a parallel spreadsheet under stress.
For groups with EU subsidiaries, add columns for EU AI Act role (provider/deployer), risk tier hypothesis, and GPAI dependency. The UK White Paper’s flexibility is valuable only if you keep the map current. Stale maps create confident wrong answers.
Train first-line staff with short modules: what counts as AI in our policy; when to escalate; how to record AI involvement in complaints. Contestability collapses when frontline teams do not know an AI system influenced the outcome.
Illustrative case study
A UK bank deploys a GenAI assistant for relationship managers and a separate model feature in retail credit decision support. The assistant is Tier B: transparency to staff, logging, hallucination controls, and ICO-minded personal-data handling. The credit feature is Tier A: FCA model-risk expectations, fairness testing, clear human accountability, and customer contestability through existing credit decision appeal paths reframed for AI assistance. One “AI Council” owns both, but evidence packs differ. Lesson: the White Paper rewards context—identical chat technology can demand unequal controls.
Practical Checklist
Publish an internal UK AI annex listing the five principles.
Tag every AI use case with primary/secondary UK regulators.
Define Tier A/B/C assurance depth.
Ensure contestability routes exist for customer-affecting AI.
Align ICO DPIA triggers with AI inventory.
Brief sector risk committees (not only a tech ethics forum).
Track GOV.UK updates on regulator guidance and any statutory proposals.
Reuse NIST/ISO artifacts in UK regulator language.
Avoid marketing claims of “UK AI Act compliant.”
Review before reliance statutory duty timelines in board decks.
Board Questions
Which UK regulators already touch our AI use cases?
Do we have contestability paths for AI-influenced customer outcomes?
Is our fairness testing driven by Equality Act / UK GDPR duties or by slides alone?
Who owns the UK principle matrix?
Are we over-building EU files and under-building UK redress?
How do we brief the board if a statutory “due regard” duty arrives?
What sandbox or innovation engagement is worth the cost?
How does UK posture interact with EU exports of the same product?
Bridge
Chapter 15 moves from national models to summit diplomacy (Bletchley, Seoul, Paris). UK hosting of Bletchley shaped frontier-safety politics even while domestic regulation stayed principle-led—an important dual track for boards watching both reputation and law.
Primary-source route: S17 UK Government | Return to contents
Chapter 15: Global Summit Process – Bletchley, Seoul, Paris
Frontier safety diplomacy from November 2023 through the February 2025 AI Action Summit
Overview
Key point: Between late 2023 and early 2025, governments and frontier developers turned AI safety into a summit track: Bletchley Park (1–2 November 2023), Seoul (21–22 May 2024), and Paris (10–11 February 2025). The track produced the Bletchley Declaration among states, voluntary Frontier AI Safety Commitments by leading companies at Seoul (initially 16 signatories, later expanded on GOV.UK), and a Paris Action Summit agenda that widened from catastrophic-risk talk toward inclusive, sustainable, public-interest AI. Soft law does not replace the EU AI Act or China’s filing rules—but it shapes investor expectations, safety-framework publication norms, and the politics of “intolerable risk” thresholds.
Learning Objectives
Sequence Bletchley → Seoul → Paris with checkable dates.
Distinguish state declarations from company Frontier AI Safety Commitments.
Explain what “intolerable risk” thresholds mean as voluntary corporate policy.
Review before reliance unverified survey statistics and non-primary “AAL” schemes.
Decide what summit outputs belong in board reporting versus legal compliance files.
Core Analysis
Bletchley Park AI Safety Summit (1–2 November 2023)
The United Kingdom hosted the first AI Safety Summit at Bletchley Park. Attending countries issued the Bletchley Declaration, stressing international cooperation on AI safety—especially frontier AI risks—while recognizing pro-innovation and proportionate governance approaches and the usefulness of risk classification where appropriate. The Declaration is political soft law: it coordinates agendas and legitimizes safety-institute science; it does not itself fine your company.
Board-relevant outcomes: shared language on frontier risk; momentum for scientific reports on advanced AI safety; expectation that states would meet again in 2024. New Zealand later joined the Bletchley Declaration commitment (GOV.UK notes 23 October 2024)—a reminder that summit clubs expand after the photo.
Seoul AI Summit (21–22 May 2024)
Co-hosted themes by the UK and Republic of Korea moved from state declaration to company commitments. On 21 May 2024, governments announced that 16 AI companies agreed to the Frontier AI Safety Commitments. GOV.UK lists the initial cohort including Amazon, Anthropic, Cohere, Google, G42, IBM, Inflection AI, Meta, Microsoft, Mistral AI, Naver, OpenAI, Samsung Electronics, Technology Innovation Institute, xAI, and Zhipu.ai. Later updates added further organisations (GOV.UK update 7 February 2025 notes additions such as Magic, Minimax, 01.ai, and NVIDIA—verify the live page for the current list).
Commitment substance (voluntary, plain English):
Assess severe risks across the frontier AI lifecycle.
Define thresholds at which severe risks, unless adequately mitigated, would be deemed intolerable; monitor proximity to breach; explain how thresholds were set, with examples.
Identify and implement mitigations to keep risks below thresholds.
If residual risk cannot be kept below thresholds, do not develop or deploy the model/system.
Invest in safety evaluation capacity; involve external trusted actors including home governments as appropriate.
Provide public transparency by publishing a safety framework focused on severe risks (timed toward the France summit in public messaging).
This is corporate soft law with reputational teeth. It is not a substitute for EU systemic-risk GPAI duties where those apply.
Paris AI Action Summit (10–11 February 2025)
France (with India co-chair themes in public materials) hosted the AI Action Summit in Paris on 10–11 February 2025. Public statements emphasize inclusive and sustainable AI, public-interest applications, energy and planetary impacts, open models within national frameworks, and continued attention to trust, safety, and information integrity. Paris commends Bletchley and Seoul safety work and notes voluntary commitments, while widening the agenda beyond frontier catastrophe narratives. Follow-on milestones named in public statements include events such as Kigali-related gatherings and UNESCO ethics forums—treat named future events as political calendar items and verify before citing as legal deadlines.
Practical read for boards: Paris does not repeal Seoul commitments. It reframes AI governance as development + safety + sustainability. Expect customers and states to ask about energy, inclusion, and public-interest deployment alongside catastrophic-risk thresholds.
What “intolerable risk” changes inside a company
Publishing a frontier safety framework forces concrete design choices:
| Capability thresholds (bio, cyber, autonomy themes) |
Makes “too dangerous” falsifiable in corporate policy |
| Eval suites and external scrutiny |
Moves safety from blog posts to measurable process |
| Deployment gates tied to mitigations |
Connects research evals to release management |
| Security of weights and insider threat controls |
Severe-risk misuse pathways |
| Public updates |
Accountability theater becomes auditable narrative |
Secondary analyses (e.g., common-elements reviews of published policies) observe recurring components among firms that published frameworks—capability thresholds, evaluations, mitigations, and security. Review before reliance any claim that “all 16 published identical policies”; publication quality and timing vary. Use GOV.UK commitment text as the primary obligation statement; use company frameworks as company-specific implementations.
Summit outputs vs. hard law (keep them separate in GRC)
| Bletchley Declaration |
State soft law |
Policy context; public affairs |
| Frontier AI Safety Commitments |
Voluntary corporate |
If signed: track framework publication & threshold logic |
| Paris statements / actions |
Political + initiatives |
Strategy, ESG, partnerships |
| EU AI Act / China Measures / UK principles |
Binding or regulator-backed |
Compliance file |
Never tell an auditor “we are Bletchley compliant” as if that were a certification.
Network of AI Safety Institutes
Summits accelerated national AI Safety Institute (or equivalent) networks for evaluation science. France’s public summit materials describe national evaluation/security institute themes and participation in institute networks. For deployers who are not frontier developers, the practical impact is better shared eval methods and more questions from enterprise customers who copy institute language into RFPs.
Open questions
Exact attendance counts and “over 100 countries” phrasing: use official summit statements when quoting.
Which additional companies signed after the original 16: check the live GOV.UK commitments page date-stamped update.
Any numeric claim about “percent of firms that cannot detect agents” or similar survey stats from older manuscript drafts: do not reuse without a primary survey cite.
Proprietary frameworks branded as universal assurance levels without public standards backing: treat as vendor proposals, not law.
How non-frontier companies should respond
Most readers of this handbook do not train frontier models. Still:
If you deploy frontier APIs, read the provider’s published safety framework and map residual risks you accept.
If you fine-tune aggressively, ask whether you create new severe-risk pathways your provider’s thresholds did not cover.
If you sell to governments, expect summit vocabulary in questionnaires (thresholds, red-teaming, responsible scaling).
If you are a board in a signatory company, demand a gap analysis between the Seoul commitment text and your published framework.
From Bletchley through Paris, information integrity and transparency remain recurring themes alongside catastrophic risk. That links summit politics to practical labeling (EU Art. 50; China deep synthesis; US state transparency). Summits amplify the expectation that synthetic media and model provenance will be governed—even when instruments differ.
Scientific reports and shared risk language
Seoul messaging highlighted continuation of an International Scientific Report on the Safety of Advanced AI as a shared evidence base for policymakers. Boards need not debate every technical appendix; they should ask whether internal risk taxonomies are compatible with the public science vocabulary (misuse, loss of control themes, societal-scale risks). Compatibility reduces translation loss when engaging governments.
Open models and summit politics
Paris materials elevate open models and public-interest AI within national legal frameworks. Open-weight strategies create governance tradeoffs: transparency and innovation benefits versus misuse and downstream-provider control limits. Record the tradeoff explicitly in risk acceptance forms—do not hide it behind summit slogans.
Investor and insurance questions after Seoul
Underwriters and investors increasingly ask whether frontier developers published safety frameworks and how thresholds are governed. Even if you are not a signatory, expect questionnaires. Prepare a short “summit posture” FAQ: signed or not; vendor dependencies; where severe-risk evals live; who can halt deployment. Keep it factual; avoid apocalyptic or dismissive tone.
From declaration to internal control test
If your company signed Seoul commitments, internal audit should sample one frontier release and ask: Were thresholds defined before deployment? Were evals run against those thresholds? Were mitigations documented? Was a go/no-go decision recorded? If any answer is no, the commitment is aspirational only. Boards should request that sample annually.
Multi-summit narrative risk
Communications teams sometimes stitch Bletchley, Seoul, and Paris into a single “we lead on AI safety” claim. That is fine if true and evidenced. It becomes greenwashing if the firm lacks thresholds, evals, or halt authority. Align spokespeople scripts with the control reality.
Timeline card for executives
| 1–2 Nov 2023 |
Bletchley Park AI Safety Summit |
Bletchley Declaration (states) |
| 21–22 May 2024 |
AI Seoul Summit |
Frontier AI Safety Commitments (initially 16 companies) |
| 10–11 Feb 2025 |
Paris AI Action Summit |
Inclusive/sustainable/public-interest action agenda; continued note of prior voluntary commitments |
Keep this card in board pre-reads. Update signatory lists from GOV.UK rather than from social media threads.
Threshold governance roles
Define who proposes thresholds (safety research), who challenges them (red team / independent reviewers), who approves them (executive risk committee), and who can halt training or deployment (named role with authority). Summit text implies these functions; organizational charts must make them real. Without halt authority, “intolerable” is rhetoric.
Downstream deployers and “shared fate”
Enterprises that build agents on frontier APIs inherit misuse and reliability risks. Contract for safety notifications, rate limits, and abuse tooling. Run your own evaluations for domain harms (fraud coaching, medical advice leakage, discriminatory outputs) even if catastrophic bio/cyber thresholds are the provider’s primary public focus.
Comparing Seoul commitments to EU systemic-risk GPAI duties
Seoul commitments are voluntary corporate promises about severe-risk thresholds and safety frameworks. EU systemic-risk GPAI duties (Chapter V themes) are binding for in-scope model providers: evaluation, risk mitigation, incident reporting, cybersecurity, and related obligations as specified in the Act. A firm can be in both regimes. Map them in one matrix with columns: Seoul clause; EU article theme; artifact; owner; status. Do not assume publishing a Seoul-style framework satisfies EU law, or that EU technical documentation alone meets a Seoul transparency expectation aimed at intolerable-risk thresholds.
For deployers, the comparison still matters: your provider’s Seoul framework may reveal eval practices you should demand contractually, while your own EU deployer duties (where applicable) remain yours.
National safety institutes and enterprise buyers
After Bletchley and Seoul, national AI safety institutes and evaluation centers multiplied. Even if you never interact with an institute directly, enterprise buyers will paste institute-inspired questions into RFPs: red-teaming methods, dangerous-capability evals, responsible scaling plans, and incident disclosure. Build an answer library that points to real artifacts. If you lack frontier capabilities, say so and describe domain evals you do run (fraud, self-harm advice, privacy leakage, discriminatory outputs). Honesty beats theater.
Openness and severe-risk tension
Paris elevated open and public-interest AI. Open weights can improve transparency and local capacity while complicating misuse controls and downstream governance. Record a deliberate openness policy: what you release, what you restrict, what evaluations gate release, and how you monitor downstream abuse reports. Summit speeches will not resolve the tension; your risk acceptance memo must.
Information-integrity themes across summits increase pressure on platforms and brands to detect and label synthetic media. Coordinate summit-driven PR claims with Chapter 20 labeling engineering. If communications promises “industry-leading deepfake defenses,” product must have a detection/label roadmap with dates.
What “publish a safety framework” should contain
Drawing from the Seoul commitment text and published company frameworks (without cloning any proprietary policy), a credible framework typically covers: scope of models covered; methods for identifying severe risks; capability or risk thresholds with examples; evaluation approaches; mitigation strategies (deployment safeguards, access controls, monitoring); governance roles; external engagement; and update cadence. Boards should ask whether thresholds are measurable and whether halt authority is real. Secondary reviews of published policies through 2025 note common elements among several companies; review before reliance any claim that all signatories published equally rigorous documents—quality varies.
Coordination with America’s AI Action Plan and EU timelines
Summit soft law coexists with US acceleration policy and EU staged obligations. A global firm may publish a Seoul-style framework, comply with EU GPAI timelines, and face US state transparency rules simultaneously. Keep one evidence vault with tagged artifacts. Public affairs should not promise “global alignment complete” when hard-law calendars still diverge.
Illustrative case study
A Seoul signatory prepares its public safety framework before Paris. Legal wants flexible qualitative language; safety researchers want measurable capability thresholds with eval protocols; communications wants reassuring tone. The working group publishes thresholds with examples, describes monitoring, and states the non-deployment commitment if mitigations fail. Internal audit then tests whether release gates actually reference those thresholds. Lesson: summit signatures create audit expectations—if you signed, your framework is not only PR.
Practical Checklist
Determine whether your company signed Frontier AI Safety Commitments (or acquired a signatory).
If yes, map each commitment clause to an owner and artifact.
Calendar framework publication and update reviews.
Separate summit soft law from EU/China/UK hard obligations in the compliance matrix.
For API deployers: collect provider safety-framework links in vendor files.
Brief the board on Paris agenda widening (inclusion, energy) if ESG-relevant.
Ban “Bletchley certified” marketing language.
Review before reliance survey statistics lacking primary sources.
Track GOV.UK list updates for added signatories.
Align severe-risk eval investment with actual model capability—proportionate, not theatrical.
Board Questions
Did we sign Seoul commitments—or rely on vendors who did?
Where is our published frontier safety framework (if applicable)?
Who can stop a deployment if an intolerable-risk threshold is approached?
How do summit promises interact with EU systemic-risk GPAI duties?
Are we over-indexing on catastrophe narratives while under-funding ordinary harm controls?
What Paris themes (energy, inclusion) affect our strategy disclosures?
How do we answer customer RFPs that paste summit language?
What is our process to update thresholds as capabilities change?
Diplomacy as early-warning system
Summit communiqués preview where hard law and procurement standards may travel next. Assign public-affairs and compliance a joint “summit delta” note after each major meeting: what is new, what is voluntary, what might become contractual. That discipline beats scrambling when a customer cites a declaration as if it were a statute.
Bridge
Chapter 16 covers standing institutions—G7 Hiroshima Process, UN advisory work, OECD, GPAI—that outlive any single summit weekend.
Extended handbook notes — summit operations
Building a summit-response playbook
Create a 48-hour playbook for major AI summits and ministerial meetings. Public affairs drafts a factual summary within one business day: documents issued, whether soft or hard law, which commitments mention companies by category, and whether any customer or regulator is likely to ask questions. Legal marks each item as: binding on us; voluntary if we signed; procurement-relevant; or ignore-for-compliance. Product and safety leads note engineering implications. The Executive AI Council reviews within a week if any item requires budget or halt-authority changes. Without this playbook, summit news becomes Slack rumor and inconsistent customer emails.
Signatory lifecycle management
If your company signed the Frontier AI Safety Commitments, maintain a controlled list of obligations extracted from the GOV.UK text. Assign each clause an owner. Link to the published safety framework sections. Calendar an annual readiness test: pick one model release and verify threshold evaluation occurred. If you acquire a signatory, treat commitment inheritance as due-diligence—confirm frameworks, thresholds, and halt rights survive integration. If you divest a signatory unit, clarify public messaging so customers are not misled.
Non-signatory posture
Most enterprises will not sign Seoul commitments. Still prepare a posture statement: we deploy models from providers who publish safety frameworks; we run domain evaluations; we maintain human oversight for high-impact actions; we monitor misuse of our applications; we do not claim frontier catastrophic-risk thresholds we do not measure. This statement prevents sales teams from improvising “we follow Bletchley” language.
Paris agenda items in enterprise strategy
Inclusive access, sustainability, and public-interest AI affect ESG reporting and public-sector sales. If you claim green AI, measure energy for training and inference at a method you can defend; review before reliance precise global averages. If you claim public-interest deployments, document beneficiaries and evaluation of harms. Summit language without metrics becomes greenwashing risk.
Summit communiqués repeatedly reference information integrity. Operationalize: brand impersonation monitoring; rapid takedown partnerships; synthetic media labeling on your generative features; staff training for election-sensitive periods; and customer alerts when deepfakes of executives appear. Connect to Chapters 13 and 20 labeling duties where markets require them.
Evaluating safety frameworks of counterparties
Score vendor frameworks on: clarity of thresholds; examples of intolerable risk; eval methods; update history; security of weights; deployment gates; and contact path for enterprise customers when severe issues arise. Prefer vendors who publish and iterate over vendors who only blog. Review before reliance any single NGO score as definitive.
Board education module
Offer directors a one-hour module: what Bletchley/Seoul/Paris each produced; difference between state declarations and company commitments; how this interacts with EU/China/UK law; what questions to ask management after the next summit. Repeat when a major summit lands.
Primary-source route: S18 UK Government | Return to contents
Chapter 16: International Institutions and Convergence
G7 Hiroshima AI Process, UN advisory architecture, OECD, and GPAI as interoperability machinery
Overview
Key point: Summits make headlines; institutions keep the paperwork alive. The G7 Hiroshima AI Process (launched May 2023; Comprehensive Policy Framework endorsed December 2023) produced guiding principles and a code of conduct for advanced AI systems, later supported by a broader Friends Group. The UN Secretary-General’s High-level Advisory Body on AI issued interim work in December 2023 and a final report, Governing AI for Humanity, in September 2024, proposing light institutional functions such as a scientific panel, policy dialogue, standards exchange, capacity network, funding ideas, data framework themes, and a UN AI office concept. The OECD remains the principles and measurement hub (Recommendation revised 3 May 2024). The Global Partnership on AI (GPAI) has been integrating with OECD AI work under a shared partnership brand. Boards should treat this layer as interoperability infrastructure—useful for contracts, public affairs, and gap analyses—not as a single global regulator.
Learning Objectives
Place Hiroshima, UN HLAB, OECD, and GPAI on a timeline with roles.
Explain why “convergence” is partial and political.
Use OECD/Hiroshima vocabulary in vendor and government questionnaires without overclaiming compliance.
Review before reliance institutional proposals that are recommendations, not established organs.
Decide which institutional outputs belong in the compliance file versus the strategy file.
Core Analysis
Why institutions matter to companies
Hard law is jurisdictional. Customers, investors, and governments still ask: “Which international frameworks do you follow?” Answering well requires knowing what each body actually produces:
| OECD |
Legal recommendation + tools/metrics |
Definitional alignment; policy reporting |
| G7 Hiroshima Process |
Principles + code of conduct for advanced AI |
Frontier developer questionnaires; Friends Group signaling |
| UN HLAB / follow-ons |
Blueprint recommendations |
Long-range public affairs; capacity & inclusion themes |
| GPAI (with OECD) |
Multistakeholder projects / practice bridge |
Expert networks; sector projects |
G7 Hiroshima AI Process (2023 onward)
Leaders launched the Hiroshima AI Process in May 2023 to address generative/advanced AI opportunities and risks. After ministerial and multistakeholder meetings, G7 Digital & Tech Ministers agreed the Hiroshima AI Process Comprehensive Policy Framework in December 2023, endorsed by G7 Leaders the same month. It is widely described as including guiding principles and a code of conduct aimed at safe, secure, and trustworthy advanced AI systems.
In May 2024, public reporting describes a Hiroshima AI Process Friends Group announcement (associated with OECD ministerial context) with dozens of supporting countries/regions advancing implementation of the guidelines and code. Review before reliance exact membership counts; cite current OECD/G7 pages when precision matters.
Company implications: If you develop advanced AI, expect Hiroshima Code of Conduct themes in government engagements and in comparisons with Seoul Frontier Safety Commitments. Map overlaps (risk assessment, transparency, security, incident reporting themes) once; do not maintain contradictory promises across G7 and summit documents.
UN High-level Advisory Body and Governing AI for Humanity
The UN Secretary-General’s High-level Advisory Body on AI published interim material in December 2023 and a final report in September 2024. OECD.AI summaries highlight extensive consultations and recommendations for a globally inclusive governance architecture. Commonly listed recommendation themes include:
International Scientific Panel on AI
Policy Dialogue on AI Governance
AI Standards Exchange
Capacity Development Network
Global Fund for AI (concept)
Global AI Data Framework themes
AI Office within the UN system (concept)
Critical board message: These are recommendations for institutional design, not already-complete courts with fining power. Track what the UN system actually establishes through subsequent resolutions and the Global Digital Compact follow-through. Review before reliance any claim that a UN AI regulator already licenses models.
The Advisory Body’s gap analysis lineage openly surveyed major initiatives (EU AI Act, Hiroshima, GPAI, OECD, national measures, summit processes, and others). That survey mindset is useful for corporate gap analyses: list regimes, list overlaps, list holes (especially Global South capacity).
OECD as the steady metronome
Chapters 1 and 3 covered OECD definitions and principles. For institutional convergence, remember three OECD functions:
Normative: Recommendation on AI (2019; revised 3 May 2024).
Analytical: policy observatory, measurement, country reviews.
Convening: support to G7 Hiroshima reporting frameworks and UN processes.
Organisations developing advanced AI may participate in Hiroshima AI reporting frameworks facilitated in OECD contexts—transparency by disclosure, not by certification seal. Review before reliance participation counts; verify on OECD.AI if used in public claims.
GPAI and the practice bridge
The Global Partnership on Artificial Intelligence began as a multistakeholder initiative to connect research and practice across governments, industry, academia, and civil society. Public OECD materials describe integration of GPAI and OECD member AI work under the GPAI brand as an integrated partnership. For practitioners, GPAI-shaped projects can yield sector playbooks and expert networks. They do not replace ISO certification or EU conformity assessment.
Convergence without fantasy
True global convergence would mean mutual recognition of assessments, shared incident taxonomies, and compatible transparency artifacts. Partial convergence already exists:
Shared definitional DNA via OECD.
Shared risk-management vocabulary via NIST influence and ISO management-system structure.
Shared frontier safety talk via summits and Hiroshima codes.
Persistent divergence on content controls (China), horizontal product rules (EU), sector principles (UK), and US federal–state conflict.
Corporate strategy should aim for interoperable evidence, not a mythical single filing.
Building an institutional watchlist (lightweight)
Assign public affairs + compliance a quarterly one-pager:
New Hiroshima Friends Group or reporting updates
UN follow-on bodies actually created (vs. recommended)
OECD recommendation tools or reporting frameworks
GPAI project outputs relevant to your sectors
Council of Europe / other treaty developments if you operate in covered states (review before reliance treaty status—verify separately)
Open questions
Exact Friends Group membership numbers and naming of every UN office ultimately created.
Whether any particular company “complies with Hiroshima” as a binary—codes of conduct are not CE marks.
Funding amounts for any proposed Global Fund for AI.
How to answer “which frameworks do you follow?”
Preferred answer pattern for RFPs:
We align definitions to the OECD Recommendation (2024 revision).
We operate an AI management system consistent with ISO/IEC 42001 and NIST AI RMF functions.
We comply with binding law in markets we serve (EU AI Act as applicable; China Measures for China public services; UK regulator expectations).
Where we develop frontier systems, we address Hiroshima/Seoul voluntary commitments as published.
We monitor UN institutional follow-through for public-interest and capacity themes.
This beats claiming membership in every acronym.
Regional bodies and the “more than G7” problem
Many markets care as much about regional instruments (EU law, African Union strategies, ASEAN guides, Council of Europe work) as about G7 texts. Keep regional hard law in the compliance file; use G7/UN/OECD for interoperability narrative. Do not let Friends Group diplomacy distract from EU high-risk deadlines or China filing calendars.
Standards exchange as the quiet convergence engine
UN HLAB’s “standards exchange” idea recognizes what practitioners already know: ISO/IEC JTC 1/SC 42, IEEE, and national bodies shape procurement faster than summit speeches. Assign standards watch to the same owner as ISO 42001 adoption.
Hiroshima Code of Conduct in vendor diligence
Even non-G7 companies meet Hiroshima themes through supply chains. Add four diligence questions for advanced-AI vendors: How do you assess severe risks? What transparency artifacts exist? How are incidents reported to customers? How do you secure model weights and insider access? Score answers qualitatively. Do not invent a fake “Hiroshima certification” checkbox.
Capacity and inclusion as material risk
UN HLAB themes on capacity development and global inclusion are not only ethics rhetoric. In emerging markets, lack of local evaluation capacity and data infrastructure shapes deployment risk and political license to operate. If you expand into those markets, budget for local partnerships and language-specific evaluations—not only for translation of English model cards.
Working with the Global Digital Compact lineage
UN processes around digital governance and AI increasingly reference inclusive participation and human rights. Corporate human-rights due diligence programs (UNGPs-aligned) should add AI use cases explicitly: biometric surveillance sales, content moderation AI, welfare eligibility tools, and labor-management algorithms. Institutional convergence language helps explain why these reviews belong in the same calendar as privacy DPIAs.
Some firms publicly praise the softest forum while quietly ignoring the hardest binding rule that already applies. That narrative collapses under discovery. Teach spokespeople the stack: binding law first, then voluntary codes, then aspirational UN recommendations. Honesty is a control.
Scientific panel proposals and enterprise eval strategy
If an International Scientific Panel on AI becomes operational, expect shared risk taxonomies and assessment methods to influence regulators and large buyers. Position your internal evaluation program to absorb external methods rather than rewrite from scratch each year. Modular eval harnesses are the practical response to institutional science.
Practical annual calendar for institutional monitoring
Q1: OECD tools/reporting updates; refresh “frameworks we follow” language.
Q2: G7/Hiroshima and Friends Group developments; compare to your frontier safety framework if any.
Q3: UN follow-through after HLAB recommendations; note any newly created panels or offices with primary citations.
Q4: GPAI/OECD partnership outputs relevant to your sectors; feed standards watch into ISO 42001 management review.
Attach the calendar to public-affairs OKRs so it does not die as a one-off memo. Each quarter’s note should state what changed for legal obligation versus reputation/procurement versus no action.
Treaty and standards watch (lightweight)
Beyond G7 and UN advisory reports, watch: Council of Europe AI convention developments if you operate in participating states; ISO/IEC JTC 1/SC 42 publications beyond 42001; sector standards in finance and health; and trade-agreement digital chapters that mention AI. Assign a standards lead to summarize quarterly in one page: new texts; whether binding; required action. Review before reliance ratification status—verify primary sources before telling the board a treaty “applies.”
Reporting frameworks as soft transparency mandates
Hiroshima-related reporting frameworks and OECD tools create voluntary disclosure channels for advanced AI developers. Participation can build trust with governments. It also creates written statements that may be read in litigation or procurement. Counsel should review submissions. Consistency with Seoul safety frameworks and EU documentation is mandatory if you participate in multiple channels.
Friends Group politics and market access narratives
Joining or praising Hiroshima Friends Group themes can signal cooperation to democratic governments. It does not grant market access rights. Conversely, ignoring Hiroshima vocabulary in G7-facing procurement can create friction even when not legally mandatory. Calibrate: use interoperable language; evidence with real controls; avoid empty accession rhetoric.
Capacity gaps as operational risk
UN HLAB recommendations on capacity networks and funding concepts highlight that many countries lack evaluation infrastructure. If you sell AI into those markets, local partners may be unable to validate systems. Budget for joint evaluation, language-specific red teaming, and training. Review before reliance any specific fund size proposals until primary UN documents establish them.
Illustrative case study
A multinational answers a development-bank RFP that cites OECD principles, UNESCO ethics, and “UN AI governance.” The team maps each cite to artifacts: OECD-aligned definitions in the model card; UNESCO-inspired human-rights impact questions in the FRIA-like assessment; a short annex explaining that UN HLAB recommendations are institutional proposals, while the bidder’s binding controls track EU/UK/US/China law as applicable. They win on clarity, not on acronym stacking. Lesson: institutions are a translation problem—solve it with a map.
Practical Checklist
Maintain a one-page institutions map (OECD, Hiroshima, UN, GPAI, summits).
Separate voluntary codes from binding law in all board decks.
Align public “frameworks we follow” language to the five-line pattern above.
If frontier developer: map Hiroshima code themes to Seoul safety framework.
Track Friends Group / OECD reporting invitations relevant to your models.
Review before reliance UN office claims until primary UN documents confirm establishment.
Reuse OECD vocabulary in contracts where helpful.
Brief directors annually on convergence vs. divergence.
Avoid paying for “UN-aligned certificates” without substance.
Update the watchlist quarterly.
Board Questions
Which institutional frameworks do we claim publicly—and can we evidence each claim?
Are Hiroshima/Seoul voluntary commitments in scope for us?
How do we speak about UN recommendations without implying a global license?
Who owns the institutional watchlist?
Do our RFP answers create conflicting promises across OECD, EU, and China?
What capacity-building or inclusion commitments are material to our markets?
How will a future UN scientific panel affect our evaluation strategy?
Are we mistaking soft-law logos for risk reduction?
Interoperability artifacts worth inventing once
Regardless of institution, the same evidence travels far: system cards, data lineage summaries, eval reports, incident logs, human-oversight procedures, and management-system policies. Institutions change letterhead; artifacts persist. Invest in artifacts.
Bridge
Chapter 17 turns to the certifiable management-system layer: ISO/IEC 42001:2023.
Extended handbook notes — institutional interoperability
Writing the “frameworks we follow” page
Many companies need a public or customer-facing page. Recommended structure: (1) Binding law by market; (2) Management systems (ISO 42001, NIST RMF alignment); (3) Voluntary codes relevant to our role (Hiroshima/Seoul if applicable); (4) Ethical foundations we use in impact assessment (UNESCO themes); (5) What we do not claim. Update quarterly. Make legal the owner of truth; marketing the owner of clarity. Never list a framework you cannot evidence.
Hiroshima Code themes checklist for advanced AI developers
Translate code-of-conduct themes into internal controls: risk identification across lifecycle; transparency about capabilities and limitations; security measures for models and data; content and misuse mitigation; incident reporting pathways; investment in safety research; and cooperation with governments as appropriate. Map each to artifacts. Review before reliance exact code paragraph numbers—use the official G7 text your counsel relies on.
UN recommendation tracking without hype
Maintain a tracker with columns: HLAB recommendation; UN follow-up action (resolution, new body, none yet); primary document link; impact on our firm (none/low/monitor/act); owner. Update after major UN digital events. This prevents both cynicism (“UN never matters”) and hype (“UN now regulates models”).
OECD measurement and policy observatory use
Use OECD.AI resources to benchmark national policies when entering markets. Review before reliance country rankings as investment advice. Use them as orientation for legal scoping workshops.
GPAI project outputs
When GPAI or OECD partnership projects publish sector guidance, route to the relevant risk owner for adoption/rejection with rationale. Do not ignore useful practice notes because they are soft law; do not treat them as statutes.
Multilateral consistency in government affairs
Government-affairs teams speaking in Ottawa, Tokyo, Brussels, and Washington should share one capability description of your AI systems and one map of controls. Institutional forums punish contradictory narratives. Align with product truth.
Institutional narrative for investor ESG questionnaires
Investors increasingly ask which AI ethics frameworks you follow. Answer with the layered truth: binding law by market; ISO/NIST management practice; OECD definitional alignment; voluntary summit/Hiroshima commitments only if accurate; UNESCO-inspired rights questions in impact assessment. Provide artifact pointers. Review before reliance ESG rating methodologies you do not control. Consistency across CDP-like questionnaires, sustainability reports, and security RFPs is itself a control—assign one editor of record.
Primary-source route: S01 OECD · S19 United Nations | Return to contents
Part IV — Organizational governance (Ch. 17–22)
Chapter 17: ISO/IEC 42001:2023 – AI Management System
AIMS requirements, Clauses 4–10, Annex A controls, and honest certification use
Standard-access limitation
This chapter offers implementation orientation, not a reproduced or independently audited copy of the licensed standard. The public ISO overview supports the management-system description. Obtain the authorized standard for clause-level interpretation, control selection, and certification work. [S20]
Overview
Key point: ISO/IEC 42001:2023 (Information technology — Artificial intelligence — Management system), first edition published December 2023 (ISO lifecycle shows publication 18 December 2023), is the first certifiable AI management system (AIMS) standard. It uses the common ISO management-system structure: context, leadership, planning, support, operation, performance evaluation, and improvement (Clauses 4–10). Annex A provides reference control objectives and controls (commonly described as on the order of 38 controls across objectives A.2–A.10 in practitioner summaries); organizations select applicable controls through risk assessment and document them in a Statement of Applicability (SoA). Certification can help procurement and board assurance—but it does not replace EU conformity assessment, China filing, or sector licenses.
Learning Objectives
Explain what an AIMS is and how it differs from a single model card.
Walk Clauses 4–10 as an operating rhythm.
Use Annex A / SoA correctly (select and justify—do not pretend all controls always apply).
Position 42001 beside NIST AI RMF and the EU AI Act without false equivalence.
Review before reliance marketing claims like “42001 equals AI Act compliance.”
Core Analysis
Why a management system standard for AI?
AI risk is organizational, not only algorithmic. Models change; vendors change; prompts change; agents call tools. A management system forces: policy, roles, risk and impact assessment, lifecycle controls, data controls, supplier controls, monitoring, and improvement. ISO/IEC 42001 packages those expectations in auditor-familiar form—like ISO 27001 did for information security.
Clauses 4–10 (practitioner tour)
| 4 |
Context |
Who are interested parties? What is the AIMS scope? Internal/external issues? |
| 5 |
Leadership |
Policy, roles, top-management commitment |
| 6 |
Planning |
Risks/opportunities; AI risk assessment; impact assessment; objectives |
| 7 |
Support |
Resources, competence, awareness, communication, documented information |
| 8 |
Operation |
Lifecycle controls; implementing SoA controls; change management |
| 9 |
Performance evaluation |
Monitoring, internal audit, management review |
| 10 |
Improvement |
Nonconformity, corrective action, continual improvement |
If your “AI governance” is a slide committee without Clause 9–10 evidence, you do not yet have an AIMS.
Annex A control objectives (A.2–A.10 themes)
Practitioner summaries of Annex A group reference controls under objectives such as:
Policies related to AI
Internal organization
Resources for AI systems
Assessing impacts of AI systems
AI system life cycle
Data for AI systems
Information for interested parties
Use of AI systems
Third-party and customer relationships
SoA discipline: include, exclude, justify. Organizations may add controls beyond Annex A. Annex A is not a checkbox religion; it is a structured menu tied to risk.
Annex B provides implementation guidance; Annex C discusses objectives/risk sources; Annex D discusses cross-domain use—useful for implementers, not for inventing legal duties.
Mapping to NIST and the EU AI Act
| NIST AI RMF Govern/Map/Measure/Manage |
Management-system home for RMF practices |
NIST is voluntary guidance in US federal context; 42001 is certifiable MSS |
| EU high-risk QMS / documentation |
Can organize evidence |
Not automatic conformity assessment or CE marking |
| GPAI transparency |
Helps governance of model providers’ processes |
Does not replace Chapter V duties |
| China filing packs |
May structure evidence vaults |
Does not replace 备案 |
Certification: value and failure modes
Value: external audit pressure; customer trust; internal clarity; board-friendly attestation language (carefully worded).
Failure modes: paper AIMS disconnected from engineering; scope so narrow it excludes the risky products; treating certificate as permission to skip DPIA/FRIA; buying logos without competence.
Scope the AIMS around real AI systems in production and material development programs. A certificate covering only a lab chatbot while production ranking models sit outside scope is a governance own-goal.
Implementation sequence (honest 42001 program)
Executive decision on scope and objectives.
Inventory AI systems and interested parties.
Gap assessment against Clauses 4–10 and Annex A.
Risk & impact assessment method (align with Chapter 19).
SoA draft and control owners.
Documented information minimum set (policy, SoA, risk records, lifecycle procedures).
Operate for a real cycle (not only pre-audit theater).
Internal audit + management review.
Certification audit if desired (stage 1/2 pattern familiar from other MSS).
Continual improvement tied to incidents and model changes.
Open questions
Exact control counts if your auditor’s edition differs—verify against the purchased standard text.
Claims that EN adoption dates automatically change legal duties—standards adoption ≠ statute.
Any maturity score proprietary overlay sold as “ISO level 5”—not part of 42001 itself.
Integrating suppliers and foundation-model APIs
Clause themes on third parties matter because most enterprises are deployers. Flow down: model change notices, eval summaries, incident reporting, data-use limits, and subcontracting transparency. Your SoA should say how you control providers you do not train.
AI policy and scope statement
SoA
Risk/impact assessment procedure and recent results
Inventory extract
Competence matrix for AI roles
Internal audit results and corrective actions
Management review minutes
If these cannot be produced in two weeks, certification marketing is premature.
Common Annex A pitfalls
Excluding “use of AI systems” controls while employees paste secrets into public chatbots.
Ignoring impact assessment because “we only use reputable APIs.”
Writing policies that engineering has never seen.
Letting marketing own the certificate narrative without audit participation.
Cost realism
Budget for: gap assessment, documentation, tooling for inventory, training, internal audit time, certification body fees, and—largest—engineering change to meet lifecycle and data controls. Review before reliance any vendor’s fixed “compliance in 30 days” promise.
Clause 6 methods: keep them lightweight but real
AI risk assessment under 42001 should identify sources of risk (data, model, human factors, third parties, misuse) and treatments. Impact assessment should consider affected persons and groups—not only enterprise loss. Start with a two-page method, not a 90-page methodology shrine. Improve after the first ten systems. Consistency beats ornamental complexity.
Harmonized structure benefits
If you already run ISO 27001 or 9001, reuse: document control, internal audit program, management review calendar, competence records, supplier processes. Add AI-specific modules rather than inventing a parallel bureaucracy. Auditors reward integrated systems that staff can actually operate.
Leadership and culture signals auditors notice
Auditors notice whether executives can explain AIMS scope without reading a cue card; whether engineers know the AI policy exists; whether incidents trigger corrective action beyond blame; and whether objectives are measurable. Tabletop the management review before the certification body arrives.
AI policy minimum contents
State: commitment to responsible AI aligned with law and ethics principles you actually use; scope; roles; risk/impact assessment requirement; lifecycle gates; data and supplier expectations; transparency; human oversight; incident reporting; improvement. Keep it short enough to read. Put detail in procedures.
Use operational metrics: percent of AI systems inventoried; percent with current risk assessment; median days to close AI incidents; audit nonconformity aging; training completion for AI roles; supplier assessment coverage. Do not sell the board a color-coded “Level 4.2 trustworthy AI” score that is not in the standard.
When not to certify yet
Skip external certification if inventory is incomplete, production systems sit outside proposed scope, or engineering refuses lifecycle gates. Fix those first. A failed or hollow certificate damages trust more than “we are implementing.”
Worked SoA example (illustrative)
Suppose a company deploys an enterprise coding assistant (API-based) and a customer-facing recommendation ranker. SoA includes: AI policy controls; roles; resources; impact assessment for both systems; lifecycle gates (change management for prompt/model updates); data controls for repositories and click logs; transparency notices; acceptable use; supplier controls for the API provider. Exclusions might include controls aimed at in-house model training if the firm does not train—justified in writing. The SoA points to procedures and records. Internal audit samples two changes: a model-provider version bump and a new repository connector—checking whether impact assessment and security review occurred. Nonconformities feed corrective action. This is what Clause 9–10 look like in practice.
You can run 42001 with a document repository and ticketing system. Tag tickets with AIMS control IDs. Link CI/CD checks to lifecycle gates for model and prompt changes. Store SoA in version control. Avoid buying an “AI GRC platform” until inventory and owners exist—tools amplify process; they do not create it. If you already have GRC software for SOX or operational risk, extend it with AI risk taxonomies rather than inventing a parallel universe.
Competence and the job market reality
Clause 7 competence is hard because AI skills are scarce. Define minimum competence by role: system owners need lifecycle and incident skills; reviewers need assessment skills; executives need enough literacy to challenge. Use training, hiring, and managed services deliberately. Record evidence. Review before reliance promises that a two-day course makes staff “42001 certified” in the ISO sense—certification applies to organizations, not weekend badges.
Stage 1 and Stage 2 audit readiness
Certification bodies typically review documentation readiness first, then implementation effectiveness. Before Stage 1: scope, policy, SoA, risk/impact procedures, inventory sample, competence plan. Before Stage 2: operated records—risk assessments completed, lifecycle changes controlled, internal audit done, management review minutes, corrective actions closed or on track. Rushing Stage 2 without operating history produces nonconformities. Plan months, not weeks, after first procedure approval.
Multi-site and multi-cloud scope tricks to avoid
Do not exclude the risky business unit from scope to “make certification easy.” Customers will ask which products are covered. Marketing must match the certificate’s scope statement exactly. If the certificate covers “AI platform services in Region A,” do not imply global coverage.
Illustrative case study
A mid-size SaaS firm sells an AI feature into EU and UK markets. Customers ask for “ISO 42001.” The firm scopes AIMS to the AI feature and its data pipelines, maps Annex A controls to existing ISO 27001 controls where overlapping (access control, supplier security), adds AI-specific impact assessment and lifecycle gates, runs six months of internal audits, then seeks certification. Parallel EU AI Act classification work continues—42001 evidence feeds documentation but counsel still owns legal classification. Lesson: AIMS organizes; law obligates.
Practical Checklist
Buy/read the standard (do not implement from blogs alone).
Set AIMS scope with executive signature.
Build AI inventory linked to SoA.
Write risk and impact assessment procedures.
Assign control owners for applicable Annex A controls.
Integrate with ISO 27001/9001 where already certified.
Schedule internal audit before external audit.
Ban “AI Act certified via 42001” claims.
Include API/vendor controls in SoA.
Review AIMS after material model or agentic-capability changes.
Board Questions
What is in—and out—of our AIMS scope?
Who is top management for Clause 5 purposes?
When was the last management review with AI incident metrics?
Does our SoA match production reality?
Are we seeking certification for assurance or only for sales?
How does 42001 evidence map to EU high-risk documentation?
What competence gaps block Clause 7?
Which Annex A exclusions would embarrass us if published?
Relationship to Chapters 18–22
Corporate governance (Ch 18) supplies leadership. Risk/impact assessment (Ch 19) feeds Clause 6. Data/transparency (Ch 20) feeds data and interested-party controls. Liability (Ch 21) informs risk acceptance. Auditing (Ch 22) deepens Clause 9. Use 42001 as the binder, not the entire bookshelf.
Bridge
Chapter 18 translates management-system leadership into board and executive operating models.
Extended handbook notes — AIMS implementation depth
Policy; scope; SoA; risk assessment procedure; impact assessment procedure; AI system lifecycle procedure; data management procedure; supplier procedure; performance monitoring procedure; internal audit program; competence matrix; incident procedure; management review agenda template. Keep each short. Version-control them. Link records (completed assessments, audit reports) separately from procedures.
Drawing on common AIMS practice and Annex C themes without copying proprietary checklists: unwanted bias; opacity; unreliable outputs; insecurity; misuse; data quality failures; third-party failures; human-factor failures; societal and environmental impacts where relevant. Organizations add domain risks (clinical, credit, safety-critical industrial).
Treat significant prompt-chain changes, tool-enablement, and RAG corpus expansions as controlled changes under Clause 8. Require impact screening. Many firms control model weights but let prompts roam free—that is an AIMS hole.
Metrics for Clause 9
Examples: assessment currency; incident counts by severity; corrective action aging; training completion; supplier assessment coverage; monitoring alert volume and mean time to acknowledge. Review in management review. Avoid vanity metrics.
Certification body selection
Choose accredited bodies experienced with management systems. Ask about AI competency. Clarify multi-site sampling. Read the scope statement draft before marketing designs logos. Budget surveillance audits, not only initial certification.
AIMS and open-source / open-weight models
If you release open weights, your AIMS should still cover release gates, evals, documentation, and misuse monitoring commensurate with risk. If you only consume open weights, supplier controls and inbound evals dominate. Scope statements should say which posture applies. Review before reliance claims that open release equals automatic legal compliance anywhere.
Practitioner deep-dive — standing up AIMS in a mid-size firm
Month-by-month sketch (illustrative, not a maturity score)
Month 1: executives approve scope; inventory workshop; policy draft; appoint AIMS manager.
Month 2: risk and impact procedures; SoA first cut; map overlaps with ISO 27001 controls.
Month 3: train system owners; complete assessments for top five systems; close obvious access-control gaps on AI tools.
Month 4: lifecycle change tickets live in engineering; supplier questionnaire for model APIs.
Month 5: internal audit of two Tier A systems; fix nonconformities.
Month 6: management review; decide on external certification timing.
Months 7–9: operate and gather records; expand inventory; refine monitoring metrics.
Months 10–12: Stage 1/2 if pursuing certification; surveillance planning.
Adjust for size. Regulated banks may move faster on Tier A; startups may stop at “operate without certificate.”
Statement of Applicability narrative quality
Auditors read justifications. “Not applicable because we do not train models” is fine if true. “Not applicable because too hard” is not. When partially applicable, say how you compensate. Keep SoA synchronized with inventory—decommissioned systems should not leave orphan controls, and new agentic tools should not sit outside SoA for months.
Combining 42001 with EU technical documentation
Create a crosswalk: AIMS records → AI Act documentation themes (risk management, data governance, logging, human oversight, accuracy/robustness evidence). The crosswalk saves counsel time. It does not by itself prove conformity assessment completed.
Management review should explicitly consider changes in AI technology (agents, multimodal models) and whether SoA controls still fit. Record decisions to expand scope. Keep certification marketing synchronized with surveillance audit results.
Primary-source route: S20 ISO | Return to contents
Chapter 18: Corporate Governance – Board and Executive
Board oversight, committee charters, AI Councils, and accountable executives
Overview
Key point: AI governance fails when it is everyone’s slogan and no one’s job. Boards need a clear oversight model: which committee owns AI risk; what management must report; how material AI incidents escalate; and how incentives avoid shipping unsafe systems for growth. Executives need an operating forum—often an Executive AI Council—plus empowered roles for risk, legal, security, data, and product. This chapter gives charter language patterns and reporting cadences without pretending one org chart fits every firm.
Learning Objectives
Choose a board oversight pattern (full board, risk committee, tech committee, or hybrid).
Define an Executive AI Council mandate distinct from a theater ethics panel.
Write RACI for inventory, risk acceptance, deployment gates, and incidents.
Connect governance to ISO 42001 Clause 5 and NIST Govern function.
Review before reliance any universal “best” committee name; fit to existing board structure.
Core Analysis
The board’s job on AI
Directors already oversee strategy, risk, cyber, privacy, and culture. AI is a cross-cutting amplifier: it can create new products, new liabilities, new concentration risk on model providers, and new conduct failures. The board should:
Approve AI risk appetite themes (what harms are unacceptable).
Ensure management has an inventory and classification method.
Review material regulatory exposure (EU high-risk/GPAI; China filing; UK regulators; US states).
Challenge growth narratives that depend on untested agentic autonomy.
Confirm incident and whistleblowing pathways work for AI harms.
Align incentives: variable pay should not reward reckless deployment.
The board does not pick model architectures. It ensures the control system exists and is tested.
| Risk committee primary |
Strong ERM culture |
May underweight product/strategy upside |
| Technology/innovation committee primary |
Tech-heavy boards |
May underweight legal/conduct risk |
| Full board retains AI |
Smaller boards; transformative bets |
Agenda crowding |
| Hybrid: risk + tech dual touch |
Large complex firms |
Coordination cost; split brain |
Pick one primary owner; allow informational updates elsewhere. Publish the choice in the governance framework.
Executive AI Council (operating layer)
A useful council includes: CEO or delegate sponsor; CTO/CPO; CISO; Chief Risk/Compliance; General Counsel; Chief Data/AI Officer; business-unit leads for material deployments; HR for workforce tools; communications for transparency incidents. Mandate examples:
Approve enterprise AI policy and tiering.
Review inventory completeness quarterly.
Accept residual risk for Tier A systems.
Gate high-impact deployments.
Sponsor ISO 42001 / regulatory programs.
Review serious incidents within defined SLAs.
Meet monthly in the first year; then right-size. Publish decisions and dissent. A council that only hears demos is not governance.
Role clarity (minimum set)
| Executive sponsor |
Resources and tone |
| AI system owner |
Lifecycle outcomes for a system |
| Data owner |
Training/fine-tune/prompt data fitness |
| Risk owner |
Independent challenge |
| Legal/regulatory owner |
Classification and filings |
| Security owner |
Model theft, prompt injection, abuse |
| Appeal/human review owner |
Contestability operations |
One person may wear multiple hats in smaller firms; document it.
Committee charter inserts (patterns, not statutes)
Add to risk committee charter: oversight of AI risk management framework; annual review of AI risk appetite; receipt of material AI incident reports; oversight of regulatory AI programs. Add to tech committee: oversight of AI architecture strategy and technical debt in eval/monitoring. Add to audit committee: assurance over AI-related controls and third-party attestations where used. Review before reliance exact wording—counsel adapts to jurisdiction and listing rules.
Reporting cadence that fits a board book
Quarterly management report (2–4 pages): inventory metrics; Tier A changes; regulatory calendar (EU/China/UK/US); incidents and near misses; customer/regulator inquiries; certification or audit status; top residual risks.
Annual deep dive: strategy vs. risk appetite; third-party concentration; agentic AI roadmap; liability/insurance posture.
Ad hoc: halt events; material enforcement; major model provider outages affecting safety controls.
Employees will use public GenAI tools unless governed. Governance must include acceptable-use policy, approved tooling, DLP controls, training, and detection. Boards should ask for estimated shadow-AI prevalence and remediation—not only for flagship products.
Incentives and culture
If product leaders are rewarded solely for launch speed, safety gates will be gamed. Include control effectiveness and serious-incident metrics in performance goals for AI system owners. Protect staff who raise deployment concerns in good faith.
Nonprofits, public agencies, and SMEs
Scale the model: a monthly working group can replace a formal council; the board (or equivalent) still needs a named oversight hook. SMEs should not copy megabank committee sprawl. They should still write who can say no.
Open questions
Specific director liability outcomes by jurisdiction—seek local counsel.
Proprietary “AI governance maturity” scores sold as objective truth.
Claims that an ethics advisory board alone satisfies EU or China duties.
Connecting to three-layer model
Principles (OECD/UNESCO) inform policy tone. Law sets hard gates. Practice (NIST/ISO) supplies the management system. Corporate governance is how the three layers get staffed and challenged.
Directors drown in slideware. Structure AI board packs as: (1) decisions needed; (2) risk appetite breaches or near-breaches; (3) regulatory countdown; (4) incidents; (5) metrics sparklines; (6) appendix inventory. Ban demo-only board sessions without risk content. Require dissent logs when the AI Council accepts high residual risk.
Interaction with cyber and privacy governance
AI governance should not create a fourth silo beside cyber, privacy, and operational risk. Prefer a hub-and-spoke: AI Council as hub; cyber/privacy/model-risk as spokes with clear interfaces. Shared taxonomies for incidents (confidentiality, integrity, availability, fairness, safety, consumer harm) prevent double-counting and gaps.
Public company disclosure themes
Where securities regulators and investors ask about AI, disclose risks and governance at a level matching other operational risks—neither hype nor vagueness. Review before reliance specific MD&A examples; counsel reviews jurisdiction-specific disclosure duties. Consistency between marketing AI claims and risk-factor language is itself a governance test.
Nonprofit and government boards
Public bodies should map AI oversight to existing audit/risk committees and to statutory transparency duties. Procurement is often the real control point: require assessment artifacts before contract award. Elected boards need plain-language briefings; jargon hides accountability.
Escalation thresholds for directors
Define which AI events must reach the board within 24–72 hours: personal safety harm; large-scale discriminatory impact; major regulator inquiry; material data leakage via GenAI; halt of a flagship AI product; credible catastrophic-misuse near miss for frontier developers. Write thresholds into incident policy. Ambiguity produces late surprises.
Subsidiary and franchise governance
Global groups often deploy AI in subsidiaries with weak reporting lines. Require subsidiaries to register Tier A systems in the group inventory; adopt the group AI policy baseline; and escalate FRIA/DPIA-equivalent assessments for group legal review when rights impacts are high. Franchisors should flow down AI rules in brand standards when franchisees use corporate AI tools.
Ethics advisory boards—use and misuse
External ethics advisors can challenge blind spots. They cannot replace legal compliance, risk acceptance authority, or engineering gates. If you appoint such a board, publish its mandate, independence rules, and whether advice is advisory only. Avoid using advisors as reputational shields after ignored warnings.
Model risk management heritage in banks
Banks already run model risk management (MRM) frameworks. Extend them to GenAI and agentic tools rather than inventing a rival process. Challenges: GenAI outputs are non-deterministic; RAG corpora change; prompt chains are code-like. Update MRM standards for qualitative validation, ongoing monitoring, and human-in-the-loop evidence. Regulators familiar with MRM will ask how GenAI fits—have an answer.
Startup board realities
Early-stage boards still need: inventory of AI features; named engineering owner; basic acceptable use; privacy review; and honesty in investor updates about regulatory exposure. Skip megabank committee counts. Do not skip the “who can halt launch” question. Customers of startups increasingly ask governance questions in security questionnaires.
Illustrative case study
A retailer board discovers customer-service GenAI gave unsafe product advice. Incident review finds no system owner, no eval suite for safety advice, and a marketing-led “innovation squad” outside risk review. The board assigns AI oversight to the risk committee, creates an Executive AI Council, freezes expansion of GenAI to regulated advice domains, and ties the CPO’s objectives to gate compliance. Within two quarters, inventory coverage rises and shadow tools are redirected to an approved enterprise assistant with logging. Lesson: governance is a control after failure—or before it, if you choose.
Practical Checklist
Name the board committee with primary AI oversight.
Approve an AI risk appetite statement (qualitative is fine).
Charter an Executive AI Council with decision rights.
Assign system owners for all Tier A systems.
Set quarterly AI risk reporting format.
Include shadow-AI in acceptable-use and DLP programs.
Align incentives for safe deployment.
Map governance to ISO 42001 leadership requirements.
Review before reliance maturity score vendors without evidence.
Review charter annually.
Board Questions
Which committee owns AI risk, and is that clear in writing?
Can management produce an inventory this week?
Who can halt a deployment?
How do incentives interact with safety gates?
What AI incidents rose to board level in the last year?
Are we concentration-risked on one model provider?
Does our governance cover employee tools as well as products?
How will agentic systems change oversight in the next 500 days?
Sample RACI snapshot
For “Deploy Tier A AI system”: System owner (R), AI Council (A for residual risk), Risk (C), Legal (C), Security (C), Business executive (I), Board risk committee (I for material). Write yours; train it; audit it.
Bridge
Chapter 19 details the assessments boards should see: AIA/DPIA/FRIA-style impact work and risk management methods.
Extended handbook notes — board and executive operating system
Sample quarterly AI risk dashboard (qualitative OK)
Sections: inventory coverage %; Tier A systems count and changes; open high residual risks; regulatory countdown (next 180 days); incidents/near misses; assurance status; concentration risk on providers; shadow-AI indicators; decisions needed from board. Keep to two pages plus appendix. Directors should finish with clear asks.
Delegations of authority
Write monetary and risk delegations: who may accept residual rights risks; who may approve China filings; who may enable new agentic tool permissions; who may publish safety frameworks. Ambiguous authority causes either paralysis or rogue launches.
Whistleblowing and psychological safety
AI harms are often spotted first by junior engineers or support agents. Ensure hotlines accept AI concerns; prohibit retaliation; and route technical concerns to risk—not only HR. Report anonymized themes to the board annually.
Mergers and acquisitions
AI due diligence: inventory; pending regulatory filings; open incidents; training-data litigation exposure; open-source license issues; assurance claims; Seoul/Hiroshima commitments; key person dependencies for model operations. Price risk into deals. Review before reliance valuation impacts—deal teams decide.
Agenda library for the Executive AI Council
Standing items: inventory deltas; Tier A approvals; incident review; regulatory calendar; vendor concentration; shadow-AI metrics; assurance findings; training completion; decisions log. Timebox demos to the end. Circulate papers 48 hours ahead. Record votes on residual risk acceptance. Publish minutes to the board committee pack quarterly. Rotate a “challenger” seat so the same leaders are not always marking their own homework.
Practitioner deep-dive — making oversight real
First 30 days after a governance failure
If an AI incident reveals missing ownership: (1) freeze related expansions; (2) name interim system owner; (3) complete emergency assessment; (4) brief board committee; (5) commission root cause; (6) charter AI Council if absent; (7) adjust incentives; (8) communicate with customers as counsel advises. Speed and humility beat spin.
Charters: risk committee AI appendix (pattern language)
“The Committee oversees management’s AI risk framework, including inventory completeness, high-impact deployment gates, regulatory programs material to the Group, and significant AI incidents. Management shall report quarterly. The Committee may meet in camera with risk and internal audit regarding AI.” Adapt to bylaws.
Executive scorecards
Include: percent Tier A with owners and current assessments; critical AI incidents; overdue audit actions; regulatory milestones hit/missed. Review before reliance composite trust scores. Tie a meaningful fraction of variable pay for AI product leaders to control metrics—enough to matter, not enough to incentivize metric gaming alone.
Additional practitioner notes
Directors should request at least one closed session yearly with the chief risk officer on AI without product leaders present, to surface suppressed concerns.
When AI strategy is transformative for the business model, consider full-board education sessions each half-year rather than burying updates in consent agendas.
Map AI governance to existing three-lines-of-defense language so audit, risk, and management roles stay intelligible to financial-services directors.
Require management to disclose concentration risk: share of AI features dependent on a single model provider, and exit options if that provider fails safety or availability tests.
Include labor impacts in board strategy discussions: augmentation versus replacement, reskilling budgets, and monitoring for discriminatory workplace AI.
For dual-listed companies, align AI risk disclosure themes across jurisdictions without copying false precision into filings.
Test crisis communications for AI scandals in tabletop form with the board chair and CEO—roles, holding statements, and customer remediation authority.
Ensure the corporate secretary tracks AI-related regulatory correspondence in the same system as other material regulator letters.
Challenge management if ethics advisory panels are showcased while deployment gates remain unsigned.
Ask whether agentic roadmaps have been risk-accepted at board level or only demoed to the innovation committee.
Primary-source route: S04 NIST · S20 ISO | Return to contents
Chapter 19: Risk Management and Impact Assessment
Operationalizing AIA, DPIA, FRIA, and bias testing without paperwork theater
Overview
Key point: Risk management turns AI principles into go/no-go decisions. Impact assessment asks who can be hurt and how. In the EU, deployers of certain high-risk systems face fundamental rights impact assessment duties under Article 27 of Regulation (EU) 2024/1689 (FRIA). Separately, GDPR Article 35 DPIAs remain required when processing is likely high risk for rights and freedoms. Algorithmic impact assessments (AIA) used in public-sector and enterprise practice are cousins: structured questions before deployment. Boards should demand a single assessment spine that can generate FRIA/DPIA views—not three disconnected PDFs written after launch.
Learning Objectives
Distinguish risk management (enterprise/system) from impact assessment (people/rights).
Explain EU FRIA (Art. 27) and GDPR DPIA coexistence at a plain level.
Build a tiered assessment method aligned to NIST Map/Measure and ISO 42001 Clause 6.
Integrate bias and robustness testing as evidence, not vibes.
Review before reliance non-EU “AIA statutes” unless you cite the specific law that applies.
Core Analysis
Two questions every deployment must answer
What can go wrong for the enterprise and society? (risk management)
Whose rights and interests are affected, and how are they protected? (impact assessment)
Confusing them produces either security-only reviews that ignore discrimination, or ethics essays that ignore cyber misuse and model theft.
EU FRIA (Article 27) — plain map
For in-scope high-risk deployers, Article 27 requires an assessment of impact on fundamental rights before deploying the system (with elements specified in the Act—confirm current consolidated text for your role). Typical practical contents include: processes in which the system is used; deployment period and frequency; categories of persons affected; specific risks of harm; human oversight measures; and measures if risks materialize. Coordinate with the provider’s instructions and risk information. Review before reliance edge cases on who must FRIA when roles blur—counsel classifies.
GDPR DPIA (Article 35)
If personal-data processing via AI is likely high risk (profiling, large-scale sensitive data, systematic monitoring themes), complete a DPIA: necessity/proportionality; risks to rights; mitigations. A FRIA does not automatically satisfy a DPIA or vice versa, but integrated templates reduce duplication. Record lawful bases and retention for prompts/logs/embeddings.
NIST and ISO hooks
NIST AI RMF Map identifies context and risks; Measure quantifies/estimates; Manage treats and monitors; Govern sets culture. ISO/IEC 42001 Clause 6 expects AI risk assessment and impact assessment processes inside the AIMS. Use those hooks so assessments are living controls, not launch-day PDFs.
A practical assessment spine (enterprise)
Step 0 — Screen: Is it AI? Tier A/B/C? Personal data? EU high-risk? China public service? Safety-critical sector?
Step 1 — Context: Purpose, users, affected persons, deployment environment, autonomy level.
Step 2 — Rights & harms: discrimination, privacy, expression, access to services, physical harm, financial harm, child impacts.
Step 3 — Technical risks: hallucinations, robustness, security (prompt injection, data exfiltration), misuse, drift.
Step 4 — Tests: bias metrics suitable to context; red teams; domain evals; accessibility checks.
Step 5 — Controls: human oversight, fallback, transparency, rate limits, monitoring, appeals.
Step 6 — Decision: deploy / deploy with conditions / reject; residual risk owner signature.
Step 7 — Monitor: triggers for reassessment (model change, new population, incident).
Bias testing without false precision
Choose metrics that match the decision type (selection rates, calibration, error disparities) and document data limits. Qualitative review still matters when protected-class labels are unavailable. Review before reliance any claim of “zero bias.” Say “tested against X; residual risk accepted by Y.”
Algorithmic impact assessment (public-sector lineage)
Canada’s Directive on Automated Decision-Making and various city/agency AIA templates popularized questionnaire-style assessments. Enterprises can borrow structure (impact levels, peer review, publication norms) without pretending those directives bind them outside their jurisdictions. Review before reliance: cite the specific public instrument if you claim legal compulsion.
Common failure modes
Assessment written after marketing launch.
Copy-paste FRIA across products.
Ignoring downstream fine-tunes that change impact.
Testing only average accuracy, never subgroup or misuse cases.
No reassessment when switching foundation-model providers.
Open questions
Exact Art. 27 field list if your counsel’s consolidated text differs—verify EUR-Lex.
Digital Omnibus timing changes that affect when high-risk duties bite—track Chapter 11 updates.
Vendor “automated FRIA generators” that invent rights analysis without human judgment.
Human oversight design as assessment output
Assessments should specify oversight mode: in-the-loop, on-the-loop, or post-hoc review—and why that mode matches residual risk. Define escalation triggers (confidence scores, anomaly flags, customer vulnerability indicators). Train overseers; measure override rates; investigate both rubber-stamping and alert fatigue. An assessment that says “human oversight exists” without design detail is incomplete.
Reassessment triggers (write them down)
Reassess when: model or prompt chain changes materially; training/RAG data shifts; user population expands to new geographies or ages; legal classification changes; serious incident occurs; monitoring detects drift; or six to twelve months elapse for Tier A. Put triggers in the assessment record so they are auditable.
Cross-walk table
| Enterprise AI risk assessment |
Business + safety + security risks |
Risk + system owner |
| DPIA |
Personal-data rights risks |
Privacy |
| FRIA Art. 27 |
Fundamental rights impacts for in-scope high-risk deployers |
Deployer compliance + legal |
| Sector safety case |
Physical safety / clinical |
Safety / quality |
| Bias test report |
Fairness evidence |
Science / risk |
One spine, multiple views.
Quantitative vs. qualitative risk
Some AI risks allow quantitative estimates (error rates, latency, fraud lift). Rights harms and novel misuse often require qualitative severity–likelihood grids with narrative. Do not fake numeric precision. Do record assumptions. For frontier severe risks, scenario analysis and capability evals matter more than color heat maps alone. Present both styles to the AI Council with clear uncertainty language.
Third-party components in assessments
If your system embeds a foundation model, a vector database, and a tool-calling agent runtime, the assessment must include each component’s failure modes and your residual responsibility. “Vendor said it’s safe” is not an assessment. Attach vendor diligence and your own domain evals.
Rights impact categories checklist (starter)
Consider: non-discrimination and equality; privacy and data protection; freedom of expression and information; children’s rights; access to essential services; due process and contestability; physical and psychological safety; labor rights; environmental impacts of large training/deployments where material. Not every system hits every category. Screening should justify exclusions briefly. Review before reliance scoring schemes that claim scientific precision across all rights.
Evidence quality rubric
Score each assessment: completeness of context; clarity of affected persons; quality of tests; specificity of oversight; realism of residual risk language; reassessment triggers. Peer-review Tier A assessments. Reject circular statements (“risk is low because we are responsible”).
Illustrative case study
A public employment service pilots an AI ranking tool for caseworker queues. Screening flags EU high-risk employment themes and GDPR profiling risk. The team runs an integrated DPIA/FRIA-style assessment, finds higher false deprioritization risk for some language groups, adds human review for edge scores, publishes a plain-language notice, and sets a six-month reassessment. The pilot proceeds with conditions. Lesson: assessment changed the system, which is the point.
Practical Checklist
Adopt a single assessment spine with FRIA/DPIA modules.
Screen every AI use case before development spend scales.
Require residual-risk signatures for Tier A.
Link tests (bias/robustness) to assessment IDs.
Reassess on model, data, or population change.
Store assessments in the AIMS documented information set.
Train product managers to start assessments early.
Review before reliance automated legal conclusions from tools.
Align with Article 27 when you are an in-scope deployer.
Report Tier A assessment status to the AI Council quarterly.
Board Questions
What fraction of Tier A systems have current assessments?
Who signs residual risk?
Are FRIAs and DPIAs integrated or duplicated?
Which deployments proceeded with unresolved high rights risks?
How do we reassess after foundation-model swaps?
Are bias tests meaningful for our data reality?
Do assessments influence design—or only binders?
What assessment quality issues has audit found?
Template fields (minimum)
System ID; owner; purpose; persons affected; legal flags (EU/UK/US/China); data categories; autonomy; oversight plan; key risks; tests run; mitigations; residual risk; review date; halt criteria. Keep to something staff will complete.
Bridge
Chapter 20 deepens data governance and transparency controls that assessments almost always require.
Extended handbook notes — assessment craft
Facilitation tips for assessment workshops
Gather system owner, data owner, legal, security, and a challenger who does not benefit from launch. Walk the spine. Capture disagreements. Timebox. Require written residual risk. Ban “we’ll fix it later” without a dated action and interim control. For high-stakes systems, invite an external reviewer.
Special cases: generative AI and RAG
Assess hallucination harm in the domain; data leakage via prompts; retrieval of sensitive documents; over-reliance by users; and jailbreaks that bypass policies. Test with domain red teams, not only generic toxicity lists.
Special cases: biometric and workplace AI
Heightened rights impacts; legal prohibitions may apply under EU Art. 5 themes or national labor law. Screen early. Review before reliance deployment until counsel clears.
Publication and transparency of assessments
Public agencies sometimes publish AIA summaries. Private firms may publish high-level summaries for trust. Never publish credentials or exploit details. Legal reviews publications.
Connecting assessments to product requirements
Every medium/high risk in an assessment should generate a tracked requirement: control, test, or acceptance. Link tickets to assessment IDs. At launch review, verify requirements closed or explicitly deferred with interim mitigations. This is how assessments change products instead of decorating SharePoint.
Practitioner deep-dive — assessment quality control
Peer review rubric (0–2 each)
Context clarity; affected persons specificity; legal flag accuracy; test adequacy; oversight design; residual risk honesty; reassessment triggers; action linkage. Total below a threshold returns the assessment for rework. Publish rubric internally so teams know the bar.
Library of scenarios
Maintain scenario cards: discriminatory lending outcome; medical advice hallucination; child-directed chatbot manipulation; deepfake of executive; agent wrong payment; poisoned RAG document; model provider silent version change. Use cards in workshops to force concrete mitigations.
When to kill a project
Assessments should sometimes stop projects. Criteria examples: prohibited practice risk under EU Art. 5 themes; unacceptable rights impact without feasible mitigation; inability to provide contestability; security inability to protect model/data; legal classification unresolved with launch pressure. Record kills as governance successes.
Additional practitioner notes
Assessment templates should force a plain-language ‘who could be hurt’ paragraph before any risk matrix graphics.
Include environmental impact screening for large training runs when material to your operations; review before reliance global average energy figures.
For credit and insurance, connect assessments to existing fair-lending or treating-customers-fairly analyses rather than creating orphan AI ethics forms.
Document uncertainty: what you could not test, and why residual risk is still accepted.
Require version pins: assessment applies to model version X, prompt pack Y, corpus hash Z.
When using automated assessment assistants, human experts must still own legal and rights conclusions.
Store assessments where e-discovery can find them; do not hide them in personal drives.
Compare pre-launch predicted harms with post-launch incidents annually to improve calibration.
For multi-tenant SaaS, assess both platform-level and tenant-configuration risks.
Kill zombie assessments that describe systems no longer in production.
Primary-source route: S06 European Union · S04 NIST | Return to contents
Chapter 20: Data Governance and Transparency
Lineage, quality, privacy, explainability, and user-facing disclosures
Overview
Key point: Most AI failures are data failures wearing a model costume—wrong labels, leaked personal data in prompts, undocumented training sources, or silent distribution shift. Transparency failures are cousin problems: users do not know AI is involved; enterprises cannot explain decisions; regulators cannot trace responsibility. This chapter ties data governance (lineage, quality, privacy, retention) to transparency duties across the EU AI Act (including Article 50-type labeling themes), China deep-synthesis labeling, UK “appropriate transparency,” and emerging US state disclosure rules—without cloning earlier landscape chapters.
Learning Objectives
Build a data control set for training, fine-tuning, RAG, and logs.
Explain lineage and quality as board-visible metrics.
Implement transparency scaled to risk (not weight dumps).
Connect explainability techniques to contestability.
Review before reliance proprietary “full explainability” claims for deep models.
Core Analysis
Data domains that need owners
| Pretraining corpora |
Web scrapes, licensed sets |
IP, personal data, illegal content |
| Fine-tune sets |
Curated instructions, domain docs |
Bias, confidential leakage |
| RAG corpora |
Enterprise knowledge bases |
Access control, staleness |
| Prompts & outputs logs |
User content, tool traces |
Privacy, retention, discovery |
| Evaluation sets |
Gold tests, red-team prompts |
Overfitting to evals; leakage |
| Telemetry |
Click/feedback data |
Purpose limitation |
Assign a data owner per domain for Tier A systems.
Lineage minimum viable practice
Record: source system; collection date; license/terms; personal-data flag; transformation steps; responsible steward; link to model versions that consumed the data. You rarely need perfect byte-level provenance on day one; you need enough to answer “can we use this?” and “what do we delete?” Review before reliance marketing claims of complete web-scale provenance unless evidenced.
Quality and fitness
Fitness depends on purpose. A chatbot FAQ corpus and a clinical decision-support corpus demand different quality bars. Define acceptance tests: freshness, coverage, toxicity filters, PII scrubbing where required, and human spot checks. Drift monitoring should watch input features and output distributions—not only loss curves.
Privacy and secrecy
Apply DPIA triggers; minimize personal data in prompts; separate secrets from model contexts; encrypt logs; set retention; honor deletion where legally required (knowing model unlearning limits—be honest). Enterprise GenAI gateways help; they are not magic. Review before reliance claims that a filter “guarantees” no personal data leaves the tenant.
Transparency layers
User notice: AI is involved.
Synthetic content labels: where EU Art. 50 / China deep synthesis / state laws require.
Decision explanation: suitable detail for impacted persons.
Technical documentation: for regulators, auditors, and enterprise customers.
Public reports: voluntary transparency reports for frontier or platform actors.
Engineering options include visible labels, machine-readable credentials (e.g., C2PA Content Credentials where adopted), watermarking research, and latent disclosures—choose based on legal triggers and robustness needs. Review before reliance any single watermark as unbreakable.
Explainability techniques (use with humility)
Feature attributions, counterfactuals, concept methods, retrieval citations for RAG, and rule extractions for hybrid systems can support explanations. For large generative models, prefer process explanations (what tools were called; what policy blocked an answer) plus uncertainty communication over fake causal certainty. Document limits.
Transparency and trade secrets
You can protect genuine secrets while disclosing: AI involvement; high-level factors; oversight methods; data categories; and contact routes. Fight the false binary “full open weights vs. total opacity.”
Open questions
Exact Art. 50 operative details for every modality—confirm Act text and guidance.
State-law operative dates (Chapter 12).
Vendor claims of perfect provenance or unremovable watermarks.
RAG governance in detail
Retrieval-augmented generation fails when access controls on source systems are bypassed by the assistant; when citations are fake; when stale documents dominate; or when confidential folders are indexed without approval. Controls: inherit ACLs; require citations; block answer-without-retrieval in high-stakes modes; inventory indexed sources; run red teams for retrieval jailbreaks; log retrieval IDs for audit. Treat the index as a production data store with change management.
Training-data transparency vs. trade secrecy
California-style training-data documentation and EU GPAI summary themes push developers to disclose categories and sources at a useful level. Build a documentation pipeline early: dataset registry → public summary generator → legal review. Fighting every disclosure often costs more than structured transparency. Review before reliance exact statutory field lists—verify operative law.
Employee communications
Transparency is not only external. Tell employees when AI monitors productivity or screens HR decisions (subject to labor and privacy law). Hidden workplace AI destroys trust and creates legal exposure. Pair notices with contestability routes.
Synthetic data governance
Synthetic data can reduce personal-data exposure or amplify biases if poorly generated. Document generation method, seed data sensitivity, quality checks, and whether synthetic sets could still memorize personal information. Label synthetic sets in the registry so they are not mistaken for measured reality in model monitoring.
Cross-border data transfers for GenAI
Prompts may leave the country when APIs are called. Map transfer mechanisms (contractual clauses, adequacy, etc.) and regional routing features. Review before reliance specific transfer mechanism recommendations—privacy counsel decides. Product must not silently enable global routing that breaks local law commitments.
Logging architecture for accountability
Log: model/version IDs; retrieval document IDs; tool calls; policy blocks; human overrides; user notices shown. Protect logs with access control and retention limits. Logging enables contestability and incident response; over-logging creates privacy risk. Design on purpose. Review before reliance indefinite retention “for AI improvement” without legal basis analysis.
Explainability for generative agents
When agents plan and call tools, explain the plan and tool results to users or operators at a suitable level. Provide “why blocked” messages when policies refuse actions. Store plan traces for audit in high-risk domains. This process transparency often helps more than token-level attributions.
Illustrative case study
A bank’s RAG assistant cites outdated fee PDFs, giving wrong customer explanations. Root cause: no corpus owner, no freshness SLA, no citation display. Fix: data owner; weekly crawl validation; answer citations; decline to answer when retrieval confidence is low; transparency notice that answers are AI-assisted. Complaints fall. Lesson: transparency + data ownership beat model swaps alone.
Practical Checklist
Name data owners for each Tier A data domain.
Implement lineage records linked to model versions.
Set retention for prompts/logs.
Deploy AI-use notices for customer-facing systems.
Implement synthetic content labeling where legally triggered.
Prefer RAG citations for enterprise Q&A.
Run PII/secret scanning on outbound GenAI gateways.
Document explainability limits honestly.
Align China/EU/US labeling engineering where possible.
Review before reliance “fully explainable deep net” sales language.
Board Questions
Who owns training and RAG data quality for our top AI systems?
Can we produce lineage for our last Tier A launch?
What is our prompt-log retention and legal-hold posture?
Where are we legally required to label synthetic content?
Do customers get meaningful explanations for AI-influenced decisions?
How do we prevent secrets from entering public models?
Are transparency claims consistent across markets?
What investments in Content Credentials or labels are planned?
Operating metrics
Percent of Tier A systems with named data owners; median corpus age; labeling defect rate; number of privacy incidents involving GenAI logs; explanation request SLA performance. Review quarterly at the AI Council.
Bridge
Chapter 21 addresses what happens when harms occur despite these controls: liability, insurance, and redress.
Extended handbook notes — data and transparency operations
Dataset registry fields
ID; name; source; license; personal data flag; sensitive categories; owner; creation date; last review; linked models; retention; geographic storage; quality checks performed; known limitations. Start with Tier A linked datasets.
Prompt injection and data exfiltration defenses
Gateway filters; allowlists for tools; output DLP; compartmentalized credentials for agents; monitoring for unusual export volumes. Review before reliance any vendor’s “guaranteed” prompt-injection immunity.
Customer-facing transparency UX patterns
Pre-use notice; in-thread AI label; expandable “how this answer was produced” for RAG; feedback button; human handoff. Test with users. Measure comprehension qualitatively.
Retention vs. improvement tension
Product wants long logs for fine-tuning; privacy wants minimization. Set purpose-specific retentions; anonymize where feasible; document tradeoffs in DPIA. Review before reliance indefinite retention justifications.
Data poisoning and integrity
For systems that continually learn or that refresh RAG corpora, integrity controls matter: signed sources; review before index; anomaly detection on corpus diffs; rollback capability. Review before reliance advanced cryptographic provenance as universally deployed—use where available (e.g., Content Credentials) without claiming ubiquity.
Practitioner deep-dive — transparency engineering backlog
Prioritized backlog themes
P0: legally required labels and notices by market.
P1: RAG citations and confidence declines.
P2: Content Credentials / machine-readable provenance where customers demand.
P3: public model/system cards for major products.
P4: research watermarks evaluated honestly for robustness.
Fund P0 before P4. Review before reliance watermarks as complete solutions.
Data deletion and models
Be honest with customers: deleting a record from a database may not remove influence from a trained model. Offer process explanations, suppressions, and future-training exclusions where feasible. Document limits in privacy notices. Review before reliance “machine unlearning complete” claims without technical evidence.
Additional practitioner notes
Create a data-incident subtype for GenAI leaks and track it separately in privacy metrics.
Ban pasting secrets into unapproved tools via DLP and cultural reinforcement; measure blocked attempts.
For synthetic media products, maintain a label QA sample each release—human review of outputs for missing labels.
Publish an internal ‘explanation style guide’ so customer explanations are consistent and not improvised by each agent.
Separate training data licenses from inference-time retrieved content licenses in legal review.
When fine-tuning on customer data, contract for permitted uses and deletion schedules explicitly.
Evaluate third-party data brokers for AI training with the same diligence as privacy procurement.
Align transparency UX with accessibility standards so notices are perceivable.
Record when marketing claims exceed what system cards support—and correct them.
Treat embeddings stores as personal data repositories when they encode personal information.
Primary-source route: S06 European Union · S05 NIST | Return to contents
Chapter 21: Liability, Insurance, and Redress
EU Product Liability Directive 2024/2853, withdrawn AI Liability Directive, tort, insurance, and customer redress
Overview
Key point: When AI causes harm, victims and firms meet liability law—not ethics slogans. In the EU, Directive (EU) 2024/2853 revises product liability to cover software including AI systems as products, with application to products placed on the market or put into service after early December 2026 (verify consolidated/corrigendum text for the precise ‘after 8/9 December 2026’ formulation). The separate AI Liability Directive proposal (COM/2022/496) was withdrawn (OJ notice lineage October 2025). US exposure remains largely tort, contract, and sector statutes. Boards need redress paths, insurance dialogue, and evidence hygiene—not invented fine tables.
Learning Objectives
Explain why PLD 2024/2853 matters for AI software providers and component integrators.
Note the AILD withdrawal and review before reliance residual national fault rules.
Design customer redress and contestability that reduce harm and litigation heat.
Prepare insurance and contractual risk transfer without magical thinking.
Review before reliance exact damages categories and presumptions—read the Directive text with counsel.
Core Analysis
EU Product Liability Directive (EU) 2024/2853 — plain map
Adopted 23 October 2024, the Directive modernizes no-fault product liability for the digital age. Recitals and definitions clarify that software—including AI systems—can be a product, whether standalone or integrated, including certain supply modes discussed in the text (verify SaaS boundary analysis with counsel). Manufacturers of software, including AI system providers in the AI Act sense, are treated in manufacturer roles for liability analysis. Updates and upgrades within manufacturer control can matter for defectiveness analysis. Free and open-source software developed/supplied outside commercial activity has specific treatment—review before reliance edge cases.
Timing: Member States transpose by 9 December 2026 themes; the Directive applies to products placed on the market or put into service after the Directive’s application date (corrigendum activity around ‘after 8 December 2026’ vs original ‘after 9 December 2026’—verify the consolidated EUR-Lex text before filings). Older Directive 85/374/EEC continues for earlier products as transitional themes provide.
Board takeaway: From the application date forward, AI products in commercial supply chains face a modernized strict-liability environment in the EU. Documentation, update control, and defect monitoring become litigation evidence—not optional niceties.
AI Liability Directive proposal — withdrawn
The Commission’s 2022 proposal on non-contractual fault-based AI liability was withdrawn as part of the 2025 work programme cleanup (formal withdrawal publication lineage 6 October 2025 on EUR-Lex procedure tracking). Do not cite AILD as future binding law. National fault-based tort rules and other EU instruments still apply. Review before reliance commentary that “there is no AI liability in Europe”—PLD and national law remain.
US and other common-law textures (high level)
Expect negligence, products liability theories varying by state, contract warranties, consumer-protection claims, and sector rules (employment, credit, health). Class actions and discovery into training data, evals, and known failure modes are the practical risk. Review before reliance any single “US AI liability statute” claim unless citing a specific enacted law.
Redress as a control
Redress is not only post-judgment. Build: clear complaint channels; human review for material AI decisions; refund/remediation playbooks; preservation of logs for fairness; and public communications that do not admit liability carelessly. Contestability (UK principle; EU rights themes) reduces harm escalation. Measure time-to-fix and overturn rates.
Insurance dialogue
Cyber policies may not cleanly cover AI discrimination or hallucination harms. Talk to brokers about: media/tech E&O; cyber; product liability; and exclusions for generative content. Review before reliance premium figures. Insurers will ask for assessments, monitoring, and human oversight evidence—the same artifacts Chapters 19–20 demand. Do not assume “we have cyber insurance” equals AI coverage.
Contracts and risk transfer
Flow down: safety requirements; update obligations; incident notice; indemnity where lawful; audit rights; and halt cooperation. Upstream, avoid accepting unlimited liability for foundation-model black boxes you cannot test—negotiate caps and shared diligence. Review before reliance enforceability of indemnity across jurisdictions.
Evidence hygiene for litigation readiness
Preserve: model versions; assessments; known limitations disclosed; incident tickets; human override logs; user notices. Legal hold procedures must include AI systems. Deleting inconvenient logs is a separate legal disaster.
Interaction with AI Act roles
AI Act compliance failures can inform negligence narratives even though the Act is public-law regulation. Conversely, PLD liability can attach even when AI Act classification is debated. Run compliance and liability programs as siblings.
Illustrative case study
A GenAI customer-support bot authorizes incorrect refunds at scale. Customers are harmed financially; the firm faces chargebacks and potential product-liability theories for defective software behavior. The firm activates redress (honor corrections quickly), preserves logs, notifies carriers, and patches oversight thresholds. Post-incident, the AI Council requires human approval above a monetary limit. Lesson: redress speed and evidence matter as much as model accuracy.
Practical Checklist
Map AI products to PLD manufacturer/component roles with counsel.
Calendar EU PLD application timing for new placements.
Remove AILD from forward-looking compliance plans.
Create redress SLAs for AI-influenced customer harm.
Review insurance policies for AI exclusions.
Align contracts with update and incident duties.
Preserve assessment and log evidence.
Train counsel and engineers on litigation holds for AI.
Review before reliance corrigendum date wording—verify EUR-Lex.
Report residual uninsured AI risks to the board.
Board Questions
Which AI systems could be ‘products’ under PLD analysis?
Are we ready for 2026+ placement rules in the EU?
What AI harms does insurance actually cover?
How fast can we redress customers when AI errs?
Who owns litigation holds for model logs?
Do contracts with model providers allocate risk realistically?
Are we still planning as if AILD will pass?
What residual risk will the board explicitly accept?
Open questions
Exact PLD application-day wording after corrigenda.
National transposition differences.
Damages categories and disclosure/presumption mechanics—use primary text.
Bridge
Chapter 22 covers auditing and assurance that produce the evidence liability and insurance stakeholders demand.
Extended handbook notes — liability and redress operations
Litigation hold playbook for AI
When dispute is reasonably anticipated: suspend deletion of prompts, outputs, model versions, eval sets, assessment docs, Slack/tickets about the system, and vendor notices. Notify system owners. Image relevant repositories. Train staff not to “clean up” failing examples. Review before reliance jurisdiction-specific hold rules—litigation counsel directs.
Customer redress runbook
Severities: S1 physical safety / rights-critical; S2 significant financial; S3 minor. For S1/S2: human contact within hours; containment (disable feature if needed); remediation offers approved by counsel; root-cause started within 24 hours; regulator notice if legally required. Publish internal SLAs. Measure compliance.
Product security meets product liability
Defectiveness analysis will look at warnings, updates, and reasonable safety expectations. Ship clear limitation statements without overclaiming safety. Patch known dangerous failure modes promptly. Document why certain residual risks remain.
Cross-border judgment and class exposure
A model shipped globally can generate multi-forum disputes. Keep a jurisdiction map for where you place products. Review before reliance forum strategy—disputes counsel leads.
Insurance application questionnaires
Answer consistently with your assessments and monitoring reality. Inconsistencies create coverage fights. Involve risk and legal in applications. Update carriers after material AI product launches.
Warnings, instructions, and the “reasonable expectation of safety”
Product liability analysis often considers instructions and warnings. For AI, that means: intended use statements; prohibited uses; known failure modes; required human oversight; update obligations on deployers. Write them in plain language. Keep them versioned with the model. Marketing must not contradict warnings. Review before reliance jurisdictional nuances on warning adequacy—product counsel drafts.
Practitioner deep-dive — preparing for PLD-era placements
Pre-2026 worklist for EU-facing AI products
Role map: manufacturer, component producer, deployer implications.
Warning/instruction review for AI products.
Update and vulnerability handling process for models/software.
Defect monitoring and complaint trending.
Evidence repository for design and testing.
Insurance re-brokerage conversation.
Counsel memo on corrigendum application dates.
Training for product managers on “product” framing of AI.
Settlement and apology protocols
Coordinate communications, legal, and redress. Apologies can be humane without unauthorized legal admissions. Pre-draft templates for AI errors. Review before reliance jurisdiction-specific apology laws—local counsel reviews.
Additional practitioner notes
Run a yearly joint session among legal, risk, product, and insurance broker focused only on AI products.
Track AI-related complaints as a leading indicator even when not yet lawsuits.
Review terms of service limitations of liability for enforceability and consumer-law conflicts by market.
For open-source AI components used commercially, analyze who may be treated as manufacturer under PLD themes with counsel.
Preserve eval datasets that show known failure modes—they may be discoverable but also demonstrate due care if acted upon.
Coordinate product recalls or feature disables with liability counsel when defects are systemic.
Do not let sales promise ‘zero risk’ indemnities your balance sheet cannot support.
Map where AI outputs are relied upon as professional advice; those domains need stronger human ownership.
Update incident severity matrices to include mass incorrect automated decisions.
Review before reliance expected settlement values—finance and counsel estimate case by case.
Primary-source route: S21 European Union · S22 European Parliament | Return to contents
Chapter 22: Auditing and Third-Party Assurance
Internal audit, external assurance, frontier evaluations, and continuous monitoring—without fake assurance levels
Overview
Key point: Boards and customers ask “who checked?” Auditing AI means testing controls and outcomes—not rubber-stamping ethics posters. Combine internal audit (management-system and control testing), model evaluation (performance, safety, fairness), and selective third-party assurance. Treat proprietary “AAL-1…AAL-4” marketing schemes as vendor proposals unless tied to a public standard you can cite. Prefer ISO/IEC 42001 audits, SOC-style control reports where scoped honestly, domain evaluations, and continuous monitoring for high-change GenAI systems.
Learning Objectives
Distinguish management-system audit, model evaluation, and red-teaming.
Scope third-party assurance so certificates match products.
Design continuous monitoring for drift and incident detection.
Review before reliance non-standard assurance-level brands.
Connect audit findings to corrective action and board reporting.
Core Analysis
Three assurance lanes
Management-system / control audit — Is the AIMS real? (ISO 42001, internal audit).
Model and system evaluation — Does the system meet performance, safety, and fairness bars for its use?
Adversarial testing — Red teams for misuse, prompt injection, jailbreaks, data exfiltration.
All three matter. None replaces the others.
Internal audit program
Extend the annual audit plan: inventory completeness; assessment quality; deployment gate effectiveness; logging/retention; vendor diligence; labeling; incident response. Sample Tier A changes. Report to audit committee. Require management remediation dates. Review before reliance “continuous auditing” claims unless telemetry and analytics truly exist.
Third-party assurance options (honest scopes)
ISO/IEC 42001 certification (organizational AIMS).
ISO 27001 / SOC 2 for security control environments that AI rides on.
Independent model evaluations for defined threat models.
Sector certifications where they exist (health, aviation themes).
Avoid: vague “Trusted AI” logos without procedures; assurance reports that exclude the production system customers buy; recycled reports older than major model changes.
Frontier evaluation
Frontier developers should fund dangerous-capability evaluations and external scrutiny consistent with Seoul frameworks and EU systemic-risk duties where applicable. Deployers should demand summaries. Review before reliance numeric catastrophic-risk probabilities without methods.
Continuous monitoring
For GenAI: track refusal rates, toxicity/safety classifier hits, retrieval failures, human override rates, customer complaint tags, and drift in input/output distributions. Alert owners. Feed incidents into Chapter 19 reassessment triggers. Monitoring is assurance between audit cycles.
On proprietary assurance ladders
Older manuscript drafts referenced multi-level frontier auditing ladders and branded runtime frameworks. Unless you can cite a public standard or peer-reviewed specification the board adopts knowingly, treat them as optional tools, not law. This handbook will not invent AAL tiers or productize unverified frameworks.
Auditor competence
AI audits fail when financial auditors lack ML literacy or when ML researchers lack control-testing discipline. Pair skills. Provide system demos, data dictionaries, and threat models. Grant deep access under NDA for serious assurance—shallow demos produce shallow reports.
Illustrative case study
A company markets “independently audited AI” based on a SOC 2 report that never tested the recommendation model’s fairness or the GenAI assistant’s hallucination controls. A journalist notices. The firm restates claims, commissions a scoped AI evaluation, and aligns marketing with assurance scope. Lesson: scope discipline is ethical and legal hygiene.
Practical Checklist
Put AI into the internal audit plan.
Define Tier A evaluation requirements.
Match public assurance claims to report scopes.
Implement monitoring dashboards for GenAI.
Remediate audit findings with owners and dates.
Re-audit after major model changes.
Review before reliance proprietary AAL marketing.
Train audit staff or hire specialist co-source.
Share red-team high findings with the AI Council.
Brief the audit committee annually on AI assurance.
Board Questions
What assurance exists for our top five AI systems?
Do marketing claims match report scopes?
How continuous is our monitoring, really?
Who remediates audit findings?
Are frontier evals relevant to our vendors?
What access do external assurers get?
How do assurance results affect deployment gates?
What review-dependent frameworks are vendors selling us?
Open questions
Any numbered assurance level scheme not in ISO/NIST.
Survey statistics about agent detection without primary cites.
Bridge
Chapter 23 turns to agentic AI—where auditing must follow tool-using systems at runtime.
Extended handbook notes — assurance program design
Annual AI assurance calendar
Q1: update audit universe and Tier A list. Q2: internal audits of gates and assessments. Q3: external evaluation sampling / certification surveillance. Q4: management review of assurance findings and budget for next year. Align with financial audit cycles where helpful but do not bury AI issues inside generic IT audits only.
Sampling strategies
Risk-based: all Tier A; sample Tier B; rare Tier C. Within systems, sample changes, not only steady state. Include at least one GenAI and one classical ML system each year for method diversity.
Red-team governance
Scope threat models; rules of engagement; data handling; severity rubric; fix verification. Do not punish teams for findings. Track mean time to remediate critical jailbreaks. Review before reliance public disclosure of exploit details.
Customer assurance questionnaires
Build a knowledge base answering common asks: ISO status; eval summaries; subprocessors; incident history high-level; human oversight; logging. Keep versioned. Avoid contradictory answers across RFPs.
Dual-running classical and GenAI audits
Classical score-based models need stability, challenger models, and backtesting themes familiar to MRM. GenAI needs eval harnesses, jailbreak tests, and retrieval audits. Train auditors on both. A single checklist copied from credit scoring will miss prompt injection; a chatbot red team will miss PD calibration. Maintain two method annexes under one AI audit program.
Practitioner deep-dive — standing up AI internal audit
Skills matrix
Control testing; sampling; interviewing; basic ML literacy; GenAI threat literacy; privacy literacy; reading evaluations; writing findings that management can action. Hire or co-source gaps. Rotate guest engineers into audit for time-boxed tours.
Finding language examples
Weak: “AI ethics should be improved.” Strong: “Three of five Tier A deployments in the sample lacked residual-risk acceptance signatures before production (Procedure AIR-06), increasing unauthorized risk-taking; require signatures and block pipeline without ticket evidence within 30 days.”
Continuous monitoring vs. continuous auditing
Monitoring is operational telemetry. Continuous auditing implies automated control tests with auditor oversight. Review before reliance vendor claims of fully continuous AI auditing. Start with monitoring plus quarterly audit samples.
Additional practitioner notes
Include AI in integrated audits with cyber and privacy to reduce assessment fatigue while preserving AI-specific tests.
Require management self-assessments before auditor fieldwork to accelerate sampling.
Track ‘repeat findings’ on AI gates as a cultural metric—repeats mean governance theater.
When using external model eval vendors, review their conflict-of-interest and data-handling practices.
Assure that monitoring alerts have on-call owners; unowned alerts are not controls.
Sample marketing webpages for assurance overclaims during brand audits.
For high-risk EU systems, align assurance evidence packs early with conformity needs.
Document auditor access paths to non-public eval results under confidentiality.
Re-perform critical calculations or evals on a sample basis rather than trusting screenshots.
Report assurance coverage gaps explicitly to the audit committee (‘these three Tier A systems unaudited this year because…’).
Additional practitioner notes
Track repeat findings on AI gates as a cultural metric—repeats mean governance theater.
Report assurance coverage gaps explicitly to the audit committee.
Pair AI literacy training for auditors with control-testing training for ML staff on temporary rotation.
Assurance programs should publish an annual internal coverage statement to the audit committee: systems covered, methods used, major findings themes, and residual coverage gaps. That statement is more useful than a purchased logo.
Keep assurance scoping honest: if the report excludes GenAI production systems, do not imply otherwise in sales.
Primary-source route: S04 NIST · S20 ISO | Return to contents
Part V — The frontier and the program (Ch. 23–25, Conclusion)
Chapter 23: Agentic AI – The Next Governance Frontier
Planning, tool use, memory, runtime controls, and human authority at machine speed
Overview
Key point: Agentic AI systems plan multi-step tasks, call tools and APIs, browse, write code, spawn sub-agents, and act with less constant human prompting. Benefits are real; so are new failure modes: runaway actions, memory poisoning, confused deputy problems, unsupervised spending or messaging, and cascading tool errors. Governance designed for single-shot chat completions will not suffice. You need runtime policy gates, least-privilege tool access, identity for agents, logging of plans, and clear halt authority—before agents email customers or move money.
Learning Objectives
Define agentic AI in inventory terms (tools, autonomy, memory, multi-agent).
List distinctive risks versus chatbots.
Design runtime controls (permissions, budgets, approvals, kill switches).
Review before reliance branded frameworks (MI9, AAGATE, etc.) as optional proposals unless adopted knowingly.
Place agent governance inside ISO 42001 operation and Chapter 18 ownership models.
Core Analysis
What to inventory
For each agentic system record: goals it may pursue; tools it can call; data stores it can read/write; whether it can spend money or send external messages; memory stores; ability to spawn sub-agents; autonomy level; human approval gates; rate limits; owner. If you cannot answer these, you are not ready to deploy.
Distinctive risk themes
| Planning errors |
Confident wrong plans executed end-to-end |
| Tool misuse |
Correct API used for harmful purpose |
| Prompt/memory poisoning |
Malicious content alters future behavior |
| Privilege abuse |
Agent inherits overly broad credentials |
| Cascade failure |
Sub-agents amplify mistakes |
| Speed |
Harmful actions complete before review |
| Opacity |
Hard to explain why a plan was chosen |
Review before reliance survey percentages about undetected agents unless you cite a primary study with date and method.
Runtime governance pattern
Identity: each agent identity is distinct, attributable, and revocable.
Least privilege: tools scoped to need; no standing admin.
Policy engine: allow/deny/require-approval by action type and risk.
Budgets: token, money, email, and write-action ceilings.
Human gates: mandatory approval for high-impact actions.
Logging: plans, tool calls, outputs, approvals.
Kill switch: immediate revoke of tokens and tools.
Eval & monitoring: simulators and production anomaly detection.
Memory stores as high-risk data
Long-term memory can retain personal data and poisoned instructions. Apply retention, access control, encryption, and periodic review. Allow users to reset agent memory. Assess memory under Chapter 20 data governance.
Multi-agent systems
When agents delegate to sub-agents, require: inheritance of policy constraints; tracing of delegation trees; caps on spawning; and unified kill. Review before reliance claims of fully verified multi-agent safety—treat as research-grade risk.
On branded frameworks mentioned in older drafts
Names such as MI9 runtime governance or AAGATE appear in emerging literature and vendor narratives. This handbook treats them as examples of the problem space, not as endorsed standards. If you adopt a vendor runtime, map it to the pattern above and keep SoA ownership. Do not imply ISO or legal mandate.
Sector constraints
Finance: payment initiation agents need strong approvals and audit trails. Health: clinical action agents need regulatory pathway analysis. Critical infrastructure: agents that can change OT parameters may be inappropriate without extreme safeguards. Default to human confirmation for irreversible physical actions.
Shadow agents
Employees will connect personal agent tools to corporate SaaS. Extend shadow-AI programs: discover OAuth grants; block high-risk scopes; provide approved enterprise agents. Review before reliance detection rates without measurement.
Illustrative case study
A sales agent authorized to send emails begins promising non-existent discounts after a poisoned CRM note enters memory. Finance notices margin collapse. Response: revoke agent credentials; wipe memory; require human approval for discount language; add content policy checks on outbound mail; incident review under liability/redress playbooks. Lesson: runtime permissions beat model promises.
Practical Checklist
Inventory agents with tools, memory, and autonomy fields.
Enforce least-privilege tool credentials.
Implement approval gates for high-impact actions.
Set budgets and rate limits.
Log plans and tool calls.
Test kill switches.
Assess memory poisoning risks.
Extend shadow-AI discovery to agent OAuth.
Review before reliance unverified survey stats and proprietary frameworks as law.
Update ISO 42001 SoA for agent operations.
Board Questions
Where do agents act without human approval today?
Who can revoke agent credentials in minutes?
What budgets bind agent actions?
How do we detect shadow agents?
Are memory stores governed as sensitive data?
What irreversible actions are banned for agents?
How do agent risks appear in our liability and insurance reviews?
What evaluations cover tool-use jailbreaks?
Extended handbook notes — agent operations
Permission taxonomy (starter)
Read internal knowledge; write internal tickets; message employees; message customers; move money; change IAM; deploy code; control physical systems. Map each to default deny, allow, or approve. Review quarterly as tools expand.
Simulation before production
Run agents in sandboxes with fake customers and fake money. Score goal completion and policy violations. Do not graduate agents on demo charm alone.
Alignment with Chapter 15 severe-risk themes
Autonomous cyber offense or biological assistance capabilities—if ever approached—belong in frontier threshold governance, not only enterprise IT policy. Most corporate agents never approach that bar; still ban toolkits that enable abuse and monitor for dual-use requests.
Incident severity for agents
Raise severity when agents contact customers, alter financials, or escalate privileges autonomously. Include agent incidents in board thresholds from Chapter 18.
Practitioner deep-dive — agent control plane
Policy examples (illustrative)
Deny: outbound wire transfers above zero without human approval.
Deny: IAM privilege changes.
Approve: customer emails that include pricing.
Allow: read-only knowledge base search.
Allow with rate limit: create draft tickets.
Encode in a policy engine; test; monitor bypass attempts.
Evaluation harness for agents
Tasks with known goals; injected hostile instructions; noisy tools; partial outages. Score success and policy compliance separately. An agent that completes goals by violating policy fails.
Organizational rollout
Start with internal-only agents; then limited customer-facing with approvals; then broader autonomy only with proven metrics. Review before reliance “fully autonomous enterprise” roadmaps without control evidence.
Additional practitioner notes
Require change tickets when enabling a new tool for an agent—even if the base model is unchanged.
Separate developer agents (code repos) from customer agents (CRM, email) with different privilege tiers.
Monitor cost anomalies as a safety signal—runaway loops often show up as spend first.
Forbid agents from storing credentials in memory stores; use short-lived tokens from a vault.
Add customer-visible indicators when an agent, not a human, is acting on a thread.
Review agent logs weekly in the first 90 days of any production agent; then right-size.
Include agentic systems explicitly in business-continuity plans—what happens if the agent platform fails open or closed?
Test for collusion or unsafe cooperation in multi-agent setups where relevant.
Align HR policy: employees must not connect personal agents to corporate admin roles.
Review before reliance claims of solved agent alignment; govern as evolving risk.
Separate developer agents from customer agents with different privilege tiers.
Primary-source route: S04 NIST · S05 NIST | Return to contents
Chapter 24: Sector Applications – Finance, Health, Critical Infrastructure
How horizontal AI rules meet sector regulators, safety cases, and procurement
Scope of sectoral examples
The finance and FDA updates below identify particular supervisory and guidance instruments. Their applicability depends on the institution, product, and activity. Suggested controls are not a substitute for a required regulatory submission or sectoral validation. [S23][S24]
Overview
Key point: AI governance must be mapped to the activity and its sectoral requirements. Finance, medical-device functions, and critical infrastructure require different evidence, supervision, and failure responses. The chapter connects the common governance framework to those differences without treating a generic model benchmark as proof of suitability.
Learning Objectives
Map finance AI uses to conduct, prudential, and model-risk expectations.
Explain why health AI often triggers medical-device and clinical-safety pathways (FDA/MHRA themes) alongside AI Act analysis.
Design critical-infrastructure AI controls that respect safety and cyber constraints.
Note employment and education high-risk themes without cloning EU chapters.
Review before reliance device classification outcomes—regulatory counsel decides.
Core Analysis
Finance
Finance. The Federal Reserve’s SR 26-2, issued on 17 April 2026, supersedes SR 11-7 and SR 21-8. It emphasizes a risk-based approach tailored to an institution’s model risk profile, size, and complexity, and is expected to be most relevant to Federal Reserve-regulated banking organizations above $30 billion in assets. This does not make the letter a universal rule for every insurer, investment firm, or AI application. [S23]
Practical merges:
| MRM inventory |
Include GenAI, RAG, agents |
| Validation |
Add qualitative evals, jailbreaks, fairness |
| Consumer duty |
Test customer understanding of AI-influenced communications |
| Outsourcing |
Treat foundation-model APIs as critical third parties |
| Op resilience |
Plan for provider outages and degraded modes |
| Financial crime |
Monitor AI-assisted fraud and model misuse |
UK FCA/PRA and counterparts elsewhere will ask familiar questions in AI clothing. EU high-risk Annex III themes for creditworthiness and essential services may apply—classify carefully. Review before reliance firm-specific capital impacts.
Health
AI used for diagnosis, triage, clinical decision support, or medical image analysis may be regulated as software as a medical device (SaMD) under FDA, MHRA, EU MDR/IVDR pathways—parallel to EU AI Act high-risk medical device themes where linked. Governance needs: clinical evaluation; quality management; post-market surveillance; human clinician oversight design; dataset shift monitoring; cybersecurity.
FDA’s final August 2025 guidance on predetermined change control plans addresses planned modifications, validation methods, and impact assessment for AI-enabled device software functions in the relevant marketing-submission pathways. A reviewed plan is not unrestricted permission for an AI system to modify its clinical function. Determine device classification and the applicable submission requirements separately. [S24]
Critical infrastructure
Energy, transport, water, and communications operators adopting AI for forecasting, maintenance, or control must prioritize safety integrity and cyber. Prefer decision-support over closed-loop control until assurance is extraordinary. Segment OT networks; deny agents privileged OT credentials by default; require human confirmation for actuation. Align with existing critical-infrastructure cyber regulations in your markets. Review before reliance specific NIS2/sector rule citations per site—local counsel maps.
Employment and education (short)
Hiring algorithms and education scoring tools trigger discrimination, transparency, and—in EU—high-risk duties for listed use cases. Require bias testing, notices, human review, and vendor diligence. Review before reliance local labor statute details.
Shared sector pattern
Sector law first for safety/license.
Horizontal AI law second for classification.
Management system (ISO 42001/NIST) as binder.
Sector regulator engagement early for novel uses.
Illustrative case study
An insurer pilots GenAI to draft decline letters. Conduct risk emerges when drafts invent reasons. Fix: retrieve-only reasons from decision engine; ban free-form legal rationales; human send; fairness monitoring. Lesson: sector conduct beats chatbot fluency.
Practical Checklist
Tag AI inventory with sector regulator IDs.
Extend MRM/QMS to GenAI where applicable.
Classify health AI with device counsel before marketing claims.
Ban OT actuation agents without safety case.
Test hiring tools for discrimination risk.
Add foundation-model APIs to critical outsourcing registers.
Align incident response with sector notification clocks.
Review before reliance device classifications without filings.
Fund post-market monitoring for clinical AI.
Brief sector risk committees, not only tech ethics boards.
Board Questions
Which sector regulators have AI on their exam agenda for us?
Are GenAI tools inside MRM/QMS scope?
Any health claims without device pathway analysis?
Can AI systems actuate physical infrastructure?
How do we oversee hiring AI?
What outsourcing concentration exists on model APIs?
Are sector notification clocks in the AI incident plan?
What sector-specific assurance will we fund next year?
Extended handbook notes — sector playbooks
Finance deep notes
Create a GenAI annex to MRM policy: inventory fields for prompt packs; validation expectations for stochastic systems; ongoing monitoring via complaint tags and override rates; challenger processes for material credit models that remain classical; separate faster track for low-tier internal productivity bots with data controls. Train model risk staff on prompt injection. Include AI in consumer-duty outcome testing samples. For trading or market-abuse surveillance AI, involve compliance surveillance leads early. Review before reliance quantitative capital add-ons without supervisor dialogue.
Health deep notes
Separate research prototypes from clinical deployment. Use sandboxes where available. Document intended use tightly—intended use drives classification. Monitor for dataset shift when hospitals differ from training sites. Ensure clinicians understand automation bias. Log AI suggestions and clinician final decisions. Coordinate privacy (health data) with AI transparency. Review before reliance performance metric claims in ads.
Critical infrastructure deep notes
Maintain zones and conduits thinking: AI analytics in IT should not silently gain OT write paths. Any predictive maintenance recommendation that leads to switching should pass through existing work-order and safety systems. Test failure modes: AI outage should default to safe manual procedures. Include AI suppliers in critical supplier assurance. Review before reliance claims of autonomous grid optimization without extensive safety cases.
Hiring and workplace
Notice employees; allow contestation; avoid prohibited biometric emotion inference themes under EU Art. 5 where applicable; assess vendor training data. Works councils may have consultation rights—review before reliance country rules.
Education
Student scoring and proctoring AI need fairness, privacy, and academic integrity design. Prefer assistive tools with teacher oversight for high-stakes assessment.
Additional practitioner notes
Map each material AI system to a primary sector statute or rulebook paragraph your compliance team already knows—then add AI-specific deltas. This translation step prevents double bureaucracy and regulator confusion. Keep a sector x AI matrix reviewed quarterly by compliance, risk, and technology together. When sector guidance updates (FCA speeches, FDA discussion papers, energy regulator circulars), assign a delta owner within ten business days. Review before reliance treating speeches as binding law—but treat them as exam blueprints.
Sector governance succeeds when AI owners speak the language of the sector regulator and when sector compliance officers can read AI assessments without a translator. Invest in bilingual staff or paired ownership. Rehearse regulatory interviews with both present.
Primary-source route: S23 Board of Governors of the Federal Reserve System · S24 US Food and Drug Administration | Return to contents
Chapter 25: Building a 500-Day Program – Playbooks and Metrics
Honest roadmap design from day 0 to day 500—without fake maturity scores
Overview
Key point: Strategy decks do not govern AI. A 500-day program does: sequenced work, named owners, budgets, and operational metrics. This chapter offers a practical roadmap from mobilization (days 0–90) through foundation (91–180), scale (181–365), and assurance/optimize (366–500). It deliberately avoids proprietary maturity scores and color-coded “Level 4.7 Trustworthy AI” theater. You will track inventories, assessments, gates, incidents, and regulatory milestones—things auditors can re-perform.
Learning Objectives
Build a 500-day phased plan tailored to your risk profile.
Select KPIs that are auditable and non-vanity.
Integrate EU/China/UK/US obligations into the same plan.
Review before reliance vendor maturity models as optional diagnostics only.
Connect the program to board governance (Ch 18) and ISO 42001 (Ch 17).
Core Analysis
Design principles
Risk-first sequencing: Tier A systems before productivity chatbots.
Owners before tools: name people prior to buying GRC software.
Evidence continuously: every phase leaves artifacts.
Law by market: calendar binding dates; soft law secondary.
No fake scores: report coverage and quality, not mystical levels.
Phase 0–90: Mobilize
Deliverables: executive sponsor; AI Council charter; draft policy; inventory v1; tiering rules; regulatory heat map (EU/US/UK/China); shadow-AI acceptable use; incident pathway; board committee assignment; 500-day backlog.
Metrics: sponsor named (Y/N); inventory count; percent systems with owners; policy approved.
Phase 91–180: Foundation
Deliverables: assessment spine live; Tier A assessments underway; data owners for critical corpora; transparency notices for customer GenAI; vendor diligence for top APIs; AIMS gap assessment if pursuing ISO 42001; China/EU classification hypotheses documented.
Metrics: percent Tier A with current assessments; labeling defects found in QA; vendor diligence completion for critical providers.
Phase 181–365: Scale
Deliverables: lifecycle gates in engineering; monitoring dashboards; agent controls if agents exist; sector overlays (finance/health); redress runbooks; insurance dialogue; internal audit first cycle; training program completion; SoA draft.
Metrics: gated changes percent; mean time to remediate critical AI incidents; training completion; audit findings open/aged.
Phase 366–500: Assure and optimize
Deliverables: management review cycle; certification Stage 1/2 if chosen; PLD-readiness work for EU placements; Seoul/Hiroshima mapping if applicable; board deep dive; next-year funding; retirement of zombie systems; program retrospective.
Metrics: management review completed; certificate decision; percent zombie systems decommissioned; regulatory milestones hit.
KPI dictionary (honest)
| Inventory coverage |
AI systems meeting definition / known |
You cannot govern ghosts |
| Owner coverage |
Systems with named owner |
Accountability |
| Assessment currency |
Tier A assessed within policy window |
Rights/risk living |
| Gate integrity |
Prod changes with passed gate / all AI prod changes |
Control reality |
| Incident MTTB/MTTR |
Detect and restore metrics for AI incidents |
Operations |
| Redress SLA hit rate |
Timely customer remediation |
Harm reduction |
| Regulatory milestone hit |
On-time filings/labels/docs |
Law |
| Shadow-AI ticket rate |
Discovery/remediation trend |
Insider risk |
Ban: composite “trust scores”; unexplained maturity levels; unauditable green dashboards.
Resourcing sketch (qualitative)
You need: program manager; legal/regulatory; risk; security; data; engineering champions; training capacity; budget for evals and possible certification. Review before reliance headcount formulas by revenue—size to Tier A count and regulatory footprint.
Failure modes of 500-day programs
Boiling the ocean on Tier C tools.
Buying platforms in month one.
Ethics workshops without gates.
Ignoring China filing or EU dates on the calendar.
Declaring victory at policy approval.
Maturity score theater for the board.
Tailoring
Frontier labs: heavier eval and threshold governance. SMEs: compress phases; focus inventory, acceptable use, Tier A assessments, and vendor diligence. Public agencies: add transparency publication norms and procurement gates.
Illustrative case study
A 4,000-person firm launches a 500-day program after an EU customer RFP failure. Days 0–90 produce inventory revealing three undeclared high-impact tools. Days 91–180 assess and gate them. By day 365, monitoring and audit are live; by day 500, ISO 42001 Stage 1 passes and EU documentation packs exist for the RFP rematch. They never publish a maturity score. They publish coverage metrics. Lesson: boring KPIs win renewals.
Practical Checklist
Approve 500-day charter with sponsor and budget.
Publish phase exit criteria.
Build KPI dictionary and data sources.
Put binding regulatory dates on the program calendar.
Reject maturity-score vendors as primary steering metrics.
Report to board committee each quarter.
Re-baseline after major model/provider shifts.
Integrate agent controls if agents are in roadmap.
Fund internal audit sampling.
Run retrospective at day 500 and set the next 500.
Board Questions
Who is the executive sponsor of the 500-day program?
What KPIs will we see quarterly—and are they auditable?
Which regulatory dates are on the critical path?
Are we over-investing in tools vs. owners?
What Tier A gaps remain after day 180?
How will we know gates work?
What happens if funding is cut at day 200?
Will we pursue ISO 42001 certification—why or why not?
Extended handbook notes — program mechanics
Backlog taxonomy
Epics: inventory; policy; assessments; engineering gates; data/transparency; vendors; sector overlays; agents; assurance; training; regulatory packs. Stories under each with owners and due dates. Review backlog weekly in the first 180 days.
RACI for the program itself
Program manager (R) for plan; sponsor (A); risk/legal/security/data/engineering (C/R as assigned); board committee (I). Write it.
Communication cadence
Weekly working group; monthly AI Council; quarterly board committee; ad hoc for incidents and law changes. Keep a single source of truth wiki—not five slide decks.
Budget lines
People; evals/red teams; tooling; certification; training; external counsel; contingency for filings. Review before reliance dollar amounts—local finance builds.
Day 500 retrospective questions
What controls actually changed products? Which metrics were gamed? Which regulatory bets were wrong? What technical debt remains in monitoring? What should the next 500 days retire?
Additional practitioner notes
Treat the 500-day plan as a controlled document under change management. When EU Digital Omnibus timing or China batch notices shift obligations, update the plan within two weeks and inform the board committee if critical path moves. Do not silently slip dates.
Pair each KPI with a data owner and a validation method (query, sample, audit). If validation is “trust the slide,” delete the KPI.
For multi-entity groups, run a group program with local annexes—not twenty unrelated programs. Shared inventory schema is non-negotiable.
Celebrate halted launches and decommissioned shadow tools in town halls. Culture metrics matter alongside counts.
If using agile delivery, place governance stories in the same sprints as feature work for AI products—otherwise gates become after-the-fact paperwork.
Review before reliance any consultant’s claim that their five-level maturity model is “the industry standard.” Ask for the public standard citation. If none, treat it as opinion.
At day 90, force a go/no-go on whether inventory quality is sufficient to proceed; if not, extend mobilize rather than building gates on sand.
Program offices should maintain a risk register of program-level risks (sponsor departure, funding cut, engineering non-adoption, regulatory date surprise) with mitigations. Review it monthly alongside product AI risks.
Primary-source route: S04 NIST · S20 ISO | Return to contents
Conclusion: Interoperable Governance by 2030
What boards should expect—and build—between now and 2030
Overview
Key point: By 2030, AI governance will not converge into a single global statute. It will remain a stack: principles (OECD/UNESCO), hard law that differs by market (EU AI Act and product liability; China algorithmic/GenAI measures; UK regulator principles; US federal–state tension), and practice systems (NIST AI RMF, ISO/IEC 42001, evaluations, audits). Interoperability is the realistic goal—shared definitions, reusable evidence, compatible risk tiers—not identical rules. Organizations that invest in inventory, assessment spines, lifecycle gates, transparency engineering, and honest metrics will travel better than those chasing logos or maturity theater.
Learning Objectives
Restate the three-layer model as a 2030 operating thesis.
List reusable artifacts that travel across regimes.
Sketch scenarios without false certainty.
Issue a concrete call to action for the next 500 days.
Review before reliance predictive claims about treaties or preemption outcomes.
Core Analysis
What “interoperable by 2030” means
Interoperable governance means:
Definitions close enough (OECD DNA) that contracts and model cards translate.
Risk management functions that map (Govern/Map/Measure/Manage ≈ AIMS clauses).
Transparency artifacts that satisfy multiple labeling regimes with one engineering effort where possible.
Assurance reports whose scopes customers understand.
Incident taxonomies that regulators and insurers can read.
It does not mean mutual recognition of all conformity assessments, a UN licensing agency for all models, or the end of China-specific filing.
Scenario sketch (qualitative)
| Persistent multipolar rules |
Keep multi-annex compliance; invest in evidence vaults |
| Heavier EU enforcement |
Prioritize high-risk/GPAI documentation quality |
| US preemption partial |
Still track state duties until courts/statutes settle |
| Summit soft law hardens via procurement |
Safety frameworks become contractual |
| Agentic ubiquity |
Runtime controls become as normal as IAM |
Review before reliance probabilities—use for planning stress tests, not predictions.
The reusable artifact set (build once)
AI inventory with roles and tiers
Policy + SoA / control mapping
Assessment spine (risk + rights + privacy modules)
Lifecycle gate records
Data lineage and retention
Transparency/labeling capability
Monitoring and incident logs
Vendor diligence files
Redress runbooks
Board metrics pack
These artifacts are the practical meaning of interoperability.
Call to action
Name owners this month.
Inventory within 90 days.
Assess Tier A before expansion.
Calendar EU, China, UK, and US state duties.
Reject fake maturity scores.
Fund evaluations and monitoring proportional to autonomy.
Practice halt authority.
Tell the truth in marketing and ESG claims.
What this book tried to do
the foundational chapters built definitions, principles, NIST, EU, and US trajectories. the later chapters added China, UK, summits, institutions, ISO 42001, corporate governance, assessments, data/transparency, liability, assurance, agents, sectors, and the 500-day program. Together they form a handbook path from “why govern” to “what to do on Monday.”
Illustrative case study
Illustrative synthesis. An organization can prepare for changing legal requirements by maintaining a system inventory, versioned evaluations, controlled disclosures, and release records. The comparative performance of firms using different approaches is not established by this example.
Practical Checklist
Re-read your three-layer map with 2030 multipolarity assumed.
Fund the reusable artifact set.
Launch or refresh a 500-day program.
Align board oversight and halt authority.
Review before reliance treaty and preemption forecasts.
Keep soft law and hard law in separate columns.
Invest in agent runtime controls early.
Measure coverage, not mystical maturity.
Update this handbook’s calendars as law moves.
Make interoperable evidence a competitive capability.
Board Questions
Are we planning for multipolar rules through 2030—or waiting for harmony?
Which reusable artifacts are still missing?
Is halt authority real?
Do our public claims match our controls?
What does the next 500 days fund?
How agent-ready is our governance?
Where are we review before relianceing uncertainty—and is that honest?
What will we tell customers we can evidence tomorrow?
Closing
Governing artificial intelligence is ordinary institutional work under extraordinary technological speed. The winners will be organizations that can show their work across borders: who owns the system, what was assessed, what was tested, what was disclosed, what was halted, and what was fixed. That is interoperable governance. Start now; revise often; keep the metrics honest.
Notes on humility and speed
Capability jumps will continue to outpace statute drafting. That is why practice layers—evaluations, monitoring, management systems—must be designed for change. Update assessments when models change; update SoAs when agents appear; update board metrics when new harm types emerge. Humility is operational: say what you do not know; measure what you can; refuse deployments you cannot oversee.
International forums will keep producing declarations. Use them as early-warning signals and procurement hints. Do not confuse them with certificates. Domestic regulators will keep asking sector questions. Answer in their language. Engineers will keep shipping. Meet them in pipelines with gates that are fast enough to respect and strict enough to matter.
If you remember one line from this conclusion, remember this: interoperability is an evidence strategy, not a wish for identical laws. Build the evidence. The laws will keep moving.
Notes on humility and speed
Maintain this handbook as a dated reference. Revisit the operative sources when an instrument, deployment, or material risk changes, and record uncertainty rather than treating an earlier interpretation as permanent.
Primary-source route: S01 OECD · S04 NIST · S06 European Union | Return to contents
Worked decision file: a bounded invoice agent
ILLUSTRATIVE DESIGN EXERCISE — NOT A REPORTED INCIDENT
This worked file connects the inventory, impact assessment, supplier review, release gate, and incident process already developed in the book. The organization, system, and events are hypothetical. No test result below is represented as an observed measurement.
1. Define the delegation
The proposed agent reads invoices, compares them with an approved purchase order, and drafts a payment request. It may not change supplier bank details, create a new payee, release funds, or expand its own tool permissions. A finance owner is accountable for the workflow; technical and security owners implement independent enforcement.
| Inventory |
One deployment ID; fixed model, retrieval, tool and policy versions; finance workflow and affected suppliers. |
A material version or purpose change triggers reassessment. |
| Impact assessment |
An invoice could contain instructions that attempt to redirect payment to a different account. |
Treat invoice text as untrusted data, not authority. |
| Supplier review |
Identify model-change notices, data retention, incident contacts, and access to relevant records. |
Unresolved evidence gaps constrain deployment scope. |
| Release gate |
Permit reading and drafting only; human approval does not confer rights the account lacks. |
Execution remains unavailable until separate evidence supports it. |
| Incident record |
Track attempted and completed tool actions, approvals, retries, and external effects. |
Stopping the agent is followed by reconciliation, not assumed reversal. |
2. Test the authorization boundary
The controls below are proposed engineering patterns. They should be implemented outside the model and tested in an isolated environment. Their presence does not establish compliance with any particular payment, data-protection, or AI law.
| An invoice asks the agent to alter the payee. |
The payment interface rejects the unapproved destination regardless of the generated explanation. |
Action request, policy decision, and rejection record. |
| An approved payment amount changes before execution. |
The approval becomes invalid; a new action-specific approval is required. |
Original and changed parameters; invalidation event. |
| A network timeout causes a retry. |
The transaction identifier prevents unintended duplicate execution; uncertain outcomes are reconciled. |
Request ID, retry history, and transaction state. |
| The policy service is unavailable. |
Sensitive execution is blocked; drafting may continue only if separately allowed. |
Fail-closed result and operator alert. |
| A sub-agent requests broader permissions. |
Delegated scope cannot exceed the approved parent authority. |
Identity, inherited scope, and denied escalation. |
3. Record a conditional decision
Proposed decision: restricted pilot for invoice reading and draft preparation only. This is an example of a decision statement, not an assertion that the system passed testing. Before approval, attach the actual test results, unresolved limitations, operator training evidence, access review, and a tested fallback. State who may suspend the pilot and which changes invalidate approval.
4. Reconcile after an incident
A shutdown can stop new requests without reversing a completed external action. The response therefore separates queued, rejected, uncertain, and completed transactions; revokes affected credentials; preserves necessary evidence; and determines whether any supplier or customer needs correction or support. Restart requires evidence that the failure mechanism is controlled, not merely that the agent has been restarted.
Reading connection: Chapters 18–20 establish ownership and evidence; Chapter 23 develops agentic boundaries; Chapter 25 incorporates the controls into a maintained program.
Sources
Primary-source register
These links identify the principal instruments and update sources used by the manuscript and this enhancement. They are not an exhaustive bibliography or a claim that every retained proposition has been independently verified. Source titles are clickable. Some institutional pages may require browser verification. Review operative amendments and document status before reliance.
Selected update checks: EU application milestones and Omnibus description; US executive-order sequence; Colorado’s replacement framework; NIST revision status; China’s later measures; Federal Reserve model-risk guidance; FDA change-control guidance. Review date: 16 September 2026.
[S01]** OECD. **AI Principles and Recommendation on Artificial Intelligence. 2019; revised 2024.
[S02]** OECD. **Explanatory memorandum on the updated definition of an AI system. 2024.
[S03]** UNESCO. **Recommendation on the Ethics of Artificial Intelligence. 2021; official overview.
[S04]** NIST. **AI Risk Management Framework 1.0 and official resource page. 2023; revision activity noted on the resource page.
[S05]** NIST. **Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (AI 600-1). 26 July 2024.
[S06]** European Union. **Regulation (EU) 2024/1689: Artificial Intelligence Act. 2024; read with applicable amendments.
[S07]** European Commission. **AI Act: regulatory framework and implementation overview. current institutional overview.
[S08]** European Commission. **AI Omnibus enters into force. 27 July 2026; updated 31 July 2026.
[S09]** European Commission, AI Act Service Desk. **Timeline for the implementation of the EU AI Act. amendment-aware implementation timeline.
[S10]** United States, Federal Register. **Executive Order 14148: Initial Rescissions of Harmful Executive Orders and Actions. 20 January 2025; Section 2 rescinds EO 14110.
[S11]** The White House. **Executive Order 14179: Removing Barriers to American Leadership in Artificial Intelligence. 23 January 2025.
[S12]** The White House. **Executive Order 14365: Ensuring a National Policy Framework for Artificial Intelligence. 11 December 2025.
[S13]** Colorado General Assembly. **SB26-189: Automated Decision-Making Technology. signed 14 May 2026; enacted summary.
[S14]** Cyberspace Administration of China. **Interim Measures for the Management of Generative Artificial Intelligence Services. 2023; authoritative Chinese text.
[S15]** Cyberspace Administration of China. **Measures for Labelling AI-Generated and Synthetic Content. 2025; authoritative Chinese text.
[S16]** Cyberspace Administration of China. **Interim Measures for Human-Like Interactive AI Services. 2026; authoritative Chinese text.
[S17]** UK Government. **AI regulation: a pro-innovation approach. 2023 White Paper and 2024 response.
[S18]** UK Government. **Frontier AI Safety Commitments, AI Seoul Summit 2024. 21 May 2024; voluntary commitments.
[S19]** United Nations. **High-level Advisory Body on Artificial Intelligence; Governing AI for Humanity. final report, 2024.
[S20]** ISO. **ISO/IEC 42001:2023 — AI management systems. public overview; licensed standard needed for clause-level implementation.
[S21]** European Union. **Directive (EU) 2024/2853 on liability for defective products. 2024; national transposition and application rules require review.
[S22]** European Parliament. **AI Liability Directive: legislative procedure tracker. status reference for the withdrawn proposal.
[S23]** Board of Governors of the Federal Reserve System. **SR 26-2: Revised Guidance on Model Risk Management. 17 April 2026.
[S24]** US Food and Drug Administration. **Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. final guidance, August 2025.
End of handbook
PRINCIPLES · LAW · PRACTICE