Article 11 Technical Documentation Is Your Key Compliance File

Update — 11 May 2026: The AI Act Omnibus deal reached at the May trilogue moves the 2 August 2026 deadline for Annex III high-risk obligations to 2 December 2027, pending formal adoption and publication in the Official Journal. Article 50 transparency moves to 2 November 2026. See: EU AI Act High-Risk Deadline Delayed to December 2027.

If you’re building a high-risk AI system, the technical documentation file is what an inspector will actually ask for. Article 11 is the rule that governs it: it has to exist before you ship, stay current as the system evolves, and be ready to hand over when an authority writes asking for it. Without that file, nothing else you’ve done really counts.

The risk management work under Article 9, the data governance under Article 10, the logging under Article 12, the oversight design under Article 14, the accuracy and security work under Article 15 — none of it is compliant on its own. Each Section 2 obligation has to be evidenced inside a single Annex IV dossier. That dossier is what Article 11 governs.

With the Omnibus agreement moving Annex III high-risk obligations to 2 December 2027, you’ve got more time. But Annex IV is a multi-quarter exercise. Teams that wait until the last six months will find their dossier is missing the evidence trail behind every claim they want to make.

What Article 11 actually requires

Article 11 is short — three paragraphs, each more consequential than its length suggests.

Article 11(1). Technical documentation has to be drawn up “before that system is placed on the market or put into service” and kept “up to date.” It has to demonstrate that the system meets Section 2 (Articles 8 to 15) and give national authorities and notified bodies the information they need “in a clear and comprehensive form.” The minimum contents are listed in Annex IV.

Three obligations sit in that paragraph.

• Before placement. The file is a precondition for shipping. A high-risk system on the market without a complete dossier is non-conforming from day one.
• Up to date. Not a snapshot. The file tracks the system as it changes.
• Clear and complete. Written for an inspector. Your internal engineering wiki is not the format.

Article 11(1), second subparagraph. SMEs (including startups) can provide the documentation in a “simplified manner.” The Commission will publish a simplified template; you can choose to use it. This is the only material concession in Article 11. Every Annex IV topic still has to be covered — the simplification is in form and depth. The scope is the same as a large provider.

Article 11(2). For high-risk AI systems that are “safety components of products” already covered by Union harmonisation legislation in Section A of Annex I — medical devices, machinery, in-vitro diagnostics, and the other New Legislative Framework instruments — you produce a single set of documentation that contains both the Annex IV elements and the sectoral elements. The intent is to avoid parallel dossiers for the same system. The work is in reconciling the two structures.

Article 11(3). The Commission can amend Annex IV by delegated act “where necessary, to ensure that… the technical documentation provides all the information necessary to assess the compliance of the system.” The structure can change. If you’re building a dossier in 2026, design it so it can absorb new sections without being rebuilt — expect Annex IV revisions later in the decade.

Article 11 is short because the substance is in Annex IV. Article 11 says the file must exist, exist on time, stay current, and be available. Annex IV says what’s in it.

Annex IV: what the file contains

Annex IV lists “at least” nine sections. “At least” matters. More may be required depending on the system.

1. General description of the AI system. Intended purpose, name, version. How the system interacts with hardware or software it’s not part of. Software and firmware versions. Hardware it’s intended to run on. The product it’s integrated into, if any. The user interface. The instructions for use for the deployer. The forms in which the system is placed on the market — software embedded in hardware, downloads, APIs, and so on. This section answers the question “what is this thing.”

2. Detailed description of the elements and process of development. Methods and steps for development, including any reliance on pre-trained systems or third-party tools and how they were used. Design specifications, including the system’s logic, the key design choices and their rationale, and the main classification choices. System architecture, including how model components build on each other. Data sheets describing the training methodologies and techniques, the datasets used, their provenance, scope, main characteristics, and how the data was obtained and selected — this connects directly to Article 10 data governance. The human oversight assessment under Article 14. Predetermined changes and continuous learning processes, where applicable. Validation and testing procedures with the metrics they use. Cybersecurity measures.

3. Monitoring, functioning and control of the system. Capabilities and limitations in performance, including expected accuracy for specific persons or groups. Foreseeable unintended outcomes. Sources of risks to health, safety, fundamental rights, and discrimination. Human oversight measures and the technical measures put in place to facilitate the interpretation of outputs. Input data specifications, where appropriate.

4. Appropriateness of the performance metrics. The metrics you used and why they’re appropriate for this system and its purpose.

5. Risk management system. The complete Article 9 risk file.

