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)

See 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 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 t