EU AI Act Annex IV: every required section explained

Annex IV of the EU AI Act sets out what technical documentation a provider of a high-risk AI system has to produce before placing that system on the market, and keep current afterward. It's organized into distinct sections, each asking for a different kind of evidence. Here's what each one covers.

1. General description of the system

Its intended purpose, who develops and deploys it, its version, how it interacts with hardware or other software, and the forms in which it's placed on the market (software, embedded in a product, API, and so on).

2. Detailed description of the elements and development process

Design specifications, the system's architecture, the logic and algorithms used, key design choices and assumptions, and — for machine learning systems — details of the training methodology, data, and any human oversight built into training.

3. Monitoring, functioning, and control

Detailed information on the capabilities and limitations of the system, including expected accuracy against its intended purpose, foreseeable unintended outcomes, and the human-oversight measures in place — what a human can see, and what a human can do to intervene.

4. Performance metrics

The metrics used to measure accuracy, robustness, and cybersecurity, and the results of testing against those metrics, including testing on relevant subgroups where discriminatory impact is a concern.

5. Risk management

A description of the risk-management system required under Article 9: identified risks, the measures taken to mitigate them, and any residual risk that remains after mitigation.

6. Lifecycle changes

A description of relevant changes made to the system through its lifecycle — new versions, retraining, configuration changes — and why they were made.

7. Standards and conformity

The harmonized standards applied, or a description of the solutions adopted to meet the requirements where no standard was applied, plus a copy of the EU declaration of conformity where applicable.

Where the evidence for this actually lives

Sections 1 and 2 are largely design-time information — you likely already have it written down. Sections 3, 4, and 6 are different: they ask what the system actually does and how it behaves in production, which is operational evidence that lives in the system's runtime traces, not in its source code or design docs. That's the specific gap Attestly is built to close.