lawve-ai/eu-ai-act-high-risk-classifier-oliver-schmidt-prietz
Depth assessment of whether an AI system is high-risk under Art. 6 of the EU AI Act, grounded in the Commission's draft Art. 6(5) classification guidelines (general principles + Annex I + Annex III). Covers the Annex I product-safety route, all eight Annex III areas with worked examples, the Art. 6(3) exception and its profiling re-exception, and the Art. 25 quasi-provider trap. Outputs a structured decision block, a practitioner memo, and a JSON interchange artefact.
npx skills add https://github.com/lawve-ai/awesome-legal-skills --skill eu-ai-act-high-risk-classifier-oliver-schmidt-prietz
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.
> 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.
If the AI system has not yet been triaged across all five risk tiers (prohibited / high-risk / GPAI / limited / minimal), do that breadth-first triage before the Annex I / Annex III depth analysis below. For a pure article-lookup question without a classification verdict, answer it directly with the cited regulation text rather than running the full depth assessment.
| 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 for citation chain.
Before beginning, gather from the user:
If any of these is missing, ask before proceeding. Classifications based on incomplete information must be flagged as preliminary.
Run the five steps in order. Each step either terminates with a verdict or feeds the next.
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).
Document the provider's stated intended purpose. Apply the GPAI / multi-purpose trap test:
Output of Step 2: a clean, documented intended-purpose statement to use in Steps 3 and 4.
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).
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:
If neither applies → skip to Step 4.
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):
See 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:
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.
Look up the conformity assessment procedure required by the relevant Annex I legal act:
If module is A without mandatory-harmonised-standards condition → not high-risk under Art. 6(1).
If 3a + 3b + 3c all YES → high-risk under Art. 6(1). Record:
See references/annex-i-section-a-vs-b.md for the full mapping.
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 |
| 2 | Critical infrastructure | annex-iii-area-2-critical-infrastructure.md |
| 3 | Education and vocational training | annex-iii-area-3-education.md |
| 4 | Employment, workers management, access to self-employment | 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 |
| 6 | Law enforcement | annex-iii-area-6-law-enforcement.md |
| 7 | Migration, asylum, border control management | annex-iii-area-7-migration.md |
| 8 | Administration of justice and democratic processes | 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).
If a use case matches in Step 4a, check whether the AI system performs only one of the following narrow categories (Art. 6(3)):
See references/art-6-3-exception-decision-tree.md.
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.
If the exception applies → not high-risk, BUT the provider must:
If the user is not the original provider but is modifying, fine-tuning, or rebranding an existing AI system, flag Art. 25(1):
If any apply → the user becomes a provider of a high-risk system with full Chapter III obligations. Follow up with a role-determination step (provider / deployer / importer / distributor under Art. 3 and Art. 25). The Commission is preparing separate Art. 25 guidelines; this skill flags only.
See references/art-25-substantial-modification-flag.md.
Produce all three artefacts unless the user explicitly requests a subset.
═══════════════════════════════════════════
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.<sub>] (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]
═══════════════════════════════════════════
Markdown memo addressed to a DPO / AI compliance officer. Sections:
The cross-skill interchange JSON. Schema (matches the existing repo convention):
{
"skill": "ai-act-high-risk",
"version": "1.0",
"assessed_at": "2026-MM-DD",
"system_name": "<provider-supplied name>",
"intended_purpose": "<cleaned Step 2 statement>",
"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.<sub>" | 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"}
],
"next_steps": ["role-determination", "obligation-mapping", "compliance-report"]
}
A high-risk depth assessment usually sits inside a larger workflow. Once this skill has produced the verdict, the natural next steps are:
See CHANGELOG.md.
This skill works on its own, but it's designed to interlock with my other EU AI Act skills — install any individually, or use them together for an end-to-end workflow:
Each is available as a separate skill — install only what you need.
Take lawve-ai/eu-ai-act-high-risk-classifier-oliver-schmidt-prietz from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.