EU AI Act Annex IV: What Goes in Your Technical Documentation File

Annex IV of Regulation (EU) 2024/1689 sets out the exact contents that every provider of a high-risk AI system must include in its technical documentation. It does not describe an optional best-practice framework. It specifies nine categories of information, and a conformity assessment under Article 43 will check each one.

Three articles work together here and are often confused. Article 11 creates the obligation: providers must draw up and keep up to date the technical documentation before placing a high-risk AI system on the market or putting it into service. Annex IV defines what that file must contain. Article 43 covers the conformity assessment procedure that reviews the file — either an internal check (Annex VI) or a notified-body review (Annex VII). This guide covers Annex IV: the substance of the file.

Under the Digital Omnibus agreed in May 2026, stand-alone high-risk AI systems (the Annex III list) must comply from 2 December 2027, and high-risk AI embedded in regulated products from 2 August 2028, pushing back the original August 2026 date. That extends the runway, but assembling a credible Annex IV file takes months. The penalty ceiling for non-compliance with the high-risk requirements is €15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). For SMEs and start-ups, the fine is capped at the lower of the two figures (Article 99(6)).

Providers must retain the documentation for 10 years after the system is placed on the market or put into service (Article 18).

---

The Nine Sections of Annex IV in Order

Annex IV is organised into nine numbered sections. They are not interchangeable or collapsible. Here is what each requires.

Section 1 — General Description of the AI System

This section anchors everything that follows. It must cover:

• Intended purpose, including the specific task the system performs and the persons or groups it affects
• Provider identity: the name and registered address of the provider, and the name and contact details of any authorised representative (Article 22) where applicable
• Version information: version number and date of release
• Hardware and software interaction: how the system interacts with hardware or software it is not itself part of, including other AI systems
• Software versions used in development
• Forms in which the system is placed on the market or put into service: standalone software, embedded in a product, API, or other
• Hardware on which the system is intended to run
• Instructions for use for deployers, and where applicable, a basic description for affected persons

A useful test: if a competent authority reads only Section 1, they should know precisely what the system does, who built it, and where it is deployed.

Section 2 — Detailed Description of System Elements and the Development Process

This is the longest and most technical section. It must document:

Design specification and architecture. The choices made and why — model type, architecture, key hyperparameters, input/output specifications, feature engineering.

Training data requirements and datasheets. For each dataset used in training, validation, and testing: provenance (where it came from, under what legal basis), scope (what it covers and what it does not), size and composition, labelling methodology, cleaning and preprocessing steps, and known limitations. Article 10 requirements on data governance underpin this — but the datasheet goes in Annex IV.

Human oversight assessment under Article 14. The design-time analysis of how human oversight is built in — which decisions require human review, how the system makes its outputs interpretable, and what override mechanisms exist.

Predetermined changes and continuous-learning provisions. If the system is designed to change after deployment — whether through scheduled updates or active learning — the documentation must describe those mechanisms, the conditions under which changes occur, and the controls that prevent drift beyond intended behaviour.

Validation and testing procedures and metrics. How the system was validated and tested: datasets used, test conditions, the specific metrics applied (accuracy, F1, demographic parity, equal opportunity score, or others), the threshold values set, and how the system performed. Not just the headline number — the breakdown by subgroups, edge cases, and failure modes.

Logs. What the system generates automatically, what is retained, and for how long.

Section 3 — Detailed Information on Monitoring, Functioning, and Control

Section 3 documents operational characteristics:

• Capabilities and limitations: what the system can and cannot do, including known failure modes and the conditions under which performance degrades
• Accuracy for specific persons or groups: where performance differs across demographic characteristics (gender, age, ethnicity, disability), those differences must be disclosed, not buried
• Foreseeable unintended outcomes and risks: identified at design time, including risks of misuse or use in contexts other than the intended one
• Human oversight measures: repeating and deepening the Article 14 analysis from Section 2 in operational terms — what a deployer's team must do, how alerts work, and escalation paths
• Input data specifications: the data the system expects at inference time, including format, quality requirements, and out-of-distribution warnings

