Annex IV technical documentation, section by section

Providers of high-risk AI systems must draw up technical documentation before placing the system on the market or putting it into service, and keep it up to date (Art. 11(1)). Annex IV defines what the file must contain; Art. 18 requires the provider to keep it at the authorities' disposal for ten years after market placement. For Annex III systems the duty applies from 2 December 2027.

What Annex IV asks for

• A general description of the system — intended purpose, provider, version and how it relates to earlier versions, how it interacts with hardware and software, the forms it is placed on the market in, the instructions for use.
• A detailed description of its elements and the development process — methods and steps, use of pre-trained systems or third-party tools, design specifications and architecture, the training methodologies and the data used (provenance, scope, labelling, cleaning), the human-oversight measures needed, pre-determined changes, validation and testing procedures and their results, cybersecurity measures.
• Information on the monitoring, functioning and control of the system — capabilities and limitations, foreseeable unintended outcomes, human-oversight measures, input-data specifications.
• The appropriateness of the performance metrics.
• A description of the risk management system (Art. 9).
• Changes made through the lifecycle.
• The standards applied — harmonised standards or the alternative solutions used.
• A copy of the EU Declaration of Conformity (Art. 47).
• The post-market monitoring plan (Art. 72).

A provider that is an SME, a start-up or a small mid-cap (SMC) may supply the same content in the simplified form the Commission provides, and a notified body must accept that form (Art. 11(1), as amended by the Digital Omnibus).

How Veritome composes it

Each system has an Annex IV editor — opened from Documents (the per-system grid, one cell per system), from the system itself, or from Evidence → Generate document. It splits the file into eight guided sections: General Description, System Elements & Development Process, Training, Validation & Testing Data, Testing & Validation Results, Human Oversight Measures, Risk Management Summary, Cybersecurity Measures, and Pre-determined Changes & Continuous Learning.

The file is a composed document: every section carries the article it is composed from, and its draft is assembled from that obligation's answers — Art. 9 feeds the risk summary, Art. 10 the data section, Art. 14 the oversight section, Art. 15 the cybersecurity section. Composition is prefill, never overwrite: only empty fields are seeded, and what you wrote stays yours. The pre-determined-changes section has no obligation beneath it — it is your own account, written there and nowhere else. The Declaration of Conformity and the post-market plan have their own editors; reference them from the file rather than duplicating.

Synced to the obligation

The Art. 11 obligation tracks the Annex IV document: as the file is populated, the obligation's status follows, so the Documentation row and your completion figures reflect the real state of the file. The evidence links this creates are marked derived — composition made them, and they cannot be removed by hand, because deleting one would make the coverage meter lie.

Export, seal, keep

Export PDF renders an A4 technical file stamped with the system name and provider from the live record. Issuing it computes a SHA-256 fingerprint, writes it into the system's dossier chain-of-custody, mints a Generated evidence record, and appends the issue to the Issued archive with a ten-year retention floor stamped at that moment — a later reclassification cannot shorten a clock that already started. Re-generating the file later appends a new issue; the earlier one stays retrievable under its own hash, which is what an auditor opening the evidence filed against a March obligation needs to still read March's text.

Hash-sealed dossier records

The system's classification dossier is a tamper-evident chain: every submitted entry gets a SHA-256 fingerprint that folds in the previous entry's fingerprint, plus a verification ID. The Verify link on an entry opens a public verify page anyone can check without logging in, and issued documents carry their own fingerprint with the same public verification.