Why Annex IV is more than a form
Under Article 11(1) of the EU AI Act, the technical documentation of a high-risk AI system must be drawn up before that system is placed on the market or put into service – and it must be kept up to date thereafter. The purpose is stated plainly: the documentation must demonstrate that the system complies with the requirements set out in the relevant section, in a manner that allows competent national authorities and notified bodies to assess this clearly and comprehensibly. Annex IV sets out the minimum information required for this. “At least” means it is not a menu from which providers pick and choose, but a baseline that must be covered in full, insofar as it is relevant to the system in question.
Organisations that leave documentation until shortly before conformity assessment usually underestimate the effort involved. Annex IV demands a level of technical depth that can only emerge from an ongoing development process – reconstructed after the fact, it tends to be error-prone and incomplete.
The core blocks of Annex IV
Annex IV is essentially structured around several layers:
- General system description (point 1): intended purpose, provider, versioning, interaction with hardware/software, form of deployment (embedded, downloadable, API), user interface and instructions for use for the deployer.
- Detailed development process (point 2): development methods, including the use of pre-trained systems from third parties; design specifications with the reasoning behind key decisions; system architecture and computational resources; data requirements (training datasets, provenance, labelling, cleaning); the assessment of human oversight measures under Article 14; pre-determined changes together with their technical safeguards; validation and testing procedures, including test logs and dated test reports signed by those responsible; and cybersecurity measures taken.
- Monitoring, functioning and control (point 3): capabilities and performance limitations – including breakdowns by affected groups of persons – foreseeable unintended outcomes and sources of risk to health, safety and fundamental rights, human oversight measures under Article 14, and specifications on input data.
- Performance metrics (point 4): why these particular metrics are appropriate for this system – not merely which ones were used.
- Risk management system (point 5): a detailed description in line with Article 9.
- Change history (point 6) and standards applied (point 7): harmonised standards, with the relevant reference published in the Official Journal, or, where none were applied, a detailed description of the alternative solutions adopted to meet the requirements of Chapter III, Section 2.
Common gaps in practice
Three patterns recur time and again:
First, insufficient depth of reasoning. Annex IV point 2(b) requires not just the design specifications but also the reasons and assumptions underlying the key decisions – for example regarding the groups of persons the system is intended to be used for, or the trade-offs made between competing requirements under Chapter III, Section 2. A pure architecture description without reasoned decisions does not satisfy this.
Second, the link to Article 9 and Article 14 is asserted rather than substantiated. Annex IV point 5 requires a detailed description of the risk management system, while point 2(e) and point 3 specifically require evidence of how human oversight measures were assessed and how they help deployers interpret the system’s outputs. A reference to an internal risk register is not enough unless it sets out exactly which measures were taken and why they are adequate.
Third, test reports are missing in the required form. Annex IV point 2(g) requires test reports that are dated and signed by the responsible persons – including for pre-determined changes under point (f). Informal test notes without signature or date do not meet the letter of the requirement.
Relief for SMEs
Article 11(1) provides that SMEs, including start-ups, may provide the elements of the technical documentation in a simplified manner. The Commission is to establish a simplified form for this purpose, which notified bodies must accept for conformity assessment purposes. This does not change the substantive scope of the requirements set out in Annex IV – it reduces the formal burden of presentation, not the substance of the content.
Important for combined products: where a high-risk AI system is placed on the market together with a product covered by the harmonisation legislation listed in Annex I, Section A, Article 11(2) requires a single set of technical documentation containing both the Annex IV information and the information required under the relevant product legislation – not two separate dossiers.
Where to start
Annex IV is not a document that can be written at the end of a project – it is a record of the development process that must be kept alongside it as work proceeds. If you are not yet sure whether your system even qualifies as high-risk AI under the AI Act, clarify that first: the free risk check at /einstufung gives you an initial classification before you commit resources to the documentation obligations under Article 11 and Annex IV.