What the law wants: the artifact map, and keeping it honest
Lesson 5 of 5 in Data Governance and Documentation Artifacts for AI.
The voluntary stack became load-bearing when legislators wrote it into statute. For EU high-risk systems, Article 11 and Annex IV define the technical file: drawn up before placing on the market, kept current, retained for ten years — general description, development process, data requirements, risk management, metrics for accuracy, robustness and cybersecurity, and the post-market monitoring plan. Article 13 adds the instructions for use — the provider-to-deployer document that makes deployer duties (oversight, monitoring, the FRIA) even possible. For GPAI models, Article 53 requires technical documentation for the AI Office (Annex XI), information for downstream providers who build on the model (Annex XII), a copyright policy, and a sufficiently detailed summary of training content on the AI Office’s template — the first law anywhere to force public disclosure about foundation-model training data. The statutory detail lives in the EU AI Act domain; what matters here is the operational reading: Annex IV is not a new document — it is an assembly of the artifacts this module has already covered. Teams that maintain datasheets, model cards, and evaluation reports generate the tech file; teams that do not, reconstruct history under regulatory deadline.
One document map, then, before the operations: what each artifact covers, who writes it, when, and which law or framework demands it.
| Artifact | What it documents | Who writes it | When | Which law / framework wants it |
|---|---|---|---|---|
Datasheet | A dataset: motivation, composition, collection, preprocessing, uses, distribution, maintenance | Dataset creator / data engineering, owned by the data steward | At dataset creation; updated on every version | Voluntary (Gebru et al.) — but feeds AI Act Art 10 data-governance evidence and Annex IV s 2(d) |
Model card | A model version: intended and out-of-scope use, disaggregated metrics, eval and training data, caveats | Model development team; reviewed by 2nd line | At every model release; version-locked to the model | Voluntary (Mitchell et al.) — de facto expected in procurement; feeds Annex IV s 2–3 |
System card | A deployed system: model + guardrails + tools, safety evals, red-team findings, mitigations | Provider of the assembled system | At product launch and major system changes | Voluntary genre (frontier labs); the evidence deployers should demand before consequential integration |
Technical file (Annex IV) | A high-risk AI system end-to-end: description, development, data, risk management, metrics, post-market plan | Provider (Art 11) | Before placing on market / putting into service; kept current; retained 10 years | EU AI Act Arts 11, 18 — mandatory for high-risk; basis of conformity assessment |
Instructions for use (Art 13) | What the deployer needs: capabilities, limitations, intended purpose, oversight measures, expected lifetime, maintenance | Provider, addressed to deployers | Delivered with the system | EU AI Act Art 13 — the hinge document deployer duties depend on |
GPAI documentation (Annex XI/XII) | A general-purpose model: training and testing process, evaluation results (XI); capabilities and limits for downstream integrators (XII) | GPAI model provider | On placing the model on the market; kept current | EU AI Act Art 53(1)(a)–(b) |
Training-content summary | A sufficiently detailed public summary of the content used to train a GPAI model | GPAI model provider, on the AI Office template | Published when the model is placed on the market | EU AI Act Art 53(1)(d) — the first statutory public training-data disclosure |
Impact/risk assessments (DPIA, FRIA…) | Effects on data subjects and affected persons — covered in the assessments module | Controller (DPIA); deployer (FRIA) | Before processing / before first use; refreshed on change | GDPR Art 35; EU AI Act Art 27 — see operations/impact-assessments |
Documentation operations is where good artifact design goes to die or survive. Four disciplines separate the programs whose documentation is evidence from those whose documentation is decoration:
Version-lock everything. A model card describes one model version; a datasheet describes one dataset snapshot. Pin the linkage — card ↔ model hash ↔ dataset version — in the registry, and regenerate on release. Documentation that floats free of versions answers questions about a system that no longer exists.
Automate the generatable, review the judgmental. Metrics tables, data statistics, lineage graphs, and eval results should be auto-generated from pipelines — machines do not forget to update tables. Intended-use bounds, ethical considerations, and limitation narratives are judgments; automation cannot write them and boilerplate defeats them. The mature pattern is a generated skeleton with mandatory human-authored sections, plus a reviewer empowered to reject.
Treat documentation as future evidence — because it is. Candid documentation cuts both ways: it is your best defence (the file shows you identified, tested, and mitigated) and it is discoverable in litigation (the file shows you knew). The resolution is not less candour — sanitised documentation fails as compliance evidence and looks like concealment in front of a jury. It is candour plus follow-through: never document a risk you are unwilling to either mitigate or formally accept, and route the risk-acceptance language through people trained to write it.
Retention is a legal parameter, not an ops preference. Annex IV files: ten years. Logs for high-risk systems: per Arts 12 and 19. Training snapshots: long enough to answer erasure and audit questions, short enough to honour minimisation. Write the schedule down; “whatever the backup system kept” is not a policy.
Interactive sorting exercise: A fact needs a home. File each statement in the artifact where it belongs.
Tool: AIMS Builder & Audit — Slot these artifacts into a working management system: build the documentation and data-governance controls of an ISO/IEC 42001 AIMS.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.