Is Your AI System High-Risk? A Decision Tree Through Annex III

Route 1: The Annex I Safety Component Test

Determining whether your machine learning architecture falls into the high-risk tier under Regulation (EU) 2024/1689 requires navigating two separate statutory gates, set out in Article 6(1) and Article 6(2) of the Regulation. Before evaluating high-risk criteria, ensure your deployment does not run afoul of Article 5 prohibited practices, which we detail in our prohibited AI checklist. Once cleared of absolute bans, the first statutory gate to evaluate is Article 6(1), which governs artificial intelligence integrated into regulated physical products and industrial systems.

The Conjunctive Test Under Article 6(1)

Article 6(1) establishes a strict conjunctive legal test. An AI system is classified as high-risk under Route 1 if, and only if, both of the following statutory conditions are fulfilled simultaneously:

1. Condition A (Product Scope): The AI system is intended to be used as a safety component of a product, or is itself a product, covered by the Union harmonisation legislation listed in Annex I.
2. Condition B (Conformity Procedure): The product whose safety component is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment with a view to placing it on the market or putting it into service under that Annex I legislation.

Why Ignoring the Second Limb Over-Classifies Software

Engineering teams frequently misinterpret Article 6(1) by stopping after Condition A. Annex I covers extensive Union legislation, including the Machinery Regulation (EU) 2023/1230, the Medical Devices Regulation (EU) 2017/745, Toy Safety Directive 2009/48/EC, and Civil Aviation Regulation (EU) 2018/1139. However, if an embedded model acts as a safety component for industrial machinery where the underlying sectoral directive permits internal production control (Module A self-assessment) rather than mandatory notified-body assessment, Condition B is not met. Such software does not enter the high-risk tier through Route 1.

Route 2: The Annex III Use-Case Mapping

If your application is not a safety component of an Annex I regulated physical product, it bypasses Route 1 entirely. You must then evaluate Route 2 under Article 6(2), which provides that the AI systems referred to in Annex III shall be considered to be high-risk. Route 2 classifies systems strictly by their intended purpose rather than model architecture, parameter count, or training compute. Whether you deploy a small fine-tuned model or an orchestrated cluster of mixture-of-experts models, classification depends on how the output affects natural persons across the domains listed in Annex III. For an overview of how this fits into the broader risk framework, see our classification framework.

The Eight Standalone Annex III Risk Domains

To determine whether your software matches an Annex III use case, test your system's operational objective against the eight statutory domains:

• 1. Biometrics: Remote biometric identification systems (excluding purely 1:1 biometric verification to confirm an asserted identity), biometric categorisation inferring sensitive or protected attributes, and emotion recognition systems.
• 2. Critical Infrastructure: Safety components in the management and operation of critical digital infrastructure, road traffic, or the public supply of water, gas, heating, or electricity.
• 3. Education and Vocational Training: Systems determining admission, assigning individuals to institutions, evaluating learning outcomes to steer educational paths, assessing access levels, or detecting prohibited student behaviour during tests.
• 4. Employment and Worker Management: Systems used for targeted recruitment advertising, job application filtering, candidate evaluation, task allocation based on personal traits, or monitoring worker performance and contractual terms.
• 5. Essential Private and Public Services: Systems evaluating eligibility for public assistance, credit scoring and creditworthiness assessments (excluding financial fraud detection), life and health insurance risk pricing, or emergency call dispatch and medical triage prioritisation.
• 6. Law Enforcement: Individual victim risk assessments, polygraphs, evidence reliability evaluations, re-offending risk assessments, and criminal profiling tools.
• 7. Migration, Asylum, and Border Control: Polygraphs, security and irregular migration risk assessments, visa and asylum application examination assistants, and biometric identification tools.
• 8. Administration of Justice and Democratic Processes: Judicial research tools used to interpret facts and law in dispute resolution, or systems intended to directly influence voting behaviour in elections and referenda.

If your intended purpose does not touch any of these eight areas, your system exits the high-risk framework. If it matches one of these domains, you proceed directly to the Article 6(3) derogation analysis.

Article 6(3): The Four Conditions for Derogation

Landing within an Annex III use case does not automatically make your system high-risk. Article 6(3) introduces a statutory derogation: an Annex III system is not considered high-risk if it does not pose a significant risk of harm to the health, safety, or fundamental rights of natural persons, including by not materially influencing the outcome of decision-making.

The Four Concrete Statutory Limbs

The law does not leave this risk assessment to subjective intuition. Under Article 6(3), a system avoids the high-risk designation if it satisfies at least one of four explicit conditions:

1. Narrow Procedural Task: The system performs a narrow procedural task, such as formatting raw text, transforming data schemas, or classifying document types without evaluating the substantive content against subjective human criteria.
2. Improving Completed Human Activity: The system is designed to improve or polish the result of a previously completed human activity, such as syntax checking or stylistic editing of a performance review drafted by a human manager.
3. Pattern Detection Without Replacing Review: The system detects decision-making patterns or deviations from historical decisions, designed purely as an analytical aid that does not replace or influence human assessment without proper human review.
4. Preparatory Task: The system performs a preparatory administrative task for an Annex III assessment, such as handling OCR document ingestion, deduplication, or indexing candidate CVs without ranking or scoring them.

A Strict Legal Test, Not a Risk Vibe

Engineering leads often treat Article 6(3) as a general license to declare their tooling safe. It is not. If your software influences the final decision or scores candidates in an Annex III domain, claiming low risk without satisfying one of the four objective limbs fails the statutory requirement. Meeting one condition provides the legal basis to claim non-high-risk status, provided the profiling override does not apply.

