EU AI Act Article 6. The classification decision that determines whether high-risk obligations apply.

Article 6 sits in Chapter III, Section 1 of Regulation (EU) 2024/1689. It is the provision that separates AI systems subject to the full high-risk compliance regime from those subject to the lighter obligations that apply to the general population of AI systems. Getting the classification right is not optional. A provider or deployer who misclassifies a system as not high-risk and later faces market surveillance scrutiny carries the full Article 99 penalty exposure for every obligation that was not met.

The structure of Article 6

Article 6 is structured in three paragraphs. The first two establish the two distinct tracks through which an AI system can be classified as high-risk. The third establishes the exception that can remove an Annex III system from high-risk classification even if it appears to fall within one of the listed categories.

The two-track structure reflects a fundamental distinction in how different categories of AI risk arise. Track 1 (Article 6(1)) is product-safety based. It captures AI systems that are already embedded in products that carry established third-party certification obligations under Union harmonisation law. The risk is not primarily the AI itself but the consequences of AI failure within a safety-critical product. Track 2 (Article 6(2)) is purpose-based. It captures AI systems whose intended use in specific high-sensitivity domains generates risk regardless of the product they sit inside.

The two tracks are not mutually exclusive. A system can satisfy both simultaneously, and both sets of obligations will apply. The classification analysis must therefore work through both tracks before concluding whether a system is high-risk, and if so, on what basis.

The Article 6(3) exception applies only to systems that would otherwise fall under Article 6(2) via Annex III. It does not apply to Track 1 systems. A system classified under Article 6(1) is high-risk without exception.

Track 1: Article 6(1) and Annex I products

Article 6(1) classifies as high-risk any AI system that is a safety component of a product covered by Union harmonisation legislation listed in Annex I, where that product itself is subject to third-party conformity assessment under that Annex I legislation.

The critical phrase is "safety component." Not every AI system integrated into an Annex I product is automatically a safety component. The system must perform a function that, if it failed or produced incorrect output, could compromise the safety of the product or the safety of persons exposed to the product. A user interface powered by AI that controls product settings is likely a safety component. A recommendation engine that suggests accessories to purchase is not.

Annex I of Regulation (EU) 2024/1689 lists the following Union harmonisation legislation that triggers Track 1 classification:

• Regulation (EU) 2017/745 on medical devices
• Regulation (EU) 2017/746 on in vitro diagnostic medical devices
• Regulation (EU) 2018/858 on motor vehicle type-approval
• Regulation (EU) 2019/2144 on type-approval requirements for motor vehicles with regard to general safety
• Directive 2006/42/EC on machinery (and its successor Regulation (EU) 2023/1230)
• Directive 2000/14/EC on outdoor equipment noise
• Directive 2006/66/EC on batteries (superseded in part by Regulation (EU) 2023/1542)
• Directive 2013/29/EU on pyrotechnic articles
• Directive 2014/30/EU on electromagnetic compatibility
• Directive 2014/33/EU on lifts
• Directive 2014/34/EU on equipment for use in explosive atmospheres
• Directive 2014/35/EU on low voltage electrical equipment
• Directive 2014/53/EU on radio equipment
• Directive 2014/68/EU on pressure equipment
• Regulation (EU) 2016/424 on cableway installations
• Regulation (EU) 2016/425 on personal protective equipment
• Regulation (EU) 2016/426 on gas appliances
• Regulation (EU) 2017/1369 on energy labelling
• Directive 2009/48/EC on the safety of toys
• Regulation (EU) 2018/1139 on civil aviation and aviation safety

The breadth of this list captures a substantial portion of manufactured goods that incorporate AI components. In practice, the most commercially significant Track 1 categories are medical devices, automotive safety systems, machinery, and civil aviation equipment. AI systems embedded in these products as safety-relevant components are high-risk under the EU AI Act independently of any question about their use case.

For the third-party conformity assessment requirement to activate Track 1, the Annex I product itself must require third-party assessment under the relevant legislation. Many Annex I products permit self-assessment by the manufacturer. Where third-party assessment is not required for the product, the AI embedded in it does not meet the Article 6(1) threshold. However, deployers should not assume that Track 2 via Annex III is unavailable simply because Track 1 does not apply.

Track 2: Article 6(2) and the eight Annex III categories

Article 6(2) classifies as high-risk all AI systems listed in Annex III, subject to the Article 6(3) exception. Annex III sets out eight numbered categories covering specific use cases and sectors where AI decisions can have significant consequences for individuals' health, safety, or fundamental rights.

The eight Annex III categories are as follows.

1. Biometric identification and categorisation of natural persons. This category covers AI systems intended to be used for real-time remote biometric identification of natural persons in publicly accessible spaces for law enforcement purposes, and AI systems intended for post-remote biometric identification of natural persons. It also covers AI systems intended to be used for biometric categorisation based on sensitive or protected attributes. The scope of this category is one of the more actively debated in the legal commentary, particularly in relation to the boundary between biometric identification and biometric verification.

