Standards, statutes, and how to actually read them

Lesson 4 of 5 in How AI Governance Works: Laws, Standards, and Everything Between.

A statute tells you what you must achieve; a standard tells you how to achieve it — and the difference in origin explains everything else about them.

Statutes come from legislatures: politically negotiated, publicly debated, free to read, binding, and deliberately technology-vague so they age slowly. Standards come from private consensus bodies — ISO/IEC committees like SC 42 for AI, European bodies like CEN and CENELEC, the IEEE — where technical experts (heavily industry-drawn, a governance issue in itself) hammer out detailed specifications. Standards are precise, revisable, usually paywalled, and voluntary.

Then comes the trick that makes standards the hidden power centre of AI governance: legal reference. The EU AI Act says high-risk systems must have "appropriate" risk management and "sufficiently" accurate performance — words no engineer can build to. So the European Commission asked CEN-CENELEC to write harmonized standards filling in the detail, and Article 40 provides that a system conforming to them is presumed to comply with the corresponding legal requirements. Voluntary in theory; in practice, the cheapest and safest route to market. Private technical documents thereby acquire near-legal force — which is why who sits on the committee is a political question, not just a technical one.

How a voluntary standard acquires legal force (EU model)

  1. Statute sets essential requirements

    EU AI Act Arts 8–15: risk management, data governance, accuracy, oversight — in deliberately general language.

  2. Commission issues standardization request

    A formal mandate to CEN-CENELEC: write standards operationalizing these requirements.

  3. CEN-CENELEC JTC 21 drafts standards

    Expert committees draft, often building on ISO/IEC work (42001, 23894) to avoid duplication.

  4. Standard cited in the Official Journal?

    Citation in the OJEU is what turns a standard into a harmonized standard.

  5. Presumption of conformity

    Follow the standard → presumed compliant with the matching legal requirement (Art 40). Auditors and notified bodies check against it.

  6. Providers must prove compliance their own way

    Without harmonized standards, each provider argues from first principles that its approach satisfies the law — costlier and riskier.

The second professional skill of this lesson: reading these documents without drowning. Statutes, standards, and frameworks each have an anatomy, and each anatomy tells you where the binding content lives — and where it doesn’t.

Anatomy of a statute (EU-style): recitals, articles, annexes

Recitals — the numbered "whereas" paragraphs at the front (the AI Act has 180) — explain intent and context. They are not operative law, but courts use them to interpret ambiguous articles, so lawyers quote them constantly.

Articles are the law itself: definitions first (Art 3 — always read definitions first, they silently decide every scope fight), then obligations, then governance and penalties.

Annexes carry the lists that need frequent amendment — Annex III’s high-risk use cases, Annex IV’s documentation requirements. The Commission can update annexes faster than articles, which is why so much political combat happens over what sits in an annex versus an article.

Reading order for professionals: definitions → scope → the annex relevant to you → the obligations the annex triggers → recitals for anything ambiguous.

Anatomy of a standard: normative vs informative, shall vs should

Standards separate normative clauses (required for conformity) from informative content (annexes and notes offering guidance — you cannot fail an audit on them, though ISO/IEC 42001’s "informative" Annex A controls come close in practice because certifiers expect you to justify any exclusion).

The verbs are a contract: "shall" = mandatory requirement, "should" = recommendation, "may" = permission, "can" = statement of possibility. Auditors check shall statements. When you scan a standard, grep for "shall" and you have found the audit checklist.

Anatomy of a framework (NIST-style): functions, outcomes, profiles

Voluntary frameworks avoid command language entirely. The NIST AI RMF is organized into four functions (Govern, Map, Measure, Manage) decomposed into categories of outcomes — descriptions of what good looks like, not instructions. Nothing is mandatory, so there is no "shall" anywhere; instead you build a profile selecting which outcomes fit your context.

Read a framework asking "which of these outcomes do we already achieve, and where are the gaps?" — it is a mirror, not a mandate. That is also its limit: a framework cannot make anyone do anything.

The traps: definitions, scope carve-outs, and transition dates

Three places where careless readers get burned. Definitions: whether something is an "AI system", a "provider", or "substantial modification" decides which obligations exist at all. Scope carve-outs: the AI Act exempts military uses, pre-market research, and (partially) free open-source models — miss a carve-out and you analyse the wrong universe. Transition and application dates: a law "in force" is not necessarily "applicable" — the AI Act entered into force August 2024, but its obligations switch on in waves through 2027–2028. Citing an obligation that doesn’t yet apply is the most common rookie error in AI-law memos.

Key terms: harmonized standards, normative clause, recital, conformity assessment

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.