Chapter 70 — AI governance and compliance

The EU AI Act: a risk-tiered structure

The EU AI Act entered into force on 1 August 2024 and applies in stages: GPAI obligations began on 2 August 2025, transparency requirements on 2 August 2026, Annex III high-risk rules on 2 December 2027, and product-embedded high-risk rules on 2 August 2028. It is the most comprehensive framework as of this writing, and many other jurisdictions' proposals borrow its shape. It sorts AI systems into tiers by risk:

General-purpose AI (GPAI) models — i.e. foundation models/LLMs — sit in a separate track regardless of tier: providers must maintain technical documentation, a summary of training data, and a copyright policy. Models deemed to carry systemic risk (roughly, trained above a very large compute threshold) face extra obligations: adversarial testing, incident reporting, and cybersecurity measures — practically, this is Part 14's guardrail work plus Part 15's adversarial-test suite (Chapter 62), but documented and reportable rather than just run once internally.

Penalties scale with severity: up to €35M or 7% of global annual turnover for unacceptable-risk violations, lower tiers for lesser breaches.

NIST AI Risk Management Framework: a process, not a law

The US NIST AI RMF (voluntary, but widely adopted as a de facto standard, including by regulators referencing it) organises governance into four functions instead of risk tiers:

• Govern — policies, accountability, and culture around AI risk, set before any specific system exists.
• Map — identify context, intended use, and foreseeable risks for a specific system (this is where you'd classify Chapter 62's support agent: what could go wrong, who's affected).
• Measure — quantify those risks with the same tools Part 11 already taught: eval sets (Chapter 49), LLM-as-judge, adversarial test suites.
• Manage — respond to identified risks: mitigate (add a guardrail), transfer (insurance, contracts), or accept (with documented sign-off).

The practical difference from the EU AI Act: NIST doesn't tell you which systems must comply or set penalties — it gives you the process to run, which you can point to as evidence of due diligence regardless of which jurisdiction's law you're actually subject to.

Model cards and datasheets: the artifact, not just the process

A model card (Mitchell et al., 2019) is a short, structured document answering: intended use and out-of-scope use, the training data (at a summary level), evaluation results (including across subgroups, not just aggregate accuracy), known limitations, and ethical considerations. A datasheet for a dataset (Gebru et al., 2018) is the equivalent for the data itself: how it was collected, whether it contains personal data, what it's not representative of.

Minimal model-card template you can actually use:

# Model Card: [system name]

## Intended use
- What it's for. What it's explicitly NOT for.

## Inputs and outputs
- What goes in, what comes out, in plain language.

## Training / grounding data
- Where the knowledge comes from (fine-tuning data, RAG corpus, or "none —
  base model only").

## Evaluation
- Eval set size and source (Chapter 49). Metrics. Known failure modes found
  during adversarial testing (Chapter 62, Step 8).

## Limitations
- What it will confidently get wrong. What it should never be trusted for.

## Human oversight
- Where a human approves before action (Chapter 60's action guardrails).
  Who is accountable when it's wrong.

## Contact / incident reporting
- Where to report a problem, and what happens next.

What an audit actually asks for

Whether internal (pre-launch, Part 16's spirit), third-party, or regulatory, an audit wants evidence, not assurances:

• The model card and any datasheets.
• The risk classification (which tier, and why).
• Eval results over time, not just at launch (Chapter 55's monitoring).
• The guardrail configuration itself (Chapter 60's layered defence) — what's enforced in code, not just described in a prompt.
• The adversarial test suite and its results (Chapter 62, Step 8) — an auditor treats "we didn't test for X" as a finding.
• An incident log: what went wrong in production, when, and what changed afterward.
• Sign-off records: who approved deployment, and against what criteria.