2. Critical infrastructure. This category covers AI systems intended to be used as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating, and electricity. The safety component framing again applies: not every AI used in infrastructure management falls within scope, but AI whose failure could compromise infrastructure safety does.

3. Education and vocational training. This category covers AI systems intended to be used for the purpose of determining access to or admission to, or assigning students to, educational and vocational training institutions. It also covers AI used to evaluate learning outcomes, to assess the appropriate level of education for a person, and to monitor and detect prohibited behaviour during tests. This category is directly relevant to higher education institutions and online education platforms operating in the EU.

4. Employment, workers management, and access to self-employment. This category covers AI systems intended to be used for recruitment and selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates in the course of interviews or tests. It also covers AI used to make decisions affecting terms and conditions of work, including promotion or termination of employment relationships, to allocate tasks based on individual behaviour or personal traits, and to monitor and evaluate performance and behaviour of persons in employment relationships.

For enterprise deployers in 2026, this is the category most likely to be encountered in practice. AI screening tools, performance monitoring platforms, and automated task allocation systems are in widespread use. Many providers of these tools have not conducted Article 6 classifications. Deployers who use them without confirming classification status are accepting the compliance exposure themselves.

5. Essential private and public services and benefits. This category covers AI systems intended to be used by or on behalf of public authorities to evaluate the eligibility of natural persons for essential public assistance benefits and services. It also covers AI used to make decisions on access to essential private services, including housing, mortgage credit, insurance, and healthcare. Credit scoring by financial institutions falls clearly within this category. So does AI-based underwriting in insurance, which creates a recursive compliance question for insurers who deploy AI in their own operations.

6. Law enforcement. This category covers AI systems intended to be used by or on behalf of competent authorities as polygraphs or similar tools, to assess the risk of criminal offending by natural persons, to detect emotional states in the context of law enforcement, to detect deep fakes in criminal evidence, to evaluate the reliability of evidence in criminal proceedings, to predict the occurrence or recurrence of actual or potential criminal offences, and for profiling in the context of criminal offence detection, investigation, and prosecution.

7. Migration, asylum, and border control management. This category covers AI systems intended to be used as polygraphs or similar tools in border management contexts, to assess a risk, including a security risk, posed by natural persons intending to enter the territory of a Member State, to assist competent authorities in examining applications for asylum, visa, and residence permits, and to verify the authenticity of travel documents.

8. Administration of justice and democratic processes. This category covers AI systems intended to be used for researching and interpreting facts and the law and for applying the law to a specific set of facts, as well as AI used to influence the outcome of an election or referendum, or the voting behaviour of natural persons in an election or referendum. The explicit inclusion of electoral influence AI in this category reflects the specific concerns raised during the regulation's legislative history about AI manipulation of democratic processes.

Article 7 of Regulation (EU) 2024/1689 grants the European Commission the power to update Annex III by delegated act to add new use-case categories where AI poses a level of risk equivalent to that covered by the existing eight categories. This means the Annex III scope is not fixed. Providers and deployers in adjacent sectors should monitor Commission delegated act activity as the regulation matures.

The Article 6(3) exception: when an Annex III system is not high-risk

Article 6(3) provides that an AI system referred to in Annex III shall not be considered high-risk where it does not pose a significant risk of harm to the health, safety, or fundamental rights of natural persons. This is a substantive exception, not a procedural safe harbour. The provider must demonstrate on the facts that the specific system in question does not meet the harm threshold.

The regulation specifies three criteria under which the exception may apply. First, the AI system is intended to perform a narrow procedural task. This criterion targets systems whose function is genuinely limited in scope, where the output is operationally narrow and does not feed into consequential decisions in a material way. An AI tool that formats or routes documents within a predefined workflow may satisfy this criterion. An AI tool that summarises applicant profiles for a recruiter almost certainly does not, because the summary directly shapes the human decision.

Second, the AI system is intended to improve the result of a previously completed human activity. This criterion is intended for systems that operate after a human decision has been taken, to improve its execution rather than to inform the decision itself. Quality control AI that checks documents already approved by a human, or AI that formats an approved output for delivery, may fall within this criterion.

Third, the AI system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the human assessment. This criterion targets pattern-detection systems that surface information to a human without substituting the human's judgment. A dashboard that shows statistical anomalies in hiring decisions for human review may satisfy this criterion. A system that flags candidates for rejection without human review does not.

Critically, Article 6(3) also provides that an AI system shall not be considered high-risk if it performs a preparatory task for an assessment relevant to the use cases listed in Annex III, as long as the output does not directly and significantly influence a decision. The key word is "directly." A system that produces a structured summary which a human then reads and acts upon is closer to the exception than a system whose output is automatically fed into a decision engine. The more the human step is genuinely deliberative rather than confirmatory, the stronger the exception claim.

