What Annex IV technical documentation has to do, and who owes it
Article 11 gives the technical documentation of a high-risk AI system a specific job: to demonstrate compliance with Chapter III Section 2, Articles 9 to 15, and to give national competent authorities and notified bodies what they need to assess that, clearly and comprehensively. Art 11(1) Annex IV is the minimum contents list that makes the duty concrete: nine blocks, each of which a reviewer can look for and find missing.
The duty falls on the provider. If you place a high-risk system on the market under your own name, the file is yours to build, keep current and hand over on request. Deployers do not draw it up, but they should read it: the instructions for use and the oversight measures described in it are what their own obligations rest on. A buyer who cannot get a straight answer about blocks 2, 3 and 9 is buying an unevidenced compliance claim.
Buying a system does not exempt you from writing the file. Under Article 25 a deployer, importer or distributor becomes the provider if it puts its own name or trademark on a high-risk system already on the market, substantially modifies one, or repurposes any system so that it becomes high-risk. The flip hands you the whole Article 16 obligation set, Annex IV included. See how the Article 25 role flip is triggered and what it costs.
The nine Annex IV blocks, and what a thin version of each looks like
These nine blocks are the whole of Annex IV, and they run as a sequence: what the system is, how it was built, how well it works, how risk was managed, what changed, what you built against, who signed, and what happens after launch.
| Annex IV block | Core question it answers | Thin version that fails |
|---|---|---|
| 1 · General description | What system, which version, what purpose | Marketing copy, no version, no testable purpose |
| 2 · Elements and development | How it was built, on what data, tested how | An architecture diagram and a model card link |
| 3 · Monitoring and control | What it can and cannot do, and who oversees it | One aggregate accuracy figure, no group breakdown |
| 4 · Appropriateness of metrics | Why these are the right metrics here | Block 3 metrics repeated, no reasoning |
| 5 · Risk management system | How Article 9 ran across the lifecycle | A risk register scored once at design time |
| 6 · Lifecycle changes | What changed, and did it affect compliance | An engineering changelog, no compliance view |
| 7 · Harmonised standards | What you built against, or what you did instead | Blank, because no standard is cited yet |
| 8 · Declaration of conformity | Who signed, and for which version | A placeholder page marked to follow |
| 9 · Post-market monitoring | What you watch, who owns it, what triggers action | A line saying the team reviews support tickets |
Block 1: the general description of the system
Intended purpose, provider name and contact, the version and how it relates to earlier ones, how the system interacts with hardware or software it is not part of, the software and firmware versions, the forms in which it is placed on the market (embedded in hardware, as a download, as an API), the hardware it runs on, the deployer interface, and the instructions for use. Intended purpose is the load-bearing sentence in the file: it decides which Annex III area you are in and whether the Article 6(3) derogation is even arguable.
Block 2: the system elements and the development process
The largest block. It covers the development methods and steps, including recourse to pre-trained models or third-party tools and how those were integrated or modified; design specifications, general logic and key design choices with their rationale; what the system optimises for; architecture and computational resources; datasheets covering training methodology and the training, validation and testing sets, their provenance, scope and characteristics, and how the data was obtained, selected, labelled and cleaned; the Article 14 human oversight assessment; any predetermined changes and the solutions that keep the system compliant across them; validation and testing procedures, the accuracy and robustness metrics used, and dated test logs signed by the responsible persons; and cybersecurity measures. Provenance and dated logs cannot be reconstructed later without redoing the work.
Block 3: monitoring, functioning and control
The capabilities and limitations of the system in performance, including degrees of accuracy for the specific persons or groups it is intended for and the overall expected accuracy; foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights and non-discrimination; the Article 14 human oversight measures, including what helps a deployer interpret an output; and the specifications on input data. The group-level breakdown is the part teams skip.
Block 4: the appropriateness of the performance metrics
Block 4 asks for something the rest of the file does not: not numbers, but the argument that the numbers are the right ones for this system. Why a threshold-independent measure rather than raw accuracy on an imbalanced population, why calibration matters when a score feeds a human decision, what the metric fails to capture and what you do about that gap.
Block 5: the Article 9 risk management system
Article 9 requires a continuous, iterative process across the lifecycle, regularly reviewed: identify and analyse the known and reasonably foreseeable risks to health, safety and fundamental rights, evaluate the risks arising from intended use and from reasonably foreseeable misuse, adopt targeted mitigations, and judge the residual risk acceptable. Because Article 9 is a process obligation, block 5 has to show the process running, not that a table exists.
Block 6: the changes made through the lifecycle
The relevant changes made across the lifecycle, in a form that lets a reader work out which version was assessed against which requirements. The compliance question is not which sprint a change landed in but whether it went beyond what the initial conformity assessment foresaw. A post-market change not foreseen there, which affects compliance or alters the intended purpose, is a substantial modification under Art 3(23): it forces a fresh assessment, and for anyone but the original provider it triggers the Article 25 flip.
Block 7: the harmonised standards applied
The harmonised standards applied in full or in part, with their references as published in the Official Journal. Where none was applied, the block converts: it then carries a detailed description of the solutions adopted to meet the Chapter III Section 2 requirements, plus the other standards and technical specifications used. There is no null answer here, and no standard being cited yet is exactly the situation the alternative wording is written for.
Block 8: a copy of the EU declaration of conformity
A copy of the declaration drawn up under Article 47. It carries an ordering trap: the declaration can only be signed once the conformity assessment is complete, and that assessment runs against the other eight blocks. Build blocks 1 to 7 and 9, run the Article 43 assessment, sign, then bind the copy back in.
Block 9: the post-market monitoring plan
The system for evaluating performance in the post-market phase under Article 72, including the monitoring plan itself. A usable plan names the signals collected from deployers, the route by which they reach you, who is accountable for reviewing them, the cadence, and the thresholds that trigger a change or a serious-incident report. Post-market findings are what drive the updates Article 11 requires.
When AI Act technical documentation is due, and how long you keep it
Three timing rules govern the file, and they are separate obligations rather than one. It is drawn up before the system is placed on the market or put into service. It is kept up to date for as long as the system is on the market. And it is retained, with the quality management system documentation, any notified body approvals and the EU declaration of conformity, for ten years after placement, at the disposal of national competent authorities.
Both dates come from the Digital Omnibus, adopted by the European Parliament on 16 June 2026 and the Council on 29 June 2026 and signed on 8 July 2026, though not yet published in the Official Journal at the July 2026 review date. See the AI Act timeline as amended by the Digital Omnibus. Retention runs from placement, so a system shipped in 2028 carries a documentation obligation into 2038.
The Article 11(2) simplified form for SMEs, and who qualifies
Article 11(2) lets providers that are SMEs, including start-ups, supply the Annex IV elements in a simplified form, with the Commission to establish a simplified technical documentation form aimed at the needs of small and micro enterprises. The SME test is the Union-wide definition in Commission Recommendation 2003/361/EC: fewer than 250 staff and either annual turnover not exceeding €50 million or an annual balance sheet total not exceeding €43 million.
Read the concession narrowly: it simplifies presentation, not substance. Every requirement in Articles 9 to 15 still has to be evidenced. The effect is fewer pages and a standard layout, not fewer facts. SME status does change the downside, because under Article 99(6) SMEs and start-ups pay the lower of the fixed sum or the turnover percentage where companies pay the higher. The tiers are in the guide to Article 99 penalties and split enforcement.
How the Annex IV file feeds conformity assessment under Article 43
The file is the evidence base for the conformity assessment under Article 43, which has to happen before a high-risk system is placed on the market. Article 43 sets two routes for Annex III systems, and the route changes how much scrutiny the file gets, and when.
The Annex VI internal control route
Annex VI is self-assessment. The provider verifies that its Article 17 quality management system conforms, examines the technical documentation, and checks that design, development and post-market monitoring match what the file says. No external body is involved. This is the route for Annex III points 2 to 8: hiring tools, credit models, education systems, essential-service systems.
The Annex VII notified-body route
Annex VII brings in an independent notified body, which assesses the quality management system and the technical documentation and can require further evidence, testing or access. Under Article 43 this is the route for Annex III point 1, biometrics, where harmonised standards do not exist or were not applied; where they were applied in full, the provider may choose. Annex I systems take neither route standing alone: their assessment runs under the relevant sectoral product legislation, into which Article 43(3) folds parts of the Annex VII procedure, with the notified body designated under that legislation checking the Chapter III Section 2 requirements.
| Question | Annex VI internal control | Annex VII notified body |
|---|---|---|
| Who assesses | The provider, alone | An independent notified body |
| When it applies | Annex III points 2 to 8, and point 1 biometrics where harmonised standards were applied in full | Annex III point 1 biometrics where harmonised standards do not exist or were not applied |
| What is examined | The Article 17 quality system and the Annex IV file, against actual design, development and monitoring | The same, plus power to demand evidence, testing or access before certifying |
| What comes out | A conformity conclusion the provider signs for itself | A notified body certificate, on top of the same file |
| When a thin file is caught | Late: when an authority asks, or an incident forces the ask | Immediately: the file is the object being assessed |
Internal control is a later audience, not a lighter standard. Annex VI removes the external reviewer, not the requirements. Articles 9 to 15 are identical on both routes, and the file still has to satisfy a market surveillance authority that can request it at any point in the ten-year window.
The Article 47 declaration of conformity and Article 49 registration
When the assessment concludes, the provider draws up a written EU declaration of conformity for each high-risk system under Art 47, machine-readable, physical or electronically signed. It identifies the system, states that it meets the Chapter III Section 2 requirements, is kept for ten years after placement and is given to national competent authorities on request. Where other Union harmonisation legislation also requires a declaration, a single one covers every applicable act. Signing is the operative step, and the CE marking under Article 48 follows from it.
Registration is the step that makes the system visible. Under Art 49 the provider registers itself and the system in the EU database before an Annex III high-risk system is placed on the market, and public-authority deployers register too. It reaches systems you concluded are not high-risk as well: under the Digital Omnibus a system self-assessed out under Article 6(3) must still be registered, in simplified form, after the Commission proposal to drop that duty did not survive negotiations. Article 6(4) separately requires that assessment to be documented before placing on the market, so read what a defensible Article 6(3) assessment has to contain before relying on the off-ramp.
Why 2 December 2027 is the wrong date to start documenting
The application dates tell you when the file has to be finished, not when to start it, and the gap matters more here than anywhere else in the Act, because Annex IV is largely retrospective. Blocks 2, 5 and 6 document things that happened: the data you selected and how you labelled it, the design choices and why, the tests you ran and when, the risks you reviewed, the changes you shipped. That is either captured as you go or reconstructed.
Picture a credit-scoring model built through 2025 and 2026 by a team that reads 2 December 2027 as a project start date. In late 2027 they need dated, signed test logs for validation runs nobody logged, provenance for a training set assembled from three vendor feeds and an internal warehouse, and a labelling procedure never written down. Everything they cannot evidence, they redo, against a system already in production, on a deadline, with the original engineers gone.
A file that overstates what was tested is its own offence. Failing the high-risk obligations sits in the €15,000,000 or 3% tier. Supplying incorrect, incomplete or misleading information to authorities or notified bodies has a separate tier at €7,500,000 or 1%. Under deadline pressure the tempting fix for an unevidenced block is confident prose. That converts one exposure into two.
Start where the obligation starts, which is classification. If the system is not high-risk, Annex IV does not attach. An Annex III system that you self-assess out under Article 6(3) is the exception: the reasoning still has to be documented under Article 6(4) before placement, and the system still has to be registered in simplified form. If it is high-risk, you know which blocks you owe and which route you are on. The two Article 6 routes into the high-risk regime set out the test, and the free triage classifier walks the same questions in order. Primary sources: the regulation on EUR-Lex and the Commission AI policy pages.