Article 11 requires a provider to draw up technical documentation for a high-risk AI system before it is placed on the market or put into service, and to keep it up to date. The documentation must contain the information in Annex IV, including a general description of the system, its intended purpose, its design and development, its data and data governance, its human oversight, its testing and validation, and its post-market monitoring. For Annex I Section A products, the technical documentation may be part of the product technical file, provided the Annex IV information is included. Documentation must be kept for ten years under Article 18 and made available to authorities on request, and it must be sufficient for an authority to assess conformity.
What is technical documentation for?
Technical documentation is the evidence that a system meets the Chapter III requirements. It allows a provider to show, a notified body to assess, and an authority to verify, how the system was designed, what it is intended to do, how it was tested, and how it is monitored. Without it, conformity is an assertion. With it, conformity is traceable from requirement to design to test to result. The documentation should be written for a competent reviewer who does not know the system, with enough detail to follow the reasoning without needing to ask the author for missing pieces. It should be accurate, complete and current, and it should reflect the system as supplied, not an earlier version or a planned version.
What does Annex IV require?
Annex IV sets out the information the documentation must contain. It includes a general description of the system, including its intended purpose, the version, the provider, and the interaction with other hardware or software; a detailed description of the elements of the system and the process for its development, including design specifications, methods, and the logic of the system where relevant; a description of the data sets used, including their provenance, scope, and data governance; a description of the human oversight measures; a description of the pre-determined changes and the performance metrics; a description of the testing, validation and evaluation procedures and results; a description of the risk management system; and a description of the post-market monitoring plan. The provider should work through Annex IV point by point, and record where each point is addressed, rather than producing a general product description and assuming it covers the annex.
For the broader regulatory framework, see provider responsibilities.
How detailed should the description of the system be?
The description should be detailed enough to assess conformity, without disclosing more than the annex requires. It should cover the architecture, the model and components, the data flows, the user interface, the operating conditions, and the expected performance, including accuracy metrics and their limitations. For systems using machine learning, it should describe the training, validation and testing approach, the data characteristics, and the measures taken to address bias and error. For systems using a general-purpose model, it should describe the model, the adaptation, and the system-level controls that surround it. Trade secrets and intellectual property can be protected through the handling of the documentation, but they do not justify omitting information the annex requires.
How should documentation be kept up to date?
Article 11 requires the documentation to be kept up to date. Every substantial change to the system, every new version, and every change to the intended purpose, data, or oversight design should trigger a documentation update before the changed system is supplied. The update should be versioned, dated, and linked to the change record, so that the documentation for each version of the system can be identified. A documentation set that describes version one while version three is on the market is not up to date, even if version one was fully documented at release. The provider should assign an owner for the documentation, set review triggers, and check the documentation as part of the release process, not as an afterthought.
How does documentation relate to instructions for use?
Technical documentation is for the provider, the notified body and the authority. Instructions for use under Article 13 are for the deployer, and must be concise, complete, correct and clear, and in a form that the deployer can use. The two documents draw on the same facts but serve different readers. The instructions should be consistent with the technical documentation: the intended purpose, the capabilities and limitations, the oversight measures, and the performance information must match. An inconsistency between the two documents undermines both, because a deployer acting on the instructions will operate the system differently from the system described in the technical file. A consistency check should be part of the release process.
Continue with Article 16 provider duties.
What is not covered by this guide?
This guide explains the Article 11 and Annex IV structure in outline. It does not provide a template that guarantees conformity, does not decide what information a specific system must contain beyond the annex wording, and does not address the product technical file requirements under sectoral legislation in detail. Each system needs its own documentation, built from Annex IV, the system design, and the conformity route, and confirmed with a notified body where one is involved and with a competent authority or legal adviser where the documentation approach is novel. The documentation should be treated as a living compliance record, not as a document produced once for a filing.
Frequently asked questions
When must technical documentation be drawn up?
Before the high-risk system is placed on the market or put into service, under Article 11. It must then be kept up to date throughout the lifecycle, and kept for ten years under Article 18.
Can technical documentation be part of a product file?
For Annex I Section A products, the Annex IV information can be included in the product technical documentation, provided it is present and identifiable. The provider should map the Annex IV points to the product file so that a reviewer can find each point.
Who can request technical documentation?
National competent authorities can request it, and notified bodies assess it as part of conformity assessment where they are involved. It must be sufficient for an authority to assess whether the system complies with the Chapter III requirements.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