This third part continues Part I, EU market access for AI systems and models, and Part II, Responsibility for AI systems across the EU supply chain. Part I explains the market-access framework, principal obligations and application dates. Part II addresses the allocation of responsibility between customers, developers, integrators and other supply-chain actors. This part turns to category-specific high-risk classification, additional safeguards and the evidence supporting classification decisions.
Two routes to high-risk classification
A hypothetical hospital appointment assistant is not high-risk merely because a hospital uses it. Emergency healthcare triage appears expressly in Annex III, point 5(d), while a qualifying medical device can satisfy Article 6(1). An administrative assistant that performs neither function requires analysis of any other applicable Annex III entry. The distinction follows from the listed purpose, rather than a general healthcare label. (Article 6; Annex I, Section A, points 11–12; Annex III, point 5(d).)
Regulated products and safety functions
Separate supply of the AI does not defeat classification. A voluntary external audit does not establish the mandatory-assessment condition. (Article 6(1)(a)–(b).)
Article 6(1c) expressly addresses spectrum distribution and electromagnetic interference that do not affect health and safety. A radio-equipped product does not enter the high-risk route solely because it faces an external assessment of those non-safety risks. (Article 6(1c).)
Section A covers specified product legislation concerning toys, lifts, radio equipment, protective equipment, medical devices and other listed products. (Article 2(2); Annex I, Sections A–B.)
Biometrics and critical infrastructure
Annex III, point 1, covers permitted uses of remote biometric identification, sensitive or protected-attribute biometric categorisation, and emotion recognition. It excludes biometric verification whose sole purpose is confirming that a person is who that person claims to be. Matching a claimed identity and searching a reference population are legally different functions; the verification exclusion cannot automatically cover the latter. (Annex III, point 1(a)–(c).)
Remote biometric identification has further safeguards. Article 14(5) generally requires separate verification by at least two competent, trained and authorised persons before action on an identification. Its exception depends on the specified public uses and a proportionality determination under EU or national law. Post-remote identification in the criminal investigations described in Article 26(10) requires a judicial or qualifying administrative authorisation request beforehand or, without undue delay, within forty-eight hours. The provision contains a limited initial-identification exception, prohibits untargeted use and requires cessation and deletion when authorisation is refused. These conditions remain separate from high-risk classification. (Articles 14(5), 26(10).)
Critical-infrastructure classification requires a safety-component function in managing or operating the infrastructure listed in point 2. That list covers critical digital infrastructure, road traffic, water, gas, heating and electricity. A utility's staff scheduling assistant is not within point 2 solely because the utility supplies electricity. Employee-based task allocation may instead fall within point 4(b). Each function requires its own statutory match. (Annex III, points 2, 4(b).)
Education and employment
Education entries cover access, admission and assignment to educational institutions; evaluation of learning outcomes; assessment of the education level a person can access; and monitoring prohibited behaviour during tests. An admissions-ranking tool falls within point 3(a), subject to Article 6(3). A document-formatting function needs a different analysis because the heading education does not itself classify every administrative tool. (Article 6(2)–(3); Annex III, point 3(a)–(d).)
Employment entries extend beyond final hiring decisions. They cover targeted job advertisements, application analysis or filtering, and candidate evaluation. They also cover employment terms, promotion, termination, task allocation based on individual behaviour or personal traits, and worker performance or behaviour monitoring. (Annex III, point 4(a)–(b).)
Benefits, credit, insurance and emergency services
Annex III, point 5(a), covers public authorities and entities acting on their behalf when assessing eligibility for essential public assistance benefits and services, including healthcare. It also covers decisions to grant, reduce, revoke or reclaim them. The entry does not convert every private customer-service chatbot into a benefits-assessment system. The relevant actor, service and decision must match the provision. (Annex III, point 5(a).)
A mixed fraud-and-credit product must be assessed function by function; a fraud label does not establish an exception for a separate credit assessment. (Annex III, point 5(b)–(c).)
Emergency-call evaluation and classification, dispatch or prioritisation of emergency first-response services, and emergency healthcare patient triage fall within point 5(d). An appointment organiser differs when it neither evaluates emergency urgency nor performs another listed function. Clinical software may still enter the product route independently. (Article 6(1)–(2); Annex III, point 5(d).)
Law enforcement, migration, justice and elections
The law-enforcement entries concern specified competent uses: victimisation-risk assessment, polygraphs or similar tools, evidence-reliability assessment, offending or reoffending assessments within the stated limits, assessment of personality traits or past criminal behaviour, and profiling during criminal detection, investigation or prosecution. (Article 5(1)(d); Annex III, point 6(a)–(e).)
Migration, asylum and border-control entries cover polygraphs, specified security or migration risks, application and complaint examination, and detection, recognition or identification of persons. The entry concerning identification excludes verification of travel documents. The competent-actor requirements and permitted-use qualifications remain material. A general travel-service assistant does not satisfy point 7 merely by discussing visas. (Annex III, point 7(a)–(d).)
Judicial classification concerns systems used by or on behalf of a judicial authority to assist with facts, law or application to particular cases. It also reaches similar use in alternative dispute resolution. A private lawyer's research assistant is not automatically used on behalf of a judicial authority. Its actual institutional role, intended purpose and any other applicable category remain decisive. (Annex III, point 8(a).)
Point 8(b) excludes administrative or logistical campaign organisation where natural persons are not directly exposed to the output. (Annex III, point 8(b).)
The ancillary-function exception and profiling
Article 6(3)(c) has a precise restriction. The system must not replace or influence the previously completed human assessment without proper human review. (Article 6(3)(c)–(d).)
Article 3(52) incorporates the definition of profiling in Article 4(4) of Regulation (EU) 2016/679. (Articles 3(52), 6(3), final subparagraph.)
A provider relying on the exception must document its assessment. It must provide that documentation to competent authorities on request. A file supporting the exception should identify the matching Annex III entry, claimed ancillary function, decision influence, profiling analysis and countervailing risks. Article 6(4) leaves the documentation's format unspecified. (Articles 6(4), 49(2); Regulation (EU) 2026/1744, Article 1(42).)
Provider requirements and evidence
Where the general high-risk requirements apply, the provider must maintain a continuous risk-management process throughout the system's lifecycle. Article 9 requires identification, evaluation and treatment of relevant risks, testing before supply or first use, and attention to foreseeable misuse. The process must consider risks to children and other vulnerable groups where relevant. The provision confines the risks to those reasonably reducible through design, development or adequate technical information; it does not promise elimination of every social risk. (Articles 9, 16(a).)
Article 10 requires suitable training, validation and testing data practices where models use training data. For systems developed without model training, the specified rules apply to testing datasets. (Article 10(1)–(4), (6); Regulation (EU) 2026/1744, Article 1(9).)
Article 16 also requires provider identification and contact details, corrective action and demonstrations of conformity on reasoned official request. Its accessibility requirement operates in accordance with Directives (EU) 2016/2102 and (EU) 2019/882. Providers must preserve these duties alongside the technical controls. (Articles 16(b), (j)–(l), 20–21.)
Conformity assessment and registration
Equivalent solutions and common specifications require the separate analysis in Article 41. (Articles 40–43.)
Specified law-enforcement, migration and border entries use a secure non-public section of the EU database. (Articles 47–49.)
Deployer duties and fundamental-rights assessments
Deployers must cooperate with competent authorities. (Article 26(1)–(6), (12).)
Public-authority deployers must not use a system found unregistered where the EU database requirement applies. (Articles 2(7), 26(7)–(9), (11), 49.)
A private employer does not become subject to Article 27 merely because recruitment is high-risk; another trigger must apply. (Article 27(1).)
Article 27(2) permits reliance on previous assessments in similar cases, including an existing provider assessment. (Article 27(1)–(5).)
Existing systems
Recital 177 treats significant change as equivalent in substance to substantial modification. That interpretive statement must be read with amended Article 111(2), which specifies changes in design and the relevant application date. The actual change must still satisfy the operative provision. (Articles 3(23), 111(2); recital 177.)
Commission guidance and classification evidence
Commission guidance assists interpretation, but legislative provisions determine classification. The Commission's publication concerning its draft classification guidelines expressly describes them as nonbinding. It also describes illustrative use cases as non-exhaustive. A provider should therefore connect its decision to Article 6 and the relevant annex entry, rather than claim exemption solely because a factual illustration resembles its product. (Articles 6(5), 96; European Commission, Guidelines for providers and deployers of AI high-risk systems, webpage, last updated 6 July 2026, introductory paragraph 2 and Key points of the draft guidelines, second bullet.)
Amending the ancillary-function conditions or Annex III requires the delegated powers and procedures in Articles 6–7 and 97. Article 80 authorises market surveillance authorities to examine a provider's non-high-risk classification against Article 6(3) and the Commission guidelines. A documented exception is consequently open to examination, even after registration. An authority finding high-risk status can require compliance and corrective action within a prescribed period. (Articles 6(6)–(8), 7, 80(1)–(3), 97.)
A defensible classification decision connects the system version and intended purpose to each statutory condition. It should distinguish the product route, each relevant Annex III function, the ancillary-function assessment and the operator's role. That organisation follows from the separate duties in Articles 6(4), 11 and 25; it is an analytical means of evidencing them. (Articles 6(4), 11, 25, 43(4), 111.)
Enforcement
Article 80 also permits sanctions for deliberate misclassification intended to circumvent the Act. Conformity documentation does not prevent action against a compliant system that presents a relevant risk under Article 82. The operator must assess the applicable procedure and grounds, rather than treat certification as immunity. (Articles 79–83.)
