The EU AI Act: what engineering teams actually have to build

Engineering guidance, not legal advice.

Most writing about the EU AI Act is aimed at legal and compliance teams. That leaves engineers with a set of obligations expressed in a vocabulary they do not use and no clear sense of what to build.

Here is the translation.

Article 9: risk management system

What it says: a continuous, iterative risk management process across the system’s lifecycle.

What you build: a living risk register tied to your actual system, listing identified risks, the mitigations in place, and the residual risk. Updated when the system changes, not annually. In practice this works best as a document in the repository, reviewed in the same cadence as architecture decisions.

Article 10: data governance

What it says: training, validation and testing data must be relevant, representative, and examined for bias.

What you build: documented provenance for every corpus in your retrieval index: where it came from, what it covers, what it does not cover, and the known gaps. For retrieval systems, the important and often-missed part is representativeness of your evaluation set: if it only contains questions from one department, you cannot claim system-wide performance.

Article 11 and Annex IV: technical documentation

What it says: documentation sufficient to assess conformity.

What you build: a system description, architecture, design choices and their rationale, performance metrics, and known limitations. Teams that keep architecture decision records are most of the way there already. Teams that do not will find this the most tedious part of the programme.

Article 12: logging

What it says: automatic recording of events over the system’s lifetime, enabling traceability.

What you build: for a retrieval system, that means the query, the retrieved passages and their identifiers, the model and configuration version, the output, the user and the timestamp. With a defined retention period that survives contact with your privacy team. Good tracing largely satisfies this.

Article 13: transparency and instructions for use

What it says: deployers must be able to interpret and use the output appropriately.

What you build: documentation of what the system does, what it does not do, its measured accuracy, its known failure modes, and the conditions under which it should not be relied on. The failure modes section is the one that matters and the one most likely to be written vaguely.

Article 14: human oversight

What it says: effective oversight by natural persons.

What you build: a human decision point on consequential outputs, with enough information presented for that person to actually exercise judgement, which means showing the retrieved sources rather than only the answer. Design against automation bias: an interface that shows a confident answer and an approve button produces rubber-stamping, and a regulator will say so.

Article 15: accuracy, robustness, cybersecurity

What it says: appropriate levels of accuracy, with declared metrics, plus robustness and security.

What you build: the evaluation harness. Declared metrics, a fixed test set, continuous measurement, adversarial testing including prompt injection, and monitoring for degradation. If you have built serious evaluation, this article is largely covered, and that is the strongest argument for doing evaluation work regardless of your classification.

The convergence

Read as a whole, the technical articles describe a system that is measured, logged, documented and supervised. That is not a regulatory invention; it is what a well-engineered system looks like.

The organisations finding the Act painful are generally the ones who shipped AI features without evaluation, tracing or documentation. The work they are doing now is work they needed anyway. The regulation set a deadline for it.