SKIP TO CONTENT
AI AGENTS6 minAgents in Production / Ep. 9 · Stage 9-1

EU AI Act Technical File: Which Parts Can Be Generated?

Your AI system has changed since its last release. Does its EU AI Act technical file still describe it?

XIN

IN 30 SECONDS

EU AI Act technical documentation is the file that describes a high-risk AI system and must show how it meets the Act. It must be kept up to date, so a build can generate the facts of each release while named people own the judgements.

KEY TAKEAWAYS · 3

  • Article 11 asks for technical documentation kept up to date, not written once.
  • Generate the version facts from each release where it helps, and check what the tool pulls out.
  • Design reasons, the metric case and the risk system stay with named people.
On this page

Why a hand-written technical file can go stale

IN SHORT A hand-written technical file still looks finished after the system changes, so its drift can go unnoticed unless someone owns its upkeep.

Take a made-up team. It writes a careful text about its AI system: the model, the prompts (the instructions given to the model), the search setup, the test scores. The text fits release 1.4 to the letter.

Then the system changes: a new model, a rebuilt search index, a prompt edit. If the document sits outside the release checks, it can keep describing 1.4. Nobody re-reads it.

TWO WAYS TO KEEP THE FILE

Written by hand

Describes release 1.4. The model, prompt and index change in 1.5. The document still says 1.4, and it looks finished.

Rendered at each release

Version facts are read from the release itself. Sections that need judgement carry an owner and a review date. A stale review blocks the release.
Illustrative. Either way, the file needs a maintenance process, and people still review what it says.

WATCH OUT

Not legal advice. This is documentation engineering by an AI and smart-contract engineer, current as of 6 August 2026. Nothing here tells you whether your system is high-risk, and nothing here interprets the Act.

Every Article, Annex and date here comes from the consolidated text of the EU AI Act on EUR-Lex: Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744. Check EUR-Lex before you rely on any of it.

I checked the changed parts against that amending law in the Official Journal. The Commission’s AI Act Service Desk said it had not been updated yet. Avoid unofficial tracker sites: one of the most-cited had out-of-date text when I checked.

Coming up next: So what is this file, and who has to write it?

What the technical file is, and who writes it

IN SHORT The technical file is the provider’s job, and it has to keep up with the system it describes.

Article 11(1) of the EU AI Act covers each High-risk AI system An AI system the Act classifies as high-risk, for example under Annex III. Whether yours is one is a legal question. See the glossary. Its Provider The person or organisation that develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark. See the glossary draws up a file before the system is placed on the market or put into service, and keeps it up to date. The Act calls it the Technical documentation The file Article 11 asks a provider to draw up before the system goes on the market or into service, then keep up to date. See the glossary.

WORDS TO KNOW

Provider
The person or organisation that develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark.
High-risk AI system
An AI system the Act classifies as high-risk, for example under Annex III. Whether yours is one is a legal question.
Technical documentation
The file Article 11 asks a provider to draw up before the system goes on the market or into service, then keep up to date.
Release tag
A label in version control, like 1.4.0, that marks the code and versioned settings of one release.

The file must show that the system meets the rules of Chapter III, Section 2. It must be clear and complete for national competent authorities and notified bodies. Annex IV sets its minimum contents.

ADAM says: Think of a food label printed from each batch’s recipe, not copied by hand. Where it breaks: Annex IV asks far more, several parts are judgements no printer can produce, and here a person re-confirms them on a schedule.

Coming up next: So which parts of that file can a build produce for you?

Which half of the file a build can generate

IN SHORT Treat the file as a build output with two halves: facts read from the release, and judgements a named person writes.

Everything starts from the Release tag A label in version control, like 1.4.0, that marks the code and versioned settings of one release. See the glossary: the file describes one version of one system.

Without a release tag, a technical file describes a system in general, which means no system in particular.

Generate the facts kept in trusted, versioned records: models, prompts, index settings, libraries, eval scores. Check what the tool pulls out. Don’t assume every fact is in Git, your version history.

STEP BY STEP

Flow diagram: 3 stepsFlow diagram: 3 steps. Tag the release, then Ask each block where its answer comes from. Ask each block where its answer comes from branches into 2: If a fact in a record, then Generate it. If a judgement, then Fetch the owner’s text. Both paths continue to Render one dated file under that tag.A FACT IN A RECORDA JUDGEMENT1Tag the release2Ask each block where itsanswer comes fromGenerate itFetch the owner’s text3Render one dated fileunder that tag

Step 1. Tag the release. The tag fixes the subject: the exact code and settings this file will describe.

Pick a step to see it move
  1. Tag the release The tag fixes the subject: the exact code and settings this file will describe.
  2. Ask where each answer comes from A manifest, a small config file, says, for each Annex IV point, whether the answer is a recorded fact or a judgement.
  3. Facts: generate them Versions, dependencies, architecture, the last eval run and the changes since the last tag are read from the release.
  4. Judgements: fetch the owner’s text Each judgement block comes from its owner. The build checks the review date and never writes the words.
  5. Render one dated file Both halves land in one document, stamped with its release and render date. The date alone doesn’t prove it is current: people still review it.
One release through the build. One Annex IV point can need both halves, so each block names its source and owner.

IN PLAIN WORDS

A generator may assemble reasons a person already signed off. It must not make up decisions, or take the place of the people who answer for them.

In production, I build document search, abstention (refusing to guess), evals (automated tests) and red-teaming (attacks on purpose). This build is my proposal for documenting such systems. I don’t claim a client used this exact Annex IV setup.

ITEM GET

Facts generate, judgements don’t

Version facts come from each release. The design rationale, the metric case and the risk system need a named owner and a review date.

STAGE CLEAR

What you now know

  • The file must follow the system as it changes, so a copy written once can drift.
  • A build can fill in what a release records; why the system is built that way still needs a person.

Check yourself

Tap or click a question to see the answer.

Illustrative case: your generator writes a neat paragraph on why you chose your model. Is that the generated half?

No. Why you chose it is a judgement. A person writes and approves it; the build may only fetch that approved text.

Next stage:Which of the nine Annex IV points can a build fill, and which need a person?6 min
Adam Boudjemaa
Adam Boudjemaa

Web3 x AI engineer, former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft.

Have a project to ship or a role to fill?

Discuss your project or role

My work at the web3 x AI intersectionOpen-source tools I build

LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.