If you provide a high-risk AI system, you must keep a technical documentation file that demonstrates the system complies with the Act. It is the evidence base regulators and notified bodies draw on — and Annex IV sets out, in detail, what it must contain.
The mistake is to treat it as a report written at the end. Built late, it is a fiction reconstructed from memory. Built alongside the system, it is simply a record of decisions you already made.
Why the file exists
The file lets someone outside your team verify that the system was designed, tested and monitored against the Act’s requirements. It is proportionate — what a small provider documents differs from a large one — but the core elements are fixed.
What goes in it
Broadly, the file should describe:
- The system: purpose, intended use, and how it works at a high level.
- Design choices, architecture and the data used for training, validation and testing.
- The risk-management system and the results of testing for accuracy, robustness and bias.
- Human oversight measures and the system’s limitations.
- Post-market monitoring and how changes are tracked over the lifecycle.
Build it as you go
Each item maps to a stage of development you are already doing. Capture the data lineage when you assemble the dataset; record the test results when you run them; note the oversight design when you build the interface. The file becomes an index into artefacts, not a separate writing project.
Documenting the system as it was at launch and never updating. The file must reflect the system as it is — including substantial changes. Tie updates to your change-management process.
Who owns it
It is cross-functional by nature: engineering owns architecture and testing, data owns lineage and quality, product owns intended use, and compliance assembles and reviews. Name a single owner for the file even though many contribute to it.
At conformity assessment
When the system goes through conformity assessment, this file is what gets examined. Keeping it current and linked to live evidence means assessment is verification, not archaeology. A single evidence layer keeps the artefacts the file references from going stale.
Key takeaways
- High-risk AI requires a technical documentation file demonstrating compliance.
- Annex IV is effectively a checklist — system description, data, testing, oversight, monitoring.
- Build it alongside development, not as an end-of-project report.
- Keep it current through change management; name a single owner.
Want your AI documentation structured from the start? Book a 30-minute demo.
This article is general guidance, not legal advice. Verify obligations and deadlines for your organisation with qualified counsel.