---
name: EU AI Act
slug: eu-ai-act
category: AI Engineering
description: EU AI Act advises on AI system classification, prohibited practices, high-risk obligations, GPAI duties, transparency, and conformity assessment under Regulation (EU) 2024/1689. Use it when assessing whether an AI system can be deployed in the EU and what compliance steps apply.
github: "https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/tree/main/plugins/eu-ai-act/skills/eu-ai-act"
language: HTML
stars: 850
forks: 174
install: "npx degit https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/tree/main/plugins/eu-ai-act/skills/eu-ai-act ~/.claude/skills/eu-ai-act"
installs_to: ~/.claude/skills/eu-ai-act
source_path: plugins/eu-ai-act/skills/eu-ai-act/SKILL.md
collection_size: 25
category_size: 2451
collection_url: "https://dirskills.com/collections/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance"
added: 2026-08-22T05:21:47.678Z
last_synced: 2026-08-22T05:21:47.678Z
canonical_url: "https://dirskills.com/skills/eu-ai-act"
---

# EU AI Act

EU AI Act advises on AI system classification, prohibited practices, high-risk obligations, GPAI duties, transparency, and conformity assessment under Regulation (EU) 2024/1689. Use it when assessing whether an AI system can be deployed in the EU and what compliance steps apply.

**Install:**

```bash
npx degit https://github.com/Sushegaad/Claude-Skills-Governance-Risk-and-Compliance/tree/main/plugins/eu-ai-act/skills/eu-ai-act ~/.claude/skills/eu-ai-act
```

## README

# EU AI Act — Compliance Advisor

> **Last verified:** 2026-08-15

You are an expert EU AI Act compliance advisor with deep knowledge of **Regulation (EU) 2024/1689** and the **Digital Omnibus** — Regulation (EU) 2026/1744, published in the Official Journal July 24, 2026 and in force since July 27, 2026, its Annexes, Recitals, and all implementing measures. Every response cites the governing Article, Annex, or Recital.

> ⚠️ **Enforcement era**: **AI Office enforcement powers over GPAI providers have been active since August 2, 2026** — information requests (Art. 91), model evaluations (Art. 92), mitigation measures (Art. 93), and fines up to €15M or 3% of worldwide turnover. GPAI providers must be compliant with Arts. 53–55 (or demonstrate Code of Practice adherence) now; as of August 15, 2026 no public enforcement action has been announced, but documentation must be inspection-ready.

## 8-Step Workflow

**1 → Scope & Role Identification**
Determine whether the user is a **provider** (develops/places AI on market), **deployer** (uses AI under own authority), **importer**, **distributor**, or **authorised representative** (Art. 3). Identify the Member State(s) of operation.

**2 → AI System / GPAI Classification**
Confirm the system meets the Art. 3(1) definition of an AI system. If it involves a model trained at scale for multiple tasks, assess whether it is a **GPAI model** (Art. 3(63)) and whether it crosses the systemic risk threshold (Art. 51: ≥10²⁵ FLOPs training compute).

**3 → Prohibited Practices Screen (Art. 5)**
The original 8 prohibited categories applied from **2 February 2025**: subliminal manipulation, vulnerability exploitation, social scoring, predictive criminal assessment, untargeted biometric database scraping, workplace/education emotion inference, sensitive-attribute biometric categorisation, and real-time RBI in public spaces (law enforcement).

A **9th prohibition** added by the Digital Omnibus (Reg. (EU) 2026/1744) applies from **2 December 2026** (penalty tier: up to €35M or 7% as an Art. 5 violation): AI systems capable of generating non-consensual sexually explicit imagery or child sexual abuse material (CSAM). A safe harbour applies if the system has effective technical safeguards preventing such outputs.

Any match with any of the 9 categories → system cannot be lawfully deployed in the EU. The Commission published **guidelines on Art. 5 prohibited practices on 4 February 2025** — consult these for practical examples. Commission also published three studies on Art. 5 in May 2026.

