The EU AI Act is the first comprehensive law on artificial intelligence. It is written, like most regulation, for lawyers and compliance officers — which means the obligations land on engineers in a language we have to translate ourselves. Here is that translation: from legal text to the things you actually build.
Find your risk tier first
Nothing else makes sense until you know which tier your system falls into. The Act sorts AI systems into four:
- Prohibited — social scoring, certain biometric surveillance. Don't build these.
- High-risk — AI in hiring, credit, critical infrastructure, medical, and similar. This is where the heavy obligations live.
- Limited-risk (transparency) — chatbots, generative content. You owe users disclosure.
- Minimal — most other software. Few specific obligations.
Determine the tier before writing a requirement, because it sets the entire workload.
Transparency: this touches almost everyone shipping AI
If users interact with an AI system, you generally have to tell them. If you generate or manipulate content (text, image, audio), it has to be labelled as AI-generated in a machine-readable way. In engineering terms this is UI work plus metadata: a disclosure in the interface and a marker in the artifact's metadata. Cheap if designed in, awkward if retrofitted.
High-risk: the real work
If you are high-risk, the obligations become concrete system requirements:
- Risk management system — an ongoing, documented process, not a one-time sign-off.
- Data governance — training and validation data quality, with bias examined and recorded.
- Logging and traceability — the system must log enough to reconstruct why it produced a given output. In practice: an append-only decision log.
- Human oversight — a human must be able to intervene and override. That is an API and a UI seam you design deliberately.
- Accuracy, robustness, cybersecurity — measured and reported, not asserted.
Each of these is an architectural decision. "We'll add logging later" is how a high-risk system fails an assessment.
General-purpose AI models
If you provide a foundation/GPAI model, you owe technical documentation, a training-data summary, and a copyright policy. Models with systemic risk carry more. If you only use such a model through an API, most of this sits with the provider — but their terms become part of your compliance posture.
The engineer's translation
Notice the pattern, because it is the whole job: every legal obligation becomes a system requirement. Traceability becomes an append-only decision log. Human oversight becomes an override API. Transparency becomes a label plus metadata. Data governance becomes dataset lineage you can actually produce. Do this translation at design time and compliance is structural; do it later and it is a rescue mission.
Timelines are part of the spec
The Act's obligations phase in on different dates. A correct implementation is date-aware: it does not apply a rule before it is in force, and it does not miss the date when it becomes binding. Treat effective dates as data, not as a comment in the code.
I help teams translate the EU AI Act into system requirements — logging, oversight, and the architecture that makes them real. If you are staring at the Act wondering what to build, get in touch.