Annex IV Technical Documentation: The Nine Points
The nine points of EU AI Act Annex IV for the technical documentation of high-risk AI systems, with the rules around them: timing, retention, SME form and scope.
Annex IV lists nine points that the technical documentation of a high-risk AI system must contain at least, as applicable to the system.
Providers must draw it up before placing the system on the EU market or putting it into service (Article 11(1)). The duty applies from 2 December 2027 (Annex III systems) or 2 August 2028 (Annex I). Missing documentation breaches Article 16. Fines reach EUR 15 million or 3% of worldwide annual turnover, whichever is higher (Article 99(4)). Next step: compare your system with the nine points below.
We group six rules around the documentation
Before market placement or service
Prepare the documentation before the system is placed on the market or put into service, and keep it up to date (Article 11(1)).
Keep it for 10 years
Keep the documentation at the disposal of national authorities for 10 years after the system is placed on the market or put into service (Article 18(1)).
Simplified form for small firms
SMEs, including start-ups, and small mid-cap companies may provide the Annex IV elements in a simplified form. The Commission must set up the form, and notified bodies must accept it (Article 11(1)). For SMEs and small mid-caps, fines are capped at the lower amount (Article 99(6) and (6a)).
One set for product laws
If the system relates to a product under the Annex I Section A laws, draw up a single set of documentation that also covers those laws (Article 11(2)).
Some scope limits
Annex IV applies to high-risk AI systems within the scope of the Act. The Act does not affect areas outside Union law and does not apply to AI systems where and in so far as they are used exclusively for military, defence or national security purposes (Article 2(3)), or to scientific research systems and pre-market research or testing (Article 2(6) and (8)). For AI systems classified high-risk under Article 6(1) that relate to products under Annex I Section B, only Article 6(1), Article 60a and Articles 102 to 112 apply. Articles 57 to 59 apply only in so far as the requirements for high-risk AI systems are integrated in that product legislation (Article 2(2)).
Systems already on the market
A high-risk system placed on the market or put into service before the application date is covered only if its design changes significantly afterwards. In any case, providers and deployers of high-risk systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 (Article 111(2)). AI systems that are components of the large-scale IT systems of Annex X, placed on the market before 2 August 2027, must comply by 31 December 2030 (Article 111(1)).
Annex IV has nine points
General description
1
Point 1 identifies the system: what it is for, which version it is, where it runs and how it is supplied.
What the Annex requires
- Intended purpose, provider name and system version, including its relation to previous versions
- How the system interacts with hardware or software that is not part of it, where applicable
- Versions of relevant software or firmware and any requirements for version updates
- All forms in which the system is placed on the market or put into service, such as software packages embedded in hardware, downloads or APIs
- The hardware on which the system is intended to run
- For a component of a product: photographs or illustrations showing external features, marking and internal layout
- A basic description of the user interface provided to the deployer
- Instructions for use for the deployer
Practical tip (not required by the Act)
Keep this point in a versioned file next to the code and update it with each release.
Elements and development process
2
Point 2 is the longest: it covers how the system was built, trained, tested and secured.
What the Annex requires
- Development methods and steps, including pre-trained systems or tools from third parties and how they were used, integrated or modified
- Design specifications: general logic and algorithms, key design choices with rationale and assumptions (including about the persons or groups the system is used on), main classification choices, what the system is designed to optimise for and the relevance of the different parameters, expected output and output quality, and trade-offs made to meet Chapter III, Section 2
- System architecture and the computational resources used to develop, train, test and validate the system
- Where relevant, data requirements as datasheets: training methods, data sets, provenance, scope, main characteristics, how data was obtained and selected, labelling and cleaning
- Assessment of the human oversight measures needed (Article 14), including technical measures that help deployers interpret outputs (Article 13(3)(d))
- Where applicable, pre-determined changes to the system and its performance, with the technical solutions that keep it compliant
- Validation and testing: procedures, data used, metrics for accuracy, robustness and other requirements, potentially discriminatory impacts, and dated, signed test logs and reports
- Cybersecurity measures put in place
Practical tip (not required by the Act)
Derive architecture and dependency lists from the repository, and add the rationale that only your team knows.
Monitoring, functioning and control
3
Point 3 states what the system can and cannot do, and which risks and oversight measures follow.
What the Annex requires
- Capabilities and limitations in performance, including accuracy for specific persons or groups and the overall expected accuracy for the intended purpose
- Foreseeable unintended outcomes and sources of risk to health and safety, fundamental rights and discrimination
- Human oversight measures (Article 14), including technical measures that help deployers interpret outputs
- Specifications on input data, as appropriate
Practical tip (not required by the Act)
Record measured accuracy per group together with the test that produced it.
Performance metrics
4
Point 4 asks for a description of why the performance metrics are appropriate. The metrics themselves belong under point 2.
What the Annex requires
- A description of why the performance metrics are appropriate for this specific AI system
Risk management system
5
Point 5 refers to the risk management system of Article 9.
What the Annex requires
- A detailed description of the risk management system in accordance with Article 9
Changes over the lifecycle
6
Point 6 keeps the documentation current: it records what changed after the first release.
What the Annex requires
- A description of relevant changes made by the provider to the system through its lifecycle
Practical tip (not required by the Act)
Use release notes and git history, and mark which changes were pre-determined (point 2(f)).
Standards and other solutions
7
Point 7 names the standards you relied on, or explains your own solutions.
What the Annex requires
- A list of the harmonised standards applied in full or in part whose references are published in the Official Journal of the European Union
- Where no such standards were applied: a detailed description of the solutions adopted to meet Chapter III, Section 2, with a list of other standards and technical specifications applied
EU declaration of conformity
8
Point 8 attaches the declaration of conformity.
What the Annex requires
- A copy of the EU declaration of conformity (Article 47)
Post-market evaluation
9
Point 9 links the documentation to post-market monitoring.
What the Annex requires
- A detailed description of the system in place to evaluate performance in the post-market phase (Article 72)
- The post-market monitoring plan (Article 72(3))
What Scanara does for Annex IV documentation
Scanara checks your compliance documents for required content. It does not check that the content is true.
Annex IV documentation drafts
Scanara generates Annex IV documents from your inputs and assessment answers. You review and complete them. A draft is not automatically accurate or complete.
Versioned evidence
Scanara keeps versions and timestamps of the documents and of the assessment answers behind them.
Common questions about Annex IV
How long must I keep technical documentation?
For 10 years after the AI system is placed on the market or put into service, at the disposal of the national competent authorities (Article 18(1)).
Can SMEs use simplified documentation?
Yes. SMEs, including start-ups, and small mid-cap companies may provide the Annex IV elements in a simplified form. The Commission must establish the form, and notified bodies must accept it for the conformity assessment (Article 11(1)).
What triggers an update of the documentation?
The documentation must be kept up to date (Article 11(1)). A substantial modification, meaning a change not foreseen or planned in the initial conformity assessment that affects compliance or the intended purpose (Article 3(23)), requires a new conformity assessment (Article 43(4)). Changes of a continuously learning system that were pre-determined and documented under point 2(f) of Annex IV are not substantial modifications.
Read next: Article 11, Annex III and the AI inventory
Article 11: Technical Documentation and Annex IV
Explains when the documentation is due, the simplified form for small firms and the fines.
Annex III Deep Dive: All 8 High-Risk Categories
Lists the 8 areas whose AI systems are high-risk and so need this documentation.
Shadow AI: Building an AI System Inventory
Shows how to find the AI systems in your organisation before you document them.
Scanara prepares evidence from your repositories
Scanara reads your connected GitHub repositories and runs rule-based scans for standard AI and machine-learning patterns. It can miss non-standard code. Separately, it generates draft documentation from templates and your assessment answers as evidence for your compliance work. You make the classification decisions.