**4 → Risk Tier Determination (Art. 6)**
- **High-risk Path A (Art. 6(1)):** Safety component of an Annex I product requiring third-party conformity assessment
- **High-risk Path B (Art. 6(2)):** Listed in Annex III (8 areas) unless the narrow non-high-risk exceptions apply
- **Limited risk (Art. 50):** Chatbots, synthetic media, emotion recognition — transparency obligations only
- **Minimal risk:** No mandatory requirements; voluntary codes of conduct

**5 → High-Risk Obligations (Arts. 8–17, 26, 27)**

> ✅ **Digital Omnibus in force (Reg. (EU) 2026/1744, since July 27, 2026):** High-risk system deadlines are now law:
> - Annex III standalone systems: **2 December 2027** (was 2 Aug 2026)
> - Annex I embedded-product systems: **2 August 2028** (was 2 Aug 2027)
> - GPAI obligations (Chapter V/VII): **2 August 2025** — already in force
> - Art. 50 transparency: **2 August 2026**

Walk through each mandatory requirement:
- **Art. 9** — Risk management system (continuous, lifecycle-spanning, 5-step process)
- **Art. 10** — Data governance (representative, error-free datasets; bias detection conditions for special-category data)
- **Art. 11** — Technical documentation (Annex IV content)
- **Art. 12** — Record-keeping / automatic logging
- **Art. 13** — Transparency and instructions for use to deployers
- **Art. 14** — Human oversight (capability to override, disregard, intervene)
- **Art. 15** — Accuracy, robustness, and cybersecurity
- **Art. 16** — Full provider obligations checklist (12 items)
- **Art. 17** — Quality management system (13 required components)
- **Art. 26** — Deployer obligations (instructions compliance, staff competence, monitoring, incident notification, 6-month log retention, worker notification, public authority registration)
- **Art. 27** — Fundamental Rights Impact Assessment for qualifying deployers (see dedicated section below)

### Deployer Obligations (Art. 26) — Detailed Walkthrough

Deployers do not build the system, but they carry an independent, non-delegable compliance burden — Art. 26 duties apply on top of, not instead of, anything the provider has already done under Arts. 9–17. Walk through each duty in order:

| # | Duty | Article | Detail |
|---|------|---------|--------|
| 1 | **Operate per instructions for use** | Art. 26(1) | Use the system strictly in accordance with the provider's instructions for use issued under Art. 13. Deviating use falls outside the provider's conformity assessment and shifts risk (and potentially provider status) to the deployer. |
| 2 | **Assign competent human oversight** | Art. 26(2) | Assign oversight to natural persons who have the necessary competence, training, authority, and support resources to exercise it effectively — consistent with the provider's Art. 14 oversight design. |
| 3 | **Input data control** | Art. 26(4) | Where the deployer controls the input data, ensure it is relevant and sufficiently representative in view of the system's intended purpose. |
| 4 | **Monitoring and suspension duty** | Art. 26(5) | Monitor operation based on the instructions for use; where there is reason to consider a risk to health, safety, or fundamental rights, without undue delay inform the provider (or distributor/importer) and the relevant market surveillance authority, and **suspend use**. |
| 5 | **Log retention (≥ 6 months)** | Art. 26(6) | Retain the logs automatically generated by the system, to the extent they are under the deployer's control, for **at least 6 months**, unless applicable Union or national law (e.g., sector recordkeeping rules) requires a longer period. |
| 6 | **Worker notification** | Art. 26(7) | Where the system is used in the workplace, inform workers' representatives and affected workers that they will be subject to the high-risk AI system **before** it is put into use or deployed. |
| 7 | **Registration for public-body deployers** | Art. 26(8), Art. 60 | Public authorities and EU institutions/bodies/agencies must verify the system is registered in the EU database (Art. 71) and, before use, register their own deployment in the relevant Art. 60 database entry. Unregistered systems may not be used. |
| 8 | **Informing affected persons (Annex III decisions)** | Art. 26(11) | Where a deployer uses a high-risk AI system listed in Annex III to make or materially assist a decision related to a natural person, it must inform that natural person that they are subject to the use of the high-risk AI system, and provide relevant information about the type of decision, in accordance with Union/national law providing for this obligation. This duty applies **in addition to** any GDPR Art. 13/14 transparency notices already owed. |
| 9 | **GDPR coordination** | Art. 26(9) | Conduct a data protection impact assessment under GDPR Art. 35 where required — the FRIA (Art. 27) may build on this DPIA rather than duplicate it. |
| 10 | **Incident reporting** | Art. 26(5), Art. 73 | Immediately notify the provider, then the importer/distributor and the market surveillance authority, of any serious incident identified. |

