--- name: ai-act-high-risk description: | EU AI Act High-Risk Classification — depth assessment of whether an AI system is high-risk under Art. 6 AI Act, grounded in the Commission's draft Art. 6(5) classification guidelines (general principles + Annex I + Annex III). This skill should be used when the user asks to "assess high-risk status under the AI Act", "check Annex I", "check Annex III", "apply the Art. 6 classification", "check Art. 6(3) exception", "is our AI system high-risk", "perform safety component analysis", "check third-party conformity assessment trigger", or mentions "Hochrisiko-Einstufung", "Hochrisiko-KI-System", "Sicherheitsbauteil", "Anhang I", "Anhang III", "Anhang III Nr. X" under the AI Act. For broad risk-tier classification (prohibited / high-risk / GPAI / limited / minimal), use ai-act-classifier; for Q&A and article lookup, use ai-act-knowledge. metadata: author: Oliver Schmidt-Prietz license: AGPL-3.0 version: 1.2 --- # EU AI Act High-Risk Classification Depth assessment of whether an AI system is **high-risk** under **Art. 6 AI Act** (Regulation (EU) 2024/1689), grounded in the European Commission's draft Art. 6(5) classification guidelines (general principles, Annex I, Annex III) published for stakeholder consultation in 2026. ## Disclaimer (show at session start, do not block) > **Important:** This skill provides structured high-risk classification guidance based on the EU AI Act (Regulation (EU) 2024/1689) and the Commission's draft Art. 6(5) classification guidelines (general principles, Annex I, Annex III) issued for stakeholder consultation. The Commission guidelines are non-binding; authoritative interpretation rests with the Court of Justice of the EU. This is not legal advice. Final classification decisions should involve qualified legal counsel with AI Act expertise. --- ## When to use this skill - The user has already concluded (via `ai-act-classifier` or otherwise) that high-risk is the likely tier and needs the **depth assessment**. - A high-risk verdict is consequential (FRIA may apply, Chapter III conformity assessment regime, post-market monitoring, registration in EU database). - The user explicitly asks for Annex I or Annex III analysis. - The user is uncertain whether a borderline AI system is high-risk and needs the Commission-guideline-grounded reasoning. For broad risk-tier triage (prohibited / high-risk / GPAI / limited / minimal), route to `ai-act-classifier` first. For Q&A on any AI Act article without a classification verdict, use `ai-act-knowledge`. --- ## Effective dates (per AI Omnibus 2026) | Provision | Original date (Art. 113) | **Postponed date (AI Omnibus)** | |-----------|--------------------------|----------------------------------| | Art. 6(2) + Annex III obligations | 2 August 2026 | **2 December 2027** | | Art. 6(1) + Annex I obligations | 2 August 2027 | **2 August 2028** | | Art. 111(2) legacy cut-off | 2 August 2026 | **2 December 2027** | See [references/ai-omnibus-timeline-postponements.md](references/ai-omnibus-timeline-postponements.md) for citation chain. --- ## Required inputs Before beginning, gather from the user: 1. **System description** — what does it do, who built it, who uses it, what is the intended purpose stated by the provider. 2. **Intended-purpose evidence** — instructions for use, technical documentation, promotional materials, terms of service, sales materials. The provider's framing matters per ¶¶10–13 of the general-principles guidelines. 3. **Deployment context** — sector (machinery, medical, employment, education, law enforcement, etc.), is the user the provider, deployer, importer, or distributor. 4. **Modification status** — is the user the original provider or did they fine-tune / rebrand / substantially modify a third-party system (Art. 25 trap). If any of these is missing, ask before proceeding. Classifications based on incomplete information must be flagged as preliminary. --- ## Decision tree Run the five steps in order. Each step either terminates with a verdict or feeds the next. ### Step 1 — AI system gating (Art. 3(1)) Confirm the technology meets the Art. 3(1) AI system definition. If it does not (e.g., pure rule-based software with no inference, no learning, no autonomy), the AI Act does not apply → terminate as **not in AI Act scope**. Reference: see Commission Guidelines on the definition of an artificial intelligence system, C(2025) 5053 (separate from these high-risk guidelines). ### Step 2 — Intended-purpose framing (Art. 3(12); general principles ¶¶10–13) Document the provider's stated intended purpose. Apply the **GPAI / multi-purpose trap** test: - If the provider's materials present the system as broadly applicable across many contexts and do not consistently exclude high-risk uses → the intended purpose is **deemed** to encompass high-risk uses (¶12). - Merely asserting in terms-of-service that high-risk use is excluded is **insufficient** if other materials (promotional, examples, product positioning) suggest such uses are feasible and reasonably foreseeable (¶12). - Capture but exclude from this assessment: Art. 3(13) "reasonably foreseeable misuse" — by definition outside intended purpose. Output of Step 2: a clean, documented intended-purpose statement to use in Steps 3 and 4. ### Step 3 — Art. 6(1) / Annex I branch Apply this branch in full **before** Step 4. The two branches are not mutually exclusive: a system can be high-risk under both Art. 6(1) and Art. 6(2) (in which case the Art. 6(1) conformity-assessment integration applies — see Art. 8(2) and Art. 102–109). #### 3a. Is the AI system a product / safety component under Annex I? Screen against the Union harmonisation legislation listed in Annex I AI Act (machinery, toys, lifts, ATEX, radio equipment, pressure equipment, recreational craft, cableways, gas appliances, MDR, IVDR, automotive, aviation, etc.). Distinguish: - **AI system is itself a regulated product** (¶30): independently placed on market, has own intended purpose, directly regulated. Example: machinery-related software under Reg. (EU) 2023/1230. - **AI system is a safety component of a regulated product** (¶31). If neither applies → skip to Step 4. #### 3b. Safety-component two-prong test (Art. 3(14); ¶¶32–49) Apply BOTH alternative scenarios — either is sufficient: **Scenario (i) — Safety function (intent-based, ¶¶35–37)** The system constitutes a safety component if the provider's intended purpose is to prevent or mitigate risks to health, safety, or property. Use this checklist (from ¶37 box): - **Preventive functions** (any one): monitoring/detection of harm-leading situations; maintenance/inspection detection; harm prevention; supervision of another safety system. - **Mitigation functions** (any one): control or limitation of physical harm; mitigation of consequences (e.g., safe-stop); control of another safety system. - **NOT safety functions**: performance optimisation, service efficiency, automation of user decisions, comfort/convenience, quality control of non-safety aspects. See [references/safety-function-checklist.md](references/safety-function-checklist.md) for the full taxonomy and worked examples. **Scenario (ii) — Failure or malfunctioning (consequences-based, ¶¶38–43)** The system constitutes a safety component if its failure or malfunctioning could endanger health, safety, or property. Failure modes include: incorrect outputs (false positives/negatives), loss of function/availability, performance instability/drift, timing/latency errors, misclassification leading to hazardous control decisions. The likelihood must be more than theoretical (¶39). Worked examples from ¶46: - Lifts: AI for door closing / obstacle detection → safety component via failure (efficiency intent, but malfunction injures persons). - Vehicles: lane-assist AI → safety component via failure. - Agriculture: chemical-spray targeting AI → safety component via failure if persons nearby. - Smart thermostat (¶48 footnote 5): NOT a safety component except where it controls child-lock or operates around vulnerable users. Output of Step 3b: if (i) OR (ii) is satisfied → continue to Step 3c. Otherwise, this is not a safety component → skip to Step 4. #### 3c. Third-party conformity assessment requirement (¶¶50–59) Look up the conformity assessment procedure required by the relevant Annex I legal act: - **Modules B, C1, C2, D, D1, E, E1, F, F1, G, H, H1 (Decision 768/2008/EC)** → involve a notified body → third-party conformity assessment required → **YES**. - **Module A** (pure internal control) without harmonised-standards condition → not third-party → **NO**. - **Module A conditioned on mandatory application of harmonised standards** (e.g., Toys Safety Regulation, Machinery Regulation, Radio Equipment Regulation) → still classified as high-risk; the option to use Module A is procedural flexibility, not a discretion to escape high-risk classification (¶57; Toys Safety Reg. Recital 15). If module is A without mandatory-harmonised-standards condition → not high-risk under Art. 6(1). #### 3d. Section A vs Section B distinction (Annex I; Art. 2(2)) If 3a + 3b + 3c all YES → **high-risk under Art. 6(1)**. Record: - Annex I citation (specific legal act). - Whether the legal act is in Annex I **Section A** (NLF-based) — full Chapter III requirements apply. - Or **Section B** (other Union harmonisation legislation, e.g., aviation, automotive) — only Art. 6(1), 102–109, 112 apply per Art. 2(2). See [references/annex-i-section-a-vs-b.md](references/annex-i-section-a-vs-b.md) for the full mapping. ### Step 4 — Art. 6(2) / Annex III branch #### 4a. Map to the eight Annex III areas Cross-check the system's intended purpose against each of the eight areas. Use the corresponding per-area reference file: | # | Area | Reference | |---|------|-----------| | 1 | Biometrics | [annex-iii-area-1-biometrics.md](references/annex-iii-area-1-biometrics.md) | | 2 | Critical infrastructure | [annex-iii-area-2-critical-infrastructure.md](references/annex-iii-area-2-critical-infrastructure.md) | | 3 | Education and vocational training | [annex-iii-area-3-education.md](references/annex-iii-area-3-education.md) | | 4 | Employment, workers management, access to self-employment | [annex-iii-area-4-employment.md](references/annex-iii-area-4-employment.md) | | 5 | Access to and enjoyment of essential private and public services and benefits | [annex-iii-area-5-essential-services.md](references/annex-iii-area-5-essential-services.md) | | 6 | Law enforcement | [annex-iii-area-6-law-enforcement.md](references/annex-iii-area-6-law-enforcement.md) | | 7 | Migration, asylum, border control management | [annex-iii-area-7-migration.md](references/annex-iii-area-7-migration.md) | | 8 | Administration of justice and democratic processes | [annex-iii-area-8-justice-democracy.md](references/annex-iii-area-8-justice-democracy.md) | For each area where there is a use-case match, capture the specific Annex III sub-point (e.g., Nr. 4(a) for recruitment). #### 4b. Apply the Art. 6(3) exception filter If a use case matches in Step 4a, check whether the AI system performs **only** one of the following narrow categories (Art. 6(3)): - **(a) Narrow procedural task** — strictly procedural, no influence on outcome. - **(b) Improvement of a previously completed human activity** — refining what a human already decided. - **(c) Detection of decision-making patterns or deviations** — without replacing or influencing previously completed human assessment. - **(d) Preparatory task to an assessment** relevant to the Annex III use case. See [references/art-6-3-exception-decision-tree.md](references/art-6-3-exception-decision-tree.md). #### 4c. Apply the profiling re-exception (Art. 6(3) last sentence) If the system performs **profiling of natural persons** (Art. 4(4) GDPR — automated processing of personal data to evaluate personal aspects), the Art. 6(3) exception is **excluded** and the system **is** high-risk. #### 4d. Documentation duty if exception applies (Art. 6(4)) If the exception applies → not high-risk, BUT the provider must: - Document the reasoning before placing on the market / putting into service (Art. 6(4)). - Register the system in the EU database per Art. 49(2). ### Step 5 — Art. 25 substantial-modification trap If the user is not the original provider but is modifying, fine-tuning, or rebranding an existing AI system, flag Art. 25(1): - (a) Putting their own name/trademark on an existing high-risk system. - (b) Substantial modification to an existing high-risk system. - (c) Modifying the intended purpose of a non-high-risk system (including GPAI) such that it becomes high-risk under Art. 6. If any apply → the user becomes a **provider** of a high-risk system with full Chapter III obligations. Refer to `ai-act-roles` for the role-determination workflow. The Commission is preparing separate Art. 25 guidelines; this skill flags only. See [references/art-25-substantial-modification-flag.md](references/art-25-substantial-modification-flag.md). --- ## Output artefacts Produce all three artefacts unless the user explicitly requests a subset. ### Artefact 1 — Structured decision block (terminal) ``` ═══════════════════════════════════════════ EU AI Act — High-Risk Classification Result ═══════════════════════════════════════════ High-risk verdict: [YES — Art. 6(1) Annex I | YES — Art. 6(2) Annex III Nr. X | NO] Basis: [Safety function / Failure-based / Annex III use-case match] Annex I citation: [Legal act + Section A/B] (if applicable) Annex III citation: [Nr. X.] (if applicable) Art. 6(3) exception: [N/A | Applied — limb (a/b/c/d) | Excluded by profiling re-exception] Art. 25 trap: [Not triggered | Watch — modifying existing system] Effective date: [2 December 2027 (Annex III) | 2 August 2028 (Annex I)] Documentation duty: [Art. 6(4) (if Art. 6(3) applied) | Chapter III + Art. 11 technical docs] ═══════════════════════════════════════════ ``` ### Artefact 2 — Practitioner memo (1–2 page narrative) Markdown memo addressed to a DPO / AI compliance officer. Sections: 1. **System under assessment** — name, provider/deployer, intended purpose (the cleaned Step 2 statement). 2. **Verdict and reasoning** — which branch (6(1) or 6(2)), which sub-test triggered it, which paragraph of the Commission guidelines is the anchor. 3. **Citations** — explicit paragraph numbers from the Commission guidelines and the corresponding article numbers. 4. **Routing** — point to `ai-act-roles` for role determination, `ai-act-obligations` for the obligation matrix, `ai-act-report` for the formal report. 5. **Open questions** — anything that needs counsel input before finalisation. ### Artefact 3 — JSON interchange artefact The cross-skill interchange JSON. Schema (matches the existing repo convention): ```json { "skill": "ai-act-high-risk", "version": "", "assessed_at": "2026-MM-DD", "system_name": "", "intended_purpose": "", "verdict": "high_risk" | "not_high_risk" | "exempt_art_6_3", "basis": { "article": "6(1)" | "6(2)" | null, "annex": "I" | "III" | null, "annex_item": "Nr. X" | "Nr. Y." | null, "section_a_or_b": "A" | "B" | null }, "art_6_3_exception": { "applied": true | false, "limb": "a" | "b" | "c" | "d" | null, "profiling_excluded": true | false }, "art_25_trap_flag": true | false, "effective_date": "2027-12-02" | "2028-08-02", "citations": [ {"source": "Commission Guidelines Annex III ¶123"}, {"source": "Annex III Nr. 4(a) AI Act"} ], "downstream_routing": ["ai-act-roles", "ai-act-obligations", "ai-act-report"] } ``` --- ## References - [art-6-general-principles.md](references/art-6-general-principles.md) — Commission's general principles (¶1–14, ¶448–451). - [art-6-1-annex-i-guidelines.md](references/art-6-1-annex-i-guidelines.md) — Commission's Annex I section (¶15–62). - [art-6-2-annex-iii-guidelines.md](references/art-6-2-annex-iii-guidelines.md) — Commission's Annex III section (¶63–447). - [safety-function-checklist.md](references/safety-function-checklist.md) — taxonomy of safety functions from ¶37 box. - [annex-i-section-a-vs-b.md](references/annex-i-section-a-vs-b.md) — Section A (NLF) vs Section B (other) mapping. - 8 × per-area Annex III files (see Step 4a table). - [art-6-3-exception-decision-tree.md](references/art-6-3-exception-decision-tree.md) — exception filter with worked examples. - [art-25-substantial-modification-flag.md](references/art-25-substantial-modification-flag.md) — quasi-provider trap. - [ai-omnibus-timeline-postponements.md](references/ai-omnibus-timeline-postponements.md) — postponement citation chain. ## Related skills - **`ai-act-classifier`** — broad risk-tier triage; routes to this skill for high-risk depth. - **`ai-act-knowledge`** — Q&A over the full AI Act + Commission guidelines (now including the three guideline documents this skill is built on). - **`ai-act-roles`** — provider / deployer / importer / distributor determination, including Art. 25. - **`ai-act-obligations`** — once high-risk verdict is in, maps obligations by role + risk tier. - **`ai-act-report`** — formal compliance report generation. - **`ai-act-quick`** — 15–25 min preliminary assessment; routes here for full Art. 6 depth. ## Changelog See [CHANGELOG.md](CHANGELOG.md).