Article 11 · Annex IV · Updated for the Digital Omnibus

EU AI Act technical documentation: what Annex IV requires

Every high-risk AI system needs a technical file before it reaches the EU market. Here is what goes in it, point by point, with a free checklist that saves your progress and exports to Markdown for your repository.

Who

Providers of high-risk AI systems. Deployers have other duties (Art. 26); general-purpose AI model providers document under Art. 53 and Annexes XI-XII instead.

When

Before the system is placed on the market or put into service, then kept up to date. Applies from 2 Dec 2027 (Annex III) and 2 Aug 2028 (Annex I products).

How long

10 years after placing on the market, together with your quality management system records and the EU declaration of conformity (Art. 18).

Smaller companies

SMEs, start-ups and, since the Digital Omnibus, small mid-caps may use the Commission’s simplified form. Notified bodies must accept it.

Not sure your system is high-risk? Technical documentation is only mandatory for high-risk systems. Classify it first (3 minutes, free) or look up your use case.

The Annex IV checklist

The nine points every technical file must cover, paraphrased from the regulation. Tick what you already have; the outline you export keeps the same structure, ready to fill.

0 of 26 Annex IV items covered (0%). Saved in this browser only.

1. General description of the AI system

0/8

What the system is, who makes it, how it is delivered and how deployers use it.

1(a) Intended purpose, provider name, and the system version (with its relation to earlier versions).
1(b) How the system interacts with hardware, software or other AI systems that are not part of it.
1(c) Versions of relevant software or firmware and any requirements for version updates.
1(d) Every form in which it is placed on the market or put into service (embedded software, download, API, etc.).
1(e) The hardware it is intended to run on.
1(f) If it is a component of a product: photos or illustrations of external features, marking and internal layout.
1(g) A basic description of the user interface provided to the deployer.
1(h) The instructions for use for the deployer (Article 13).

2. Elements of the system and its development process

0/8

How it was built, on what data, how it was tested and how it is secured.

2(a) Development methods and steps, including any third-party pre-trained systems or tools and how you used, integrated or modified them.
2(b) Design specifications: general logic and algorithms, key design choices and their rationale (including who the system is meant for), main classification choices, what it optimises for, expected output, and trade-offs made to meet the requirements.
2(c) System architecture (how the software components fit together) and the compute used to develop, train, test and validate it.
2(d) Where relevant, data requirements: datasheets on training methods and data sets, with provenance, scope, main characteristics, how data was obtained and selected, labelling and cleaning.
2(e) Assessment of the human oversight measures needed (Article 14), including technical measures that help deployers interpret outputs.
2(f) Where applicable, pre-determined changes to the system and its performance, and how it stays compliant through them.
2(g) Validation and testing: test data and its characteristics, metrics for accuracy, robustness and potentially discriminatory impacts, and dated, signed test logs and reports.
2(h) The cybersecurity measures put in place.

3. Monitoring, functioning and control

0/3

What the system can and cannot do, and for whom it performs worse.

3 Capabilities and limitations in performance, including accuracy for the specific persons or groups it is used on and the overall expected accuracy.
3 Foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights and discrimination.
3 The human oversight measures, and specifications for input data where appropriate.

4. Appropriateness of the performance metrics

0/1

Why the metrics you chose are the right ones for this system.

4 A description of why the chosen performance metrics are appropriate for this specific system.

5. Risk management system

0/1

The Article 9 process, described in detail.

5 A detailed description of the risk management system under Article 9.

6. Changes through the lifecycle

0/1

What you changed after release, and when.

6 A description of relevant changes made by the provider to the system through its lifecycle.

7. Harmonised standards applied

0/2

Which standards you followed, or how you met the requirements without them.

7 The harmonised standards applied in full or in part (with their Official Journal references).
7 If none were applied: a detailed description of the solutions adopted to meet the high-risk requirements, plus other standards or specifications used.