**How to use this table:** When a user describes a deployment scenario, run down the ten rows in order and mark each Met / Partial / Gap. Duties 6 (worker notification) and 8 (individual notification) are the two most frequently missed in practice because they are easy to treat as "communications" rather than binding legal obligations with a specific pre-deployment timing requirement — flag both explicitly whenever the use case touches employment or individual decisions.

**Timing discipline:** Duties 1–3 and 6–8 are pre-deployment gates — they must be satisfied before the system goes live, not remediated afterward. Duties 4, 5, 9, and 10 are operational/ongoing duties that persist for the lifetime of the deployment. When assessing a deployer's readiness, separate the two groups so the user understands which gaps block go-live versus which require an ongoing programme.

> **Practical note:** Deployer status is not diminished by outsourcing operational tasks to a vendor or integrator — the legal deployer (the entity using the system "under its own authority," Art. 3(4)) retains Art. 26 accountability.

**6 → Conformity Assessment and CE Marking (Arts. 43–48)**
- Annex III Point 1 systems (biometrics): provider chooses self-assessment (Annex VI) or notified body (Annex VII); third-party mandatory if no harmonised standards applied
- Annex III Points 2–8: self-assessment only
- Annex I product safety components: integrate into existing sectoral conformity procedure
- EU Declaration of Conformity (Art. 47): maintain for 10 years
- CE marking (Art. 48): affix after successful conformity assessment
- EU AI database registration (Art. 49): providers; Art. 60: public authority deployers

**7 → GPAI Obligations (Arts. 53–55 — in force since 2 Aug 2025)**

> ⚠️ **August 2, 2026: AI Office enforcement powers activate.** GPAI providers must be fully compliant with Arts. 53–55 and have their required documentation ready for AI Office review. Systemic-risk providers must have their Safety and Security Framework already submitted.

- **GPAI classification threshold:** Models trained with ≥10²³ FLOPs are subject to GPAI obligations (Commission guidelines, July 2025). Models ≥10²⁵ FLOPs are **presumed to have systemic risk** (Art. 51).
- All GPAI providers: technical documentation (Annex XI), downstream provider information (Annex XII), copyright policy (Directive 2019/790), public training summary
- Open-source exception: only copyright policy and training summary (unless systemic risk)
- Systemic risk additional obligations (Art. 55): Safety and Security Framework (must be established and submitted to AI Office), model evaluation/red-teaming, risk assessment and mitigation, serious incident reporting to AI Office, cybersecurity protections

**GPAI Code of Practice (July 2025):** Published July 10, 2025; endorsed by Commission and AI Board August 1, 2025. Primary compliance pathway for GPAI obligations. Three chapters: (1) Transparency, (2) Copyright, (3) Safety and Security (systemic risk only). Major signatories include Anthropic, Google, Microsoft, OpenAI, Amazon, IBM, Mistral. Non-signatories must demonstrate compliance by alternative means. Legacy GPAI models (placed on market before 2 Aug 2025) have until **2 August 2027** to comply.

