What technical documentation does Article 11 require?

What must Annex IV documentation contain?

Annex IV sets out the elements the technical documentation must contain, in outline covering a general description of the system, its intended purpose and operating logic, design and development information, data and data governance information, human oversight and control information, and information on monitoring, functioning and maintenance. The documentation should be written so that a competent reviewer who was not involved in development can follow the reasoning from intended purpose through risk management, data, testing and controls to the conformity conclusion. Each element should be present or its absence explained by reference to the system, rather than left blank. A documentation set that contains only marketing descriptions, or only code, will not demonstrate compliance with the Section 2 requirements, because it does not connect design choices to the legal requirements they are meant to meet.

When must documentation be drawn up and updated?

Technical documentation must be drawn up before the system is placed on the market or put into service, and must be kept up to date. Keeping it up to date means updating it when the system, its data, its intended purpose, or its deployment changes in a way that affects the information in the file. Updates should be versioned, dated, and approved, with earlier versions retained so that the history of the system can be reconstructed. A provider should assign a documentation owner, set review triggers tied to system changes, and check the file before each release. Documentation that describes an earlier version of the system, while a different version is on the market, creates a mismatch that undermines conformity assessment, registration and market surveillance alike.

For the broader regulatory framework, see High-risk requirements overview.

Who needs to be able to use the documentation?

The documentation must be sufficient for national competent authorities and, where a notified body is involved, for that body to assess compliance with the Section 2 requirements. That audience shapes the writing: the file should be complete, intelligible and traceable, with cross-references between claims, evidence and annexes. It should not rely on undocumented knowledge held by the development team, and it should not bury a key conclusion in an appendix without a pointer from the main text. A provider should test the file by asking an independent reviewer to follow it without assistance, and should record the review and any gaps found. The documentation is also the basis for the deployer information under Article 13, although the deployer pack is a separate, usable extract rather than the full technical file.

What simplified treatment exists for smaller providers?

Regulation (EU) 2026/1744 introduced simplifications to Article 11 for small and medium-sized enterprises and small mid-cap enterprises, as set out in the consolidated text. The simplifications concern the form and extent of technical documentation, not the removal of the underlying Section 2 requirements. A provider that considers itself within the simplified treatment should check the consolidated Article 11 and Annex IV wording, record the basis for the treatment, and ensure that the simplified file still demonstrates compliance with the requirements that apply to its system. The treatment should not be assumed from company size alone without checking the definitions and conditions in the text. Where the position is unclear, the provider should seek qualified review and record the conclusion, rather than producing a reduced file without a stated basis.

How long must documentation be kept?

Providers must keep technical documentation, together with related records such as the quality management system documentation and conformity records, available for a period set by the Act, which should be checked in the consolidated text for the system in question. The retention period runs from the placing on the market or putting into service of the system, and the file should remain retrievable and intelligible for the whole period. Retention planning should cover storage, access control, version preservation and handover if the provider's structure changes. A provider should not rely on individual team members' personal drives or on a system that is decommissioned when a product line ends. The retention log should state what is held, where, and until when, so that an authority request years after release can still be answered.

Continue with Evidence chains for high-risk requirements.

What does this guide not decide?

This guide does not decide whether a particular documentation set meets Annex IV, whether simplified documentation treatment applies to a specific provider, or how long a particular file must be kept. It does not approve a documentation template or assess a conformity conclusion. Those questions depend on the system, the provider's status, the consolidated Article 11 and Annex IV text as amended, and the evidence in the file. A provider should have its documentation reviewed by a competent authority or legal adviser where the position is contested, keep the file version-matched to the system on the market, and update it whenever the system changes.

Frequently asked questions

Continue through this AI Act cluster

• High-risk requirements overview
• Evidence chains for high-risk requirements
• Article 13 transparency to deployers
• Conformity assessment and CE marking
• Provider responsibilities
• What risk management system does Article 9 require?