EU AI Act Article 11: Technical Documentation — What Actually Has to Be In It

The technical documentation file is the document a national competent authority or a notified body actually reads when they want to know whether a high-risk system is compliant — not a summary of compliance, but the underlying evidence. It has to exist, in substantially complete form, before the system is placed on the market or put into service, and it has to stay current afterward. Annex IV, which spells out what belongs in it, is genuinely long. But length isn't the real risk here. The real risk is when the file gets built.

What this document actually is, and when it has to exist

Treat "before market placement" literally. This isn't a file you start once a customer's security questionnaire asks for it, and it isn't something a compliance team can produce independently of engineering after the fact — building it requires access to decisions, data, and test results that only exist properly if someone captured them as they happened.

The real content categories Annex IV requires

Stripped of its numbered-list structure, Annex IV's content breaks into three practical groups.

General system description and design rationale

Who the provider is, the system's intended purpose, its versions, how it interacts with hardware and other systems, the forms it takes in the market (packaged software, API, embedded component), and — critically — the design rationale: the key choices made, the assumptions behind them, and what trade-offs were accepted, such as between accuracy and robustness. This is where "why did we build it this way" has to be answered in writing, not left as institutional memory.

Development process: methodology, training data, and test results

The methods and steps used to develop the system, including any third-party tools, pre-trained components, or datasets incorporated and how they were used or modified; the training methodology; the training data governance work required under Article 10; the validation and testing procedures actually used, including the metrics applied; and the results of that testing — explicitly including findings related to bias, potentially discriminatory impacts, and unexpected outcomes, not a sanitized summary that only reports favorable numbers.

Operational information: limitations, oversight measures, and metrics

The system's known capabilities and limitations across different circumstances, foreseeable sources of risk to health, safety, or fundamental rights, the human oversight measures in place, and the appropriateness of the performance metrics chosen for a system of this kind. This section also has to reference the Article 9 risk management system in detail, list which harmonized standards or technical specifications were applied, include a copy of the EU declaration of conformity, and describe the system in place for post-market performance monitoring.

Why assembling this after the fact is the expensive mistake

This is the part worth taking seriously before it becomes a problem: technical documentation built retroactively is a reconstruction exercise, not a documentation exercise, and reconstructions are worse on every dimension that matters. An engineer asked six months after the fact why a specific training data cutoff was chosen, or what trade-off justified a particular threshold, will often give an approximately-right answer built from memory and inference rather than an accurate record of the actual reasoning at the time — and an approximately-right answer in a document meant to demonstrate compliance is a real liability, not a rounding error. It's also simply more expensive: reconstructing a development history costs far more analyst and engineering time than capturing decisions as a normal part of the development process would have, because reconstruction requires first figuring out what happened before it can be written down, while incremental documentation only requires writing down what's already known.

The practical fix isn't complicated — it's discipline, not tooling. Design decisions get a one-paragraph rationale recorded when they're made, not reconstructed later. Test results get saved in full, including the runs that showed a problem, not just the ones that looked clean. Data governance findings from Article 10 get written down as they're produced rather than summarized from memory at documentation time. None of this is expensive to do once; all of it is expensive to redo after the fact.

What this looks like on a real system

Take a team building an AI-assisted diagnostic support tool over eighteen months. A team documenting incrementally has, by the time the system nears launch, a running record: why an earlier architecture was abandoned in month four, the actual validation results from three different testing rounds — including the second round that revealed a performance gap for a specific patient subgroup and the specific mitigation that followed — and the reasoning behind the accuracy threshold ultimately chosen. A team that deferred documentation until pre-launch has to reconstruct all of that from Slack messages, half-remembered meetings, and whichever engineers are still on the team, and predictably ends up with a file that's thinner on the uncomfortable findings (the subgroup performance gap, the abandoned approach) than on the parts that are easy to remember because they went well. Regulators reading a technical documentation file that reads suspiciously smooth have seen that pattern before.

How this connects to the rest of the file

Article 11 is deliberately a synthesis document — it doesn't generate new content so much as organize and present evidence that Articles 9 and 10 already require producing. If those upstream processes are treated as one-off exercises rather than the maintained processes they're supposed to be, Article 11 is where that gap becomes visible to an outside reviewer, in the same way Article 13's instructions for use expose gaps in logging or oversight design. For the classification step that determines whether a system needs any of this in the first place, see how Article 6 high-risk classification actually works.