Audit Readiness
Annex IV technical documentation: what a high-risk AI provider must have ready
Annex IV of the EU AI Act lists the minimum content of a high-risk system's technical documentation. Here are its nine points, who draws them up and when, how long they are kept and what a deployer receives instead.
Annex IV of the EU AI Act lists what the technical documentation of a high-risk AI system must contain at a minimum. Article 11 says when and why: the provider draws it up before the system is placed on the market or put into service, keeps it up to date, and writes it so that national competent authorities and notified bodies can assess whether the system meets the requirements for high-risk systems. Article 18 adds that the provider keeps it available to those authorities for ten years after the system is placed on the market or put into service.
For the high-risk uses listed in Annex III, these obligations apply from 2 December 2027, the date set by the Digital Omnibus on AI, Regulation (EU) 2026/1744. That amendment left Annex IV unchanged. SMEs, including start-ups, could already provide the Annex IV elements in a simplified manner under Article 11(1); the amendment extended that to small mid-cap enterprises, using a form the Commission is to establish.
The nine points
Each point applies as relevant to the system. The right-hand column is our suggestion for the records behind each point; Annex IV sets the content, not the source records.
| Point | What Annex IV asks for | Records it usually rests on |
|---|---|---|
| 1. General description | Intended purpose, provider, version; interaction with other hardware, software and AI systems; software versions and update requirements; the forms in which it is supplied; hardware; the user interface and instructions for use for the deployer | Product specification, release notes, the instructions for use |
| 2. Development | Development methods, including any third-party pre-trained systems or tools; design specifications and key choices with their rationale and assumptions; architecture and computing resources; data requirements, provenance and preparation; the assessment of human oversight measures; pre-determined changes; validation and testing, including accuracy, robustness and potentially discriminatory impacts; cybersecurity measures | Design records, data sheets, test plans and reports, oversight assessment, security review |
| 3. Monitoring, functioning and control | Capabilities and limitations, including accuracy for the groups of persons on which it is used; foreseeable unintended outcomes and sources of risk; human oversight measures and the technical measures that help deployers interpret outputs; input data specifications | Performance analysis by group, risk register, oversight design |
| 4. Performance metrics | Why the chosen metrics are appropriate for this system | Metric selection rationale |
| 5. Risk management | The risk management system under Article 9 | Risk management records |
| 6. Changes | Relevant changes the provider makes through the lifecycle | Change log tied to versions |
| 7. Standards | Harmonised standards applied, or the solutions adopted to meet the requirements and the other standards and specifications used | Standards mapping |
| 8. Declaration | A copy of the EU declaration of conformity (Article 47) | The declaration |
| 9. Post-market monitoring | The system for evaluating performance after placing on the market, including the post-market monitoring plan (Article 72) | Monitoring plan and results |
Point 2(g) is specific about testing: the documentation includes test logs and all test reports, dated and signed by the responsible persons, including for pre-determined changes.
What makes it hard
It has to be written while the system is built. Points 2 and 3 describe data provenance, design trade-offs, test results by group and the reasoning behind them. If those were not recorded during development, they cannot be reliably reconstructed when the documentation is due. A provider that starts in late 2027 may be describing decisions it no longer has records of.
It has to stay current. Article 11(1) requires the documentation to be kept up to date, and point 6 asks for the relevant changes through the lifecycle. Each version of the system needs documentation that matches it, and the record needs to show which version a statement refers to.
It mixes facts and judgments. Some points are factual: versions, hardware, the standards applied. Others are judgments: why a metric is appropriate, which risks are foreseeable, which trade-offs were acceptable. A reviewer needs to see which is which and who made each judgment, the same separation our audit-ready evidence packs note applies to compliance decisions.
What a deployer receives
Article 11 addresses the technical documentation to national competent authorities and notified bodies. What the Regulation gives the deployer is the instructions for use (Article 13): concise, complete, correct and clear information that includes the system's intended purpose, its accuracy and known limitations, the human oversight measures and how to collect and interpret the logs. Anything beyond that is a matter for the contract.
That changes if the deployer becomes a provider. Under Article 25(1), a deployer that puts its own name or trademark on a high-risk system, makes a substantial modification after which it remains high-risk, or changes the intended purpose of a system so that it becomes high-risk is treated as its provider. Article 25(2), as amended in July 2026, requires the initial provider to cooperate with the new provider and lists what that includes where relevant: technical documentation sufficient to assess compliance, information on known limitations and failure modes, and targeted technical access. That duty does not apply where the initial provider has clearly specified that its system is not to be changed into a high-risk system. For the deployer's own duties, see human oversight under the AI Act.
Where an evidence pack fits
An evidence pack can hold the records behind individual points, such as a test report, an oversight assessment or a change record, each with its source and the decision of the person who reviewed it. It does not replace the technical documentation, and it does not establish conformity.
Our initial scope is KYC/AML onboarding and EU AI Act risk assessment. For EU AI Act documentation, agents classify your AI system's risk level, prepare the Annex IV points they can, list what is missing, and assemble an evidence pack with regulatory references for reviewer approval. A workflow or evidence pack does not by itself establish compliance with a regulation.
For dates, roles and classification in one place, see EU AI Act documentation.
Agents do the work. Humans make the call.
Annex IV technical documentation is the provider's document. It is drawn up before the system is placed on the market, kept up to date and kept available to authorities for ten years.
Several points can only be written from records made during development, such as data provenance, test results and design choices. They cannot be reconstructed at the end.
A deployer receives instructions for use, not the technical documentation. A deployer that puts its name on or substantially modifies a high-risk system, or repurposes another system so that it becomes high-risk, becomes its provider and needs the documentation itself.
→Who has to draw up Annex IV technical 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 trademark (Articles 3(3) and 11). A deployer becomes a provider in the situations listed in Article 25(1).
→How long must the technical documentation be kept?
For ten years after the high-risk system has been placed on the market or put into service, at the disposal of the national competent authorities (Article 18(1)).
→Can a small company use a simpler format?
Yes. SMEs, including start-ups, could already provide the Annex IV elements in a simplified manner; the July 2026 amendment extended this to small mid-cap enterprises (SMCs). The simplified form is one the Commission is to establish for that purpose (Article 11(1)).
