What is Annex IV of the EU AI Act?

Annex IV specifies the contents of the technical documentation that a provider of a high-risk AI system must draw up before placing the system on the EU market, as required by Article 11. It is the evidentiary file behind every other high-risk obligation: it describes the system and its intended purpose, how it was developed and on what data, its performance and accuracy characteristics, the risk management system, the human oversight measures, and the post-market monitoring plan. If a market surveillance authority asks how you comply, this document is the answer you hand over.

Who has to produce Annex IV documentation?

The provider of a high-risk AI system — the party that develops it, or has it developed, and places it on the EU market or puts it into service under its own name or trademark. Deployers do not draw up Annex IV documentation, but they depend on it, because the instructions for use they must follow are derived from it. A deployer can also become a provider by rebranding a system, substantially modifying it, or repurposing a general-purpose system into a high-risk use, which pulls the full documentation obligation onto them.

Is there a simplified Annex IV form for small companies?

Yes. The AI Act directs that a simplified technical documentation form be made available for SMEs, including startups, and a provider that uses it is treated as meeting the Article 11 requirement. The simplification is in format and presentation rather than in substance — you still have to be able to describe the system, its data, its performance and its risk controls. It reduces documentation overhead; it does not exempt you from having the underlying practices in place.

How long must Annex IV documentation be kept?

The technical documentation, along with the EU declaration of conformity and related records, must be kept at the disposal of national authorities for ten years after the system is placed on the market or put into service. That retention period is longer than most startups' entire operating history and longer than most document stores are configured to hold anything, which makes archival an early architectural decision rather than a later administrative one.

Does the documentation have to be updated after launch?

Yes — it must be kept up to date across the system's lifecycle. Annex IV expressly calls for a record of changes made to the system through its lifetime, and post-market monitoring findings feed back into it. In practice this means the technical file cannot be a one-time document produced for launch; retraining a model, changing a data source, adjusting a decision threshold or expanding the intended purpose all generate entries, and a substantial modification can require the conformity assessment to be revisited.

EU AI Act Annex IV Technical Documentation 2026: What a High-Risk AI Vendor Actually Has to Write

Why the Technical File Is the Real Deliverable

The high-risk provisions read as a list of practices: manage risk, govern your data, enable human oversight, hit accuracy and robustness targets, keep logs, monitor after launch. Practices are invisible. What is visible — to a notified body during conformity assessment, to a market surveillance authority during an inquiry, and to an enterprise buyer during procurement — is the documentation that describes them.

This is the standard shape of EU product regulation, and it produces a specific failure mode for software companies encountering it for the first time. Teams do the engineering work, ship, and then discover months later that they cannot evidence any of it: no record of which data sources trained which model version, no written rationale for a threshold, no signed-off statement of intended purpose, no changelog tying a retrain to a validation run.

Reconstructing that record after the fact is dramatically more expensive than generating it as you go — and for some sections it is impossible, because the people who made the decisions have moved on and the artifacts were never captured.

What Annex IV Requires, Section by Section

The annex is organized around a small number of blocks. Below is what each covers, who in a typical software organization owns it, and the failure that keeps recurring.

General description of the system

Owner: Product

Intended purpose, provider identity, versions, how the system interacts with hardware and other software, the forms in which it is placed on the market, hardware it runs on, user interface description, and the instructions for use supplied to deployers.

Recurring trap: Intended purpose gets written expansively for sales reasons. A broad purpose statement widens your risk assessment, your testing obligations and your liability surface. Write it narrowly and precisely, then police the marketing copy against it.

Development process and system design

Owner: Engineering / ML

Design specifications and the rationale behind key choices, system architecture, computational resources, data requirements and provenance, labelling and cleaning methodology, human oversight measures and how they were designed, and any pre-determined changes planned for the system.

Recurring trap: Data provenance. Teams can describe the model architecture in an afternoon and then spend weeks reconstructing where training data came from, under what terms, and what preprocessing was applied — because none of it was recorded at the time.

Monitoring, functioning and control

Owner: ML / Risk

Capabilities and limitations, expected accuracy for specified persons or groups, foreseeable unintended outcomes and sources of risk to health, safety and fundamental rights, human oversight measures in operation, and specifications on input data.

Recurring trap: 'Expected accuracy for specific groups' means disaggregated performance metrics. An aggregate accuracy figure does not satisfy this, and producing group-level numbers late often reveals disparities you now have to document and address.

Performance metrics and validation

Owner: ML / QA

The metrics used to measure accuracy, robustness and cybersecurity, along with test logs and validation reports dated and signed by the responsible persons, including against the pre-determined changes described earlier.

Recurring trap: Dated, signed test reports. Ad-hoc evaluation notebooks are not test logs. Establish a validation run that emits a durable, versioned artifact tied to a specific model version before you need it for an audit.

Risk management system

Owner: Risk / Compliance

A detailed description of the risk management system established under Article 9 — how risks are identified, analyzed, evaluated, mitigated and re-evaluated across the lifecycle.

Recurring trap: A generic risk register copied from an ISO template. It has to be about this system's specific hazards, and it has to show the loop closing: risk identified, control applied, residual risk evaluated, decision recorded.

Lifecycle changes

Owner: Engineering

A description of relevant changes made to the system throughout its lifecycle.

Recurring trap: Nothing captures the changes that matter. Git history records code, not that a decision threshold moved from 0.7 to 0.6 or that a data vendor was swapped. Keep a purpose-built change log for the AI-relevant surface.

Standards applied

Owner: Compliance

A list of harmonised standards applied in full or in part, and where none were applied, a description of the solutions adopted to meet the requirements.