6. Relevant changes made through the lifecycle. The change history.

7. Harmonised standards applied. Listed in full or in part. Where you haven’t applied harmonised standards, a detailed description of how you met the Section 2 requirements anyway, including a list of other relevant standards and technical specifications you used. The role of harmonised standards is what makes this section tractable — naming a standard you complied with takes the place of a much longer explanation.

8. A copy of the EU declaration of conformity referred to in Article 47.

9. Post-market evaluation system. Detailed description of the system you have in place to evaluate AI performance after deployment under Article 72, including the post-market monitoring plan. The monitoring plan lives inside the technical documentation. Teams that file it in a separate folder are quietly out of conformity with Article 11.

The nine sections aren’t a checklist. Each is substantive documentation with auditable content. The dossier for a serious system runs to hundreds of pages, because the work behind it ran to thousands of hours.

How this differs from the instructions for use

The instructions for use sit inside Annex IV §1(h) — one item in the system description — and are governed in detail by Article 13, which extends beyond instructions to a wider transparency duty owed to the deployer. The instructions are the deployer-facing extract: what a deployer needs to operate the system in conformity. That document is covered in the Annex IV instructions for use piece. The full Annex IV technical file is a much larger document. The instructions are an output of the file. A provider who has written excellent instructions and never assembled the rest of the dossier has shipped about a tenth of the obligation.

Keeping the file current

“Kept up to date” is the part of Article 11 that catches teams. The file isn’t what you submitted at the moment of conformity assessment. It’s what describes the system as it exists in the field today. Three things follow.

Version control isn’t optional. Every change to the system that materially affects an Annex IV section must produce a corresponding change in the file. A new feature, a retrained model, a new data source, a new component, a revised intended purpose — each is a documentation update.

Imagine you ship version 1.4 of your AI hiring tool on a Friday afternoon, after retraining on six months of new feedback data. By Monday, your Annex IV §2 dataset description still references the previous training corpus. By Tuesday, your dossier is non-conforming with the system it’s meant to describe. Teams treating the file as a launch deliverable discover this pattern at the first significant version bump.

The change log is part of the regulated file. Annex IV §6 requires a description of relevant changes through the lifecycle. The change log is the audit trail of how the dossier has tracked the system. An empty or implausibly thin change log on a system that has shipped twelve versions is a finding on its own.

Your conformity declaration ages with the system. Article 47 declarations of conformity reference the technical documentation. If the documentation is stale, the declaration is stale too. If the system has moved beyond what the declaration covers, the system is non-conforming until both the file and the declaration catch up. A substantial modification under Article 43(4) normally triggers a new conformity assessment — and the trigger thresholds belong in your quality management system, defined ahead of time rather than improvised under pressure.

Retention, access, and authority requests

Article 18 requires you to keep the Annex IV technical documentation, your quality management documentation, the records of any approved changes, the decisions of notified bodies, and your declaration of conformity at the disposal of national competent authorities for ten years after the system has been placed on the market or put into service.

Ten years isn’t a filing cabinet. It’s an information-architecture decision. The dossier, including version history, has to remain retrievable long after the people who built it have moved on. Format choices matter. PDFs are durable but lossy. Markdown in a versioned repository is portable but harder to hand over neatly. Bespoke wiki systems are convenient but tied to vendors who may not be around in 2036. A defensible approach is a portable, vendor-neutral format with a documented retrieval procedure.

Article 21 requires you, on a reasoned request from a national competent authority, to provide “all the information and documentation necessary to demonstrate the conformity of the high-risk AI system with the requirements set out in Section 2” — and to provide it in “a language which can be easily understood” by that authority, in one of the official EU languages the Member State has indicated. You also have to grant access to any Article 12 logs within your control. Producing a dossier from cold storage in two weeks because nobody updated the access list since 2026 — and then translating it — isn’t a position the authority will be sympathetic to.

The SME simplified form

Article 11(1) second paragraph creates the only relief valve in the article. SMEs, including startups, can provide the documentation “in a simplified manner.” The Commission is producing a simplified template “taking into account the needs of small and micro enterprises.”

Two cautions.

The simplification is in form and depth. The scope of what you cover is the same as a large provider. Every Annex IV section still has to be addressed. A two-page document that says “we are a small company so this is short” and skips the data governance section isn’t a simplified dossier. It’s a deficient one.

The simplification doesn’t change the conformity bar. A simplified Annex IV file still has to support a defensible Section 2 conformity claim — risk management, data governance, transparency, oversight, accuracy and security. The relief reduces documentation overhead for organisations that haven’t yet built large quality systems. It doesn’t reduce the underlying engineering work.

