The technical documentation file usually gets written once, at launch, by whoever was free that quarter. Article 11 requires it to reflect the system as it currently runs. Those two facts are on a collision course, and it's usually a governance team, not engineering, that finds out first.
Under Regulation (EU) 2024/1689, Article 11 and Annex IV, providers of high-risk AI systems must keep technical documentation "up to date," not just produce it once before market entry. In practice, most Annex IV files are written in a sprint before a launch or an audit deadline, then left alone. The system keeps shipping changes: a retrained model, a new integration, a prompt template tweak, a vendor swap. The documentation doesn't move with it.
This is a familiar shape to anyone who has run a privacy program. It's the same failure mode that hits DPIAs and records of processing: accurate on the day they're signed, quietly wrong six months later, and nobody owns the job of noticing. Annex IV adds one more layer of difficulty, because unlike a DPIA, several of its sections (Sections 3, 5, 6, and 9 in particular) aren't asking for a description at all. They're asking for dated evidence: a specific test result, a risk register entry tied to a scan that surfaced it, a change log, a monitoring mechanism that actually ran on a schedule.
Engineering teams optimize for shipping; the documentation file isn't in their loop unless someone puts it there. Compliance and governance teams own the obligation, but they don't have first-hand access to what changed in a model pipeline or what a recent red-team scan found. The result is a structural gap: the people who generate the evidence (engineering, security testing) and the people who owe the up-to-date file (governance, legal) aren't the same people, and there's rarely a mechanism connecting them.
The standard fix teams reach for is a calendar reminder: "review the Annex IV file quarterly." That catches obvious drift but not the underlying problem, because a manual review still depends on someone remembering what changed and translating it into the right section, by hand, from memory rather than from a record.
The alternative isn't a smarter template, it's changing where the content of Sections 3, 5, 6, and 9 comes from. Instead of a person recalling what was tested and writing a summary, the entry cites the actual test output: a scan result with a date and a finding ID, a risk register row that points at the artifact that surfaced it, a change log entry generated at deploy time rather than reconstructed at audit time. The file becomes a pointer into a running record, not a document that has to be independently kept in sync with reality.
That's a smaller lift than it sounds like for teams that already run any kind of AI security or evaluation testing (prompt injection testing, red-teaming, adversarial evals), because the evidence already exists somewhere. The gap is almost always the translation step: getting that scan output into the shape Annex IV expects, mapped to the right section, instead of a person re-describing it in prose from memory a month later.
Before the next audit or internal review, it's worth asking three questions about your own Annex IV file:
If the honest answer to any of those is "we're not sure," the file is probably accurate for the day it was written and nothing since.
We're validating demand for a tool that takes scan or eval output (starting with our own Sentinel Scan results, expanding to other formats) and maps it directly into Annex IV Sections 2, 3, 5, 6, and 9, so the file cites dated evidence instead of a paraphrase written from memory. It's a waitlist right now, not a shipped product; we're building it if there's real demand from teams that already have evidence sitting in a JSON file with nowhere to go.
Sources cited: EU AI Act Annex IV, artificialintelligenceact.eu; Article 11 (technical documentation obligation, "kept up-to-date"); Article 113 for phased application dates.