What the high-risk AI classification guidelines draft contains
The Commission's high-risk AI classification guidelines are more than eight months overdue and still not final. Article 6(5) required the Commission to provide, no later than 2 February 2026, guidelines on the practical implementation of Article 6 "together with a comprehensive list of practical examples of use cases of AI systems that are high-risk and not high-risk". What exists instead is a draft, published on 19 May 2026 on the Commission's digital strategy library in three documents: general principles, the Annex I chapter and a 148-page Annex III chapter.
The targeted consultation page records that the consultation "was originally open for 6 weeks until 23 June", that the deadline "was extended to 23 July 2026", and that "the final guidelines will be adopted by the end of 2026". As at 5 October 2026 the Commission's pages still list only the draft, and no final version has been adopted.
Everything below is the draft's view. Its disclaimer calls it "still a draft document", paragraph 5 of the general chapter says it will be consulted again with the AI Board before adoption, and paragraph 6 says: "The Guidelines are not binding. Any authoritative interpretation of the AI Act may ultimately only be given by the Court of Justice of the European Union". It is still the most detailed statement of how the Commission reads Article 6, and it matters for any provider relying on the Article 6(3) derogation.
Two general points set the tone. Paragraph 12 says a system presented "as broadly applicable across a generality of contexts and functions" that does not "consistently limit its application or exclude high-risk uses" will be deemed to have a high-risk intended purpose, and that "merely asserting (for example in the terms of service) that high-risk uses are excluded is insufficient" where the product positioning promotes such uses. Paragraph 14 reminds deployers and distributors that Article 25(1) can make them the provider, a point covered on the provider versus deployer page.
How the draft reads the Article 6(3) conditions
Article 6(3) lets an Annex III system escape the high-risk label where it meets one of four conditions, and the draft (section 2.7 of the Annex III chapter) calls this "the filter mechanism". Its reading is narrow throughout.
The conditions are the test. Paragraph 88 says the conditions are "exhaustive, but alternative" and that "there is no separate or independent assessment to determine whether the AI system poses a significant or any risk of harm besides those conditions". It then says that, as an exception to rules protecting fundamental rights, "the conditions must be interpreted narrowly" and in the light of the first subparagraph, so that the system "should not materially influence the outcome of the decision". In practice the draft still asks whether the system materially influences the outcome, but inside each condition rather than as a separate step. Paragraph 87 confirms the filter does not apply to Article 6(1) systems at all.
(a) Narrow procedural task. Paragraph 92 covers systems that "categorise, change the format, structure or presentation of data, or change its metadata". Paragraph 93 draws the line: systems that make "a value judgement of data relevant for decision-making", for example labelling inputs "useful" or "less useful", or "attributing a score or ranking", are not narrow procedural.
(b) Improving a completed human activity. Paragraph 94 sets three cumulative elements: a completed human activity, a result, and an improvement to that result. Paragraph 96 says the legislature chose "improve" rather than "review", so the system must not produce "a materially different result" and the improvement "should not change the rights, protection, legal or economic position" of the persons affected.
(c) Detecting decision-making patterns. Paragraphs 100 to 102 limit this condition three ways: the human assessment must be complete, the system may only make "an ex-post comparative assessment" and must not "infer relevant criteria from previous decisions and propose a new assessment", and any influence must pass through "proper" human review, which paragraph 102 defines as "meaningful and comprehensive".
(d) Preparatory task. Paragraph 104 confines this to tasks "that occur prior to the actual assessment process". Paragraph 108 is the operative line: where a system "is intended to produce a specific recommendation or evaluation of the case, it plays a decisive role" and is not preparatory.
Two horizontal rules close common gaps. Paragraphs 70 and 71 say human involvement "has no effect on the classification of the system as high-risk under Article 6(2)" and that a provider cannot exempt a system "simply by adding to it a requirement for human involvement". Section 2.3 and paragraph 90 say that where several components "materially influence an individual decision, the combined configuration is treated as a single AI system", that "split architectures are assessed as a whole", and that this "also extends to complex, interconnected setups like agentic AI systems".
Profiling and materially influencing the outcome
The third subparagraph of Article 6(3) says an Annex III system "shall always be considered to be high-risk where the AI system performs profiling of natural persons". The draft (section 2.7.2) takes the definition from Article 3(52), which cross-refers to Article 4(4) GDPR, and paragraph 110 splits it into three cumulative elements: automated processing, of personal data, with the objective of evaluating personal aspects of a natural person.
Paragraph 111 notes that the first element "will always be fulfilled" for an AI system, so the live questions are whether the inputs include personal data and whether the purpose is to evaluate a person. Paragraph 112 adds that "a simple classification of individuals based on personal characteristics such as their age, sex, and height does not necessarily lead to profiling", because evaluation "must always include a form of prediction, assessment or judgement". Its worked example reaches the opposite result: a tool that flags deviations from past recruitment patterns while "evaluating the personal characteristics of the recruiters" profiles the recruiters, so condition (c) cannot save it.
On "materially influencing the outcome", paragraph 85 reads recital 53 to mean that a system meeting a condition "typically does not materially influence the outcome", and paragraph 105 adopts the recital's test that such a system does "not have an impact on the substance, and thereby the outcome, of decision-making, whether human or automated". The examples apply that test in practice. In the recruitment section a background-check tool that gives applicants composite risk scores is in scope because, although "human review is formally part of the process, in practice the system's output heavily influences which candidates advance", and because it performs profiling it cannot use Article 6(3) at all.
Worked examples: the draft's verdicts by Annex III area
Section 3 of the Annex III chapter gives, for each Annex III point, examples that fall within the use case, outside it, or within it but exempt under the filter. The table maps a selection to the draft's conclusion. "Outside" means the draft finds the system is not in the Annex III use case at all. "Exempt" means it is in the use case but the draft applies Article 6(3).
| Use case | Annex III point | Draft's conclusion | Where |
|---|---|---|---|
| Job-matching tool that scores and ranks candidates into shortlists | 4(a) | High-risk, even with recruiters able to override | s. 3.4.2 |
| Interview scheduling and reminders | 4(a) | Exempt, narrow procedural task, 6(3)(a) | s. 3.4.2 |
| Retrospective bias audit of anonymised past hiring decisions | 4(a) | Exempt, pattern detection, 6(3)(c) | s. 3.4.2 |
| Employer-branding ads not tied to a vacancy | 4(a) | Outside the use case | s. 3.4.2, para 251 |
| Shift scheduler ranking workers on punctuality, no-shows and ratings | 4(b) | High-risk, no filter available | s. 3.4.3 |
| Desk and meeting-room booking | 4(b) | Outside the use case | s. 3.4.3 |
| Grading of tests that count towards a final evaluation | 3(b) | High-risk | s. 3.3.3 |
| Grade-average calculator using set weights | 3(b) | Exempt, 6(3)(a) | s. 3.3.3 |
| Checker that flags errors in a teacher's finished exam paper | 3(b) | Exempt, 6(3)(b) | s. 3.3.3 |
| Language app a student uses voluntarily, no credential | 3(b) | Outside the use case | s. 3.3.3, para 225 |
| Credit score built from payment behaviour and income for consumer credit or mortgages | 5(b) | High-risk | s. 3.5.3 |
| Creditworthiness of companies from business data only | 5(b) | Outside, not a natural person | para 74 |
| Detecting forged ID or income documents in credit applications | 5(b) | Outside, fraud-detection carve-out | paras 306 to 308 |
| Margin credit for leveraged trading | 5(b) | Outside, not an essential service | s. 3.5.3, para 304 |
| Health insurance claims management | 5(c) | Outside the use case | s. 3.5.4 |
| Classifying 112 calls by urgency and routing responders | 5(d) | High-risk | s. 3.5.6 |
| Transcribing poor-quality emergency calls | 5(d) | Outside the use case | s. 3.5.6 |
| Matching a traveller's face to their passport chip at an e-gate | 1(a) | Outside, biometric verification, unless also checked against a criminal database | para 136 |
| Fire-alarm control in a cloud data centre run by a designated critical entity | 2 | High-risk | s. 3.2.2 |
| Network-load prediction for digital infrastructure | 2 | Outside, no direct safety function | s. 3.2.2 |
| Scanning visa files and filing them into fixed folders | 7 | Exempt, 6(3)(a), if it does not rank or label usefulness | para 93 |
| Anti-money-laundering screening by an accounting firm | 6 | Outside, not acting on behalf of law enforcement | para 81 |
Several of these turn on a scope limit the draft spells out. Paragraph 194 confines the critical digital infrastructure case to systems used by an entity identified as critical under the Critical Entities Resilience Directive. Paragraphs 222 to 224 separate summative evaluation, which can be high-risk, from formative feedback, which is not. Paragraph 300 keeps pure pricing out of point 5(b) unless it is integrated with a creditworthiness assessment. Paragraph 305 puts the burden on the provider to show a credit model is "solely intended to be used for non-essential private services". The guides on recruitment, credit scoring and education work through these use cases against the Act.
The draft is not always internally consistent. Its example of a system that organises CV data into a searchable database describes a narrow procedural task but cites "Article 6(3)(d)", which is the preparatory-task condition. It is a reason not to quote a draft example as settled.
The Annex I safety-component reading, and where the Omnibus overtook it
The Annex I chapter covers the product route in Article 6(1). Paragraph 27 reads it as two cumulative conditions: the AI is a safety component of, or itself is, a product covered by Annex I legislation, and that product requires third-party conformity assessment. Paragraph 33 treats "safety component" in Article 3(14) as an autonomous AI Act definition, and paragraph 34 finds two alternative routes into it: a safety function, or failure or malfunction that endangers health and safety.
The draft illustrates both. A vision system that triggers a safe stop when a person enters a robot cell has a safety function (para 45). A lift-door timing system or a lane-assistance system can qualify through failure risk even where the provider's intended purpose is efficient operation or a better user experience (para 46). A combustion optimiser in a gas appliance is a safety component if its failure "could lead to carbon monoxide formation, explosion or fire", while a heating-schedule optimiser whose failure causes only "discomfort or higher energy bills" is not (section 2.2.2). A music recommender in a connected toy is not a safety component (para 47), and paragraph 48 says most AI in smart home appliances will fall outside the definition. Paragraph 57 adds that a manufacturer's option to use internal control with harmonised standards "does not confer discretion on the manufacturer to determine the risk classification".
Regulation (EU) 2026/1744 has since written much of that reading into the Act. The consolidated Article 6 now provides in paragraph 1a that systems "solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control shall not qualify as safety components", in paragraph 1b that systems "the failure or malfunctioning of which would endanger health and safety shall qualify as safety components", and in paragraph 1c that third-party assessment required "solely due to risks other than risks to health and safety", such as radio spectrum or electromagnetic interference, does not satisfy point (b). The draft reached similar results by interpretation, without citing the new paragraphs: the list of functions that are not safety functions after para 37, the failure-based route from para 38, and in para 25 a reading of "safety component" that excludes risks such as radio spectrum or electromagnetic compatibility. Paragraph 1c gets to the radio spectrum point by a different route, through the third-party assessment condition in point (b) rather than through the definition of a safety component.
That tells you when the draft was written. Its general chapter already refers to the dates "postponed with the AI Omnibus" (para 448), but the Annex I chapter predates the Official Journal text. Two points need cross-checking. Paragraph 60 says only "Article 6(1), Articles 102 to 109, and Article 112" apply to Section B products, while the amended Article 2(2) now reads "only Article 6(1), Article 60a and Articles 102 to 112". And paragraphs 30 and 59 discuss the Machinery Regulation without noting that the consolidated Annex I deletes Section A point 1 and lists the Machinery Regulation as Section B point 21, which changes which AI Act requirements apply directly. The Digital Omnibus guide sets out that change.
Documentation, registration and what to do with a draft
Article 6(4) requires a provider that considers an Annex III system not high-risk to "document its assessment before that system is placed on the market or put into service", makes it "subject to the registration obligation set out in Article 49(2)", and requires the documentation to be provided on request. Article 49(2) requires that provider to register itself and the system in the Article 71 EU database before placing it on the market or putting it into service.
The draft (section 2.7.3) adds detail on the record. Paragraph 115 says the assessment should contain four things:
- a description of the intended purpose of the system;
- why the system falls under Article 6(2);
- which Article 6(3) condition or conditions apply, and why;
- why the system does not perform profiling.
Paragraph 116 says the record should be available "at any time upon the request of a market surveillance authority", and encourages deployers procuring AI systems to check use of the exception in the EU database as part of due diligence. Paragraph 117 points to Article 80, under which a market surveillance authority can evaluate a classification and require corrective action, and to Article 99 penalties where a system "was misclassified as non-high risk to circumvent" the high-risk rules.
A draft is evidence, not a defence. No final guidelines exist, so a classification made today will be read later against a text that may differ. If the draft treats your use case as high-risk, a contrary self-assessment needs reasoning that engages with the draft's example. If the draft treats it as exempt, cite the paragraph, but make sure your record also meets the four elements in paragraph 115.
In practical terms, find your use case in the Annex III chapter, compare your system's real outputs with the example (scores, rankings and recommendations usually decide it), test profiling against the three elements in paragraph 110, and check whether a human-review step is doing work the draft says it cannot do. For background on what the label means, read what high-risk AI is, the full walkthrough of both Article 6 routes and the free triage classifier, which runs the Article 6(3) conditions and the profiling override against a description of your system.