EU AI Act Annex IV: the 9-section technical-file checklist

Executive summary

• What: Annex IV of Regulation (EU) 2024/1689 specifies the nine sections every high-risk AI system must produce as its technical file under EU AI Act Article 11. Without a complete, current Annex IV technical file, you cannot lawfully place the system on the EU market.
• Who: Every provider of an Annex III high-risk system - and every annotation, data, or model supplier whose work appears inside that system.
• By when: 2 December 2027 for stand-alone Annex III systems, 2 August 2028 for Annex I embedded systems - deferred from 2 August 2026 by the Digital Omnibus (final Council approval, 29 June 2026). Have counsel confirm the dates for your product before relying on them.
• Penalty for incomplete Annex IV technical documentation: up to €15 million or 3% of global annual turnover, whichever is higher.

If you supply training data, run an annotation pipeline, or build models for a high-risk AI system going to market in the EU, the EU AI Act Annex IV technical file is the document that decides whether your customer ships on the Act’s timeline or gets pulled from the market. This one is written from the angle that matters most for our work at LabelFort: Section 2 (development process and data governance) and Section 4 (performance metrics) - nearly impossible to reconstruct after the fact.

What is Annex IV?

EU AI Act Article 11 requires every provider of a high-risk AI system to draw up technical documentation before the system is placed on the market and to keep it current throughout the system’s lifecycle. Annex IV is the regulation’s exhaustive specification of what that documentation must contain.

The file is not a marketing artifact. It is the evidentiary backbone of your CE-mark conformity assessment. Get it wrong and the system cannot ship in the EU.

Penalty: Incomplete Article 11 documentation carries fines of up to €15 million or 3% of global annual turnover, whichever is higher - enforceable at any time, not tied to a single compliance date.

The 9 sections of an Annex IV technical file

The structure is fixed. Notified Bodies expect to read it in this order, with these names, and find each section either populated or with a defensible reason for its absence.

Section 1 - General description

A plain-language description of the AI system, including: intended purpose, the name and contact of the provider, version, the system’s interactions with hardware or other software, software versions, user interface designs, instructions for use, and a description of the hardware on which the system is intended to run.

Section 2 - Detailed description of elements and development process

This is the section that catches annotation providers out. It must cover methods and techniques, design specifications, system architecture, data requirements (datasheets, provenance, labeling procedures, cleaning methodologies), human oversight measures, validation and testing procedures, and cybersecurity measures.

Section 3 - Monitoring, functioning, control

Detailed information about monitoring, functioning, and control - including capabilities and limitations, degrees of accuracy for specific persons or groups, foreseeable unintended outcomes, and human oversight measures.

Section 4 - Performance metrics justification

A description of the appropriateness of the performance metrics used, plus per-cohort performance metrics - accuracy broken down by every relevant cohort surfaced in Section 3.

Sections 5–9

Section 5 covers the Article 9 risk management system. Section 6 documents lifecycle changes. Section 7 lists harmonised standards applied. Section 8 is the EU Declaration of Conformity. Section 9 is the post-market monitoring plan under Article 72.

The LabelFort wedge - why Section 2 is impossible to reconstruct after the fact

Every Annex IV section needs evidence. Most can be produced retroactively. Section 2 is different.

None of these can be honestly reconstructed two months after the data has been shipped. This is what we mean at LabelFort by evidence-grade annotation: every artifact Annex IV Section 2 will ask for is captured at the time of annotation, versioned, and exportable as a single per-dataset bundle.

In practice, that bundle contains:

• The signed annotator guideline, with version hash, applicable to every record in the batch.
• Per-record annotator identity, qualification record, and time-stamp.
• Per-record disagreement log between primary and secondary annotator, with the adjudication decision.
• Cohort-level inter-rater reliability (Cohen’s κ or Krippendorff’s α) broken down by the cohorts Section 3 will need to evidence.
• The cleaning rule set, applied as code with a commit hash, and a sample of cleaned vs uncleaned records.
• The Gebru-pattern datasheet - auto-populated from the underlying log rather than written from memory.

Section 4 - and why “average accuracy” is a fail mode

Section 4 asks you to justify your performance metrics and present performance broken down by relevant cohort. For a medical-imaging AI screening for diabetic retinopathy, “92% sensitivity” is not Section 4 evidence. The auditable form is sensitivity broken down by age cohort, scanner manufacturer, and demographic sub-groups - flagged where out-of-scope.

You cannot generate that table at audit time. You can only generate it if your training annotation captured the cohort tags. Sections 2 and 4 are an evidence pair.

A worked example - Annex IV for a high-risk medical imaging system

Section	Evidence the file contains (illustrative)
1. General description	Diabetic retinopathy triage AI; v3.2.1; deployed on hospital PACS; HL7 FHIR integration.
2. Development & data governance	Dataset card v3 covering 47,000 retinal scans; provenance log; annotator guideline v1.4; per-cohort IRR (κ = 0.86 adult, 0.79 geriatric); cleaning code at commit a4b2f9c.
3. Monitoring & control	Capability statement; per-cohort accuracy table; foreseeable misuse register; Article 14 human oversight design.
4. Performance metrics	Sensitivity 91.2%, specificity 94.6%, AUROC 0.96; cohort breakdown; metric justification.
5–9	Risk register, lifecycle changes, harmonised standards, Declaration of Conformity, post-market monitoring plan.

What about the Digital Omnibus extension?

On 19 November 2025 the Commission proposed pushing Annex III obligations to December 2027. Parliament adopted the text on 16 June 2026 and the Council gave final approval on 29 June 2026: stand-alone high-risk obligations now apply from 2 December 2027, Annex I embedded systems from 2 August 2028. See our Article 12 logging guide for the full Digital Omnibus timeline.

• Don’t treat the extension as slack. Provenance is captured at labeling time or not at all.
• Don’t slow down your annotation discipline. Section 2 evidence decays with delay, not with deadline.

The 9-section ready-to-export Annex IV checklist

Section	Produced?	Versioned?	Survives Notified Body spot-check?
1. General description	☐	☐	☐
2. Development & data governance	☐	☐	☐
Datasheet (Gebru-pattern)	☐	☐	☐
Annotator guideline (versioned)	☐	☐	☐
Inter-rater reliability per cohort	☐	☐	☐
Data cleaning code + commit hash	☐	☐	☐
Provenance log incl. cross-border	☐	☐	☐
3. Monitoring & control	☐	☐	☐
4. Performance metrics (cohort breakdown)	☐	☐	☐
5. Risk management (Article 9)	☐	☐	☐
6. Lifecycle changes log	☐	☐	☐
7. Harmonised standards applied	☐	☐	☐
8. Declaration of Conformity (Article 47)	☐	☐	☐
9. Post-market monitoring plan (Article 72)	☐	☐	☐

FAQs