Reg. (EU) 2024/1689

EU AI Act Annex IV Technical Documentation: Complete Guide

Article 11 + Annex IV Providers only Updated June 2026 · 12 min read

Providers of high-risk AI systems must prepare and maintain a technical documentation file before placing their system on the EU market. Annex IV of Regulation (EU) 2024/1689 defines what that file must contain — nine mandatory sections covering the system's design, development, performance, risk management, and conformity evidence. This guide explains what belongs in each section.

Contents

  1. Who must prepare Annex IV documentation
  2. The nine sections — complete breakdown
  3. Conformity assessment and CE marking
  4. EU AI database registration
  5. Retention and update requirements
  6. What deployers should ask for
  7. FAQ

1. Who must prepare Annex IV documentation

Article 11 imposes the technical documentation obligation on providers of high-risk AI systems. A provider is any legal or natural person who develops or commissions a high-risk AI system and places it on the EU market or puts it into service in the EU under their own name or trademark.

This covers:

Deployers who use third-party tools do not prepare Annex IV documentation — they are entitled to receive it from their vendors and should ask for it as part of vendor due diligence. See Section 6.

Fine-tuning and substantial modification If your company fine-tunes a general-purpose AI model (like GPT-4 or Llama) for a high-risk use case and places it on the market, you are the provider of the resulting high-risk AI system. You must prepare Annex IV documentation for your version of the system.

2. The nine sections — complete breakdown

Section 1

General description of the AI system

The intended purpose, the persons or groups affected, how the system interacts with hardware and software, version information, and the categories of natural persons and organisations the system is intended to be used by. This is the overview section — it sets context for everything that follows.

Section 2

Description of the development process

Methods, techniques, and tools used to develop the system; design specifications (overall logic, design choices, key assumptions); training methodologies; datasets used for training, validation, and testing (with documentation of data governance, data sources, and labelling procedures); and the computing infrastructure used. This section must allow an auditor to understand and replicate the development process in principle.

Section 3

Detailed information about system performance

The measures of performance — accuracy, robustness, cybersecurity metrics; the performance across all groups the system affects; the foreseeable unintended outcomes and sources of risk; the results of testing and validation; and where applicable, the description of evaluation procedures and results on benchmarks. For systems affecting protected groups (gender, ethnicity, age), bias testing results must be documented.

Section 4

Risk management documentation

Description of the risk management system implemented in accordance with Article 9: the identification and analysis of known and reasonably foreseeable risks; the estimation and evaluation of risks; the adopted risk mitigation and control measures; residual risk assessments; and the post-market monitoring plan. The risk management system must be documented as an ongoing process — not a one-off exercise.

Section 5

Data governance description

The data governance and management practices for training, validation, and testing datasets. This covers: the origin and provenance of data; the data collection and processing procedures; the extent of the data (geographical, time period, population); the examination for possible biases; the measures taken to detect and correct bias; and the data quality assessment methodology. GDPR documentation should be cross-referenced here where training data includes personal data.

Section 6

Logging capability description

Description of the automatic logging capabilities of the system (Article 12): what events are recorded, at what level of detail, what the log format is, how long logs are retained in the system before handover to the deployer, and how the logs enable the reconstruction of the sequence of events leading to an incident or anomaly. Logs must be sufficient to identify whether the system has been used in its intended purpose.

Section 7

Description of human oversight measures

The technical measures built into the system to support human oversight (Article 14): the user interface design choices that facilitate oversight; the ability to pause or interrupt the system; the ability to override outputs; the information provided to deployers about the system's confidence levels and limitations; and how the system alerts the human oversight person to situations where its confidence falls below a defined threshold.

Section 8

Cybersecurity measures

Measures implemented in accordance with Article 15 to ensure the accuracy, robustness, and cybersecurity of the system. This covers: resilience against errors, faults, and inconsistencies; resilience against adversarial attacks (including data poisoning, model evasion, and model extraction attacks); and any technical solutions implemented for backup and fail-safe capabilities. Cybersecurity documentation should reference the provider's broader information security framework.

Section 9

Declaration of Conformity

The EU Declaration of Conformity signed by the provider declaring that the high-risk AI system meets all applicable requirements of the EU AI Act. The Declaration must include: the provider's name and address, the AI system's name and version, a statement that the system is in conformity with the regulation, references to any harmonised standards applied, the date and place of issue, and the name and signature of the responsible person.

3. Conformity assessment and CE marking

Before placing a high-risk AI system on the market, providers must carry out a conformity assessment under Article 43. For most Annex III high-risk AI systems, providers can carry out an internal conformity assessment — they self-assess against the requirements without requiring a third-party notified body.

Exceptions requiring third-party assessment:

After successful conformity assessment, providers must affix the CE marking to the high-risk AI system or its documentation. The CE marking must be visible, legible, and indelible. It must appear before the system is placed on the market.

Conformity assessment is not a one-time event Article 43(4) requires providers to carry out a new conformity assessment when making changes to a high-risk AI system that may affect compliance. Changes to training data, model architecture, intended purpose, or performance thresholds all potentially trigger reassessment. Build reassessment into your change management process.

4. EU AI database registration

Article 49 requires providers of high-risk AI systems to register their systems in the EU AI database before placing them on the market. The database is publicly accessible and covers:

Registration in the EU AI database is a prerequisite to lawful market placement — not an optional step to be completed after launch.

5. Retention and update requirements

Article 11(3) requires technical documentation to be kept for 10 years after the high-risk AI system has been placed on the market or put into service. If the system is withdrawn or discontinued, documentation must still be available to national authorities for 10 years from the last date of operation.

Documentation must be updated whenever a change is made to the system that could affect compliance. This includes:

6. What deployers should ask for

Deployers of high-risk AI systems cannot access the full internal Annex IV documentation — it may contain trade secrets. However, Article 13 requires providers to supply deployers with instructions for use that contain sufficient information to enable deployers to fulfil their Article 26 obligations. These instructions must include:

Deployers should also request a copy of the EU Declaration of Conformity and the EU AI database registration number before deploying a high-risk AI system.

FAQ

Do SMEs have reduced documentation obligations?

The substance of Annex IV documentation obligations is the same for all providers regardless of size. However, the AI Office and national authorities are expected to publish guidance and simplified templates for SMEs. Proportionality applies in practice — a small-scale AI system will have shorter but still complete documentation. The nine sections are required regardless of company size.

What if our AI system uses a third-party model as its base?

If you fine-tune, retrain, or substantially modify a foundation model and place the result on the market as a high-risk AI system, you are the provider and must prepare Annex IV documentation for your version of the system. Your documentation should reference the base model's characteristics and the modifications you made. You should also obtain the base model provider's technical documentation to the extent they make it available — GPAI providers have their own transparency obligations under Article 53.

How does Annex IV relate to GDPR Data Protection Impact Assessments?

Both requirements apply to high-risk AI systems processing personal data, and they have significant overlap — particularly around data governance (Annex IV Section 5) and risk management (Section 4). Many of the questions a DPIA asks are also addressed in Annex IV. Running both exercises together is more efficient than treating them as separate. Your DPO should be involved in preparing both.

FREE MONTHLY UPDATES

Stay ahead of EU AI Act deadlines

Regulatory changes, compliance guides, and deadline reminders — delivered monthly. Free.

No spam. Unsubscribe anytime.