8. EU declaration of conformity

0/1

A copy of the signed declaration.

8 A copy of the EU declaration of conformity (Article 47).

9. Post-market performance evaluation

0/1

How you keep watching the system once it is in use.

9 A detailed description of the system for evaluating performance after placing on the market (Article 72), including the post-market monitoring plan (Article 72(3)).

Need the documents, not just the list?

Classify your system for free. If it is high-risk, the €49 Compliance Pack gives you the Annex IV outline with your company and system filled in, plus templates for the risk management procedure, data governance record, human oversight procedure, instructions for use and the conformity assessment checklist.

Classify my system

In practice

How to write it without losing a quarter

Write it while you build, not after

Most of Annex IV point 2 is design decisions, data provenance and test results. Captured at the time, it is a by-product of normal engineering; reconstructed a year later it is archaeology.

Keep it next to the code

A docs folder in the repository, versioned with the model and reviewed in pull requests, gives you the change history Annex IV point 6 asks for and the dated sign-off point 2(g) asks for, for free.

Report accuracy per group, not one number

Point 3 asks for accuracy for the specific persons or groups the system is used on. A single aggregate figure hides exactly what an authority will look for.

Document what you bought, not only what you built

If the system uses a third-party or pre-trained model, point 2(a) asks how you used, integrated or modified it. Record what the supplier gave you, what they did not, and how you evaluated it yourself.

Simplified does not mean shorter list

The SME and small mid-cap form reduces how much detail you give, not which Annex IV points you cover. Draft against the full list and the simplified form becomes a summary.

Related: the AI inventory template to list every system first, ai-act-scan to find the AI in a codebase, the AI Act deadlines and the full EU AI Act compliance guide.

FAQ

Frequently asked questions

Who has to prepare technical documentation under the EU AI Act?

The provider of a high-risk AI system, meaning the company that develops it (or has it developed) and places it on the market or puts it into service under its own name. Deployers that only use a high-risk system do not write the technical documentation, but they have their own obligations under Article 26. Providers of general-purpose AI models have a separate documentation duty under Article 53 and Annexes XI and XII.

When is the technical documentation due?

It must exist before the system is placed on the market or put into service and must be kept up to date afterwards. After the Digital Omnibus (Regulation (EU) 2026/1744), the high-risk obligations apply from 2 December 2027 for Annex III systems and from 2 August 2028 for AI in products covered by Annex I.

What must the technical documentation contain?

At least the nine points of Annex IV: a general description of the system; a detailed description of its elements and development process (including data, testing and cybersecurity); monitoring, functioning and control; why the performance metrics are appropriate; the risk management system; changes through the lifecycle; the harmonised standards applied; a copy of the EU declaration of conformity; and the post-market performance evaluation system.

How long do I have to keep it?

Ten years after the system is placed on the market or put into service, available to national competent authorities, together with the quality management system documentation, notified body decisions where applicable and the EU declaration of conformity (Article 18).

Is there a simplified version for SMEs and start-ups?

Yes. Article 11(1) lets SMEs, including start-ups, and since the Digital Omnibus also small mid-caps, provide the Annex IV elements in a simplified manner using a form established by the Commission, which notified bodies must accept. Check the AI Office pages for the current version of the form. The simplification reduces the level of detail, not the points you have to cover.

My AI is part of a medical device or machine. Do I need two files?

No. For high-risk AI systems related to products covered by the Union harmonisation legislation in Annex I Section A, Article 11(2) requires a single set of technical documentation that contains both the Annex IV information and what the product legislation requires.

Is a template enough?

A template gives you the structure. What makes the documentation compliant is the evidence behind each heading: real design decisions, dataset descriptions, dated and signed test reports, and a risk management process that is actually running.

General information about Article 11, Article 18 and Annex IV of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, updated 10 November 2026. Annex IV is paraphrased; rely on the Official Journal text. Not legal advice.