Providers who intend to rely on Article 6(3) must document the assessment in the technical file. The documentation should state which specific criterion applies, describe the system's actual function and output type, identify the decisions or processes the output feeds into, and explain why no significant risk of harm arises in the specific deployment context. Generic exception claims that do not address the system's actual operation carry little weight with market surveillance authorities. The burden of proof falls on the provider.

Deployers who receive a product where the provider claims an Article 6(3) exception should request the documentation supporting that claim. A deployer who relies on an exception claim without reviewing its basis, and who later uses the system in a way that clearly generates high-risk outputs, may face questions about whether the deployment was consistent with the exception basis. The safe position is to understand the exception's factual foundation before accepting it.

Practical classification steps for deployers

For deployers receiving AI systems from providers, the Article 6 classification is primarily the provider's responsibility. Providers must conduct and document it. But deployers have an independent interest in confirming that the classification is correct, because they bear the consequences of operating a misclassified system and because the classification determines what documentation and controls they are entitled to receive.

Five steps structure a sound deployer-side classification review.

Step 1: Identify the system's intended function. Before applying the Article 6 criteria, document what the system actually does in the specific deployment context. This means specifying the input data, the output produced, and the decision or process the output informs. The same AI model can be high-risk in one use case and not high-risk in another, depending entirely on what it is asked to do and what effect its output has.

Step 2: Check for an Annex I product link. Ask whether the system is embedded in, or constitutes a component of, a product that itself requires third-party conformity assessment under any of the Annex I legislation listed above. If yes, and if the AI performs a safety function within that product, Track 1 applies. The Track 1 analysis ends there: the system is high-risk.

Step 3: Check the Annex III categories. For systems not captured by Track 1, read through the eight Annex III categories against the system's intended purpose. The question to apply is not whether the system operates in the sector but whether its intended use falls within the specific functional scope of the relevant Annex III point. Employment AI that manages task allocation falls under point 4. A general HR analytics dashboard that reports on headcount and attrition does not, unless it feeds into individual employment decisions.

Step 4: Assess Article 6(3) exception eligibility. If the system appears to fall within an Annex III category, assess whether any of the three Article 6(3) criteria apply. Apply the criteria strictly: the exception is narrow by design. Where the system's output informs or shapes a consequential decision affecting an individual's health, safety, or fundamental rights, the exception is unlikely to apply. Where the system genuinely performs a bounded procedural function with no direct route to a consequential output, document the specific criterion and the factual basis carefully.

Step 5: Document the conclusion and confirm it with the provider. Record the classification outcome, the analysis underlying it, and the date it was conducted. If the system is provided by a third-party vendor, request their classification documentation and confirm that it covers the specific use case as deployed. A classification record that describes a different use case than the one in production is not adequate. Keep the record in the deployer's compliance file and schedule a review whenever the use case, the system, or the deployment context changes materially.

The classification record and its insurance implications

The Article 6 classification record is not only a regulatory compliance document. It is the foundational document that an insurer writing AI liability coverage will examine first. Before any underwriting question about risk management processes, technical documentation, or post-market monitoring arises, the insurer needs to understand whether the system being insured is high-risk and on what basis.

For high-risk systems, the classification record establishes the regulatory framework that governs the policy. The insurer will then ask for evidence that the obligations triggered by that classification have been met: technical documentation under Article 11, Article 9 risk management requirements, human oversight measures under Article 14, and the deployer-specific measures under Article 26 deployer obligations. A clean classification record, supported by the downstream compliance documentation, is what makes a policy possible to price at a commercially viable premium.

For systems where a provider has claimed an Article 6(3) exception, the insurer will scrutinise the exception documentation. An undocumented or weakly documented exception creates underwriting uncertainty. If the insurer's legal advisers conclude that the exception is not well-founded, the insurer faces the possibility of insuring a system that is in regulatory breach. Most insurers will price that uncertainty into the policy or decline coverage pending a stronger exception assessment.

The most common classification problem in enterprise AI deployments in 2026 is not ambiguity about whether Annex III applies. It is the absence of any documented classification analysis at all. Providers of widely used employment and credit AI tools have in many cases not conducted a formal Article 6 assessment, or have conducted one that does not adequately address the specific deployment configurations their enterprise customers use. Deployers who accept these tools without requesting the classification documentation are inheriting compliance risk that they have not priced.

The connection between classification, compliance documentation, and insurance eligibility is direct. A sector-by-sector Annex III guide covering the classification patterns in specific industries is available in this publication's resources. For the certification framework that produces insurance-ready documentation across the full Article 6 scope, see the certification methodology for high-risk AI systems at agentcertified.eu.