Article 11 and Annex IV EU AI Act: Your Plain-English Guide to Technical Documentation for High-Risk AI

If your AI system is high-risk under the EU AI Act, the technical documentation - sometimes called the "technical file" - is the single most important compliance artefact you will produce. It is the evidence package that regulators and notified bodies examine to decide whether your system is lawful. Get it wrong, or leave it until the last minute, and nothing else in your compliance programme can save you.

This guide explains what Article 11 requires, walks through every one of the nine mandatory Annex IV sections in plain English, covers the SME relief provisions, and gives you a practical readiness checklist to start building your file today.

What Article 11 Actually Requires

The rule is straightforward. The technical documentation of a high-risk AI system must be drawn up before that system is placed on the market or put into service, and must be kept up to date. It must be drawn up in a way that demonstrates compliance with the requirements in Chapter III, Section 2 of the Regulation, and that gives national competent authorities and notified bodies the information they need - in a clear and comprehensive form - to assess that compliance.

In other words, Article 11 has two jobs:

1. Proof of compliance - the file is your evidence that the system meets every applicable requirement (risk management, data governance, accuracy, human oversight, cybersecurity, and so on).
2. Regulator-readable dossier - it must be structured so that a market surveillance authority or notified body can actually use it to assess your system, not just confirm that a document exists.

The technical documentation must contain, at a minimum, the elements set out in Annex IV. Annex IV is not a suggested template - it is a legal minimum. You can add more; you cannot subtract.

The conformity assessment connection

The technical file is the backbone of the Article 43 conformity assessment. Whether you self-assess under Annex VI or go through a notified body under Annex VII, the technical documentation is what gets examined. It also underpins the EU declaration of conformity and the CE marking that must appear on your system before it enters the EU market. For a full explanation of how conformity assessment and CE marking work, see our conformity assessment and CE marking guide.

How long must you keep it?

Article 18 requires technical documentation to be retained for 10 years after the high-risk AI system has been placed on the market or put into service. National competent authorities may request access at any point during that period. This has direct implications for your MLOps infrastructure: you need version-controlled documentation that links each documentation version to the corresponding system version, training datasets, model weights, and deployment configuration.

The Commission's power to update Annex IV

The Commission is empowered to adopt delegated acts under Article 97 to amend Annex IV where necessary, to ensure that - in light of technical progress - the technical documentation provides all the information needed to assess compliance. In practice, this means Annex IV is a living legal instrument. Monitor the AI Office's publications and be prepared to update your file structure if the Commission exercises this power.

The Nine Mandatory Annex IV Sections

Annex IV specifies nine mandatory sections. Every high-risk AI system's technical file must address all nine - there is no optional set. Here is what each one requires in practice.

Section 1 - General Description of the AI System

Think of this as the executive summary of your system. It must cover:

• Intended purpose - what the system is designed to do, in the specific context it is designed to do it. Vague descriptions will not pass scrutiny.
• Provider identity and version history - the provider's name and the system version, showing its relationship to previous versions.
• Hardware and software interactions - how the system interacts with hardware or other software (including other AI systems) that are not part of the system itself.
• Software/firmware versions and any requirements related to version updates.
• Forms in which it is placed on the market - software packages embedded in hardware, downloads, APIs, and so on.
• Hardware it runs on - the intended hardware environment.
• Photographs or illustrations of external features, marking, and internal layout where the system is a component of a product.
• Instructions for use - the user-facing documentation that deployers and users will receive.

Section 2 - Detailed Description of the System and Its Development

This is the engineering core of the file, and typically the most demanding section to produce. It must include:

• Design specifications - the general logic of the system, its design choices, and the assumptions it rests on.
• System architecture - how the components interact, including any third-party tools or pre-trained models.
• Data requirements and datasheets - descriptions of the training, validation, and testing datasets: their origin, size, main characteristics, and how they were collected and processed. This section draws directly on your Article 10 data governance records.
• Human oversight measures - an assessment of the human oversight measures built into the system at the design stage.
• Pre-determined changes - any changes to the system and its performance that have been pre-determined by the provider.
• Validation and testing procedures - the methods used, the metrics applied, the test datasets, and the results.
• Cybersecurity measures - the measures put in place in accordance with Article 15.

The interdependencies here are significant. Sections 2, 4, and 5 all depend on evidence produced during data engineering, model development, and validation. You cannot write them retrospectively without losing critical institutional knowledge.

Section 3 - Monitoring, Functioning, and Control

This section documents how the system behaves in the real world and how it can be overseen. It must cover:

• Capabilities and limitations - including the degrees of accuracy for specific persons or groups of persons.
• Foreseeable unintended outcomes - and the sources of risk to health, safety, or fundamental rights.
• Human oversight measures - the technical measures that allow human operators to understand, monitor, and intervene in the system's outputs.
• Input data specifications - the characteristics of the data the system is designed to process.

The accuracy-by-subgroup requirement is worth flagging explicitly. It is not enough to report an aggregate accuracy figure. If your system performs differently for different demographic groups, that differential must be documented here.

Section 4 - Appropriateness of Performance Metrics