The distinction between Section 2 and Section 3 is developmental versus operational. Section 2 is about how the system was built. Section 3 is about how it behaves once deployed and how to keep it under control.

Section 4 — Appropriateness of the Performance Metrics

Section 4 is short but substantive. It requires an explanation of why the chosen performance metrics are appropriate for the system's intended purpose and risk profile.

If you are documenting a recruitment AI, explaining why you selected demographic parity as a fairness metric — rather than equalised odds or individual fairness — is required here. If the system operates in a domain where a false negative carries greater harm than a false positive (medical risk scoring, say), the choice of recall over precision as the primary metric needs justification. Regulators and notified bodies will ask. Answer it in the file.

Section 5 — The Risk Management System Under Article 9

Section 5 summarises the outputs of the Article 9 risk management system. Article 9 requires a continuous, iterative process that runs across the system's lifecycle. The Annex IV file must document:

• Known and reasonably foreseeable risks to health, safety, or fundamental rights when the system is used as intended and under foreseeable misuse
• Probability and severity assessments for each identified risk
• Mitigation measures adopted and their technical basis
• Residual risks after mitigation, with a rationale for why they are acceptable

For a credit-scoring AI deployed at a regional lender, this means documenting discrimination risk (protected attributes: gender, ethnicity, age), the fairness testing cadence, the thresholds that trigger model review, and the residual risk level with the assumptions behind it. "Fairness audit performed" is not a compliant entry. A specific threshold, an owner, and a cadence are required.

Section 6 — Lifecycle Changes

Section 6 records changes to the system that occur after initial market placement — retraining events, architectural changes, updates to training data, expansions of intended purpose, and changes to the deployment environment. Each change must be documented, along with a reassessment of whether the change constitutes a substantial modification that would re-trigger conformity assessment obligations under Article 43.

This is not a retrospective log of bug fixes. It is a forward-looking governance mechanism: providers must define in advance what change thresholds require documentation updates and what thresholds require a fresh conformity assessment.

Section 7 — Harmonised Standards, Common Specifications, and Other Technical Solutions

Section 7 identifies the technical standards applied or, where no relevant harmonised standard or common specification exists, the other technical solutions used to meet the requirements of Chapter III, Section 2 (Articles 9–15).

Where harmonised standards have been applied in full, compliance with those standards creates a presumption of conformity. Where only partial standards are applied — or where the provider has relied on its own technical solutions — Section 7 must explain how those solutions meet the statutory requirements.

ISO/IEC 42001 (AI management systems) and ISO/IEC 23894 (risk management guidance for AI) are relevant reference frameworks, though neither is yet a harmonised standard under the Act as of mid-2026. Providers relying on them should note this explicitly.

Section 8 — EU Declaration of Conformity

Section 8 requires a copy of the EU declaration of conformity (DoC) drawn up under Article 47. The DoC is a separate legal document — a formal statement by the provider that the system meets all applicable requirements of Regulation (EU) 2024/1689. It must include the system name and version, a reference to this Regulation, the provider's identity, and the authorised representative's details where applicable.

Including the DoC in Annex IV means the technical documentation and the legal statement of conformity travel together. If either is updated, both must be updated.

Section 9 — Post-Market Monitoring Plan

The final section documents the post-market monitoring plan required by Article 72. It must cover:

• How the provider will actively collect and analyse data on system performance in real-world conditions after deployment
• Incident reporting channels and internal SLAs (serious incidents must be reported to authorities under Article 73)
• Performance drift thresholds that trigger investigation
• Retraining and update procedures
• Periodic review schedule

Article 72 requires monitoring to be proactive and structured, not reactive. A Dutch AI system predicting equipment maintenance failures, for example, needs a defined monthly accuracy check against a holdout set, an alert threshold (say, accuracy drops more than 3 percentage points), and a documented procedure for what happens next — retrain within 30 days, or take the system offline.

---

Annex IV vs. Article 11 vs. Article 43

These three work together and are often conflated, so it is worth setting them out plainly.

Article 11 is the legal obligation: providers of high-risk AI systems must draw up and keep up to date the technical documentation specified in Annex IV before going to market or into service. It also sets the retention requirement (10 years via Article 18) and specifies who must be able to access the documentation: competent authorities, notified bodies, and deployers on request.