The Profiling Override

The derogation mechanism under Article 6(3) contains an absolute carve-out. The final subparagraph of Article 6(3) dictates that an AI system falling under Annex III shall always be considered high-risk if it performs profiling of natural persons.

Defining Profiling Under the AI Act

The AI Act aligns its definition of profiling with Article 4(4) of the GDPR (Regulation (EU) 2016/679). Profiling consists of any automated processing of personal data to evaluate specific personal aspects of a natural person, particularly to analyse or predict their performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location, or movements.

If your model infers traits, predicts personal performance, or builds behavioral scores, the profiling override instantly nullifies all four derogation conditions. The system is classified as high-risk with no path to exemption.

The Paperwork Exit: Article 6(4) and Registration

Successfully qualifying for the Article 6(3) derogation does not release a provider from compliance duties. Instead, it routes the system into what is known as the paperwork exit under Article 6(4).

Pre-Market Documentation and Competent Authority Access

Under Article 6(4), any provider who concludes that an Annex III system is not high-risk based on Article 6(3) must document its assessment before placing the system on the market or putting it into service. This assessment must record the exact architectural bounds, the specific derogation limb relied upon, and empirical evidence showing why the system does not materially influence decision outcomes. This documentation must be made available to national competent authorities upon request.

The Article 49(2) EU Database Registration Mandate

In addition to internal documentation, Article 6(4) subjects the provider to mandatory registration under Article 49(2). Before commercial deployment, the provider must register itself and the derogated system in the public EU database managed by the European Commission under Article 71. Operating an unregistered, derogated Annex III model constitutes a direct compliance violation.

• Draft Technical Assessment: Produce an engineering record detailing why the system meets one of the four Article 6(3) conditions prior to launch.
• Verify No Profiling: Document that no GDPR Article 4(4) profiling mechanisms are active within the inference pipeline.
• Register in EU Database: Complete the provider and system registration required under Article 49(2).
• Maintain Audit Readiness: Retain model weights, prompt templates, and evaluation logs for presentation to national market surveillance authorities.

Exit States: Provider, Deployer, and Role Flips

Your traversal through the decision tree concludes in one of four distinct exit states. Each state carries a specific obligation bundle and a rigid timeline for enforcement, as outlined in our compliance timeline.

The Four Definitive Exit States

1. Exit State 1 (High-Risk Provider): Triggered via Route 1 or Route 2 without derogation. Providers must implement a comprehensive Quality Management System (Article 17), continuous Risk Management (Article 9), technical documentation (Article 11), automatic logging (Article 12), human oversight tools (Article 14), cybersecurity and robustness safeguards (Article 15), complete conformity assessment, and affix the CE mark before market entry.
2. Exit State 2 (High-Risk Deployer): Triggered when operating a high-risk system built by a third party. Deployers must use the system per instructions (Article 26), ensure human oversight, maintain generated logs for at least six months, and conduct a Fundamental Rights Impact Assessment under Article 27 if acting as a public body or private entity providing essential public services.
3. Exit State 3 (Annex III Derogated): Triggered when an Annex III system meets an Article 6(3) condition without profiling. Providers must maintain Article 6(4) documentation and complete Article 49(2) registration.
4. Exit State 4 (Outside High-Risk Scope): Systems outside Annex I and Annex III. Providers and deployers remain subject only to Article 4 AI literacy obligations (in force since 2 February 2025) and Article 50 transparency requirements (applicable from 2 August 2026, with marking obligations extending to 2 December 2026).

The Three Article 25 Role-Flip Triggers

Deployers must be vigilant regarding Article 25(1). A deployer or distributor legally flips into a high-risk provider, inheriting the entire Chapter III Section 2 obligation stack, under three conditions:

• Trademarking: You put your name or trademark on an existing high-risk AI system.
• Substantial Modification: You make a substantial modification to an existing high-risk system altering its performance or safety parameters.
• Purpose Change: You modify the intended purpose of an unclassified or general-purpose system so that it operates within an Annex III high-risk use case.

Where Lyceum Inference APIs Sit on the Tree

When building machine learning products in Europe, infrastructure boundaries must remain distinct from regulatory classification. Consuming an open-source model through an API endpoint does not shift your position on this decision tree. The AI Act is purpose-bound and location-neutral: no provision dictates data localisation, and Article 10 data governance targets dataset representation, curation, and bias mitigation rather than physical hosting geography. Lyceum is an AI cloud infrastructure provider, holds no EU AI Act conformity statement, and takes no legal position on customer classifications.

Logging Responsibilities Under Zero Data Retention

Article 12 and Article 26 mandate that high-risk systems maintain automatic event logging during operation. Lyceum operates with zero data retention: prompts, tokens, and outputs are processed strictly within volatile GPU memory and are never persisted to disk. Because we store no user payload data, teams building high-risk systems must capture and retain API request logs, response tokens, and human review timestamps on their own side of the endpoint. Upstream providers cannot produce these logs after the fact.

Dedicated Endpoints and Operational Boundaries

For enterprise teams managing specialized workloads, Lyceum provides infrastructure across European facilities in Paris and Finland. Our Dedicated Inference offering provisions isolated endpoints for any Hugging Face or Docker model with auto-scaling and scale-to-zero capabilities, backed by contractual response times and direct 24/7 engineering escalation. Conversely, our Serverless Inference and Smart Routing products operate as self-serve, per-token endpoints without service level agreements. Navigating Annex III requires rigorous technical scoping, clear architectural boundaries, and precise tracking of intended purpose across your entire software stack.