EU AI Act Annex IV: What Technical Documentation Requires

The EU AI Act stops being abstract the moment someone asks for your Annex IV pack. From 2 August 2026, high-risk AI systems under Annex III carry binding obligations — conformity assessment, registration in the EU database, post-market monitoring, human oversight — and the technical documentation is the spine that holds all of it together. Without it, you cannot demonstrate conformity, and "we built it carefully" is not an admissible answer to a market surveillance authority.

This is a practitioner's guide to what Annex IV requirements actually mean: what the documentation must contain, how to structure it so assessors can read it, and how to keep it alive over a ten-year retention horizon. It pairs with our August 2026 readiness checklist and assumes you have already established that your system is in scope — if you have not, start with Annex III high-risk classification.

TL;DR / Key takeaways

Annex IV is a content specification, not a form. It lists what your technical documentation must prove; you build the structure, ideally one section per requirement.
It must exist before market placement. Documentation is the evidence base for the conformity assessment, so it is an input, not an output.
Retention is ten years. Providers keep technical documentation and logs available to authorities for ten years after placing the system on the market.
The provider owns it. If you substantially modify a third-party or GPAI-based system, you can become the provider and inherit the obligation.
Treat it as a living artefact. Version it under change control; every substantial modification updates the pack and may retrigger assessment.

What Annex IV actually requires

Article 11 of the AI Act requires providers of high-risk systems to draw up technical documentation before the system is placed on the market, and to keep it up to date. Annex IV then enumerates the minimum contents. Read literally, it is a checklist — but the value is in how you organise the evidence behind each item.

The required elements break down as follows:

Annex IV area	What it must demonstrate	Where the evidence usually lives
General description	Intended purpose, provider, versions, how the system interacts with hardware/software, deployment forms	Product spec, architecture docs
Development process	Design choices and trade-offs, system architecture, data requirements, pre-trained components, validation approach	ADRs, design docs, repos
Monitoring & control	Human-oversight measures, control interfaces, expected behaviour and limitations	Operations runbooks, UX specs
Performance	Accuracy, robustness, cybersecurity metrics, foreseeable unintended outcomes, test results	MLOps pipelines, eval reports
Risk management	The Article 9 risk-management system and residual-risk decisions	Risk register, DPIA/FRIA
Lifecycle changes	Changes made to the system through its lifecycle	Change log, release notes
Standards & declaration	Harmonised standards applied, EU declaration of conformity, post-market monitoring plan	Compliance file

Two points trip teams up. First, performance evidence must be quantitative and reproducible — "the model performs well" is not documentation; the metrics, test sets, and conditions are. Second, the risk-management section is not a one-time DPIA; Article 9 demands a continuous, iterative process, and your documentation has to show it runs across the lifecycle.

A workable Annex IV documentation template

You will not find a single mandated AI documentation template in the Regulation — the Commission may issue a simplified form for SMEs, but the contents are what bind you. The pragmatic move is to build a pack whose table of contents maps one-to-one onto Annex IV, so an assessor never has to hunt. The structure we deploy with clients looks like this:

Section 1 — System identification. Name, versions, provider and authorised representative, intended purpose, reasonably foreseeable misuse, hardware/software environment, and deployment form (API, embedded, on-device).
Section 2 — Development and design. Methods and steps, design rationale and trade-offs, system architecture diagram, computational resources, and the role of any third-party or GPAI components.
Section 3 — Data and data governance. Training, validation, and test datasets; provenance, labelling, and cleaning; representativeness and bias assessment; data-governance measures under Article 10.
Section 4 — Performance and validation. Accuracy, robustness, and cybersecurity metrics with the test methodology, datasets, and acceptance thresholds; known limitations and foreseeable failure modes.
Section 5 — Human oversight and control. Oversight measures, interfaces, stop/override mechanisms, and the competencies required of human overseers.
Section 6 — Risk management. The Article 9 process, identified risks, mitigations, residual risk, and the link to any fundamental-rights impact assessment.
Section 7 — Post-market monitoring and changes. Monitoring plan, logging design, incident-reporting procedures, and the lifecycle change log.
Section 8 — Compliance file. Harmonised standards applied, conformity-assessment evidence, and the signed EU declaration of conformity.

Each section should cite where the underlying evidence lives rather than duplicate it, so the pack stays maintainable. When we delivered this for a financial-services client running a credit-decisioning model, the breakthrough was treating the documentation as a thin, authoritative index over artefacts the engineering team already produced — not a parallel document set that drifts out of date the week after it is signed.

