🧭 Lesson Overview
Day 2 introduced the EU AI Act as one of four frameworks in the governance landscape. Today you go deep. The EU AI Act (Regulation 2024/1689) is not a framework, a guideline, or a voluntary code of conduct. It is binding law — directly applicable in all 27 EU member states, with extraterritorial reach, escalating penalties, and a compliance clock that is already running for most organizations.
The central skill this lesson builds is classification: given a real AI system, determine which of the four risk tiers applies, which obligations follow from that classification, and which organizational role — provider, deployer, importer, or distributor — determines your specific compliance burden. Classification errors have legal consequences.
The EU AI Act's risk-tiered approach mirrors pharmaceutical regulation. Over-the-counter aspirin requires minimal oversight — a label and basic safety data. Prescription medications require clinical trials, physician authorization, and post-market surveillance. Experimental treatments require compassionate use protocols, specialized facilities, and intensive monitoring. Some drugs are banned outright regardless of claimed benefit.
The EU AI Act works identically: most AI (aspirin) needs minimal oversight. AI in high-stakes contexts (prescription drugs) needs rigorous pre-market evaluation and human oversight. Some AI practices (banned substances) are prohibited entirely, no exceptions. The same molecule — the same model — can be OTC or prescription depending on its use case. Classification in the EU AI Act is use-case driven, not technology driven.
Day 5 Learning Objectives
- Explain the EU AI Act's legal structure, extraterritorial scope, and why "binding" matters differently from voluntary frameworks.
- Classify AI systems into the four EU AI Act risk tiers and identify what triggers each classification.
- List the nine high-risk AI system requirements (Articles 9–15) and explain what each demands in practice.
- Distinguish the obligations of providers, deployers, importers, and distributors — including the Article 25 "accidental provider" trap.
- Explain GPAI model obligations (Articles 53 and 55) and the systemic risk threshold.
- Apply the enforcement timeline to determine which obligations are already in force vs. pending.
- Classify a real-world AI scenario into the correct tier and role, with supporting rationale.
⚖️ Module 1 · Why "Binding" Changes Everything
Every other AI framework you have studied in this course — NIST AI RMF, ISO/IEC 42001, OWASP LLM Top 10 — is voluntary. The EU AI Act is not. Understanding this distinction is not semantic hair-splitting; it changes how compliance works, who is liable, and what the consequences of failure are.
| Dimension | Voluntary Framework (NIST AI RMF) | Binding Regulation (EU AI Act) |
|---|---|---|
| Legal force | Guidance. Non-compliance has no direct legal consequence. | Law. Non-compliance triggers enforceable penalties. |
| Who enforces | Nobody — market forces, procurement requirements, reputational pressure. | EU AI Office (GPAI) + national market surveillance authorities (high-risk) + data protection authorities. |
| Penalties | None directly. Risk: audit failure, lost contracts, reputational harm. | Up to €35M or 7% of global annual turnover — whichever is higher. For GPAI: €15M or 3%. |
| Extraterritorial reach | No. Applies where organizations choose to adopt it. | Yes. Applies to any AI output that reaches EU users — regardless of where the provider is headquartered. |
| Timeline | No deadlines. Organizations adopt at their own pace. | Staggered mandatory dates: Feb 2025, Aug 2025, Aug 2026, Aug 2027. Already partially in force. |
| Role-specific duties | Flexible. Organizations self-select responsibilities. | Precise. Provider, deployer, importer, distributor have legally defined, non-negotiable duties. |
| Certification | ISO 42001 is certifiable (optional market signal). | CE marking + EU database registration is mandatory for high-risk systems before market placement. |
📅 Module 2 · Enforcement Timeline — Where We Are Now
The EU AI Act uses a phased rollout across three years. The critical insight for compliance planning: as of May 2026, most organizations subject to the Act are already non-compliant on at least some obligations — prohibited practices and GPAI model rules have been in force for months. The August 2026 high-risk deadline is 9 weeks away.
🔺 Module 3 · The Four Risk Tiers — Classification Logic
The EU AI Act uses a risk-based approach: obligations scale with the potential for harm. Classification happens once per system per deployment context — and it determines your entire compliance burden. The critical rule: classification is use-case specific, not model specific. The same underlying model can be minimal-risk in one application and high-risk in another.
AI practices considered fundamentally incompatible with EU values and fundamental rights. Banned since February 2, 2025. No business justification, technical sophistication, or societal benefit argument creates an exception.
Permitted but heavily regulated. Must meet nine mandatory requirements before market placement. Requires conformity assessment, CE marking, and EU database registration. Full enforcement: August 2, 2026.
Permitted with disclosure obligations under Article 50. Users must know they are interacting with AI, or that content is AI-generated. Enforcement begins August 2, 2026.
Vast majority of AI applications. No Act-specific mandatory obligations beyond Article 4 AI literacy. Voluntary codes of conduct encouraged. Internal governance (NIST AI RMF, ISO 42001) still applies.
Flip Cards: Prohibited Practices — Know All Eight
All eight prohibited AI practices under Article 5 have been enforceable since February 2, 2025. Click each card to see the exact prohibition and a practical boundary example.
High-Risk Use Cases — Annex III Categories
Annex III lists eight specific use-case categories where AI systems are classified as high-risk. Click each card to see the full scope of that category and key classification considerations.
📋 Module 4 · High-Risk System Requirements — Articles 9–15
High-risk AI systems must meet nine mandatory requirements before being placed on the EU market or put into service. These are not post-deployment obligations — they are pre-market requirements. A system that does not meet them cannot legally be deployed to EU users. Click each requirement to expand the full detail.
A new aircraft design cannot carry passengers until it achieves type certification — a rigorous pre-market process covering structural integrity, systems redundancy, emergency procedures, and pilot training. Certification is not a checklist you complete on day one of operation; it's a comprehensive pre-deployment evaluation that must pass before a single passenger boards.
Articles 9–15 are the EU AI Act's type certification for high-risk AI systems. Risk management, data governance, technical documentation, logging, transparency, human oversight, and accuracy/robustness/cybersecurity must all be in place and verified before the system is placed on the market — not after incidents occur.
| Article | Requirement | Who Bears It | Key Deliverable |
|---|---|---|---|
| Art. 9 | Risk Management System | Provider | Documented, iterative, lifecycle-spanning risk management system |
| Art. 10 | Data and Data Governance | Provider | Training/validation/test dataset quality plan; bias evaluation; data lineage records |
| Art. 11 | Technical Documentation | Provider | Complete technical file per Annex IV — must be available to authorities on request |
| Art. 12 | Record-Keeping / Logging | Provider (design); Deployer (retention) | Automatic logs of operation; deployer retains logs ≥ 6 months |
| Art. 13 | Transparency & Instructions for Use | Provider | Instructions for use covering capabilities, limitations, known failure modes |
| Art. 14 | Human Oversight | Provider (design); Deployer (implementation) | Ability to understand, monitor, override, suspend — designed into the system |
| Art. 15 | Accuracy, Robustness & Cybersecurity | Provider | Accuracy metrics, robustness against adversarial inputs, cybersecurity measures |
| Art. 16–17 | Quality Management System | Provider | Documented QMS proportionate to provider size; includes all Art. 9–15 implementations |
| Art. 27 | Fundamental Rights Impact Assessment | Deployer (public bodies + certain private deployers) | FRIA documenting impacts on fundamental rights before deployment |
👥 Module 5 · Roles & the AI Value Chain — Who Owes What
The EU AI Act assigns compliance obligations to specific actors in the AI value chain. The most consequential distinction is provider vs. deployer — but the Act's definitions are precise and sometimes counterintuitive. Getting your role wrong is a classification error with legal consequences.
The Four Statutory Roles — Article 3 Definitions
Role Obligations Comparison
| Obligation | Provider (Art. 16) | Deployer (Art. 26) | Importer (Art. 23) | Distributor (Art. 24) |
|---|---|---|---|---|
| Art. 9–15 Technical Requirements | ✅ Full | ✗ | 〜 Verify | 〜 Verify |
| Conformity Assessment + CE Marking | ✅ Must obtain | ✗ | 〜 Must not import non-compliant | ✗ |
| EU Database Registration (Art. 71) | ✅ Required | 〜 Some sectors | ✗ | ✗ |
| Quality Management System (Art. 17) | ✅ Required | ✗ | ✗ | ✗ |
| Use System per Instructions | ✗ | ✅ Required | ✗ | ✗ |
| Human Oversight (implement) | 〜 Design-in | ✅ Implement & maintain | ✗ | ✗ |
| Retain Logs ≥ 6 Months | ✗ | ✅ Required | ✗ | ✗ |
| Fundamental Rights Impact Assessment | ✗ | ✅ Public + certain private | ✗ | ✗ |
| Post-Market Monitoring (Art. 72) | ✅ Plan + execute | 〜 Report incidents | ✗ | ✗ |
| Serious Incident Reporting (Art. 73) | ✅ To authority | ✅ To provider + authority | 〜 If health/safety risk | 〜 If health/safety risk |
Article 25 — The "Accidental Provider" Trap
🤖 Module 6 · GPAI Models — Chapter V Obligations
General-Purpose AI (GPAI) models — foundation models like GPT, Claude, Gemini, Llama, and Mistral that can be adapted for many tasks — are governed by Chapter V of the EU AI Act (Articles 51–56). GPAI obligations have been in force since August 2, 2025, and create a separate regulatory track from the risk-tier system.
| Tier | Threshold | Key Obligations (Articles 53 & 55) | Enforcement |
|---|---|---|---|
| All GPAI Models | >10²³ FLOPs training compute + placed on EU market | Technical documentation to downstream providers (Annex XII); EU copyright law compliance; public summary of training content; cooperation with AI Office | EU AI Office (centralized) |
| GPAI with Systemic Risk | >10²⁵ FLOPs training compute (or AI Office designation) | All Tier 1 obligations PLUS: Model evaluations using standard protocols; adversarial testing; systemic risk assessment and mitigation; serious incident reporting to AI Office; cybersecurity protection for model and physical infrastructure | EU AI Office (centralized); Fines up to €15M or 3% global turnover |
Think of GPAI models as ingredient suppliers to the food industry. A flour producer (GPAI provider) must meet baseline food safety standards for all flour (Art. 53 — all GPAI). If they produce a specialty high-risk additive (systemic-risk GPAI), they face additional safety evaluation, incident reporting, and stricter documentation. The restaurant that uses the flour to make bread (high-risk AI deployer) has separate obligations — it cannot hide behind "it's the flour supplier's fault if the bread harms someone." Both the ingredient supplier and the manufacturer carry obligations appropriate to their role in the chain.
🔐 Module 7 · Privacy & Data Protection as a Discipline (Beyond the AI Act)
The EU AI Act does not operate in a vacuum. Almost every high-risk AI system also processes personal data, which means a second, older, and equally binding body of law applies simultaneously: the General Data Protection Regulation (GDPR, Regulation (EU) 2016/679). The AI Act governs the system and its risk to safety and fundamental rights; the GDPR governs the data and the individuals it describes. You cannot comply with one and ignore the other — the same MVCC advising assistant is subject to both at the same time.
Privacy is a discipline in its own right, with its own principles, roles, and impact-assessment machinery that predate the AI Act by years. This module gives you the Security+/GRC-level working knowledge you need to recognize where GDPR obligations attach to AI, where the AI Act's assessment duties overlap with GDPR's, and how to actually run the assessment.
Think of a new hospital wing. The fire marshal (EU AI Act) inspects the structure for safety hazards and rights risks — can it be operated without harming people? The health inspector (GDPR) checks how patient records are collected, stored, and disposed of. They inspect the same building on overlapping days, they sometimes examine the same room, but each has a distinct mandate and each can shut you down independently. Passing one inspection does not exempt you from the other.
Core GDPR Obligations Most Relevant to AI
Four GDPR principles do the heaviest lifting when an AI system is in scope. Each maps directly onto a design decision your team makes about training data and inference.
| GDPR Concept | Article | What It Demands | The AI-Specific Tension |
|---|---|---|---|
| Lawful basis | Art. 6 | Every processing activity needs one of six lawful bases — consent, contract, legal obligation, vital interests, public task, or legitimate interests. | "We had the data for enrollment" is not automatically a basis to train a model on it. Repurposing data for AI usually needs a fresh lawful-basis analysis. |
| Purpose limitation | Art. 5(1)(b) | Data collected for one specified purpose may not be reused for an incompatible new purpose. | Data gathered to register students being reused to train a risk-prediction model is a classic purpose-creep flag. |
| Data minimization | Art. 5(1)(c) | Process only data that is adequate, relevant, and limited to what is necessary. | Directly conflicts with the "collect everything, the model will find signal" instinct. More features is not a legal defense. |
| Data-subject rights | Arts. 15–17 | Access (Art. 15), rectification (Art. 16), and erasure / "right to be forgotten" (Art. 17), among others. | Individuals can demand to see, correct, or delete their data — including data already absorbed into a trained model. |
Right to Erasure vs. Model Memorization — and "Machine Unlearning"
Article 17 gives individuals a right to erasure. That is straightforward for a row in a database — you delete the row. It is not straightforward for a trained model. Large models can memorize fragments of their training data, and that information is diffused across billions of parameters rather than sitting in a deletable record. Honoring an erasure request may therefore require more than deleting the source file: the influence of that data can persist in the model's weights.
Machine unlearning is the emerging research field that tries to remove the effect of specific training data from a model without retraining from scratch. At an awareness level, you should know two things: (1) the only fully reliable method today is retraining the model on a dataset with the target data removed — which is often expensive or impractical; and (2) faster "approximate" unlearning techniques exist but come with no guarantee that the data's influence is truly gone, and verifying removal is itself an open problem.
FRIA (AI Act Art. 27) and DPIA (GDPR Art. 35) — Two Assessments, One Workflow
Both regimes require a structured, documented impact assessment before a high-risk system goes live — but they are not the same instrument and are not triggered by the same thing. Understanding how they relate keeps you from either duplicating work or missing a required assessment entirely.
| Dimension | DPIA — Data Protection Impact Assessment | FRIA — Fundamental Rights Impact Assessment |
|---|---|---|
| Source | GDPR Article 35 | EU AI Act Article 27 |
| Primary focus | Risks to the protection of personal data and privacy. | Broader risks to fundamental rights — non-discrimination, dignity, due process — from a high-risk AI system. |
| Who must do it | The controller, when processing is likely to result in a high risk to individuals. | The deployer that is a public body or private provider of public services, plus deployers of certain Annex III systems (e.g., creditworthiness, life/health insurance risk). |
| Trigger | High-risk processing: new technologies, large-scale processing, systematic monitoring, or automated decisions with legal / similarly significant effects. | First use of an in-scope high-risk AI system by an in-scope deployer. |
| When | Before the processing begins. | Before the system is put into use. |
Conducting a DPIA / FRIA — The Practical Steps
Whether you are running a DPIA, a FRIA, or the combined package, the working method is the same disciplined sequence:
- Describe the processing / system. Document the system, its purpose, the data flows, the data categories, and the categories of individuals affected.
- Establish lawful basis and necessity. Identify the Art. 6 lawful basis and test necessity and proportionality — could you achieve the purpose with less data or a less intrusive method?
- Identify risks to individuals and their rights. Assess likelihood and severity of harms: discrimination, loss of control over data, wrongful decisions, denial of a service. For a FRIA, extend explicitly to fundamental-rights impacts.
- Identify mitigations. Define controls that reduce each risk — data minimization, human oversight, bias testing, access controls, retention limits, appeal mechanisms.
- Assess residual risk. Judge the risk that remains after mitigations. If it stays high, GDPR Art. 36 requires prior consultation with the supervisory authority before proceeding.
- Sign off, monitor, and revisit. Have the accountable owner (with the DPO's input) record the decision, then re-assess whenever the system or its purpose materially changes.
DPIA / FRIA Worksheet (Fillable Template)
Use this structured worksheet to run the combined assessment for any AI system that processes personal data. Complete every field; leave a defensible written trail. Blank cells are meant to be filled in.
| Field | Your Entry |
|---|---|
| System & purpose | [ Name the system and state its single specified purpose ] |
| Data categories & subjects | [ What personal data, whose — students, staff, applicants? Any special-category data? ] |
| Lawful basis (GDPR Art. 6) | [ Which basis, and is it valid for training AND for inference? ] |
| Necessity & proportionality | [ Why is this data necessary? Could a less intrusive approach achieve the purpose? ] |
| Risks to rights | [ Discrimination, wrongful decisions, loss of control, denial of service — likelihood × severity ] |
| Mitigations | [ Human oversight, bias testing, minimization, retention limits, appeal / contest mechanism ] |
| Residual risk | [ Risk remaining after mitigations — if still high, Art. 36 prior consultation required ] |
| Sign-off | [ Accountable owner, DPO input, date, next review date ] |
Sample DPIA — MVCC AI Enrollment & Advising Assistant
The following is an illustrative, deliberately imperfect completed worksheet for the fictional MVCC AI enrollment/advising assistant. Read it critically — it is a teaching artifact, not a model answer.
| Field | Entry |
|---|---|
| System & purpose | AI assistant that recommends courses and flags students for advisor outreach during enrollment. |
| Data categories & subjects | Enrolled and prospective students. Fields: transcripts, GPA, attendance, financial-aid status, LMS activity, demographic fields. |
| Lawful basis (GDPR Art. 6) | Public task / legitimate interests — the college already holds this data for enrollment administration. |
| Necessity & proportionality | All available student fields are fed to the model to maximize prediction accuracy. |
| Risks to rights | Possible inaccurate recommendations. Students can email an advisor if a recommendation seems wrong. |
| Mitigations | An advisor reviews flagged students before outreach. Vendor states the model is "fair." |
| Residual risk | Low. Advisor-in-the-loop resolves any errors. |
| Sign-off | Approved by Enrollment Services. DPO consulted informally. |
Your task — Critique this DPIA. Which risks are understated, and what mitigation is missing? In a short written response, identify at least four weaknesses. Consider, among others:
- Lawful basis & purpose limitation: Is "we already hold it for enrollment" a valid basis to train a prediction model? Where is the purpose-limitation analysis?
- Data minimization: "All available fields to maximize accuracy" directly contradicts Art. 5(1)(c) — which fields are actually necessary, and what is the discrimination risk of the demographic fields?
- Risks to rights: Bias and disparate impact are not assessed at all; "email an advisor" is not a real contestability or appeal mechanism.
- Mitigations & residual risk: A vendor's unverified claim that the model is "fair" is not bias testing; the "low residual risk" conclusion is unsupported and likely understated.
- Missing entirely: No FRIA extension (this is an Annex III education use case), no retention limit, no erasure/model-memorization plan, and only an "informal" DPO consultation where formal sign-off is expected.
🔀 Activity A · Interactive Classification Decision Tree
👤 Activity B · Role Identifier — Provider, Deployer, Importer, or Distributor?
For each scenario, click the role that applies under the EU AI Act's Article 3 definitions. Some organizations hold multiple roles simultaneously — select the primary or most onerous role unless the scenario specifies multiple. Immediate feedback explains the rationale.
🎯 Activity C · Scenario Tier Match — Classify 10 AI Systems
For each AI deployment scenario below, select the correct EU AI Act risk tier from the dropdown. Remember: classify the use case and deployment context, not just the underlying technology. When you've made all selections, click "Check All" to see results with explanations.
📝 Assessment Artifact
AI System Classification Worksheet — In-Class Submission
Complete a classification worksheet for the MVCC at-risk student predictor (from Days 3–4). Your worksheet must address:
- Tier classification: Is this system prohibited, high-risk, limited-risk, or minimal-risk under the EU AI Act? Justify using Annex III categories and the use-case-first classification rule. Consider: does MVCC having EU exchange students matter?
- Role identification: If MVCC built the system in-house using an open-source foundation model, what role do they hold? What if they purchased and fine-tuned a commercial model and deployed it themselves?
- Applicable obligations: If high-risk, list the Articles 9–15 requirements that apply and indicate which are the MVCC CISO's primary concern from a cybersecurity standpoint.
- Timeline question: If MVCC determined in September 2026 that this system is high-risk, what is their compliance posture under the Act as of that date?
Format: One page (400–500 words) plus a one-row classification table (Tier | Role | Primary Obligations | Timeline Status).
Grading: Daily assignment (25% of course grade). Evaluated on accuracy of tier classification, role identification including Article 25 analysis, specificity of obligation identification, and timeline reasoning.