What is Annex IV of the EU AI Act?
Annex IV of the EU AI Act (Regulation (EU) 2024/1689) is the list of minimum contents for the technical documentation of a high-risk AI system. It specifies, in numbered points, what the documentation has to describe: the system itself, how it was developed, the data used, its performance and limitations, the risk management system, the changes made across its lifecycle, the standards applied, the EU declaration of conformity, and the post-market monitoring plan.
Annex IV does not stand alone. Article 11 is the operative obligation: technical documentation containing at least the elements set out in Annex IV must be drawn up before a high-risk AI system is placed on the market or put into service, and kept up to date thereafter. The documentation exists to demonstrate to national competent authorities, in a clear and comprehensible form, that the system complies with the requirements for high-risk AI in Chapter III, Section 2.
- •In practice, Annex IV is the audit surface. It is what a market surveillance authority asks for, what a notified body reads where third-party conformity assessment applies, and what an enterprise customer's procurement team increasingly asks a supplier to summarise.
Who is responsible for Annex IV documentation?
The provider of the high-risk AI system — the party that develops it, or has it developed, and places it on the market or puts it into service under its own name or trade mark — is responsible for drawing up the technical documentation and keeping it current. That responsibility is not delegable by contract in the sense that matters to an authority: the provider remains the addressee of the obligation even if the drafting is outsourced.
Two situations catch SMEs out. First, an organisation that buys a general-purpose model or a third-party system and puts it on the market under its own brand, or substantially modifies a high-risk system, or changes its intended purpose such that it becomes high-risk, can become a provider itself under the Regulation's provider-attribution rules — and inherits the Annex IV obligation.
Second, deployers — organisations using a high-risk system in a professional capacity — do not write Annex IV documentation. They have their own duties: using the system in accordance with the instructions for use, human oversight, input data relevance where they control it, monitoring, logging retention, and, for certain public-sector and service-related uses, a fundamental rights impact assessment. Deployer records feed the provider's post-market monitoring, but they are a different artefact.
Providers established outside the EU must also have an authorised representative in the Union, and that representative keeps a copy of the technical documentation available to authorities. Documentation retention runs for ten years after the system is placed on the market or put into service.
Walking Annex IV, point by point
1. General description of the AI system
The intended purpose, the provider's identity, the version, how the system interacts with hardware or software it is not part of, the relevant software or firmware versions, the forms in which it is placed on the market (API, embedded component, downloadable package), hardware it runs on, and — where it is a product component — photographs or illustrations of external features and the user interface for the deployer.
Evidence that satisfies it: a product description reviewed against the actual release, plus the instructions for use provided to deployers under Art. 13. If the two disagree, the discrepancy is itself a finding.
2. Detailed description of the elements and the development process
This is the longest point and the one most often underdone. It covers the methods and steps taken to develop the system, including any use of pre-trained systems or third-party tools and how these were used, integrated, or modified; the design specifications and the general logic of the system and the algorithms; the key design choices including rationale and assumptions, including about the persons or groups the system is intended to be used on; the main classification choices and what the system is designed to optimise for; the system architecture; the data requirements — datasheets describing training methodologies, provenance, scope and characteristics of datasets, how they were obtained and selected, labelling procedures, and cleaning methods; the assessment of human oversight measures needed under Art. 14; where applicable, a description of predetermined changes to the system and its performance; and the validation and testing procedures used, including metrics for accuracy, robustness, and compliance with the other Chapter III requirements, together with test logs and reports dated and signed by the responsible persons.
Evidence that satisfies it: dataset registers with provenance and labelling records, model cards or equivalent, architecture diagrams held under version control, design decision records, and the raw evaluation outputs — not a prose summary of them. Signed and dated test reports are named explicitly in Annex IV, so retrieving them should not require archaeology.
3. Monitoring, functioning, and control
The capabilities and limitations of the system, including its expected level of accuracy for the intended purpose and the accuracy figures for specific persons or groups where relevant; the foreseeable unintended outcomes and sources of risk to health, safety, fundamental rights, and discrimination; the human oversight measures in place, including the technical measures that make output interpretation easier for deployers; and, where applicable, specifications on input data.
Evidence that satisfies it: disaggregated performance results rather than a single headline accuracy number, a documented statement of known failure modes, and a description of the oversight controls as actually implemented in the interface.
4. Appropriateness of the performance metrics
A short but pointed requirement: explain why the metrics chosen are appropriate for this particular system and intended purpose. An F1 score is not self-justifying in a context where false negatives and false positives carry asymmetric consequences.
5. The risk management system
A detailed description of the risk management system established under Art. 9 — the identified risks, the risk management measures adopted, the residual risks judged acceptable, and the reasoning. This should read as an operating record, not a policy statement.
6. Relevant changes made through the lifecycle
A description of the changes made to the system over its lifecycle. This is the point that makes a one-off PDF structurally unable to comply: it is a running record by definition.
7. Harmonised standards applied
A list of the harmonised standards applied in full or in part, with references to the Official Journal; where no harmonised standard was applied, a detailed description of the solutions adopted to meet the Chapter III requirements, including a list of other relevant standards or technical specifications used.
8. Copy of the EU declaration of conformity
The declaration drawn up under Art. 47, referencing the system, the provider, the requirements met, and — where a notified body was involved — the certificate. It is a copy, so version alignment between the declaration and the documentation it points to matters.
9. Post-market monitoring
A detailed description of the system in place to evaluate the AI system's performance in the post-market phase, including the post-market monitoring plan required under Art. 72. The plan is part of the technical documentation, not an appendix to it.
What 'good enough' evidence looks like for each section
Authorities assess whether the documentation demonstrates compliance in a clear and comprehensible form. That is a substantive test, not a completeness checklist. The following pattern travels well across all nine Annex IV points.
- A claim: a plain statement of what is true about the system ("the model was validated on a held-out set of 41,000 records collected between March and September 2025").
- A source: a pointer to the underlying artefact — the evaluation notebook, the dataset register entry, the ticket, the signed test report — with an identifier that resolves.
- A date and an owner: who asserted this, when, and against which system version.
- A reconciliation: confirmation that the claim still holds for the version currently on the market, or a change record explaining what moved.
Documentation that carries all four for every point survives questioning. Documentation that carries only the first is a narrative, and narratives collapse when an assessor asks for the underlying numbers.
Step-by-step guidance on assembling each Annex IV point, and on mapping existing engineering artefacts to it, is in the Veritome Help Center (help.veritome.eu).
Why continuous assembly beats the pre-audit PDF
The common approach is to treat Annex IV as a deliverable: block two weeks, interview the engineers, write a document, export a PDF, file it. This fails for four structural reasons rather than for lack of effort.
- Art. 11 requires the documentation to be kept up to date. A PDF is stale the moment the next model version ships, and there is no mechanism that notices.
- Annex IV point 6 asks for changes across the lifecycle. Reconstructing a change history from memory months later produces an account that will not match the repository, and the mismatch is discoverable.
- Test logs and reports are required to be dated and signed. Retrospective drafting either omits them or produces summaries of results nobody can now locate.
- Post-market monitoring under Art. 72 produces a continuous stream of data. Documentation that cannot absorb it drifts away from the system it describes within a quarter.
The alternative is to make Annex IV a view over records the organisation already keeps. Most of the raw material exists: risk assessments, dataset provenance notes, evaluation runs, architecture diagrams, release tickets, incident reports, oversight design decisions. What is usually missing is the mapping — a stable link between each Annex IV point and the artefacts that satisfy it, so that when an artefact changes, the documentation reflects it without a rewrite.
- •Practically, this means three things for an SME with a handful of systems. Assign an owner per Annex IV point per system, so gaps have a name attached. Store the evidence where it is produced and reference it, rather than copying prose into a separate document that immediately diverges. And generate the assembled document on demand, so that the version handed to an assessor or a customer is the current state rather than a snapshot of some past intention.
Sequencing the work
- Confirm classification first. Establish whether each system is high-risk under Annex III or as a safety component under Annex I, and record the reasoning either way — including any Art. 6(3) assessment, which is itself documented and registered.
- Inventory what already exists. Map current engineering and governance artefacts against the nine Annex IV points before writing anything new.
- Close the largest gaps. In most SMEs these are dataset provenance and labelling records, disaggregated performance results, and the documented rationale for design choices.
- Stand up the risk management record under Art. 9 as a living log, since Annex IV point 5 draws directly on it.
- Write the post-market monitoring plan under Art. 72 and link it to the documentation rather than filing it separately.
- Set a trigger, not a calendar: any substantial modification, model retrain, change of intended purpose, or serious incident prompts a documentation review.
Obligations for high-risk AI systems under the Regulation apply from 2 August 2026, with a later date for high-risk systems that are safety components of products covered by the Union harmonisation legislation in Annex I. Systems already on the market before those dates are subject to separate transitional arrangements. Because Annex IV documentation has to exist before a system is placed on the market or put into service, the practical deadline for any system due to launch in 2026 is earlier than the headline date.
This article is general information about Regulation (EU) 2024/1689 and not legal advice. Where classification or conformity assessment route is genuinely unclear for a specific system, that judgement should be taken with qualified advice.