AI Act record keeping: logs and ten-year retention

Documentation is only half the obligation. AI Act record keeping also covers automatically generated logs. High-risk systems must log events relevant to identifying risks and to post-market monitoring (Article 12), and the design of that logging belongs in your technical documentation.

The retention rules are concrete:

Technical documentation and logs must be kept at the disposal of national competent authorities for ten years after the system is placed on the market or put into service.
Logs under the provider's control are retained for a period appropriate to the intended purpose, and at least six months unless other Union or national law requires longer.

The architectural consequence: build retention, integrity, and access controls into the system from day one. Retrofitting compliant logging onto a system already in production is expensive and, for some designs, impractical.

How documentation feeds the conformity assessment

The technical documentation is not a deliverable you produce for its own sake — it is the input to the conformity assessment. Whether your system follows the internal-control route or requires a notified body depends on its category and the standards you apply. Either way, the assessment reads your Annex IV pack as the evidence that the requirements are met. Gaps in the documentation are gaps in conformity. For the assessment routes and how to choose between them, see our conformity assessment guide.

Loading diagram...

This is also where ISO/IEC 42001 earns its place. The standard gives you an AI management system — defined roles, risk processes, and lifecycle controls — that makes generating and maintaining Annex IV documentation repeatable. We treat 42001 as the operating model and the Annex IV pack as the per-system artefact that model reliably produces.

Common documentation failure modes

From assessment-readiness reviews, the same gaps recur:

Documentation written after the fact. Reconstructing design rationale post-hoc produces a pack that reads plausibly but cannot withstand a probing question. Capture decisions when you make them.
No quantitative performance evidence. Qualitative claims about accuracy and robustness fail. You need metrics, test sets, and thresholds.
Risk management as a single document. Article 9 is iterative. A one-shot assessment with no evidence of ongoing review is a finding.
Logging treated as an operational concern only. If logs are not designed for the required retention and authority access, you have a structural gap.
No change control. A substantial modification that does not update the documentation — and, where relevant, retrigger assessment — breaks the chain of conformity.

FAQ

What is EU AI Act Annex IV?

Annex IV of the EU AI Act is the prescriptive list of contents that the technical documentation for a high-risk AI system must include. It covers the system description, development process, monitoring and control, performance metrics, risk management, and lifecycle changes. The documentation must be drawn up before the system is placed on the market and kept current for as long as the system is in use.

When does Annex IV technical documentation need to be ready?

For high-risk systems under Annex III, the obligations — including technical documentation, conformity assessment, EU database registration, and post-market monitoring — apply from 2 August 2026. The documentation must exist before market placement, not after, because it is the evidence base for the conformity assessment.

Is there an official Annex IV technical documentation template?

The AI Act itself defines the required contents but does not mandate a single official template, and the Commission can adopt a simplified form for SMEs. In practice you build your own structured pack that maps one-to-one to the Annex IV headings, supported by harmonised standards and ISO/IEC 42001 for the management-system layer.

How long must AI Act records be kept?

Providers of high-risk AI systems must keep the technical documentation and automatically generated logs at the disposal of national authorities for ten years after the system is placed on the market or put into service. Logs must be retained for a period appropriate to the intended purpose, and at minimum six months unless other law requires longer.

Who is responsible for the technical documentation?

The provider — the entity that develops the system and places it on the market under its own name — is legally responsible for drawing up and maintaining Annex IV documentation. Deployers and importers have their own duties, but the documentation obligation sits with the provider. If you substantially modify a third-party system, you may become the provider and inherit the obligation.

Does Annex IV apply to general-purpose AI models?

No. General-purpose AI (GPAI) models follow a separate documentation regime under Annex XI and Annex XII, with obligations that applied from 2 August 2025. Annex IV is specific to high-risk AI systems. A high-risk system built on a GPAI model still needs full Annex IV documentation in its own right.

How does ISO/IEC 42001 relate to Annex IV?

ISO/IEC 42001 is the AI management-system standard. It does not replace Annex IV, but it provides the governance scaffolding — roles, risk processes, lifecycle controls — that makes producing and maintaining Annex IV documentation repeatable and auditable. We treat 42001 as the operating model and Annex IV as the per-system deliverable it produces.

Getting it conformity-ready

Annex IV rewards teams that document as they build and punishes those that reconstruct after the fact. If you want a second set of eyes on a high-risk system before the August 2026 deadline — or a documentation operating model that survives the next change request — our AI and data platform engineering practice has taken regulated systems through this end to end. We are happy to review where you stand.