Technical documentation is not product documentation
The most common confusion is treating Annex IV as a regulatory version of the user manual. It isn't. The user manual explains how to operate the system; Annex IV technical documentation explains how it was built, with what data, under what assumptions, with what known limitations and what test results — and it has to hold up in front of a notified body or market surveillance authority that can ask for justification on any design decision.
That difference matters because it changes who has to write it. It's not a document a product or technical marketing team can draft alone: it needs direct input from the ML/engineering team (architecture, data, metrics), from whoever manages the training data (provenance, known biases), and from whoever designed the human oversight measures. Treating it as a one-person task is the most common cause of incomplete documentation.
The sections Annex IV requires
Annex IV lists the mandatory minimum content. In practice, it groups into six blocks:
| Block | What it must include |
|---|---|
| General description | Intended purpose, version, provider, interaction with hardware/software, forms in which it's placed on the market. |
| Design elements | System architecture, key algorithms and models, design choices and their justification, chosen architecture vs. discarded alternatives. |
| Training data | Provenance, scope, main characteristics, selection criteria, and how known biases in the data were addressed. |
| Human oversight | Technical and organisational oversight measures, including the technical capability to interpret the system's output. |
| Metrics and testing | Accuracy, robustness and cybersecurity levels, with the test procedures used to validate them. |
| Risk management system | Reference to the Article 9 process and how it relates to the decisions documented in the blocks above. |
The most common mistake: writing it once and forgetting it
Annex IV isn't a static document. Article 11 requires it to be kept up to date "throughout the system's lifecycle." That means every significant retraining, architecture change or expansion of intended use should trigger a review — not a full rewrite, but real version control, with a date, the reason for the change, and who approved it.
In practice, most teams that fail an audit don't fail because they lack documentation: they fail because what they have describes a version of the model from eight months ago, and no one can explain what changed since then or why. A simple version log — even just a table with date, model version, and a summary of the change — solves most of that risk.
How to structure it so you're not starting from zero every time
The most efficient way to manage Annex IV isn't a long prose document — it's a modular template where each block updates independently as what it describes changes. Training data changes on a different cadence than architecture; test metrics update with every new version; the general description barely changes at all. Separating these blocks avoids rewriting the entire document for every minor update, and lets each team (data, ML, product) maintain their part without depending on the others.
What to check this week
- Inventory of high-risk systems (existing or planned) that your company develops, substantially modifies, or for which it acts as provider.
- Locate who holds each piece of information: architecture and design decisions (ML/engineering), data provenance and biases (data team), human oversight measures (product/compliance), test metrics (QA/ML).
- Check whether version control exists for the documentation, or whether the latest version describes a model that's no longer in production.
- Define who approves each update to Annex IV when the model changes — it shouldn't be a single person without review.
Annex IV isn't a box to check once. It's the evidence your company will need to show if something goes wrong and an authority asks why the system was designed that way. The sooner a modular, updatable structure exists, the less last-minute work there'll be when that question comes.