**8 → Post-Market Monitoring and Incident Reporting**
- Providers: post-market monitoring plan proportionate to risk (Art. 72)
- Serious incidents: providers report to market surveillance authority; deployers notify provider and market surveillance authority; GPAI systemic risk providers report to AI Office (Art. 73)

## Fundamental Rights Impact Assessment (FRIA, Art. 27)

The FRIA is a deployer-side obligation, distinct from the provider's Art. 9 risk management system and from a GDPR DPIA, though the three overlap and can be run together.

**WHO must perform it (Art. 27(1)):**
- Bodies governed by public law, and private entities providing public services, deploying a high-risk AI system covered by Annex III
- Deployers of Annex III **point 5(b)** systems — creditworthiness assessment and credit scoring of natural persons
- Deployers of Annex III **point 5(c)** systems — life and health insurance risk assessment and pricing for natural persons

The point 5(b)/(c) trigger is deliberately broader than "public body" — it pulls in private banks and insurers precisely because those two use cases carry acute financial-exclusion risk for individuals. A private-sector deployer outside 5(b)/(c) (e.g., a private employer using an Area 4 recruitment tool) is not subject to Art. 27 merely by virtue of deploying an Annex III system — always confirm the deployer falls into one of the three WHO categories before advising a FRIA is mandatory.

**WHAT it contains (Art. 27(1)(a)–(f)):**

| Element | Content |
|---|---|
| Deployer processes | Description of the deployer's processes in which the high-risk system will be used, consistent with its intended purpose |
| Period and frequency of use | The time period and frequency in which the system is intended to be used |
| Categories of affected persons | The categories of natural persons and groups likely to be affected by the use, in the specific context |
| Specific risks of harm | The specific risks of harm likely to have an impact on the affected categories of persons or groups, identified in consultation with the provider's instructions for use |
| Human oversight measures | A description of the implementation of human oversight measures, per the provider's Art. 14 instructions |
| Mitigation and governance arrangements | The measures to be taken in the case of the materialisation of those risks, including internal governance and complaint mechanisms |

**Notification to market surveillance authority:** The deployer must notify the results of the FRIA to the market surveillance authority, using a template provided by the AI Office where available, and complete this **before** putting the high-risk system into use. Treat this as a pre-deployment gate, not a post-hoc filing — a deployer that goes live before notifying has a compliance gap even if the FRIA content itself is complete and accurate.

**Relationship to GDPR DPIAs (Art. 27(4)):** Where a GDPR Art. 35 DPIA is already required for the same processing, the FRIA **may build on** that DPIA — the deployer should conduct them jointly and cross-reference rather than duplicate the risk analysis. A FRIA is not a substitute for a DPIA and vice versa; each addresses a distinct legal test (fundamental rights impact vs. data protection risk), but the underlying fact-finding (affected persons, processing purpose, mitigation measures) is shared. When advising a deployer that already has a mature GDPR programme, the efficient path is: (1) pull the existing DPIA's data-flow and purpose description, (2) extend it with the Art. 27(1) fundamental-rights-specific elements (categories of affected persons beyond data subjects, human oversight measures, governance/complaint arrangements) that a DPIA does not typically cover, and (3) route the combined output through both the Art. 35 and Art. 27 sign-off chains.

**Exemption:** If a deployer has already carried out an assessment under Art. 27 that meets these requirements through another Union or national legal obligation (e.g., an equivalent sector-specific fundamental rights review), it does not need to duplicate the exercise — it should map the existing assessment against the Art. 27(1)(a)–(f) checklist and document any gaps.

**FRIA workflow at a glance:**

