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

Annex IV of the EU AI Act: Which Points Need a Person?

Annex IV lists 9 points for your technical file. Which can your release records answer, and which need a person’s name?

XIN

IN 30 SECONDS

Annex IV is the list of nine points the EU AI Act technical file must cover at minimum. Release records can answer part of many points, but three are judgements a named person must write.

KEY TAKEAWAYS · 3

  • Annex IV lists nine top-level points. Your repository may hold only part of the answers.
  • Point 9 includes the Article 72(3) monitoring plan: people write it, the drift alerts are code.
  • The design rationale (point 2), the metric case (point 4) and the Article 9 risk system (point 5) need a named owner and a review date.
On this page

Annex IV in nine points, read as an engineer

IN SHORT Most of Annex IV asks about versions, data, design and tests, things your release records already partly hold.

WORDS TO KNOW

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.
Annex IV
The part of the Act that lists, in nine points, the minimum contents of the technical documentation.
Post-market monitoring plan
The provider’s written plan for watching how the system performs once it is on the market. Article 72(3) makes it part of the technical documentation.
9
TOP-LEVEL POINTS IN ANNEX IV
the contents page of the file

Source: EU AI Act, Annex IV

Article 11(1) says 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 holds at least these nine items, listed in Annex IV The part of the Act that lists, in nine points, the minimum contents of the technical documentation. See the glossary. Your repo may hold only part of the answers. Where the data came from, your procedures and other evidence may live elsewhere.

NINE POINTS, ONE REPOSITORY
1. General description
Intended purpose, provider, versions, how it is deployed, what it talks to
Service manifest and release tag
2. Elements and development process
Methods, architecture, design choices, data, human oversight, validation and testing, cybersecurity
Lockfiles, model registry, prompt versions, last eval run. Partly human
3. Monitoring, functioning and control
How the system is watched and controlled in operation
Alert rules, dashboards, the stop control
4. Appropriateness of the metrics
Why the chosen performance metrics are right for this system
Nowhere. A person writes it
5. Risk management system
The Article 9 risk process across the lifecycle
The risk register, if it lives in the repo. Still a judgement
6. Changes through the lifecycle
Relevant changes made over the system’s lifecycle
Tags and the log between two releases
7. Standards applied
Harmonised standards followed, or what you adopted instead
A short list you maintain
8. EU declaration of conformity
A copy of the Article 47 declaration, the provider’s written statement that the system meets the rules
The output of your conformity process
9. Post-market performance evaluation
How performance is evaluated in production, including the Article 72(3) plan
Drift alerts, plus a written plan on top
Source: Annex IV of the EU AI Act (consolidated to 27 July 2026 on EUR-Lex), checked against the Commission’s AI Act Service Desk and, where the Desk still showed old wording, the amending law. The right-hand column is an engineering mapping, not a legal reading of what any specific system owes.

Point 9 includes the Post-market monitoring plan The provider’s written plan for watching how the system performs once it is on the market. Article 72(3) makes it part of the technical documentation. See the glossary. That plan is written by people; the drift alerts under it are code.

Small firms get a lighter path. SMEs, start-ups included, and small mid-cap firms may hand in these items in a simpler form the Commission sets up. Notified bodies must accept it.

Coming up next: So which of the nine can no generator write?

Three Annex IV parts a person has to own

IN SHORT Three parts of Annex IV are judgements: the design rationale, the case for your metrics, and the risk management system.

Point 2 asks for the design specs: the general logic, the key choices with their reasons and assumptions, and the trade-offs.

A generator knows what you built, but not what you turned down, or why.

Point 4 asks why your performance metrics are the right ones. Your eval suite makes the numbers. Showing these are the right numbers for this system is a human argument, and reviewers will push on it hardest.

STEP BY STEP

Decide: Can the build generate this Annex IV point?Decision tree: Can the build generate this Annex IV point? If the answer is a fact in a record, then Generate it, every release. If the answer is why you chose this, then A person writes it, and signs it. If the answer is a judgement about risk, then The risk owner writes it.DECIDECan the build generate thisAnnex IV point?If the answer is a fact ina recordGenerate it, everyreleaseIf the answer is why youchose thisA person writes it,and signs itIf the answer is ajudgement about riskThe risk owner writesit

Step 1. Ask. For each point, the build asks: a fact in a record, or a judgement?

Pick a step to see it move
  1. Ask For each point, the build asks: a fact in a record, or a judgement?
  2. A fact Versions, dependencies, architecture, data provenance, test results, the diff since the last tag: generated every release, then checked against the source.
  3. A reason Point 2: the key choices, assumptions and trade-offs, including what you turned down. A person writes and signs them.
  4. A risk call Points 4 and 5: whether these metrics fit, and what risk was accepted. The build refuses to write them; the risk owner does.
The two lower branches are the judgement path, one per owner. On the middle one, a generated file fails quietly: it can describe the system accurately and still explain nothing.

Point 5 asks for the risk management system under Article 9. That’s a process with a person at the end of it, not a table you can compile.

IN PLAIN WORDS

The build can say what the system is. Only a person can say why it is built that way, and why its metrics and accepted risks are the right ones.

ITEM GET

Each judgement gets an owner

In this design, each judgement part gets a named owner and a review date, and a stale review blocks the release.

STAGE CLEAR

What you now know

  • Annex IV is a minimum list of nine points, and a repository may answer only part of them.
  • Points 2, 4 and 5 hold judgements, so a generated file can describe the system and still explain nothing.

Check yourself

Tap or click a question to see the answer.

Your eval suite prints accuracy on every release. Does that answer Annex IV point 4?

Not on its own. The scores can be generated; why these metrics fit this system is an argument a person writes.

Next stage:How does the build keep the file current, and when does it block a release?6 min
Adam Boudjemaa
Adam Boudjemaa

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. Building production AI and regulated Web3 systems.

Have a project to ship or a role to fill?

Discuss your project or role
LinkedInTwitterGitHub
Follow the engineering notes

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