For most SMEs, the practical answer is a single well-structured document that addresses each Annex IV section concisely, with pointers into a small number of supporting documents (a risk register, a data sheet, a logging schema, a test report). That document is your dossier. It’s shorter because your system is smaller. The obligation itself is the same size.

Documentation expectations

A defensible technical file has a few qualities.

A stable structure that maps to Annex IV. Section numbering that follows Annex IV’s numbering makes an inspector’s job tractable and makes maintenance obvious. Bespoke structures that reorganise the topic order produce dossiers that look complete and turn out to be missing pieces under audit.

Versioning at the document and section level. Every section has a last-updated date and a change history. The dossier has an overall version number. That version number is the one referenced by the declaration of conformity.

Traceability into the underlying documents. Each Annex IV section should reference the source-of-truth document behind it: the risk register, the dataset registry entry, the logging schema, the validation report, the harmonised standards conformance matrix. An inspector will follow those references. If the references don’t lead anywhere, the prose at the top is decoration.

A single owner per section, named in the document. Auditors ask for owners. Listing “the team” or “the product engineering manager” leaves the inspector to play a guessing game. Name a person — one with the authority to answer questions about the section. If they leave the company, update the document.

A defined update trigger. A documented rule for what changes to the system trigger which sections to be updated, who reviews them, and how the update is signed off. Change management belongs to your quality management system under Article 17 — but it’s the part that keeps Article 11 alive between launches.

A package you can hand over. A rehearsed process for assembling the current dossier plus the relevant logs and producing them in the format the authority requests. Article 21 gives authorities the right to demand it. If you’ve never rehearsed the production, you’ll be doing it under time pressure during an investigation.

Common traps

The dossier-of-launch. A complete file at market placement that hasn’t been touched since shipping. A regulator looking at a 2026 dossier in 2028 will assume nothing about the system has changed in two years — and then ask why.

Prose instead of evidence. Annex IV sections filled with text that describes what the engineering team meant to do, with no references to the documents that prove the work happened. An auditor will follow the references. If they don’t exist, the prose is decoration.

Monitoring plan in the wrong file. Annex IV §9 requires the post-market monitoring plan inside the technical documentation. A separate quality document containing the plan, however well-written, doesn’t satisfy Article 11.

Declarations of conformity decoupled from the dossier version. A declaration that says “the technical documentation” without a version number leaves “what version was current when this was signed?” unanswerable. The declaration should reference a specific dossier version tied to a date.

Sectoral overlap mishandled. A safety component already covered by medical-device, machinery, or other Annex I legislation that ends up with two parallel dossiers — one for the sectoral regulator, one for AI. Article 11(2) requires a single integrated file. Two parallel files produce conflicts an inspector will find inside twenty minutes.

Ten-year retention assumed. Files held in a wiki the vendor no longer supports. Files in the personal drive of the engineering lead who left the company. Files in a format your organisation no longer reads. The ten-year clock runs against you. The storage technology is your problem to solve.

The SME concession used as cover. A small team producing a thin file because the regulation allows simplification, without doing the underlying work the file is supposed to evidence. The format can be simplified. The conformity claim still has to be defensible.

What to do now

If you’re a provider building or shipping a high-risk system:

1. Build the file in parallel with the system. Don’t treat the dossier as a launch deliverable you assemble at the end. The evidence trail behind each Annex IV section is easier to capture as you generate it than to reconstruct three months later from memory and Slack scrollback.
2. Map your structure to Annex IV from day one. Use the nine-section numbering. An inspector who has audited ten other providers should recognise the layout immediately.
3. Name an owner for each section. Write the names into the document. If an owner leaves the company, that’s a documentation update.
4. Decide your update triggers ahead of time. Write into your quality management system what changes to the system require which sections to be updated, who signs off, and when. Then follow that process for every release.
5. Rehearse an Article 21 production. Pick a date. Pretend an authority has written. Assemble the current dossier, the logs, and the translation. Time how long it takes and what was missing. Do it again next year.

Article 11 is the rule that turns every other provider obligation into a single dated, owned, retrievable record. Building the practices isn’t enough. The file is how you prove you built them. A team that has done the risk management, the data governance, the logging, the oversight, and the accuracy and security work but hasn’t assembled it into a current Annex IV dossier has not yet met the bar. A team that has produced a dossier without the underlying work has built something an inspector will close in an afternoon.