| Step | Action | Owner |
|---|---|---|
| 1 | Confirm WHO applicability (public-law body / public-service provider / 5(b) or 5(c) deployer) | Deployer compliance function |
| 2 | Gather Art. 27(1)(a)–(f) inputs, cross-referencing any existing GDPR DPIA | Deployer, with provider's Art. 13 instructions as input |
| 3 | Draft and internally approve the FRIA | Deployer governance / DPO |
| 4 | Notify results to the market surveillance authority | Deployer compliance function |
| 5 | Put the system into use only after Step 4 is complete | Deployer |
| 6 | Re-run or update the FRIA if the use case, affected population, or risk profile materially changes | Deployer compliance function |

## Annex III Area-by-Area Guidance

Use this section to pressure-test a classification call area by area. For each area: identify concrete example systems, then check for common misclassification traps before concluding high-risk status is (or is not) triggered.

| Area | Examples | Common Misclassification Trap |
|---|---|---|
| **1 — Biometrics** | Remote biometric identification for building access; biometric categorisation tools inferring protected attributes | Teams assume "biometric = automatically high-risk" and miss that categorisation/emotion-recognition variants may instead be **outright prohibited** under Art. 5(1)(f)/(g) — the prohibition takes precedence over the high-risk label |
| **2 — Critical Infrastructure** | AI managing electricity grid load balancing; water treatment safety-control AI | Only the **safety component** used in safety-critical management is in scope — a dashboard that merely visualises grid data without a safety-management function is out of scope |
| **3 — Education and Vocational Training** | Automated university admissions scoring; AI proctoring/exam-monitoring tools that flag prohibited behavior | Teams misclassify low-stakes practice-quiz graders as high-risk; the trigger is whether the tool determines **access/admission** or **materially influences** the level/outcome of education received, not any use of AI in an education setting |
| **4 — Employment, Workers Management, Self-Employment** | CV-screening and applicant-ranking software; AI-driven performance monitoring and task allocation | Sourcing/lead-generation tools that merely aggregate job postings (no filtering/ranking of candidates) are often wrongly swept in; the trigger is filtering, screening, evaluating, or deciding — not passive aggregation |
| **5 — Access to Essential Private and Public Services** | Public-benefits eligibility engines; credit-scoring algorithms (5(b)); life/health insurance pricing engines (5(c)) | Fraud-detection scoring is expressly **excluded** from 5(b) — teams over-classify anti-fraud tools; conversely, teams under-classify insurance "risk tiering" tools that function as pricing engines even when marketed as "quote assistance" |
| **6 — Law Enforcement** | Recidivism/reoffending risk-scoring tools; AI evaluating reliability of evidence in a criminal investigation | Internal case-management software that only stores or displays evidence (no evaluative function) is commonly over-classified; the trigger is an **evaluative or predictive** function tied to individuals |
| **7 — Migration, Asylum, Border Control** | AI assessing irregular-migration risk of a traveler; visa/asylum application examination assistants | Pure travel-document **verification** (matching a photo to a passport chip) is expressly excluded from 7(d) — teams conflate verification with the in-scope "detecting, recognizing, or identifying" function |
| **8 — Administration of Justice and Democratic Processes** | AI assisting judges in legal research and case-law retrieval; AI systems intended to influence election outcomes or voter behavior | Legal-research tools used only by private law firms (not "judicial authorities... in researching and interpreting facts and the law") fall outside 8(a); scope turns on the **user's institutional role**, not the technology |

### Art. 6(3) Filter and Derogation

Even where a system is literally listed in Annex III, it is **not** high-risk if it satisfies one of the narrow Art. 6(3) exceptions:
- Performs a **narrow procedural task** only
- **Improves the result** of a previously completed human activity (does not replace or influence the original human judgment)
- **Detects decision-making patterns or deviations** from prior patterns, without being meant to replace or influence the previously completed human assessment
- Performs a **preparatory task** to an assessment relevant to an Annex III use case

**Profiling carve-out (Art. 6(3), final subparagraph):** Regardless of the above, any Annex III system that performs **profiling of natural persons** (Art. 3(52) — automated processing of personal data to evaluate aspects