Annex IV is the content specification: the nine sections described above. It answers the question "what must the documentation contain?"

Article 43 is the conformity assessment: the procedure by which a provider demonstrates — or a notified body verifies — that the system meets the high-risk requirements. The technical documentation is the primary evidence reviewed in that assessment. Most stand-alone Annex III systems use the internal-control procedure (Annex VI); systems covered by Annex I product safety legislation, plus biometric identification systems, require a notified-body review.

A fourth relevant provision: Article 47 requires a copy of the EU declaration of conformity — which is what Section 8 of Annex IV must include.

---

Simplified Documentation for SMEs and Start-ups

Article 11(3) explicitly allows SMEs and start-ups to provide Annex IV elements in a simplified form. This does not mean fewer sections or less content — all nine sections remain mandatory. It means the level of technical detail can be proportionate to the size, resources, and risk profile of the provider.

In practice, a 30-person HR-tech company is not expected to produce the same depth of statistical analysis as a major bank. But the company still needs to identify its training datasets, document its risk assessment, describe human oversight mechanisms, and have a post-market monitoring plan. "We are a start-up" is not an exemption from Annex IV; it is a proportionality principle within it.

---

A Worked Example: Resume-Screening AI

A German HR-tech company of 45 people offers a resume-screening AI as a SaaS product to employers across the EU. Under Annex III point 4, recruitment systems that influence hiring decisions are high-risk. Here is how the nine sections map to their situation.

Section 1 identifies the provider (the GmbH), the system name and version, that it is deployed as a cloud SaaS API, and summarises the intended purpose: ranking job applicants by predicted suitability.

Section 2 documents the training corpus — 120,000 historical CVs and their hiring outcomes, sourced from three employer clients under data processing agreements, with a bias audit showing a 4% higher false-rejection rate for female applicants in tech roles, addressed by a reweighting step in training. The human oversight design: borderline candidates (confidence 40–60%) are flagged for mandatory recruiter review before rejection.

Section 3 states that the system performs well for mid-level tech and finance roles but degrades in creative and hospitality sectors (underrepresented in training data). The documentation discloses this limitation and requires deployers to configure a domain filter.

Section 4 justifies the choice of demographic parity as the primary fairness metric, with an explanation of why it is appropriate for a tool used at initial screening rather than final selection.

Section 5 identifies three primary risks — gender discrimination, gaming by applicants, and cascading errors if deployers turn off human review — with specific controls and residual risk levels for each.

Section 6 specifies that any retraining on new employer data triggers a fresh bias audit and a documentation update. An expansion to executive-level roles would constitute a substantial modification requiring reassessment under Article 43.

Section 7 lists ISO/IEC 42001 and ISO/IEC 23894 as reference frameworks applied; notes that no harmonised standard covering recruitment AI has been published as of the documentation date.

Section 8 attaches a copy of the EU declaration of conformity signed by the company's CEO.

Section 9 commits to a quarterly accuracy review, a 24-hour triage SLA for employer-reported incidents, and model suspension if accuracy falls below 80% on the validation set.

---

Retention, Access, and What Competent Authorities Expect

Providers must retain the complete Annex IV file for 10 years after the last unit is placed on the market or put into service (Article 18). This applies to each version — not just the current one.

The documentation must be available to national market surveillance authorities and the EU AI Office promptly on request. Where a notified body is involved in conformity assessment, the body will review the file before issuing any certificate.

Deployers are entitled to relevant parts of the documentation under Article 13 and Article 11(2): they need enough information to operate the system correctly and to fulfil their own obligations under Article 26.

One practical implication: if your system is deployed by 50 enterprise clients, all 50 have a right to request access. The documentation needs to be version-controlled, findable, and legible — not a sprawling internal wiki that only your CTO can interpret.

---

How Confir Helps

Confir's AITR assessment — the Data and Technical Robustness track — guides providers through all nine Annex IV sections, prompting for the specific information each section requires and flagging gaps. The rule-based, deterministic engine maps your inputs to the statutory requirements: same answers produce the same findings, with the applicable rule visible at each step. The output is the technical documentation pack (AITR), a structured, version-controlled file that functions as your Annex IV record.

