EU AI Act Compliance — chapter audio overview

Podcast Script: EU AI Act Compliance Host: Welcome back to the GenAI Evaluation, Safety and Governance course. This is Chapter 20 of 25, and today we're tackling something that has shifted from a future planning exercise to an active legal obligation: EU AI Act Compliance. If your organization has invested in building real GenAI capability, this is exactly the kind of topic that separates engineers who ship prototypes from engineers who ship production systems that can legally operate in the European market. In the last chapter we mapped the threat landscape using the OWASP LLM Top Ten and MITRE ATLAS — the security and safety risks that actually hit LLM applications. Now the question is: how do those risks translate into regulatory obligations that carry real penalties? Picture this scenario while you drive. Your team just deployed a resume-screening assistant for the European division. It works beautifully. But as of February 2025, that system has legal obligations attached to it — and missing them can cost up to thirty-five million euros or seven percent of global annual turnover. You'll practice this across six hands-on exercises. But first, let's build the mental model. We'll walk through risk classification, AI literacy, documentation for general-purpose models, risk management, human oversight, and the enforcement timeline that's ticking right now. Expert: Let's start with what the EU AI Act actually is and why its structure matters. The EU AI Act — formally Regulation 2024/1689 — is the world's first comprehensive law governing artificial intelligence. It was adopted in June 2024, and its enforcement doesn't happen all at once. It rolls out in phases, and some of those phases are already live. The core design choice the lawmakers made is a four-tier risk classification system. Think of it like a pyramid. At the very top, a narrow set of practices are completely banned — these are called "unacceptable risk." Below that sits the high-risk tier, where systems face the most extensive requirements. Below that, limited-risk systems need only satisfy transparency obligations. And at the base, minimal-risk systems have no mandatory requirements at all. The tier your system falls into determines everything else about your compliance work. Now let's make the top of that pyramid concrete. Unacceptable-risk practices — banned since February 2, 2025 — include things like social scoring by governments, where an AI assigns a trustworthiness score to people based on their behavior. Real-time biometric identification in public spaces for law enforcement is prohibited with very narrow exceptions. Subliminal or manipulative techniques that materially distort behavior are banned. Systems exploiting vulnerabilities of specific groups due to age or disability are banned. And emotion recognition in workplaces and schools is prohibited. If you deploy any of these, you're not out of compliance — you're operating an illegal system. The penalty is up to thirty-five million euros or seven percent of global turnover. The next tier down — high-risk — covers things like CV screening, credit scoring, medical diagnosis, insurance pricing, criminal risk assessment, border control, education admissions, and judicial decision support. These are listed in what the Act calls Annex III, which is essentially a registry of use cases the regulators consider high-stakes. High-risk systems must comply with a whole stack of articles — risk management under Article 9, data governance under Article 10, technical documentation under Article 11, human oversight under Article 14, and accuracy and robustness under Article 15. The deadline for full high-risk compliance is August 2026. Below that, limited-risk is mostly about transparency — a chatbot must tell users they're talking to an AI, a deepfake generator must label synthetic content. And minimal-risk systems like spam filters face no mandatory rules. Now, there's a special category that sits alongside this pyramid: General-Purpose AI, or GPAI. These are models like GPT-4o, Gemini, and Claude — trained on broad data, capable of many tasks. GPAI models have their own obligations under a dedicated title of the Act, and here's the critical point for working engineers: even if you just call these models through an API, you are a "deployer," and deployers have documentation obligations too. You can't hide behind the model provider. Host: Okay, so the mental model is a four-tier pyramid with GPAI as a special track alongside it. Classify first, then the obligations follow. Let's unpack the two obligations that are already enforceable today — AI literacy for your people, and technical documentation for the models you use. What does that actually look like in code? Expert: Great framing. Let's take AI literacy first, because this one surprises people. Article 4 of the EU AI Act, which has been binding law since February 2, 2025, says that organizations must ensure every person who operates, deploys, or uses AI systems has sufficient AI competence. "Competence" is deliberately contextual — it considers the person's technical knowledge, their experience, their education, and the specific context in which they use the AI system. So a developer writing prompts for an LLM needs different skills than an executive approving a deployment. To turn this into real infrastructure, you build what the reading calls a literacy assessment platform. Conceptually, it has three moving parts. First, role-specific assessment modules — one for developers, one for operators, one for executives, one for end users. Each module defines its own knowledge domains, its own practical exercises, and its own passing threshold. A developer module might test prompt injection awareness and hallucination detection with a threshold of seventy-five percent. An executive module tests governance and regulatory understanding with a threshold of sixty-five percent. Second, a certification record for each person — storing who was assessed, what score they got, whether they passed, and when their certification expires. Annual recertification is the norm. Third, a compliance dashboard that shows completion rates by department, because what regulators expect to see is not just that training exists, but that it's being consistently completed and kept current. Now let's move to the GPAI technical documentation track. This obligation came into force on August 2, 2025. If your team uses hosted models through an API — which most teams do — you still have to maintain structured documentation. The reading identifies six mandatory sections. Model information: which model, which provider, which version, which API endpoint, which capabilities, and critically, the known limitations. Intended use and limitations: what the system is designed for and, just as importantly, what it isn't. Data governance: the evaluation datasets you used, whether dataset cards exist, how you handle personally identifiable information. Performance metrics: the actual evaluation scores, fairness measurements, methodology, and benchmark comparisons. Risk assessment: the due diligence narrative showing you've thought about what could go wrong. And energy consumption estimates — the EU cares about sustainability, so compute usage has to be reported. Here's the production insight that matters: this documentation is not a one-time artifact. The Act requires it to be kept up to date. Every time you change the model — switching from one version of GPT to another, updating your evaluation datasets, modifying your guardrails — you generate a new documentation version. That means you need a version tracker that captures what changed, why it changed, who authorized the change, and a full snapshot of the document at that point in time. Think of it like git commits, but for your regulatory paperwork. When the AI Office — that's the EU body overseeing GPAI compliance — requests your documentation, you don't just hand them the latest version. You hand them the history, because that history is evidence that you've been doing this continuously, not cramming the night before an audit. Host: That version history framing is powerful — your documentation has to tell a story of continuous care, not a point-in-time snapshot. Now let's connect this to something we built earlier in the course: all those risks we identified — hallucination, PII leakage, bias, prompt injection. How does the Act force us to treat those formally? Expert: This is where Article 9 enters the picture, and it's one of the most operationally demanding parts of the Act. Article 9 requires high-risk AI systems to implement a risk management system that operates continuously across the entire lifecycle. The word "continuously" is doing a lot of work here. This is not a risk assessment you do once at launch. It's an iterative process — identify risks, analyze likelihood and impact, implement mitigations, monitor residual risk, review periodically, and repeat. The core data structure is something called a risk registry. Every identified risk gets an entry with several required fields. A unique identifier. A category — typically safety, fairness, transparency, security, or privacy. A natural-language description so a non-engineer reviewer can understand it. A likelihood score from one to five — how likely is this risk to materialize? An impact score from one to five — if it does materialize, how bad is it? A computed risk score, which is simply likelihood multiplied by impact. From that score you derive a risk level — critical if the score is twenty or above, high for twelve through nineteen, medium for six through eleven, low for one through five. Then the most important field: the mitigation reference. This is what connects regulation to engineering. If you identify "hallucination causing harm" as a risk, you can't just write "we have mitigations." You have to reference the specific technical control — the evaluation harness from Chapter 2, the guardrail from Chapter 8, the monitoring alert from Chapter 17 — whatever actually reduces the risk. This creates a traceable chain from the risk to the defense. Each entry also carries a residual risk description — what's left after mitigation — and a scheduled review date, typically ninety days out for quarterly reviews. The review workflow itself is structured. A review isn't a meeting where someone says "looks fine." It's a record with the previous likelihood and impact scores, the new likelihood and impact scores, a rationale for any change, and action items for any risk whose score increased. That structure matters because it creates trend data. Over time, you can see whether your risk posture is improving or degrading. Now, the practical beauty of this is that every risk you've already encountered in this course maps neatly onto the registry. Hallucination maps to the safety category with your evaluation work as the mitigation reference. PII leakage maps to privacy with the data redaction system as the reference. Bias in responses maps to fairness with the fairness evaluation suite as the reference. Prompt injection maps to security with the guardrail layer as the reference. So the work you've already done doesn't get thrown away. It gets formally registered, scored, linked, and reviewed on a schedule. One warning the reading is emphatic about: do not rely on someone remembering to schedule quarterly reviews. Build automated reminders, calendar events, escalation workflows. A review that depends on human memory is a review that will be missed, and a missed review is a compliance gap. Host: So the risk registry turns all our earlier engineering work into a regulatory asset — nothing wasted, everything cross-referenced. Now Article 14 mentions human oversight. What does that actually mean in a production system that's processing thousands of requests per minute? Expert: Article 14 is where a lot of teams underestimate the engineering lift. The Act says high-risk systems must be designed with human oversight measures that let natural persons effectively oversee the system's functioning. "Effectively" is the operative word. A dashboard with pretty charts does not satisfy Article 14. You need concrete controls. The Act specifies three levels of oversight. Human-in-the-loop — a human approves every single decision. Human-on-the-loop — a human monitors in real time and can intervene. Human-in-command — a human can override at any moment and shut the system down entirely. Most production systems use a mixture, and the two foundational controls you need to build are an emergency stop and a confidence-based review queue. Let's start with emergency stop. This is the ability to immediately halt all AI processing across your system. When activated, the proxy connections to your LLM provider are disabled, new requests stop being accepted, in-flight requests are drained or cancelled, and fallback responses are returned that don't depend on the AI at all. The crucial architectural insight from the reading is this: the emergency stop must be a separate, independently-deployed service. Why? Because if your AI system is sick, the oversight mechanism that halts it cannot be running in the same process. If the main system crashes, you need the stop mechanism to still be reachable. Every activation and restart is recorded with the administrator identifier, the reason, and timestamps — that's the audit trail Article 14 expects to see. Now the second control: confidence-based routing. The Act requires humans to be able to intervene in high-risk decisions, but it does not require every decision to be manually reviewed. That would be impractical at scale. So you build a three-tier routing system driven by the confidence score of each AI decision. High confidence — above 0.95 — auto-approves with periodic spot-check sampling. Medium confidence — between 0.7 and 0.95 — gets flagged for regular spot-checking. Low confidence — below 0.7 — is held in a review queue and requires explicit human approval before being delivered to the end user. The queue itself tracks each decision's content, confidence score, routing status, and, if a human overrode the AI, the replacement content. Every override gets its own audit record showing the original AI content, the human replacement, and the reason. The dashboard then computes the metrics Article 14 implicitly requires — total decisions, routing distribution, override rate, and current queue depth. One critical gotcha from the reading: those thresholds — 0.95 and 0.7 — are starting points, not final answers. You must calibrate them against actual decision quality data. If your override rate in the spot-check tier is consistently high, your threshold is too low. If your review queue is always empty, your threshold is too high. Calibration is an ongoing engineering task, not a configuration you set once and forget. Host: Emergency stop as a separate service, confidence-tiered routing, and calibrated thresholds — three concrete mechanisms rather than a dashboard theater. Last big piece: how do we track our readiness against the enforcement timeline so nothing slips through the cracks? Expert: The enforcement timeline has four major milestones, and each one activates a specific set of obligations. February 2, 2025 — prohibited practice bans and the Article 4 AI literacy obligation went live. August 2, 2025 — GPAI model obligations including technical documentation came into force. February 2, 2026 — post-market monitoring requirements activate, meaning you must continuously surveil your deployed systems for incidents. August 2, 2026 — the full high-risk regime activates, including conformity assessment, risk management system, human oversight, and data governance. Missing a milestone doesn't mean you have extra time. It means you are already non-compliant and penalties are enforceable. So what you build is a compliance tracker. Structurally, it's a list of milestones, each containing a list of specific compliance requirements. Each requirement has an identifier, a description of what it demands, a reference to the specific Act article, a status field — compliant, non-compliant, partial, or not assessed — a list of evidence links pointing to supporting documentation, a remediation priority from zero to five, and the date it was last verified. The tracker runs automated checks wherever possible. Does a disclosure log exist? Is the technical documentation file present and up to date? Is the monitoring endpoint responding? Has the risk registry been reviewed within the required interval? Automated checks are vastly better than manual attestation because they produce fresh evidence on every run. The most actionable output is the gap analysis report. It identifies non-compliant and partially-compliant requirements, sorts them by proximity to their enforcement deadline, and suggests remediation steps. Anything past its deadline but still non-compliant gets top priority because that's active regulatory exposure. Let me close this section with the production wisdom that ties everything together. If you remember nothing else from this chapter, remember these three things. One: audit logs must be immutable. Store them in append-only tables with no update or delete permissions, or use cryptographic hash chains. If a regulator finds your audit log can be edited after the fact, your entire compliance record becomes suspect. Two: the EU AI Act applies based on who the system affects, not where your company is headquartered. If your application touches EU citizens, you're in scope regardless of your office address. Build jurisdiction-aware routing. Three: retention is ten years minimum for high-risk AI system documentation. Design archival and purge protection from day one — retrofitting retention policies later is painful and expensive. And the single biggest "don't" from the reading: don't treat the EU AI Act as a future problem. The February 2025 and August 2025 obligations are live. Organizations operating AI systems affecting EU citizens must be compliant now, not planning to be compliant later. Host: Perfect setup for the exercises. You'll practice six objectives hands-on, and each one maps directly to what we just covered. First, you'll classify AI systems into the four risk categories using a classifier that inspects system descriptions and returns the applicable articles and deadlines. Second, you'll implement the February 2025 AI literacy requirements with role-based assessment modules and certification tracking. Third, you'll build GPAI technical documentation generators with version tracking. Fourth, you'll construct the risk management system — registry, scoring, review workflow, and mitigation references. Fifth, you'll implement human oversight mechanisms including the emergency stop and the confidence-based review queue. And sixth, you'll build the enforcement timeline tracker with automated compliance checks and gap analysis. Each exercise has its own audio overview that goes deeper into the implementation. Host: Let's land this. You now understand three things that directly strengthen your team's ability to ship production AI in regulated markets. First, you understand the four-tier risk classification system and how to map any AI application to the obligations it triggers. Second, you understand the active enforcement milestones — February 2025 literacy and prohibition rules, August 2025 GPAI documentation — and how to build the technical controls that satisfy them. Third, you understand how human oversight, risk management, and compliance tracking work as continuously-operating infrastructure rather than paperwork. You now have the depth to evaluate your organization's AI compliance posture, flag gaps to your governance team, and architect the systems that close them. The chapter quiz will focus on which practices fall under unacceptable risk, which United States frameworks parallel or differ from the EU approach, which domains Annex III designates as high-risk, and the specific February 2025 and August 2025 obligations that are already in force. Pay close attention to the risk tier boundaries and the article references — those are the anchor points regulators and auditors will quote back at you. In the next chapter, we broaden the lens from the EU to the global compliance landscape — the NIST AI Risk Management Framework, ISO 42001, and how to build unified governance structures that satisfy multiple regulatory regimes at once. The EU AI Act gave you the foundation. Chapter 21 teaches you how to generalize it. See you there.