Arts 11–13: documentation, logging, and telling deployers the truth
Lesson 3 of 6 in Inside the High-Risk Rulebook: Arts 8–15 Article by Article.
Recall the first lesson of Foundations: nobody wrote the model’s behaviour down, so governance must demand its own artifacts. Arts 11–13 are those artifacts, in statute form — three information duties aimed at three audiences: regulators (technical documentation), investigators (logs), and deployers (instructions for use). Together they make the system legible to everyone who has to trust it.
Art 11 — technical documentation
Drawn up before the system is placed on the market or put into service, and kept up to date. The content list lives in Annex IV: general description, development methods and design choices, architecture, data requirements and provenance, the human-oversight assessment, validation and testing results with metrics, cybersecurity measures, the risk-management description, lifecycle-change management, and the standards applied.
The purpose clause matters: the documentation must demonstrate compliance with all of Section 2 and give authorities the information needed to assess that compliance. It is the file a market surveillance authority opens first — and under Art 74, refusal or inadequacy can escalate to conditional source-code access.
Two proportionality valves: SMEs and start-ups may supply the Annex IV elements in a simplified form via a Commission template, and Annex I Section A products keep one single set of documentation covering both the sectoral law and the AI Act (Art 11(2)).
Art 12 — record-keeping
The system must technically allow the automatic recording of events (logs) over its lifetime — a design requirement on the product, not a filing habit of the provider. Logging must give the traceability appropriate to the intended purpose, specifically to: identify situations where the system may present a risk (in the Art 79(1) sense) or undergo substantial modification; facilitate post-market monitoring (Art 72); and support deployers’ own monitoring duties (Art 26(5)).
For remote biometric identification systems (Annex III 1(a)), Art 12(3) prescribes minimum log content: the period of each use (start and end date and time), the reference database checked, the input data for which a match resulted, and the identity of the natural persons involved in verifying the result — the two-person verifiers Art 14(5) will require.
Retention connects forward: providers keep these logs, to the extent under their control, for a period appropriate to the intended purpose and at least six months (Art 19); deployers hold the logs they control likewise (Art 26(6)).
Art 13 — transparency to deployers
The design standard: the system must be sufficiently transparent to enable deployers to interpret the output and use it appropriately. The delivery vehicle: instructions for use — concise, complete, correct, clear, and accessible to the deployer’s actual staff.
The mandated content is a governance syllabus in miniature: provider identity; the system’s characteristics, capabilities and limitations — intended purpose, the declared accuracy (with its metrics), robustness and cybersecurity levels from Art 15, known circumstances that degrade them, and technical capabilities to explain outputs; performance regarding specific persons or groups; input-data specifications; pre-determined changes; the human-oversight measures of Art 14, including how to interpret outputs; required computational and hardware resources, expected lifetime, and maintenance including software updates; and how to collect, store and interpret the logs from Art 12.
Notice the architecture: Art 13 is the coupling between provider duties and deployer duties. Every deployer obligation in Art 26 assumes the deployer received honest, usable instructions — which is why exaggerated marketing claims that contradict the instructions are a compliance problem, not just a sales problem.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.