Annex IV Requirements Checklist: Nine Areas Your Technical File Must Cover
Annex IV checklist: nine mandatory areas for high-risk AI technical docs. Article 11 duty, 10-year retention, SME simplified form. Deadline 2 Dec 2027.
Annex IV of Regulation (EU) 2024/1689 defines what a high-risk AI provider's technical documentation must contain. Article 11 creates the obligation — you must compile the file before placing the system on the market or putting it into service. Annex IV is the content specification for that file: nine mandatory areas, no optional ones.
This page is a requirements checklist. If you want the full conceptual walkthrough — what each area means, a worked example, and the relationship to Article 43 conformity assessment — that is the EU AI Act Annex IV guide. Use this page to track what you have and what is still missing.
The deadline for stand-alone high-risk systems (the Annex III list) is 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. The file must be complete before you go to market, not by the time an authority inspects you. Non-compliance with Article 11 falls under 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 capped at the lower of the two (Article 99(6)).
The Relationship Between Article 11, Annex IV, and Article 18
Article 11 is the legal duty: providers of high-risk AI systems must draw up and keep up to date the technical documentation set out in Annex IV before market placement or service. Annex IV is not a discretionary framework — it is what Article 11 requires.
Article 18 sets the retention period: 10 years after the last unit is placed on the market or put into service. That applies to every version, not just the current one. Start your version-control and archiving discipline now; retrofitting it is harder than building it in.
Article 11(3) provides one genuine concession: SMEs and start-ups may provide Annex IV elements in a simplified form, proportionate to their size and resources. All nine areas remain mandatory. Simplified form means appropriate level of technical detail, not fewer sections. A 20-person company still needs to document its training data, its risk assessment under Article 9, and its post-market monitoring plan.
Area 1 — General Description of the AI System
What it covers: intended purpose; provider identity and contact details; authorised representative (Article 22) where applicable; version number and release date; how the system interacts with hardware or software it is not part of (including other AI systems); software versions used; forms in which the system is placed on the market (standalone software, API, embedded in product); hardware on which it is intended to run; instructions for use directed at deployers; a basic description for affected persons where applicable.
The test: a competent authority reading only this section should know precisely what the system does, who built it, and where it operates. Generic purpose statements fail it.
Common gap: providers list a general category ("recruitment AI") without specifying the task ("ranks applicants at initial CV-screening stage for software engineering roles; outputs a numeric score and pass/fail flag"). The intended purpose in the documentation must match the intended purpose as it would appear in the instructions for use and the EU Declaration of Conformity.
Area 2 — Detailed Description of System Elements and the Development Process
What it covers: design specification and the choices made (model type, architecture, key hyperparameters, input/output specifications); training, validation, and testing datasets — provenance, scope, composition, labelling methodology, preprocessing steps, known limitations and biases; the human oversight design under Article 14 (which decisions require human review, how outputs are made interpretable, what override mechanisms exist); predetermined changes to the system after deployment, including continuous-learning provisions and drift controls; validation and testing procedures and performance metrics broken down by subgroups and failure modes; logs generated automatically and how long they are retained.
The test: someone who did not build the system should be able to understand how it was built and on what data. The datasheet for each dataset used is not optional documentation — it lives here.
Common gap: validation results reported as a headline accuracy figure with no demographic breakdown. Where performance differs across age, gender, ethnicity, or disability, those differences must be disclosed. If a recruiter tool rejects female applicants in tech roles at a 4% higher rate, that goes in Section 2 — along with what was done about it.
Area 3 — Detailed Information on Monitoring, Functioning, and Control
What it covers: capabilities and known limitations, including conditions under which performance degrades and known failure modes; accuracy differences for specific persons or groups; foreseeable unintended outcomes and sources of risk, including risks from misuse or use outside the intended context; human oversight measures in operational terms under Article 14 — what deployer staff must do, how alerts surface, escalation paths; input data specifications at inference time, including format requirements, data quality requirements, and out-of-distribution warnings.
The test: Area 2 is about how the system was built; Area 3 is about how it behaves once deployed and how a deployer keeps it under control. If these two sections read the same, one of them is wrong.
Common gap: the human oversight section restates Area 2 without translating design-time choices into operational instructions. A deployer needs to know what to do when an alert fires, not how the alert was architected.
Area 4 — Appropriateness of Performance Metrics
What it covers: a justification of why the metrics chosen to evaluate the system's performance are appropriate for its intended purpose and risk profile.
This is short but substantive. Selecting demographic parity as your fairness metric for a recruitment AI rather than equalised odds or individual fairness is a deliberate choice that carries consequences for which groups benefit or lose from the system's outputs. That choice needs to be explained and defended in the file, not assumed.
Common gap: providers copy in performance numbers without explaining metric selection. If the system operates in a domain where a false negative carries greater harm than a false positive — medical risk scoring, benefits eligibility, credit — the reasoning behind the primary metric needs to be explicit. Auditors and notified bodies will ask.
Area 5 — The Article 9 Risk Management System
What it covers: the outputs of the continuous risk management process required by Article 9 — known and reasonably foreseeable risks to health, safety, or fundamental rights under intended use and 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 at that level.
Area 5 is not a risk summary paragraph. It is the formal output of the Article 9 process documented in the Annex IV file. Each risk needs a named owner, a specific control, a specific threshold, and a residual-risk assessment.
Common gap: the entry reads "bias risk identified; bias testing performed." A compliant entry names the protected attributes tested, the threshold that defines acceptable performance, the cadence of retesting, and the residual level.
Area 6 — Lifecycle Changes
What it covers: all material changes made to the system after initial market placement — retraining events, architectural changes, training data updates, expansions of intended purpose, and changes to the deployment environment. Each change must be documented with a reassessment of whether it constitutes a substantial modification (defined in Article 3(23)) that would re-trigger conformity assessment obligations under Article 43.
The test: this is not a bug-fix log. It is a forward-looking governance mechanism: before deployment, define what change thresholds require a documentation update and what thresholds require a fresh Article 43 conformity assessment.
Common gap: providers document the first version only. Every retraining event on new data, every threshold change, every expansion of use-case scope requires a dated entry in Area 6.
Area 7 — Harmonised Standards, Common Specifications, and Other Technical Solutions
What it covers: the technical standards applied during development and validation, or — where no harmonised standard or common specification exists — the other technical solutions used to demonstrate compliance with Articles 9–15 (Chapter III, Section 2).
Application of harmonised standards creates a presumption of conformity under the Act. Where providers rely on their own technical solutions instead, Area 7 must explain how those solutions meet the statutory requirements.
As of mid-2026, no harmonised standard under the EU AI Act has been formally published. ISO/IEC 42001 (AI management systems) and ISO/IEC 23894 (AI risk management guidance) are the primary reference frameworks, though neither yet carries harmonised-standard status. Note this explicitly in the file — it is the accurate position, and regulators expect it.
Area 8 — EU Declaration of Conformity (Article 47, content per Annex V)
What it covers: a copy of the EU Declaration of Conformity drawn up under Article 47. The Declaration is a separate legal document — a formal statement by the provider that the system meets all applicable requirements of Regulation (EU) 2024/1689. Its required content is set out in Annex V: the system name and version, a reference to the Regulation, the provider's identity and address, the authorised representative's details where applicable, and the provider's signature.
The Declaration and the Annex IV technical file travel together. If the file is updated, review the Declaration. If the system changes materially, both must be reviewed and potentially reissued.
Area 9 — Post-Market Monitoring Plan (Article 72)
What it covers: how the provider will actively collect and analyse data on system performance in real-world conditions after deployment; internal SLAs for incident triage (serious incidents must be reported to market surveillance authorities under Article 73 within 15 days of awareness, or 2 days for critical infrastructure incidents, or 10 days where a person has died); performance drift thresholds that trigger investigation; retraining and update procedures; periodic review schedule.
Article 72 requires monitoring to be proactive and structured. "We will monitor the system" is not a plan. A plan names a metric, a threshold, an owner, a cadence, and a response procedure.
Common gap: the monitoring section is written at the same level of abstraction as the risk management section. A credit-scoring AI at a regional lender needs: monthly accuracy check against a holdout set; alert threshold defined in percentage points; responsible owner named; response timeline specified; channel for deployers to flag anomalies; link to the Article 73 incident-reporting process.
Retention and Access
All nine areas of the Annex IV file must be retained for 10 years from market placement or service commencement (Article 18). National market surveillance authorities and the EU AI Office may request access at any time. Notified bodies review the file before issuing any conformity certificate. Deployers are entitled to access relevant parts under Articles 11(2) and 13 — they need enough information to operate the system correctly and meet their own obligations under Article 26.
In practice, if your system is deployed by multiple enterprise clients, each has a right to request access. The file must be version-controlled, findable, and legible to a non-author.
How Confir Helps
Assembling the Annex IV file is the most document-intensive part of high-risk AI compliance. The training data audit alone can take months if records are fragmented. Confir's AITR assessment (Data and Technical Robustness track) guides providers through all nine areas, prompting for the specific information each requires and flagging gaps. The engine is rule-based and deterministic: the same inputs produce the same findings, with the applicable requirement visible at each step. The output is the structured technical documentation pack that functions as your Annex IV record.
The AITR links directly to the Article 47 Declaration of Conformity and the Article 9 risk management outputs, so the file is internally consistent — which is what auditors and notified bodies will check. Pricing starts at €600 per year. No consultants required.
Frequently Asked Questions
What is the relationship between Annex IV and Article 11?
Article 11 creates the legal obligation: providers of high-risk AI systems must draw up and maintain technical documentation before going to market or into service. Annex IV defines the content of that documentation — the nine areas described above. Article 11 IS the requirement; Annex IV IS what satisfies it. A provider cannot meet Article 11 without addressing all nine Annex IV areas. The retention obligation (10 years) sits in Article 18.
Which providers must comply with Annex IV?
Any provider placing a high-risk AI system on the EU market or putting it into service — regardless of where the provider is established. If a deployer substantially modifies a high-risk system or places it on the market under its own name or trademark, that deployer becomes a provider under Article 25 and inherits the full Article 11 and Annex IV obligation. Importers (Article 23) must verify that the documentation exists before distributing a product.
Can SMEs produce a shorter version of the Annex IV file?
Article 11(3) permits SMEs and start-ups to provide Annex IV content in a simplified form, scaled to their size, resources, and risk profile. All nine areas remain mandatory — the simplification applies to depth of technical detail, not to which sections are included. A 25-person SaaS company still needs to identify training datasets, complete the Article 9 risk assessment, document human oversight mechanisms, and maintain a post-market monitoring plan.
What happens if the Annex IV file is incomplete when the system goes to market?
Non-compliance with Article 11 is a breach of the high-risk requirements 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)). Market surveillance authorities can also order the system withdrawn and impose corrective measures. There is no grace period for a deficient file once the system is on the market.
How does the Annex IV file connect to the EU Declaration of Conformity?
Area 8 of Annex IV requires a copy of the EU Declaration of Conformity drawn up under Article 47, whose required content is set out in Annex V. The two documents are linked: the Declaration is the provider's formal legal statement that the system meets all applicable requirements; the Annex IV file is the technical evidence that supports it. If the file is updated, the Declaration must be reviewed. They must remain consistent.
How often does the Annex IV file need to be updated?
The file must be kept up to date throughout the system's lifecycle (Article 11). Area 6 (lifecycle changes) is the ongoing record. Every material change — retraining on new data, architectural modification, expansion of intended purpose, change to deployment environment — requires a new entry and a reassessment of whether the change constitutes a substantial modification under Article 3(23) triggering a fresh conformity assessment. Providers should define change thresholds in advance, before deployment.
What is the Annex IV deadline under the Digital Omnibus?
Under the Digital Omnibus agreed in May 2026, the Annex IV file must be complete before stand-alone Annex III systems go to market from 2 December 2027. For high-risk AI embedded in Annex I regulated products (medical devices, machinery, vehicles), the date is 2 August 2028. These are market-entry conditions: deploying without a compliant file from those dates is a violation on day one, not something authorities check retrospectively.
Related guides
- Article 11 technical documentation guide
- Article 8 high-risk AI requirements
- Annex III autonomous vehicles classification
- open-source AI model exemptions
- OpenAI API compliance assessment
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →