The EU AI Act Technical File, Generated Not Written
KEY TAKEAWAYS
- Article 11 asks for documentation drawn up before the system is placed on the market and kept up to date. The second half of that sentence is what kills a hand-written file.
- Annex IV is nine points, and most of them are questions about versions, data, architecture and test results that your repository already answers. Render them from the build that runs your tests.
- Three things cannot be generated: why you made the design choices you made, why your performance metrics are the appropriate ones, and the risk management system under Article 9. Those need a person with a name and a review date.
- Article 19 puts a floor of at least six months on logs. Article 18 asks for the technical documentation to stay at the disposal of national competent authorities for ten years. Different objects, different clocks.
- Article 72 has applied since 2 August 2026 and its third paragraph points straight at Annex IV, while Article 11 itself sits in Chapter III Section 2, one of the sections deferred to 2027 or 2028.
Article 11 of the EU AI Act asks for a document. Annex IV tells you what has to be in it, in nine points. Almost nobody I know has one, including teams that already built every single thing those nine points describe.
I understand why. Writing it by hand is miserable, and the result is wrong within a week.
So do not write it. Render it. Most of Annex IV is a question about versions, data, architecture and test results, and your repository already knows the answers at a tag. The rest is judgement, and judgement needs a person with a name.
NOT LEGAL ADVICE
Not legal advice. This is documentation engineering from an AI and smart-contract engineer, current as of 6 August 2026. Every Article, Annex and date below comes from the consolidated text of the EU AI Act (Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744) on EUR-Lex. The provisions the Digital Omnibus amended were checked against that amending regulation as published in the Official Journal, because the Commission AI Act Service Desk states it has not yet been updated for it and still serves the pre-omnibus wording. Nothing here tells you whether your system is high-risk, and nothing here interprets the Act. Check EUR-Lex before you rely on any of it, and avoid the unofficial trackers: one of the most-cited was serving out-of-date text when I checked.
The document I wrote by hand, and why it failed
I have shipped the things Annex IV asks you to describe. Versioned prompts, a model registry, a frozen eval set, evidence-based abstention, an append-only record for every action, inside a fund where a wrong number costs real money.
What I did not have, for longer than I would like to admit, was one document describing the whole system in one place.
So I wrote one. Prompt versions, model ids, the retrieval index, the last eval run, the review path. It took an afternoon and it was accurate for about a week.
Then a model got swapped. Then the index was rebuilt. Then a prompt changed. Nobody touched the document, because updating it was not part of shipping.
That is the failure, and it is worth being precise about it. The problem was not that the documentation was hard to write. The problem was that it was written at all.
The system was already the right shape
Versioned prompts, a model registry, a frozen eval set, an audit record per action. Every fact Annex IV wants was somewhere in the repository.
I wrote the document by hand
One afternoon, one section per topic. Accurate on the day it was saved, which is the only day a hand-written system description is ever accurate.
The system moved and the document did not
A model swap, a rebuilt index, a prompt edit. None of them touched the document, because updating it was nobody's job on the release checklist.
It now described a version I no longer ran
A confident description of the wrong version is worse than an honest gap, because it looks finished. Nobody re-reads a document that looks finished.
Annex IV, read as an engineer
Annex IV is the contents page for the document Article 11 asks you to keep. Nine points.
Read them once as an engineer and something jumps out. Most of them are questions about a system you are already running, and the answers are already sitting in your repository under a version number.
If the Articles around this one are unfamiliar, start with the EU AI Act as an engineering checklist, which maps Articles 9 to 15 and 72 to code changes. This post is the one row that post left open.
Generate the file, do not write it
Here is the whole method. Treat the technical file as a build artifact with two halves.
The generated half reads the repository at a tag: model ids, prompt versions, index version, dependency tree, architecture, the last release-gating eval run. Facts. If a person retypes them, they are wrong by the next deploy.
The human half is short, and it is the part that carries weight. Why these design choices. Why these metrics are appropriate. What risk you accepted and who accepted it.
A generator that writes the second half is writing fiction, and it reads like fiction.
The eval numbers in the generated half are not new work. They are the same run described in the eval suite that gates a release, which produces the verdict. Annex IV is where that verdict finally gets written down.
The manifest that decides who writes what
You need one file that says which block answers which Annex IV point, and where each block comes from. That is the entire configuration. Everything else is a template and a build step.
Two fields do the real work. Here is the shape of a block.
Which of the nine Annex IV points this block answers. Every point needs at least one block, and point 2 takes two of them: the build describes the architecture, a person explains why it is that shape.
The field the whole design turns on. It decides who is allowed to write the block, and the generator refuses to cross the line.
The version this file describes. A technical file without a version describes a system in general, which is to say no system.
For a generated block, the paths and registries it read. This is how a reader verifies the file instead of trusting it.
For a human block, the person accountable for the words. Points 4 and 5 are judgements, and a judgement needs a name on it.
For a human block, when a person last confirmed it. Expired means the release is blocked, not that the file ships with a warning.
When the build produced the file. Article 11 asks for documentation kept up to date, so the date has to be the build date, not the author date.
# annex-iv.yaml -- the technical file as a build artifact, not a document.
# Each block names the Annex IV point it answers and who is allowed to write it.
# source: generated -> the build reads it from this repo, at this tag
# source: human -> a person owns the words and the build refuses to invent them
#
# Article 11(1) asks for documentation drawn up before the system is placed on
# the market AND kept up to date. The second half is what this file is for.
release_tag: reconciliation-agent@1.4.0
blocks:
- id: system_description
annex_iv_point: 1 # general description, purpose, versions, deployment form
source: generated
inputs: [service.manifest.yaml, git.tag, deploy/targets.yaml]
- id: build_and_architecture
annex_iv_point: 2 # elements and development process, architecture, data, tests
source: generated
inputs: [poetry.lock, models/registry.json, prompts/*.md, index/version.json]
- id: design_rationale
annex_iv_point: 2 # the key design choices, assumptions and trade-offs
source: human # a generator knows what you built, never what you rejected
owner: tech-lead
review_every_days: 90
- id: monitoring_and_control
annex_iv_point: 3 # monitoring, functioning and control in operation
source: generated
inputs: [alerts/rules.yaml, runbooks/kill-switch.md]
- id: metrics_rationale
annex_iv_point: 4 # why THESE performance metrics are the appropriate ones
source: human # the numbers generate; the argument for them does not
owner: risk-owner
review_every_days: 90
- id: risk_management
annex_iv_point: 5 # the Article 9 risk management system
source: human
owner: risk-owner
review_every_days: 90
- id: lifecycle_changes
annex_iv_point: 6 # relevant changes through the lifecycle
source: generated
inputs: [git.log(previous_tag..release_tag)]
- id: standards_applied
annex_iv_point: 7 # harmonised standards applied, or other solutions adopted
source: human
owner: tech-lead
review_every_days: 180
- id: declaration_of_conformity
annex_iv_point: 8 # a copy of the Article 47 EU declaration of conformity
source: human
owner: compliance
- id: post_market_evaluation
annex_iv_point: 9 # includes the Article 72(3) post-market monitoring plan
source: human # the plan is written; the drift alerts under it are code
owner: risk-owner
review_every_days: 90
gate:
block_release_if:
- a human block is past its review_every_days
- a generated block has no input resolvable at release_tag
- release_tag is missing
Read the `source` column top to bottom and you have the honest picture: four blocks the build produces, six a person owns. The count is not the argument. The four generated blocks are the ones that go stale between releases, and they are the ones nobody remembers to update by hand.
The `gate` block at the bottom is the part most teams skip, and it is the part that makes the file survive contact with a roadmap. A stale human section is a failed release, not a footnote in a wiki.
The three parts a human has to own
Three things in Annex IV cannot be generated, and pretending otherwise gets you a beautiful document that says nothing.
Point 2 asks for the design specifications: the general logic, the key design choices with their rationale and the assumptions behind them, and the trade-offs. A generator knows what you built. It has no idea what you rejected, or why.
Point 4 asks you to describe why your performance metrics are the appropriate ones. Your eval suite produces the numbers. The argument that these are the right numbers for this system is a human sentence, and it is the sentence a reviewer will push on hardest.
Point 5 asks for the risk management system under Article 9. That is a process with a person at the end of it, not a table you can compile.
Keeping it current is a build step
Article 11(1) does not only ask you to draw the documentation up. It asks you to keep it up to date. That clause is what kills a hand-written file, and it is also the clause a build step satisfies for free.
Put the generator in CI, next to the tests. Every release regenerates the file and diffs it against the previous one.
A generated block that moved is normal, that is just the system changing. A human block whose review date has expired is a release blocker.
Then ship the file attached to the tag. Version 1.4 gets version 1.4 documentation, not last quarter's document with a new date on the front.
This is the same discipline as the release gate that scores abstention, with a different output. One run emits a verdict, the other emits a document. Both are built, and neither is remembered.
What happens when someone asks
Everything above exists for one moment: somebody asks for the documentation, and you can produce it for the exact version that produced the thing they are asking about.
An auditor, a notified body, a client risk team. The question has the same shape every time, and it is a lookup rather than a scramble only if the output carries its version.
This is where the two halves of the evidence meet. the per-action audit record I write for an auditor names the release that produced a number. The technical file is what that release resolves to.
Two retention clocks get conflated constantly, so hold them apart.
Article 19 is about logs, and its floor is at least six months. Article 18 is about documents, and it asks providers to keep the technical documentation, along with the quality management system documentation, any notified body decisions and documents, and the Article 47 EU declaration of conformity, at the disposal of national competent authorities for ten years after the system is placed on the market or put into service.
Article 18 also carries a line worth re-reading if you work in finance. Providers that are financial institutions subject to EU financial services law keep the technical documentation as part of the documentation they already maintain under that law. It lands in a governance file you already run, rather than becoming a new one.
The reason to build this before any date is not virtue. It is that the generated half costs almost nothing once the build step exists, and the human half is three short sections that get sharper every time someone argues about them.
The teams that wait will write this in a hurry, from memory, about a version they no longer run. I would rather render it, badly at first, and improve the template.
That is the whole trade. Documentation you write is a snapshot of a system. Documentation you generate is the system, telling you what it is.
This file is one artifact on the larger map of how I build AI for regulated finance, and it is the one that turns everything else into something you can hand over.
FAQ
Article 11(1) asks the provider of a high-risk AI system to draw up technical documentation before that system is placed on the market or put into service, and to keep it up to date. It has to demonstrate compliance with the Chapter III, Section 2 requirements and give national competent authorities and notified bodies the information they need to assess that compliance, in a clear and comprehensive form. It must contain at a minimum the elements set out in Annex IV. There is also a lighter path: SMEs including start-ups, and small mid-cap enterprises, may provide those elements in a simplified manner using a form the Commission establishes, and notified bodies have to accept it.
Nine points. A general description of the system, its intended purpose, versions and how it is deployed. A detailed description of the elements and the development process, covering methods, architecture, data, human oversight measures, validation and testing, and cybersecurity. Information on monitoring, functioning and control. A description of why the performance metrics are the appropriate ones. The risk management system under Article 9. The relevant changes made through the lifecycle. The harmonised standards applied, or the other solutions adopted. A copy of the EU declaration of conformity under Article 47. And the system in place to evaluate performance after the system is on the market, including the post-market monitoring plan referred to in Article 72(3).
Most of it, yes. Versions, dependency trees, architecture, data provenance, the last release-gating eval run and the changes since the previous release are all facts sitting in a repository at a tag, and a build step reads them more reliably than a person retypes them. Three parts cannot be generated: the rationale and trade-offs behind your key design choices, the argument that your performance metrics are the appropriate ones, and the risk management system. Those are judgements. Give each an owner and a review date, and let the build refuse to ship when a review date has expired.
Article 11 sits in Chapter III, Section 2. Under the consolidated Article 113, Chapter III Sections 1 to 3, with the exception of Article 6(5), apply from 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those classified as high-risk under Article 6(1) and Annex I. Which branch covers a given system, if either does, is a legal classification and a question for a qualified lawyer, not for me. Worth knowing separately: Article 72 sits in Chapter IX, which was not carved out, so it has applied since 2 August 2026, and Article 72(3) says the post-market monitoring plan is part of the technical documentation referred to in Annex IV.
Article 18 asks providers to keep the technical documentation at the disposal of national competent authorities for ten years after the high-risk AI system has been placed on the market or put into service, alongside the quality management system documentation, any notified body decisions and documents, and the EU declaration of conformity under Article 47. Do not confuse that with logs: Article 19 is about the automatically generated logs and its floor is at least six months. One clock is for documents, the other is for records. Article 18 also says that providers which are financial institutions subject to EU financial services law keep the technical documentation as part of the documentation they already maintain under that law.
No. This is documentation engineering. It tells you how to produce and maintain a document whose contents the law specifies; it does not tell you whether the law applies to you, whether your system is high-risk, or how a regulator would read any of it. Get the classification and the interpretation from a lawyer, then use this to build the pipeline.
Enjoyed this post?
Get more like it in your inbox every Tuesday.