Writing EU AI Act technical documentation that holds up

If your AI system falls under a high-risk category in Annex III of the EU AI Act, you owe a technical documentation package before it goes live. Article 11 and Annex IV set out what it contains: a description of the system, the data it was trained and tested on, its performance and its limits, the human oversight around it, and the monitoring you run after deployment. The package has to be current, and an assessor has to be able to follow it.

That second requirement is where most teams underestimate the job. The list of headings in Annex IV is short and readable, and a summary deck can hit every one of them. Producing evidence under each heading that a reviewer can trace back to a system, a dataset version, or an evaluation run is a different task. It is engineering work.

What Annex IV actually asks for

Annex IV is a nine-point structure. Read plainly, it wants:

• A general description of the system: intended purpose, the people who developed it, versions, and how it interacts with other software.
• The detail of how it was built: design choices, model architecture, the data, and the training methodology, including what you did about known limitations.
• Validation and testing: the metrics you used, the results, the boundaries of accuracy, and the logs that back them.
• The risk management system, mapped to Article 9.
• The changes you have made across the lifecycle and why.
• The harmonised standards you applied, or the technical solutions you used instead.
• A copy of the EU declaration of conformity.
• The post-market monitoring plan.

For a fintech system this is where abstractions get tested. “Description of the data” is not a paragraph. For a transaction monitoring model it means the source systems, how entity resolution was done, how you established point-in-time correctness, and what you did to keep training features free of lookahead. An assessor who knows the domain will ask how a feature computed from a full-quarter aggregate ended up in a model scoring an event mid-quarter. If your answer lives only in a data scientist’s head, the documentation does not hold up.

Assemble it as evidence

The failure mode we see most is a document written after the fact by someone describing what they believe the team did. It reads well. It does not survive a second question. The fix is to source each Annex IV section from a system of record and let the prose reference it.

Concretely, that means:

• Dataset descriptions pull from lineage. Every training and evaluation set carries a version, the queries or extracts that produced it, and a reconciliation back to the source ledger so the row counts and totals agree with the books.
• Model entries come from an inventory. The version in the documentation is the version registered, with the same identifier the change management and monitoring systems use.
• Performance sections attach the evaluation runs themselves: the eval set, the metrics on it, the confusion matrix, and where the false-positive budget was set for the alert queue a human works.
• The limitations section names the segments where accuracy drops. Thin-file customers, a new corridor, a product launched after the training cut. Say where the model is weak and what oversight covers that weakness.

When the documentation is assembled from these sources, updating it becomes a build step. A retrain produces a new dataset version, a new inventory entry, and a fresh evaluation run, and the corresponding sections regenerate. That is how you keep the “up to date” requirement in Article 11 from becoming a standing liability.

The risk management thread has to be real

Annex IV point 4 points at the Article 9 risk management system, and this is the part you cannot generate. Article 9 wants a continuous process: identify the risks the system poses, estimate them, decide what is acceptable, put measures in place, and check that the measures work once the thing is running.

For a credit or fraud model the honest version of this reads like an engineering post-mortem written in advance. What happens when the input data drifts. What a wrong decision costs a real person, and how they contest it. Where straight-through processing is allowed and where a human must sign. What the monitoring watches, at what thresholds it escalates, and who owns the pager. The audit trail that lets you reconstruct, months later, why a specific applicant got a specific decision.

Assessors read this section for whether the measures connect to the risks. A generic “the model is monitored for drift” earns a follow-up: monitored on which features, against which reference window, and what happens at quarter-end when volumes shift for reasons that have nothing to do with the model. If your monitoring plan answers that, the documentation is doing its job. If it does not, the gap is in the system, and the document has only made it visible.

Where the package usually breaks

Three things tend to be missing when we open a draft. The data lineage does not reconcile, so the “description of the data” cannot be proven. The evaluation numbers in the document match no stored run, because they were retyped from a notebook that has since changed. And the human oversight described on paper is not the oversight that exists in production, where the queue was silently switched to auto-clear under load.

Each of these is fixable, and each is cheaper to fix as a system property than as a document edit. Build the lineage so the data section proves itself. Register models so the version in the file is the version in production. Log the evaluation runs so the numbers become citations you can point at. Do that, and Annex IV becomes a report you regenerate on demand, which is what it needs to be when someone comes to check.