Recurring trap: Where harmonised standards are unavailable or only partly applicable, the 'describe your alternative solution' path is real work — it is a written argument that your approach meets the requirement, not a checkbox.

Declaration of conformity and post-market plan

Owner: Compliance / Product

A copy of the EU declaration of conformity, and a detailed description of the system put in place to evaluate performance in the post-market phase, including the post-market monitoring plan.

Recurring trap: The post-market monitoring plan is treated as a formality until an incident, at which point reporting timelines apply and there is no data pipeline in place to detect or characterize what happened.

The Documentation Nobody Assigns

Look at the owner column above. The technical file spans product, ML engineering, QA, risk and compliance — and in most companies under a few hundred people, no single role has authority over all five. That is the actual reason these files do not get written. It is an organizational problem wearing a legal costume.

The teams that get through it name one accountable owner for the file, give them the authority to require artifacts from each function, and set a rule that a model version does not ship until its documentation entries land. That last rule is what converts the annex from a quarterly scramble into a per-release increment of a few hours.

If You Build on Someone Else's Model

Most companies facing a high-risk classification did not train the underlying model. You are assembling a system on top of a general-purpose model you access through an API, and you cannot personally document its training data or architecture. Three practical points:

Upstream providers owe you information. General-purpose model providers have their own documentation duties, including information intended to help downstream providers meet theirs. Ask for that package explicitly and in writing before you commit to a vendor.
You document your system, not their model. Your file covers the system you place on the market: what it is for, what you built around the model, what data you supply at runtime, how you evaluated it for your purpose, and how oversight works in your product.
Vendor changes are your lifecycle changes. When the upstream model version moves under you, your performance characteristics move too. Pin versions where you can, re-validate when they change, and record it — an undisclosed upstream shift is still a change to your system.

A Realistic Sequencing for a Small Provider

Weeks 1–2 · Fix the scope

☐Write the intended purpose statement in one narrow paragraph and get it signed off
☐Confirm the high-risk classification against the annexed use cases, and record the reasoning either way
☐Identify whether you are the provider, the deployer, or have become a provider through modification or rebranding
☐Name one accountable owner for the technical file

Weeks 3–6 · Capture what exists

☐Reconstruct data provenance while the people who know it are still reachable
☐Produce a versioned validation report with disaggregated performance metrics
☐Document the human oversight design as built, not as aspired to
☐Write the system architecture and design-rationale section

Weeks 7–10 · Build the loop

☐Stand up a risk register specific to this system with the mitigation loop visible
☐Start the lifecycle change log and backfill the last few significant changes
☐Draft the post-market monitoring plan with an actual data source behind each signal
☐Record which standards you applied and, where none, the alternative solutions adopted

Ongoing · Keep it alive

☐Block release on documentation entries for any model version change
☐Re-validate and re-document when an upstream model or data source moves
☐Archive the file and declaration into a store that will survive ten years
☐Review the intended purpose statement whenever sales or marketing describes a new use

Frequently Asked Questions

Do we need Annex IV documentation if our system is not high-risk?

The Article 11 obligation attaches to high-risk systems, so a system outside that classification does not need the technical file. What you do need is a defensible written record of why it falls outside — the classification analysis itself, including any reliance on the derogation for systems that do not pose a significant risk. That analysis is short, but its absence is what turns a routine inquiry into an extended one, because you will be reconstructing your reasoning under time pressure rather than handing over a memo.

Can we reuse our SOC 2 or ISO 42001 documentation?

Partially, and it is worth mapping rather than duplicating. An AI management system certification produces governance artifacts — risk processes, roles, change control, monitoring — that map onto several Annex IV sections and demonstrate the organizational maturity behind them. What those frameworks do not produce is the system-specific content: intended purpose, architecture, data provenance for this model, disaggregated accuracy metrics, and the specific hazards this system creates. Expect the management-system work to cover a meaningful share of the file and none of its technical core.

How long does the technical file take to produce in practice?

For a small provider with one high-risk system and reasonable engineering hygiene, plan on roughly two to three months of part-time effort across several people, front-loaded on data provenance and validation reporting. Teams without version-controlled data lineage or durable evaluation artifacts consistently run longer, because the bottleneck is not writing — it is recovering facts about decisions made a year ago. Producing it incrementally alongside development costs a fraction of that.

What happens if an authority asks for it and we do not have it?

Failure to produce the technical documentation on request is itself a compliance failure, independent of whether the underlying system is safe and well-built. It also removes any ability to demonstrate that it is — you have no evidence of your risk controls, your validation, or your oversight design. The practical effect is that a request you cannot answer escalates the inquiry and shifts the posture from 'show us your file' to 'show us everything,' which is a materially worse position to negotiate from.

Does the SME simplified form meaningfully reduce the work?

It reduces the presentation burden — format, structure, level of elaboration — and using it satisfies the Article 11 obligation. It does not change what you must be able to say. You still need to know your data provenance, still need performance evidence, still need a risk process and a monitoring plan. The right way to think about it is that it lowers the cost of documenting good practice; it does not lower the bar for having it. Companies hoping the simplified form excuses the underlying work are the ones it helps least.

Write the Intended Purpose First

Every other section of the file depends on one paragraph: what this system is for. Scope it narrowly and the risk analysis, the testing obligations and the oversight design all shrink with it. Let sales write it expansively and you have quietly enlarged every downstream requirement, permanently.

Then go after data provenance while it is still recoverable. It is the section that cannot be reconstructed later, and it is the one that decides whether the rest of the file takes weeks or quarters.