How to Write EU AI Act Technical Documentation: Annex IV Guide

Article 11 and Annex IV of EU AI Act Regulation 2024/1689 require providers of high-risk AI systems to draw up and continuously maintain technical documentation. Eight specific sections. Version-controlled. Retained for up to 10 years. Here is what each section requires and how to keep it current.

Article 11 of EU AI Act Regulation 2024/1689 requires that providers of high-risk AI systems draw up technical documentation before market placement and keep it updated. The content requirements are specified in Annex IV. This is not a summary document or a product brochure. It is a detailed, version-controlled technical record that must reflect the current state of your AI system at all times.

Here is what Annex IV actually requires, and where most teams fall short.

The Eight Sections of Annex IV

1. General Description of the AI System

This section must include: the intended purpose of the system; the version history with key changes per version; a description of the hardware on which the system operates; and a description of the software, including where relevant the software stack. It must also include a reference to the instructions for use required under Article 13.

2. Detailed Description of System Elements and Their Development

This is the technical core of Annex IV. It requires: general logic, design choices, and key design assumptions; the architecture of the system; training methodologies and techniques used; a description of the training data including provenance, labelling process, and data governance; validation and testing data; and a description of any pre-trained models used, including provenance and any fine-tuning steps.

If you used a foundation model and fine-tuned it, you must document the pre-trained model's origin, the fine-tuning dataset, and how fine-tuning changed the system's behaviour. "We used GPT-4" is not Annex IV documentation.

3. Monitoring, Functioning, and Control

This section covers the capabilities and limitations of the system; the performance metrics (accuracy, robustness, cybersecurity); known biases and their potential impact; and the measures taken to achieve the required accuracy, robustness, and cybersecurity standards under Article 15.

4. Risk Management

A description of the risk management system under Article 9, including the methodology used, the risks identified, and the measures adopted to address them. This section must reference your Article 9 documentation directly.

5. Changes to the System

A description of any changes made to the system through its lifecycle that were assessed for their impact on performance, risk, and compliance. This is the section most teams fail to maintain post-launch.

6. Assessment of Conformity with Article 9(9) Requirements

Documentation of the testing conducted to verify the risk management measures are effective, including testing methodologies, test sets, and results.

7. Detailed Description of the Post-Market Monitoring System

A description of the post-market monitoring plan required under Article 72, including: what metrics are monitored, at what frequency, what triggers a formal review, and how findings are fed back into the risk management system.

8. Listing of Relevant Standards

If harmonised standards were applied, a list of those standards and, where standards were not applied or only partially applied, a description of the solutions adopted to meet the requirements of Articles 8-15.

The Currency Problem

Annex IV documentation must reflect the current state of the system. This creates a continuous documentation obligation tied to every change:

Change eventAnnex IV sections that must update
Model retrainSections 2 (training data, methodology), 3 (performance metrics), 4 (risks), 5 (changes), 6 (testing)
New training dataset versionSections 2 (data description, governance), 5 (changes)
Deployment to new market or user groupSections 1 (intended purpose), 3 (limitations), 4 (risks), 7 (monitoring)
Third-party model updateSections 2 (pre-trained model reference), 3 (performance), 4 (risks)
New integration or data sourceSections 1 (system description), 2 (architecture), 4 (risks)

Who Maintains This and How

Annex IV documentation is a provider obligation. In practice, it requires close collaboration between engineering (who can document architecture, training methodology, and testing results), data science (who can document data provenance and performance metrics), and legal/compliance (who can ensure the regulatory framing is accurate).

The documentation must be retained for 10 years after market placement in most cases, and must be available to national market surveillance authorities on request. It is not a public document, but it is a mandatory one.

Engineering teams that maintain Annex IV documentation in Confluence or as part of their CI/CD pipeline -- where changes trigger documentation updates -- are far better positioned than those maintaining static PDFs. Best practices for structuring this in your engineering workflow are covered separately.


Frequently Asked Questions

How long must Annex IV technical documentation be retained?

Article 18 requires providers to keep the technical documentation for 10 years after the high-risk AI system has been placed on the market or put into service. For systems subject to a conformity assessment by a notified body, the documentation must be available to the notified body on request throughout the product's market lifetime.

Does technical documentation need to be translated for each EU market?

Article 18 specifies that technical documentation must be in a language required by the relevant Member State. Where a harmonised standard applies, the documentation requirements follow that standard. For market surveillance authority access, documentation may need to be made available in the national language of the authority requesting it.


Vigilens automates EU AI Act compliance -- turning Articles 9, 12, 13, and 14 into machine-executable controls with continuous evidence from your engineering tools.

CLASSIFY YOUR AI SYSTEM → GET EARLY ACCESS