L8.2.1 — EU AI Act compliance program design

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 8 — AI Governance, Risk & Compliance Framework tags: EU AI Act Articles 9, 14, 15, 17

Learning objectives

1. Identify the five program components an EU AI Act-compliant high-risk system requires.
2. Recognize the role-based responsibilities (provider, deployer, importer, distributor) under the Act.

Core content

From "we have to comply" to "compliance program"

Module 2 L2.5.3 introduced the EU AI Act risk tiers and obligations. This lesson is the practical follow-up: what does a compliance program for a high-risk AI system actually look like?

If your system is in the high-risk tier (Annex III categories: HR, credit, healthcare, critical infrastructure, law enforcement, etc.), the Act requires specific operational components. Not optional. Not aspirational. Required.

Five program components

1. Risk management system (Article 9). A documented, ongoing risk identification + analysis + mitigation process across the AI system's lifecycle. The NIST AI RMF program (L8.1.1) maps to this directly — most teams structure their Article 9 work around RMF. The compliance bar: documented, ongoing, lifecycle-spanning.

2. Data governance (Article 10). Training, validation, and testing datasets must meet quality criteria — relevant, representative, free from errors and bias to the extent feasible, with documented sourcing. For LLM-using applications, this often means documenting the vendor's data governance (since the base model is theirs) plus your fine-tune dataset's governance directly.

3. Technical documentation (Article 11). A comprehensive document package — purpose, design, training data, testing, performance metrics, risk management measures, instructions for use. Next lesson (L8.2.2) deep-dives.

4. Record-keeping (Article 12). Automatic logging of events relevant to risk identification. Module 7 L7.4.1 and L7.9 covered the engineering side; Article 12 is the regulatory floor on what must be logged.

5. Human oversight (Article 14). Designed-in mechanisms for natural persons to "monitor, intervene, override" the AI system. Module 3 L3.4.* covered the engineering pattern (human-in-the-loop on impactful actions); Article 14 is the regulatory floor.

Plus quality management (Article 17) for providers, and conformity assessment for some high-risk categories. These five components are the core engineering-touching obligations.

Role-based responsibilities

The Act distinguishes four roles:

• Provider — develops the AI system and places it on the market. Most obligations.
• Deployer — uses the AI system under its authority (formerly "user"). Some obligations, especially around oversight and monitoring.
• Importer — places a third-country AI system on the EU market. Verification obligations.
• Distributor — makes the system available on the EU market without being importer or provider. Lighter obligations.

If you're a SaaS using a foundation model and shipping to EU customers: - You're the provider of your SaaS to EU customers — you have the heavy obligations for your AI feature. - The foundation-model vendor is the provider of the foundation model — they have obligations to you. - Your EU customer is the deployer — they have user-side obligations.

These roles flow down via contracts. Your provider contracts with vendors must surface their compliance posture; your customer contracts must allocate deployer obligations clearly.

Building the program

Six-step starting playbook:

1. Risk-tier classification. Confirm your system is high-risk per Annex III (Module 2 L2.5.3 + Module 4 L4.9 lab cover this).
2. Gap assessment. Map current state against the five program components. Identify gaps.
3. Document baseline. Stand up the Article 11 documentation package (next lesson). Even incomplete, having a single document is the start.
4. Wire engineering controls. Logging (Article 12), oversight (Article 14), security/robustness (Article 15). Modules 7 covers each.
5. Cadence. Establish quarterly review of risk register + annual reassessment of risk-tier classification (in case Annex III gets amended or your use case shifts).
6. External attestation. Some high-risk categories require third-party conformity assessment; others self-assessment. Know which applies.

Operational reality in 2026

Most enterprises with EU customers have at least started this work, driven by: - Customer contractual pressure ("show us your EU AI Act compliance"). - Regulator pressure (formal enforcement ramping through 2026-2027). - Internal legal/compliance teams reading the timelines.

Few have completed it. The work is multi-year for most organizations. Starting now beats starting after a regulator inquiry.

Real-world example

European financial services companies were among the first to ship EU AI Act compliance programs in 2024–2025, driven by both AI Act and the EU's broader DORA (Digital Operational Resilience Act) framework. Their reference architectures — risk register, control library, documentation package, oversight design — are increasingly published as case studies. Useful templates if you're greenfielding.

Key terms

• EU AI Act compliance program — operational machinery to meet Act obligations.
• Article 9 risk management system — ongoing risk process; RMF-aligned.
• Article 10 data governance — training data quality requirements.
• Article 11 technical documentation — the documentation package.
• Article 12 record-keeping — automatic logging requirements.
• Article 14 human oversight — designed-in oversight mechanisms.
• Provider / Deployer / Importer / Distributor — role-based responsibilities.

