The EU AI Act in Practice — From Legal Text to Engineering Work

Posts 1–5 built the governance machinery; this post points it at the regulation most likely to shape AI engineering globally. The goal isn’t legal advice — it’s the engineer’s mental model: what does this law actually require me to build? The Act’s great virtue for that purpose is that it’s risk-based, so your first job is classification, and everything else follows from the tier.

The risk-tier structure

The Artificial Intelligence Act classifies AI systems by risk and scales obligations accordingly — exactly the tiering principle from post 1, now with legal force:

• Unacceptable risk — prohibited. A small set of uses are banned outright (e.g. social scoring by governments, certain manipulative or exploitative systems). The engineering implication is simple: don’t build these.
• High risk — heavily regulated. Systems used in sensitive domains (things affecting safety, or access to essentials like employment, credit, education, essential services, law enforcement). This is the tier that carries real engineering obligations (below), and the one most enterprise AI governance is built around.
• Limited risk — transparency obligations. Systems like chatbots and generative AI carry duties to disclose — users must know they’re interacting with AI, and AI-generated content should be marked. Mostly a “tell people” obligation.
• Minimal risk — largely unregulated. The vast majority (spam filters, recommendations) — no specific obligations, govern them to your own standard.

There are also specific duties for general-purpose AI / foundation models. The practical first move is therefore classification: determine which tier each system in your registry (post 1) falls into, because that single decision determines what you must do. Most of your effort will concentrate on the high-risk tier.

What “high-risk” requires — as engineering tasks

The Act’s high-risk obligations read like legal prose but map onto a concrete set of engineering and process controls — and the key realization is that a mature governance program already implements most of them. The main requirements, translated:

• Risk management system — a continuous process to identify and mitigate risks across the lifecycle. → This is your model-risk-management discipline (post 2).
• Data governance — training/validation data must be relevant, representative, and checked for bias. → Data quality and bias evaluation (post 5’s checks).
• Technical documentation — detailed records of how the system works, its purpose, and its limitations. → Model cards and design documentation, maintained (posts 2, 5).
• Record-keeping / logging — the system must automatically log its operation for traceability. → Observability, tracing, and the evidence trail (posts 5 and the LLMOps series), now a legal requirement, not just good practice.
• Transparency and instructions for use — deployers must be told how to use the system correctly and what its limits are. → Documentation aimed at the user/operator.
• Human oversight — the system must be designed so humans can oversee it, intervene, and override. → Human-in-the-loop controls (post 3’s agentic oversight), designed in.
• Accuracy, robustness, and cybersecurity — appropriate performance, resilience to errors and adversarial manipulation. → Evaluation, robustness and adversarial testing, and security controls.
• Conformity assessment and registration — high-risk systems must be assessed against these requirements (and in cases registered) before going to market. → Your evaluation gate and evidence (post 5), pointed at the Act’s criteria.

Seen this way, the Act is less a novel burden than a legally mandated version of the governance this series describes. The engineering work is to map each obligation to a control you can implement and gate on, and to generate the evidence that proves it — which is precisely what posts 4 and 5 build. Compliance becomes “encode these requirements as policy-as-code gates and let them produce the conformity evidence automatically.”

The engineer’s posture toward regulation

Two judgments make regulation tractable rather than paralyzing:

• Classify first, then scale effort to tier. The single most important action is determining each system’s risk tier, because the obligations are entirely tier-dependent. Pouring high-risk rigor onto a minimal-risk recommender wastes effort; missing that a hiring tool is high-risk is a serious failure. Tiering (post 1) is how you stay both compliant and proportionate.
• Build to the principles, not just one law. The EU AI Act is first but not alone — other jurisdictions are converging on similar risk-based ideas, and standards (like the NIST AI Risk Management Framework, the conceptual series’ topic) express the same controls voluntarily. A governance program built around the underlying principles — risk management, data quality, documentation, logging, human oversight, robustness, transparency — satisfies the Act and generalizes to the next regulation, instead of chasing each law separately. Build the controls once; map them to many regimes.

The honest caveat: this is an engineering mental model, not legal counsel — the Act has real legal nuance (definitions, timelines, obligations split between providers and deployers) where qualified legal and compliance partners are essential (post 1’s roles). But the engineer’s part is clear and implementable: classify by risk, map high-risk obligations to concrete controls, gate on them, and emit the evidence. Regulation stops being a fog and becomes a specification.

The takeaway: the EU AI Act is a risk-based law — unacceptable (prohibited: don’t build), high-risk (heavily regulated; where the engineering obligations concentrate), limited (transparency/disclosure for chatbots and generative content), and minimal (unregulated) — plus duties for general-purpose/foundation models, so the engineer’s first move is classification of each registered system. The high-risk obligations translate directly into controls a mature program already runs: risk-management system (post 2), data governance/bias checks, technical documentation (model cards), automatic logging (observability/evidence), transparency/instructions, human oversight (post 3), accuracy/robustness/cybersecurity testing, and conformity assessment (your eval gate + evidence, post 5). So the Act is largely a legally mandated version of this series’ governance — map each obligation to a policy-as-code gate (post 4) that produces conformity evidence automatically. The posture: classify first and scale effort to tier, and build to the underlying principles so you satisfy the Act and generalize to NIST RMF and future laws — while leaning on legal/compliance partners for the genuine legal nuance.

Key takeaways

• The EU AI Act (the Artificial Intelligence Act) is risk-based: unacceptable (prohibited — don’t build), high-risk (heavy obligations — sensitive domains like credit/employment/law enforcement), limited (transparency/disclosure — chatbots, generative content), minimal (unregulated — most systems), plus general-purpose/foundation-model duties — so the first engineering action is classifying each registered system’s tier (post 1).
• High-risk obligations map to concrete controls a mature program already has: risk-management system (MRM, post 2), data governance + bias checks, technical documentation (model cards), automatic logging/record-keeping (observability + evidence — now legally required), transparency/instructions, human oversight (designed-in intervention/override, post 3), accuracy/robustness/cybersecurity testing, and conformity assessment (your eval gate + evidence, post 5).
• The Act is therefore largely a legally mandated version of this series’ governance — implement by mapping each obligation to a policy-as-code gate (post 4) that emits conformity evidence automatically (post 5).
• Classify first, scale effort to tier: tiering keeps you both compliant and proportionate (don’t gold-plate a minimal-risk recommender; don’t miss that a hiring tool is high-risk).
• Build to the underlying principles, not one law: risk management, data quality, documentation, logging, human oversight, robustness, transparency satisfy the Act and generalize to NIST RMF and future regulations — build controls once, map to many regimes; and partner with legal/compliance (post 1) for the real legal nuance (this is an engineering model, not legal advice).

Further reading

• Artificial Intelligence Act — the EU’s risk-based AI law
• Regulation of artificial intelligence — the broader regulatory landscape