Article 11 is short enough to read in a minute and tells you almost nothing about what you have to write, because it delegates the content to Annex IV. The annex is the requirement, and it has nine headings.
What Article 11 itself says
Article 11(1) of Regulation (EU) 2024/1689 requires the technical documentation of a high-risk AI system to be drawn up before the system is placed on the market or put into service, and kept up to date. It must be drawn up so as to demonstrate compliance with the Chapter III Section 2 requirements and to provide national competent authorities and notified bodies with the necessary information, in a clear and comprehensive form, to assess that compliance. It shall contain, at a minimum, the elements set out in Annex IV.
Three things follow from that sentence and each is operationally significant. The documentation must exist before market placement, so it is a gate rather than a record. Its purpose is stated as demonstrating compliance to a reader, which means an internal engineering wiki that happens to contain the facts does not satisfy it unless it is organised to be assessed. And Annex IV is a floor, not a ceiling.
Article 11(2) handles the product case: where a high-risk system is related to a product covered by the Union harmonisation legislation in Annex I Section A, a single set of technical documentation is drawn up containing both the Article 11 information and whatever those acts require. One file, not two. Article 11(3) empowers the Commission to amend Annex IV by delegated act where necessary in light of technical progress, so the checklist below is the current one rather than a permanent one.
Not legal advice. Whether Annex IV or an Annex I sectoral regime governs a particular file, and how the two combine, is product-specific. And because Article 11(3) permits amendment of Annex IV by delegated act, verify the annex against the consolidated text of the AI Act on EUR-Lex before using any list — including this one — as a compliance checklist. On timing: Article 113 as adopted made this obligation apply from 2 August 2026, but Regulation (EU) 2026/1744, the Digital Omnibus on AI, in force since 27 July 2026, postponed it to 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for high-risk systems embedded in Annex I products. Note what that does and does not buy you: Article 11(1) requires the file to exist before the system is placed on the market, and the four items below that have to be captured contemporaneously do not become easier to reconstruct because the deadline moved.
The nine Annex IV headings
1. General description of the system
Intended purpose, provider name, version and its relation to previous versions; how the system interacts with hardware or software not part of it, including other AI systems; the versions of relevant software or firmware and any version-update requirements; all the forms in which the system is placed on the market or put into service — packages embedded in hardware, downloads, APIs; the hardware it is intended to run on; where it is a component of products, photographs or illustrations of external features, marking and internal layout; instructions for use and a basic description of the deployer-facing user interface.
2. Detailed description of the elements and development process
This is the longest heading and it has eight sub-items: development methods and steps including any recourse to pre-trained systems or third-party tools and how they were used, integrated or modified; design specifications including the general logic and the algorithms, key design choices with their rationale and assumptions, the main classification choices, what the system optimises for and the relevance of the different parameters, the expected output and output quality, and the trade-offs made regarding technical solutions adopted to comply with Section 2; system architecture and the computational resources used to develop, train, test and validate; data requirements in the form of datasheets; assessment of the human oversight measures needed under Article 14; any pre-determined changes to the system and its performance and the technical solutions ensuring continued compliance; validation and testing procedures, metrics for accuracy, robustness and other Section 2 compliance including potentially discriminatory impacts, and test logs and reports dated and signed by the responsible persons; and cybersecurity measures.
3. Monitoring, functioning and control
Capabilities and limitations in performance, including degrees of accuracy for the specific persons or groups the system is intended to be used on and the overall expected accuracy against intended purpose; foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights and discrimination; the human oversight measures and the technical measures facilitating interpretation of outputs by deployers; and specifications on input data as appropriate.
4. Appropriateness of the performance metrics
A description of why the chosen metrics are the right ones for this system. Reporting a number is not enough; the file must argue that the number measures what matters here.
5. The risk management system
A detailed description in accordance with Article 9.
6. Relevant changes through the lifecycle
A description of changes made by the provider over the system’s life. This is a running record, which is what Article 11(1)’s “kept up to date” means in practice.
7. Standards applied
A list of harmonised standards applied in full or in part whose references have been published in the Official Journal; where none have been applied, a detailed description of the solutions adopted to meet the Section 2 requirements, including a list of other standards and technical specifications applied. See the standards landscape for why this heading is currently harder than it will be.
8. The EU declaration of conformity
A copy of the declaration referred to in Article 47.
9. Post-market performance evaluation
A detailed description of the system in place to evaluate performance in the post-market phase under Article 72, including the post-market monitoring plan.
The four items that are hard to produce late
Most of Annex IV can be written retrospectively by someone with access to the codebase. Four items cannot, and they are the ones worth engineering for before the file is due.
- Dated and signed test logs (point 2(g)). A test run that was not recorded at the time cannot be reconstructed with a credible date.
- Data provenance and selection (point 2(d), and Article 10(2)(b)). Provenance not captured at collection time is often unrecoverable.
- Version lineage (points 1(a) and 6). The relation of each version to its predecessors, and the changes between them, is a record that has to accumulate.
- Third-party component history (point 2(a)). Which pre-trained model, which version, obtained when, modified how — this is exactly the information that disappears when a dependency is upgraded in place.
The version lineage item is worth a note for anyone whose system calls a model over an API rather than shipping weights. Annex IV point 1(a) asks for the version of the system and its relation to previous versions, and point 2(a) for how third-party components were used — but a hosted model identifier that resolves to a moving target gives you neither. Pinning a dated model version per request, and keeping a record of which version served which call, is what turns “we call a vendor endpoint” into something Annex IV can be written about. A gateway that records the resolved model version and provider on every request produces that record as a by-product; Multigrid does, which is the honest reason to mention it here.
The simplified form for small providers
Article 11(1) provides that SMEs, including start-ups, may provide the Annex IV elements in a simplified manner, and requires the Commission to establish a simplified technical documentation form targeted at the needs of small and micro enterprises, which those providers may use. The elements are not reduced — the manner of providing them is. Check whether the Commission form has been published before assuming a lighter file will be accepted.
How long it must be kept, and by whom
Article 18 requires providers to keep at the disposal of national competent authorities, for ten years after the system has been placed on the market or put into service: the Article 11 technical documentation; the documentation on the quality management system under Article 17; documentation on changes approved by notified bodies where applicable; decisions and other documents issued by notified bodies; and the EU declaration of conformity under Article 47.
Ten years is a different obligation from the six-month minimum for automatically generated logs under Article 19, and the two are frequently confused — see the Article 12 logging requirement for that distinction. The technical documentation is also what a notified body assesses where third-party conformity assessment applies, which is the point at which the quality of the file stops being an internal matter: see Article 43 conformity assessment.
Top comments (0)