Evidence and documentation
EU AI Act Annex IV explained section by section
Annex IV of the EU AI Act lists what the technical documentation of a high-risk AI system must contain: nine points, from a general description of the system to its post-market monitoring plan. The provider draws it up before the system reaches the market and keeps it current, and an authority reads it to judge whether the system complies.
Article 11 sets the duty.
The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service and shall be kept up-to date. (Article 11(1))
Two words matter in that sentence: "before" and "up to date". The documentation is not a launch deliverable. It follows every version of the system, which is why it is easier to build as evidence than to write as prose.
Who needs it and when
The duty sits with providers of high-risk systems. That means the use cases of Annex III, such as hiring, exam grading and the essential services the Annex III guide lists, and safety components of products regulated under Annex I. Deployers do not draw it up, but they will ask their vendors for it, and they carry duties of their own, set out in the deployer guide.
The Digital Omnibus, Regulation (EU) 2026/1744, has been in force since 27 July 2026. Under it, the high-risk chapter applies from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I products. Most of Annex IV cannot be rebuilt after the fact, so the records should start now. One adjustment is worth knowing: Article 11(1) lets SMEs, start-ups and small mid-caps use a simplified form the Commission is to establish.
The nine points at a glance
The nine points one by one
1. A general description of the system
This point asks for the intended purpose, the provider's name, the version and how it relates to earlier ones, the forms in which the system is supplied, the hardware it runs on, the user interface and the instructions for use. Annex IV also asks how the system connects to the rest of your IT systems.
how the AI system interacts with, or can be used to interact with, hardware or software, including with other AI systems, that are not part of the AI system itself, where applicable (Annex IV, point 1(b))
For an agent, that interaction is the set of tools and APIs it can reach. Keep this section short, but versioned: the description must match the system that is running.
2. The elements of the system and its development
This is the longest section: design choices and their trade-offs, the architecture, the data and its provenance, the human oversight measures (Article 14), and how the system was validated and tested.
the validation and testing procedures used, including information about the validation and testing data used and their main characteristics ... test logs and all test reports dated and signed by the responsible persons (Annex IV, point 2(g))
The regulation asks for a trace, not a claim: dated logs and reports, signed by the people responsible. For a system built on a third-party model, document what you control (prompts, the documents it looks things up in, tools, guardrails) and point to the model vendor's documentation for the rest.
3. Monitoring, functioning and control
This point covers capabilities and known limits, foreseeable risks, the conditions that degrade performance, and the measures that let a person interpret and oversee the output. An honest list of limits protects you. A file that admits no failure mode reads as untested, not as safe.
4. The performance metrics
This point asks not only for the metrics but for why they are the right ones for the purpose and the people affected. An agent judged only on the accuracy of its answers, never on how it refuses or how it discloses that it is an AI, leaves a gap a reader will notice.
5. The risk management system
The Article 9 process: how risks were identified, estimated and evaluated, and which measures were adopted. The practical evidence is a risk register with dates and owners, each mitigation linked to the test that shows it works.
6. Changes through the lifecycle
A description of relevant changes made by the provider to the system through its lifecycle (Annex IV, point 6)
A new model, a revised prompt, a new tool or an updated knowledge base can each void earlier test results. Keep the change log and the re-test log together.
7. Harmonised standards applied
This point asks for the list of harmonised standards applied, or a description of the solutions adopted where none was applied. No harmonised standard has been cited in the Official Journal, so there is no presumption of conformity. You will describe your solutions, and nobody can certify the system against a standard today.
8. The EU declaration of conformity
This point asks for a copy of the declaration of conformity (Article 47), once the conformity assessment is done.
9. The post-market monitoring plan
A detailed description of the system in place to evaluate the AI system performance in the post-market phase in accordance with Article 72, including the post-market monitoring plan referred to in Article 72(3). (Annex IV, point 9)
The plan says how the provider will collect experience from real use, incidents and complaints, and feed it back into risk management. The Commission is to adopt guidance, including a template for the plan, by 2 September 2027. For an agent, this is where re-testing on a schedule belongs.
From a folder of documents to evidence
Four properties separate a shared drive from documentation that survives review:
- Traceability. Every claim points to its source: the registration, the test run, the reviewer's decision. "Human oversight is ensured" is a sentence, but a referral observed in a logged test is evidence.
- Immutability. Decisions and issued packs cannot be edited. A document that can be quietly corrected loses its value as evidence.
- Versioning. Each result names the system version, the test plan and the judge (the model that grades each reply) that produced it, so it can be explained months later.
- Citations. Each element cites the obligation it answers, so the reader does not have to make the link.
The files that fail review fail the same way: documentation written once for launch and never updated, test results tied to no version, oversight described in the design and contradicted by the logs, risk registers with no dates and no owners. These are process problems, so a writing sprint before a deadline does not fix them.
How Vidimus builds the evidence pack
Vidimus builds the pack from what it already holds: your registration answers, the classification, every test with its pass rate and one quoted reply (with its attempt number and tool calls), the reviewer's decision and the audit trail. Every attempt's reply stays in the run report and the per-attempt CSV export. The pack is organised by obligation, not by Annex IV point. It cites every obligation, including Annex IV's documentation duties, and says for each whether it was tested on the live agent or checked against your documents, passage by passage.
Each behaviour test is sent ten times, and the finding is a pass rate, as how we test explains. The pack is signed: with its line from your evidence register and our published key, your auditor can check it offline. A specimen is on the evidence pack page. What a pack must hold to convince an auditor is covered in the evidence pack primer, and the controls specific to agents in the control framework for agentic AI.
To see whether your agent is high-risk, and so needs Annex IV documentation, run the AI Act risk classifier.
Quick answers
Does a deployer have to write Annex IV documentation?
No. The provider draws it up. A deployer asks its vendor for the parts it needs, such as the instructions for use, and keeps its own records under Article 26.
When does Annex IV apply?
With the high-risk chapter: from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I products, under Article 113 as amended by Regulation (EU) 2026/1744.
Can Vidimus write our technical documentation?
No. Vidimus produces the test evidence and checks your documents against each obligation, passage by passage. The design, data and risk management descriptions stay yours.
Is the Vidimus evidence pack organised by Annex IV point?
No. It is organised by obligation. It cites every obligation, including the documentation duties of Annex IV, and says for each whether it was tested on the agent or checked in your documents.
Can anyone certify our documentation today?
No. No harmonised standard has been cited in the Official Journal, so there is no presumption of conformity. Vidimus is not a notified body.
Sources
Vidimus tests your agent’s behaviour, ten attempts per test, and files the results with your documents in a signed evidence pack.