What EU AI Act Annex IV technical documentation actually requires
Annex IV is usually treated as a writing exercise. Read it closely and most sections are asking for records: what the system is, what was done to it, what it did, and what you monitored after deployment.
Article 11 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to draw up technical documentation before the system is placed on the market, and to keep it up to date. Annex IV specifies what that documentation contains.
Read as a checklist, it looks like nine essays. Read as an auditor would, most of it is a request for evidence that certain things happened, organised into nine headings.
The nine sections, in plain terms
- 1. General description. What the system is, its intended purpose, the provider, versions, and how it is deployed.
- 2. Development process. Design choices, training and validation, datasets used and their provenance.
- 3. Monitoring and control. How the system is operated and overseen, including human oversight under Articles 13 and 14.
- 4. Performance metrics. Accuracy, robustness, and the measurements that support them.
- 5. Risk management. The Article 9 risk management system and what it produced.
- 6. Lifecycle changes. Modifications made through the system's life.
- 7. Standards applied. Harmonised standards or other specifications relied on.
- 8. Declaration of conformity. The EU declaration itself, signed by the provider.
- 9. Post-market monitoring. The Article 72 plan and the data collected under it.
The part that is hard to retrofit
Sections 1, 7 and 8 can be written at any time. Sections 3, 4, 6 and 9 cannot, because they describe things that either happened or did not, at times that have already passed. If the operational record was not kept contemporaneously, the documentation ends up describing intentions rather than facts.
This is where most Annex IV packages are weakest: the prose is confident, and the evidence underneath is a database the provider could have written yesterday.
Evidence-first documentation
The alternative is to generate the documentation from attested records rather than alongside them. Each monitored event is signed when it happens and anchored to a public ledger; the Annex IV package is then rendered from those records, with every assertion in it traceable to an independently verifiable entry.
The practical difference shows up in review. A reviewer who doubts a claim in section 3 can resolve it themselves rather than requesting an export from the provider.
Check it yourself
Every Rubric attestation resolves publicly, with no account and no API key, and every anchor resolves to a public ledger message you can read without our cooperation.
HCS topic 0.0.10416909 · ML-DSA-65 signatures
Article 12 is the foundation
Annex IV section 3 leans on Article 12, which requires automatic recording of events over the system's lifetime. Annex IV describes the record; Article 12 requires it to exist. Institutions that solve Article 12 properly find Annex IV mostly assembles itself.
Retention
Article 18 requires documentation to be kept for ten years after the system is placed on the market. Ten years is long enough that the cryptography protecting the records matters. Rubric signs with ML-DSA-65 so that a decade-long retention obligation does not outlive the evidence's integrity guarantees.
Verifiable, not asserted
Rubric Protocol is a conformant C2PA Generator Product (Content Credentials 2.4, Assurance Level 1).
Record 01a002b7-3663-7b3b-a60e-db3b99ee2d94 · Echelon Intelligence Group LLC
Related: Article 12 record-keeping · How to prove an AI decision happened · Regulatory overview