EU AI Act high-risk classification is a legal determination about an AI system's intended purpose and context, not a general opinion that the technology feels risky. The same model can sit inside systems with different classifications. A resume summarizer, candidate-ranking engine, employee scheduling assistant, and public chatbot may share a model while their functions, affected people, decision roles, and regulatory treatment differ. Screen the use case at system level and preserve the evidence behind every branch.
Begin with Regulation (EU) 2024/1689, especially definitions, prohibited practices, Article 6, Annex I, and Annex III. Commission summaries and guidance aid implementation but do not displace the text. As of July 13, 2026, the Commission's high-risk classification guidance is still presented as draft and under consultation, so record its status rather than citing examples as settled law.
Use a fixed EU AI Act high-risk classification sequence
First decide whether the product or workflow contains an AI system within scope. Next screen prohibited practices because prohibited is not a more severe form of high-risk; it is a different result. Then test the Article 6(1) product-safety route and the Article 6(2) Annex III route. For an apparent Annex III match, evaluate the Article 6(3) conditions under which a system may not pose a significant risk of harm, while checking the profiling rule. Finally assess transparency, GPAI, sector, data-protection, consumer, employment, and other duties that may still apply.
Keep an answer for every branch, including not applicable. A short form should capture AI-system rationale, intended purpose, provider instructions, actual use, decision influence, affected people, geography, Annex references, exclusion reasoning, legal reviewer, evidence, and change triggers. Do not begin with a static list of product names. The classification follows what the system is intended and configured to do.
Test the regulated-product route under Article 6(1)
An AI system is high-risk through the product route when it is intended as a safety component of a product, or is itself a product, covered by specified Union harmonization legislation and the relevant product requires third-party conformity assessment. Both conditions matter. Identify the exact product, legislation, safety function, manufacturer, conformity route, and intended purpose. Involve product-safety specialists because software teams may not know the assessment status of the containing machinery, medical device, toy, lift, vehicle, or other regulated product.
A component can influence safety without being the legally relevant safety component, and a regulated product does not automatically make every embedded AI function high-risk. Conversely, a vendor describing a feature as optional does not settle whether the integrated product relies on it for safety. Preserve architecture diagrams, hazard analysis, product documentation, and conformity decisions.
Match Annex III by intended purpose, not industry label
Annex III lists particular uses within areas including biometrics, critical infrastructure, education, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice and democratic processes. The Commission's navigation FAQ stresses that classification depends on function, specific purpose, and modalities, not merely the sector.
| Screening question | Strong evidence | Weak shortcut | Reviewer |
|---|---|---|---|
| What is the intended purpose? | Instructions, requirements, marketing, technical file | Team nickname | Product and legal |
| Does an Annex III use match? | Element-by-element mapping | Industry appears on a list | Legal and domain |
| How does output affect a decision? | Workflow, authority, override, downstream automation | Human is somewhere in loop | Process owner |
| Who is affected? | Population, scale, vulnerability, recourse | Users only | Impact and privacy |
| Could Article 6(3) apply? | Documented task and significance analysis | Low internal risk score | Qualified counsel |
Write a claim chart: quote or paraphrase each relevant legal element, state the system fact, link the evidence, and explain match or mismatch. This prevents a generic employment tool from being treated the same as a candidate filter, or a school administration tool from being treated the same as a system evaluating learning outcomes. Ambiguous intended-purpose language should be corrected with the provider before acquisition or release.
Apply Article 6(3) exclusions cautiously
An Annex III system may not be high-risk when it does not pose a significant risk of harm to health, safety, or fundamental rights and does not materially influence decision-making, including specified situations such as narrow procedural or preparatory tasks. The enacted conditions and profiling treatment must be analyzed exactly. An internal label such as copilot, assistant, or recommendation does not establish the exclusion.
Document the decision pathway, weight of the output, human competence and authority, time pressure, automation bias controls, override practice, and consequences. If staff routinely rubber-stamp outputs, formal human review may not prevent material influence. Review the Commission's draft classification guidelines for current examples, while clearly recording their draft status and consultation context.
Build a classification file that engineering can maintain
The file should contain system boundary, AI definition assessment, intended and reasonably foreseeable uses, prohibited-practice screen, product-route analysis, Annex III analysis, Article 6(3) reasoning, profiling check, role map, affected populations, decision workflow, supporting artifacts, counsel approval, source versions, effective date, and triggers. Link it to the system inventory rather than burying it in email.
| Change event | Why classification may change | Required response | Release control |
|---|---|---|---|
| New use case | Different Annex III purpose or affected right | Repeat use-case screen | Block unapproved configuration |
| Higher autonomy | Output may materially influence decisions | Reassess exclusion and oversight | Approval and evaluation gate |
| New population or geography | Different impact or territorial scope | Update affected-person analysis | Regional feature control |
| Provider changes instructions | Intended-purpose evidence changed | Reconcile actual and permitted use | Contract and configuration review |
| Integration into regulated product | Article 6(1) route may apply | Engage product-safety owner | Conformity change control |
Separate classification work from deadline speculation
Classification should happen now because it influences architecture, data, evaluation, contracts, and operating controls. The Commission's high-risk guidance page reports the post-political-agreement timeline of December 2, 2027 for specified stand-alone high-risk areas and August 2, 2028 for systems integrated into products, while noting that draft guidance is being finalized. Confirm the final legal instrument and applicable date with counsel before relying on a deadline.
Use the additional preparation time to build evidence rather than defer classification. Link the decision to compliance-ready delivery, threat modeling, and a durable audit trail. A late high-risk determination can force redesign of logging, oversight, data governance, vendor contracts, and quality management.
Assign decision rights and challenge
Product owns factual accuracy about intended use and workflow. Engineering owns system boundary and technical evidence. Legal confirms regulatory interpretation. Risk and impact specialists challenge assumptions about affected people and influence. The business owner accepts operating constraints. Require independent challenge for borderline or consequential cases, and record minority views. The AI governance operating model can place this review in an existing council.
Use examples as tests, not substitutes for analysis
Build internal examples only after completing element-by-element analysis. For each approved example, describe system boundary, intended purpose, affected people, decision influence, configuration, evidence, conclusion, and date. Pair it with a near neighbor that reaches a different result, such as administrative scheduling versus worker evaluation. Contrastive examples teach reviewers which facts matter better than a long list of labels.
When Commission examples or final guidance change, identify which internal precedents rely on the changed interpretation. Do not overwrite old decisions; supersede them and trigger reassessment for linked systems. Record whether the organization follows guidance, departs with legal rationale, or awaits clarification. This creates a controlled interpretation history rather than inconsistent opinions across product teams.
Quality-review classification work by sampling false negatives as well as flagged cases. Search inventory descriptions for Annex III functions, consequential decisions, safety components, and profiling that were classified low or out of scope. Teams naturally scrutinize obvious high-risk uses while missing quietly repurposed features. Use findings to improve intake questions, reviewer training, and technical controls on unsupported uses.
Do not let an internal risk tier replace the legal analysis. Enterprise tiers can appropriately consider financial, reputational, operational, or strategic exposure beyond the Act, and may assign stricter controls to a legally non-high-risk system. Store both results and their separate methods. Dashboards should make the distinction visible so leaders do not infer that a green internal score means out of scope, or that every high internal risk is an Annex III system.
Create a rapid consultation path for teams that discover a possible high-risk use during development. The response should provide an interim constraint, required facts, legal owner, and decision date. Without a fast path, teams either stop unnecessarily or continue under uncertainty. Track recurring questions and improve intake language, provider instructions, and examples so classification becomes earlier and more predictable across the portfolio.
Key takeaways
- Classify the AI system and intended use, not the underlying model or vendor brand in isolation.
- Screen scope and prohibited practices before the two Article 6 high-risk routes.
- Match Annex III element by element and preserve evidence about decision influence and affected people.
- Treat Commission high-risk examples as draft guidance until finalized.
- Reclassify when purpose, autonomy, population, geography, provider instructions, or product integration changes.
Frequently asked questions
Is a foundation model itself a high-risk AI system?
High-risk system classification generally depends on the downstream system and intended use. A GPAI model has a separate model-level regime, while a system integrating it may be high-risk.
Does human review make a system non-high-risk?
Not automatically. Analyze how the output influences the decision, the reviewer's competence and authority, actual override practice, and the exact legal route or exclusion being considered.
Can we rely on the vendor's classification?
Use it as evidence, not the entire analysis. Your configured purpose, population, workflow, integrations, role, and jurisdiction may differ. Require enough documentation to reproduce the conclusion.
Conclusion
A defensible EU AI Act high-risk classification method is sequential, factual, and versioned. Define the system, screen prohibitions, test both Article 6 routes, analyze any exclusion precisely, and document the decision's evidence and triggers. This gives legal, product, engineering, and risk teams one reproducible answer while leaving room to update it as the system and implementation guidance evolve.