---
title: The EU AI Act: what engineering teams actually have to build
source: https://rubradigital.com/insights/eu-ai-act-what-engineering-teams-actually-need-to-do
site: Rubra Digital
description: Past the legal summaries: the concrete instrumentation the EU AI Act requires, article by article, and how much of it good engineering already covers.
published: 2026-07-20
updated: 2026-07-20
author: Your Name
topic: governance
---

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

**Summary:** Most EU AI Act coverage is written for lawyers. This is the engineering view: which articles translate into logging, evaluation, documentation and oversight work, what each one concretely requires, and how much of it a well-run team is already doing.

_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.

## Frequently asked questions

### How much AI Act work is engineering versus legal?

Classification and interpretation are legal work and your counsel should own them. Almost everything after that is engineering: logging, evaluation evidence, data governance documentation, human oversight design and technical documentation. In the programmes I have run, the engineering share is the larger one by effort, and it is the part that cannot be delegated to an external adviser because it has to be built into the system.


---

Source: https://rubradigital.com/insights/eu-ai-act-what-engineering-teams-actually-need-to-do
Rubra Digital. Independent LLM and RAG consulting for regulated and document-heavy organisations in Europe and North America.
Contact: hello@rubradigital.com