References

• EU AI Act (Regulation EU 2024/1689), Articles 9–17.
• EU AI Act portal — https://artificialintelligenceact.eu/
• European Commission AI Act guidance.

Quiz items

1. Q: Name the five program components for an EU AI Act-compliant high-risk system. A: Risk management system (Art. 9); data governance (Art. 10); technical documentation (Art. 11); record-keeping (Art. 12); human oversight (Art. 14).
2. Q: A SaaS uses a foundation-model vendor and ships to EU customers. Identify the roles. A: SaaS is provider for their AI feature (heavy obligations); foundation-model vendor is provider of the foundation model (obligations to the SaaS); EU customer is deployer (user-side obligations).
3. Q: Why does NIST AI RMF map cleanly to Article 9? A: Both are documented, ongoing, lifecycle-spanning risk processes. Most teams structure Article 9 work around their NIST RMF program rather than building parallel structures.

Video script (~600 words, ~4.5 min)

[SLIDE 1 — Title]

EU AI Act compliance program design. Five minutes.

[SLIDE 2 — From "we have to comply" to "compliance program"]

Module 2 L2.5.3 introduced risk tiers and obligations. This lesson is the practical follow-up. What does a compliance program for a high-risk AI system actually look like?

If your system is high-risk per Annex III — HR, credit, healthcare, critical infrastructure, law enforcement — the Act requires specific operational components. Not optional. Not aspirational. Required.

[SLIDE 3 — Five program components]

Five components. One: risk management system, Article 9. Documented ongoing risk identification, analysis, mitigation across the lifecycle. NIST AI RMF program from L8.1.1 maps directly. Two: data governance, Article 10. Training, validation, testing datasets meet quality criteria — relevant, representative, free from errors and bias to extent feasible, documented sourcing. Three: technical documentation, Article 11. Comprehensive document package. Next lesson deep-dives. Four: record-keeping, Article 12. Automatic logging of events relevant to risk identification. Module 7 L7.4.1 and L7.9 covered engineering side. Article 12 is the regulatory floor. Five: human oversight, Article 14. Designed-in mechanisms for natural persons to monitor, intervene, override. Module 3 L3.4 covered engineering pattern. Article 14 is the regulatory floor.

Plus quality management Article 17 for providers, and conformity assessment for some high-risk categories.

[SLIDE 4 — Role-based responsibilities]

Act distinguishes four roles. Provider — develops the AI system and places on market. Most obligations. Deployer — uses the AI system under its authority. Some obligations, especially oversight and monitoring. Importer — places third-country AI system on EU market. Verification obligations. Distributor — makes the system available without being importer or provider. Lighter obligations.

[SLIDE 5 — Worked role example]

SaaS using a foundation model, shipping to EU customers. You're the provider of your SaaS to EU customers — heavy obligations. Foundation-model vendor is provider of the foundation model — obligations to you. EU customer is deployer — user-side obligations. Roles flow down via contracts. Your provider contracts with vendors must surface their compliance posture. Your customer contracts must allocate deployer obligations clearly.

[SLIDE 6 — Six-step starting playbook]

Six-step starting playbook. Risk-tier classification — confirm system is high-risk per Annex III. Gap assessment — map current state against five program components. Document baseline — stand up Article 11 documentation package, even incomplete. Wire engineering controls — logging, oversight, security/robustness. Modules 7 covers each. Cadence — quarterly review of risk register, annual reassessment of risk-tier. External attestation — some high-risk categories require third-party conformity assessment, others self-assessment. Know which applies.

[SLIDE 7 — 2026 reality + up next]

Most enterprises with EU customers have started this work. Driven by customer contractual pressure, regulator pressure, internal legal/compliance reading timelines. Few have completed it. Multi-year work for most organizations. Starting now beats starting after a regulator inquiry.

Next lesson: Article 11 — the technical documentation package — in detail. Five minutes.

Slide outline

1. Title — "EU AI Act compliance program design".
2. From mandate to program — Act-paragraph → program-machinery arrow.
3. Five components — five-card layout: Art. 9, 10, 11, 12, 14.
4. Four roles — role-tree diagram.
5. Worked role example — SaaS scenario diagram with role labels.
6. Six-step playbook — numbered list.
7. 2026 reality + up next — "most teams have started, few have completed" + next pointer.

Production notes

• Recording: ~4.5 min. Cap 5.
• Slide 5 (worked role example) is the slide that lands the cascading-obligations concept; design carefully.