The AITR links directly to the Article 47 Declaration of Conformity and to the Article 9 risk management outputs, so the file is internally consistent — a point auditors and notified bodies will check.

---

What to Do Now

Annex IV documentation cannot be produced the week before a conformity assessment. The training data audit alone can take months if your records are fragmented. The Article 9 risk management process is iterative by design — it needs to run before the documentation is finalised.

Work backwards from 2 December 2027. If you need a notified-body review (Annex I products or biometric systems), factor in notified-body lead times, which have historically run to several months. For stand-alone Annex III systems using internal control, you still need a complete file before going to market.

Start with Section 1 (general description) and Section 2 (development process and data). Those sections surface the information you most likely do not yet have documented, and they take the longest to collect.

---

Related guides

• Article 4 AI literacy obligations
• Article 14 human oversight measures
• Article 11 documentation requirements
• Annex IV mandatory sections
• AI governance compliance
• Article 49 conformity declaration

Frequently Asked Questions

What does Annex IV actually contain — how many sections are there?

Annex IV specifies nine sections: (1) general description; (2) detailed description of elements and the development process, including data requirements and the human oversight design; (3) monitoring, functioning, and control information; (4) performance metric justification; (5) the Article 9 risk management system; (6) lifecycle changes; (7) harmonised standards or other technical solutions applied; (8) a copy of the EU declaration of conformity (Article 47); and (9) the post-market monitoring plan (Article 72). All nine are mandatory for every high-risk AI system.

What is the difference between Article 11, Annex IV, and Article 43?

Article 11 creates the legal obligation to draw up and maintain technical documentation before going to market. Annex IV defines the nine categories of information that documentation must contain. Article 43 covers the conformity assessment procedure — either internal control (Annex VI) or notified-body review (Annex VII) — during which the Annex IV file is reviewed. They are three distinct provisions that work together.

Who is responsible for compiling Annex IV documentation?

The AI provider bears responsibility under Article 11. Providers must compile the file before market placement or putting the system into service, keep it updated over the system's lifecycle, and retain it for 10 years (Article 18). Deployers are entitled to access relevant parts under Articles 11(2) and 13, but cannot substitute their own documentation for the provider's file. If a deployer substantially modifies a high-risk system or places it on the market under its own name, the deployer becomes a provider under Article 25 and inherits the full Article 11 obligation.

What penalties apply for missing or deficient Annex IV documentation?

Non-compliance with high-risk requirements — including Article 11 and Annex IV — is a breach covered by Article 99(4): up to €15 million or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, the fine is the lower of the two figures (Article 99(6)). Competent authorities can also order the system withdrawn from the market. There is no fixed fine per article; the tier applies to breaches of the high-risk requirements as a whole.

Can SMEs provide a simplified version of Annex IV?

Yes. Article 11(3) explicitly permits SMEs and start-ups to provide Annex IV elements in a simplified form, proportionate to their size and resources. All nine sections remain mandatory — simplification means appropriate depth of detail, not fewer obligations. A 30-person software company is not expected to produce the same depth of statistical documentation as a large financial institution, but it still needs to identify its datasets, document its risk assessment, and have a post-market monitoring plan.

How does the Annex IV file relate to the EU Declaration of Conformity?

Section 8 of Annex IV requires a copy of the EU declaration of conformity drawn up under Article 47. The two travel together: the Declaration is a legal statement by the provider that the system meets all applicable requirements; the Annex IV file is the technical evidence supporting that statement. If the system is updated and the Annex IV file is revised, the Declaration must also be reviewed and, if necessary, reissued. Article 47 specifies the required content of the Declaration.

When must the Annex IV file be ready?

The file must be complete before the system is placed on the market or put into service — not at the time of first audit or inspection. For stand-alone Annex III systems, that obligation applies from 2 December 2027 under the Digital Omnibus agreed in May 2026. For high-risk AI embedded in Annex I regulated products, the date is 2 August 2028. These are market-entry conditions, not eventual targets: deploying without a compliant file is a violation from day one.