This section requires a description of why the performance metrics you have chosen are appropriate for your specific system and use case. A metric that is standard in your domain may not be the right metric for a high-risk deployment. You need to justify the choice - not just report the numbers.

Section 5 - The Risk Management System (Article 9)

A detailed description of your Article 9 risk management system: the hazards identified, the risk estimation and evaluation process, the risk mitigation measures adopted, and the residual risk sign-off. This section is a cross-reference to your live risk management records, not a standalone narrative. If your Article 9 process is weak, Section 5 will expose it.

Section 6 - Lifecycle Changes

A description of the relevant changes made to the system through its lifecycle. This includes both pre-determined changes documented at design time and changes arising from substantial modifications. Disciplined change management across all development phases is a prerequisite for keeping this section current.

Section 7 - Harmonised Standards or Alternative Solutions

Section 7 requires a list of the harmonised standards applied in full or in part, the references of which have been published in the Official Journal of the European Union. Where no such harmonised standards have been applied, a detailed description of the solutions adopted to meet the requirements of Chapter III, Section 2 must be provided, including a list of other relevant standards and technical specifications applied.

This is a live gap for most providers right now. CEN-CENELEC's Joint Technical Committee 21 (JTC 21) is still developing the harmonised standards for high-risk AI systems, and many are not yet published in the Official Journal. Until they are, you will need to document your alternative compliance approach - which standards you are using (ISO/IEC 42001, NIST AI RMF, and so on) and how they map to the AI Act's requirements.

Section 8 - EU Declaration of Conformity

A copy of the EU declaration of conformity referred to in Article 47. This is the formal one-page legal statement by the provider that all applicable requirements have been met. It is included in the technical file, but it is a distinct document - not a substitute for the file itself.

Section 9 - Post-Market Monitoring

A detailed description of the system in place to evaluate the AI system's performance in the post-market phase in accordance with Article 72, including the post-market monitoring plan. This plan must define how the provider will continue to monitor the system after deployment, collect feedback from deployers, detect performance drift, and report serious incidents. The post-market monitoring system is designed to continuously collect, document, and analyse data and assess system performance throughout the system's operational lifetime.

SME and Start-Up Relief

SMEs, including start-ups, may provide the elements of the technical documentation specified in Annex IV in a simplified manner. The Commission is required to establish a simplified technical documentation form targeted at the needs of small and micro enterprises. Where an SME opts to use the simplified form, it must use the Commission's form - it cannot invent its own simplified format.

Two important caveats. First, the simplified form has not yet been published. As of mid-2026, the Commission has not released it. Second, the required content remains the same - all nine sections must still be addressed. The simplification is in format and level of detail, not in scope. Until the form is available, SMEs should structure their documentation around the nine Annex IV sections while focusing effort on the highest-risk areas.

The Deadline Picture: More Runway, Not a Reason to Wait

The original deadline for high-risk provider obligations - including Article 11 - was 2 August 2026. That date has now moved.

On 29 June 2026, the Council of the EU gave final approval to the Digital Omnibus on AI, the first substantive amendment to the EU AI Act since its 2024 adoption. The new application dates are 2 December 2027 for stand-alone high-risk AI systems listed in Annex III, and 2 August 2028 for high-risk AI systems embedded in regulated products under Annex I.

The delay reflects a pragmatic acknowledgement that the regulatory infrastructure - harmonised standards, national competent authorities, compliance guidance - has not materialised on schedule. It is a deferral, not a dismantling. The fundamental architecture of the AI Act, its risk-based approach, its governance structure, and its core obligations, remains intact.

What the delay gives you is time to build the technical file properly. What it does not give you is permission to stop. Consider three reasons to keep going:

1. Retrospective documentation is expensive. Estimates for producing a compliant technical file range from 40 to over 200 hours depending on system complexity - and retrospective documentation takes two to three times longer than documentation built during development.
2. Standards are still arriving. Harmonised standards from JTC 21 are expected towards the end of 2026 and into 2027. When they land, you will need to map your system against them. That mapping is far easier if your documentation is already structured.
3. The conformity assessment clock starts before market launch. The technical file must exist before you place the system on the market. If you wait until 2027 to start, you will be building the file under deadline pressure, not before it.

Always verify the final dates against the Official Journal publication of the Digital Omnibus as implementing detail continues to land. The EU AI Act Service Desk is the authoritative source for official guidance.

Building the Technical File: Practical Advice

The most common mistake is treating the technical file as a documentation project that happens after the system is built. It is not. The Annex IV sections are not independent deliverables - they are outputs of the development process itself.

Technical Documentation Readiness Checklist

Use this interactive checklist to assess where your technical file stands across all nine Annex IV sections.

A Note on What This Guide Is Not

This is a plain-English orientation to Article 11 and Annex IV of the EU AI Act. It is not legal advice and does not substitute for qualified legal or regulatory counsel. The AI Act is a complex regulation, its supporting standards are still being finalised, and implementing detail from the Digital Omnibus is still landing. Always verify your obligations against the official text of Regulation (EU) 2024/1689 and the latest guidance from the EU AI Act Service Desk.

For the Annex IV text itself, see artificialintelligenceact.eu/annex/4/.

This post is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for advice specific to your organisation's situation.