28 July 2026. The Commission's draft Article 6 guidelines are now the reference text for every high-risk classification decision taken ahead of the 2 December 2027 application date.
On 19 May 2026 the European Commission published draft guidelines on high-risk classification under Article 6 of the AI Act, and they say something most compliance teams were not planning for: appearing on the Annex III list is where the assessment starts, not where it ends. If your team has already logged a system as out of scope because it only ranks, filters, or prepares inputs for a human decision, this is the document that tells you whether that call survives contact with a market surveillance authority. The Article 6(3) route out of high-risk status costs you a documented assessment and a public database entry even when it succeeds. The guidelines are non-binding, the consultation on them closed on 23 July 2026, and a final version is expected by the end of 2026.
Key Takeaways
- The guidelines arrived roughly three and a half months late. Article 6(5) required the Commission to publish them by 2 February 2026; the draft came on 19 May 2026, and the final text is not due until the end of the year.
- They are three documents, not one: general principles, the Annex I product-safety route, and the Annex III use-case route (Commission guidance page for providers and deployers).
- Claiming the Article 6(3) derogation is an active compliance step, not a passive exclusion. Article 6(4) requires the assessment to be documented before the system goes to market, and the system still gets registered in the EU database under Article 49(2).
- Profiling is an absolute bar. If an Annex III system performs profiling of natural persons, no Article 6(3) condition can rescue it.
- Splitting a workflow across several small models does not shrink the classification. Where modular or agentic components combine to influence an Annex III decision, the guidelines treat the configuration as one system.
- Intended purpose, as expressed in your own marketing and documentation, is the primary evidence. A terms-of-service disclaimer excluding high-risk uses does not survive product positioning that invites them.
- Deployers are not spectators. Under Article 25 a deployer, distributor, or importer that rebrands a high-risk system, substantially modifies one, or repurposes any AI system (including a general-purpose one) into an Annex III use becomes the provider and inherits the whole classification file.
- The deadlines moved but the work did not shrink: Regulation (EU) 2026/1744 pushed standalone Annex III obligations to 2 December 2027 and product-embedded Annex I obligations to 2 August 2028.
What the Commission Published on High-Risk Classification
The draft carries a specific legal pedigree. Article 6(5) of the AI Act obliged the Commission to issue guidelines on the practical implementation of Article 6, with a list of practical use-case examples, by 2 February 2026. That date passed without publication. The draft appeared on 19 May 2026, split into three documents that follow the structure of Article 6 itself: horizontal concepts that apply to every high-risk assessment, then one document for the Annex I product route and one for the Annex III use-case route.
The three documents are sharply uneven in length, and the imbalance tells you where the Commission thinks the difficulty sits. Alston & Bird's read of the package puts the general-principles document at six pages and the Annex I product-route document at thirteen, against 148 pages for the Annex III standalone-systems document. Roughly twenty of those 148 pages deal with the Article 6(3) filter alone. If your portfolio sits on the Annex III side of the split, nearly all of the interpretive material the Commission produced is aimed at you.
The Commission's own page on the guidelines states plainly that they are not legally binding, while noting that they reflect the Commission's interpretation and will guide enforcement. That combination is the practical point. DLA Piper's analysis makes the same distinction sharper by observing that only the Court of Justice of the European Union can give an authoritative interpretation of Article 6. So the guidelines are not law, but they are the reading that market surveillance authorities will start from, which means a classification decision that contradicts them needs a reasoned file behind it, not just a defensible legal argument. If you have already mapped your systems against the key compliance requirements for enterprises under the AI Act, this is the document that tells you whether the mapping put each system in the right tier.
The targeted consultation opened the same day, originally closing 23 June 2026 and then extended to 23 July 2026. The Commission has said feedback will be reflected in the final version and that the final guidelines will be adopted by the end of 2026.
The High-Risk Classification Test, in Order
The single most common classification error is starting in the wrong place — checking Annex III first, or checking obligations before checking status. The guidelines' horizontal document puts the sequence in a fixed order, and the order matters because a "yes" at an earlier step ends the inquiry.
| Step | What you test | Where it comes from | If the answer is yes |
|---|---|---|---|
| 1 | Is this an AI system at all, as the Act defines one? | Article 3(1) | Continue to step 2; if no, Article 6 does not apply to it |
| 2 | Is the use a prohibited practice? | Article 5 | Stop. The practice is banned and has been since 2 February 2025 |
| 3 | Is it a safety component of, or itself, an Annex I product that requires third-party conformity assessment? | Article 6(1) and Annex I | High-risk by the product route; Annex III is irrelevant |
| 4 | Does the intended purpose match a use case listed in Annex III? | Article 6(2) and Annex III | Presumed high-risk; continue to step 5 |
| 5 | Does the system perform profiling of natural persons, as data protection law defines profiling? | Article 6(3), final sentence | High-risk with no derogation available; stop |
| 6 | Does it avoid significant risk of harm and meet at least one of the four Article 6(3) conditions? | Article 6(3)(a)–(d) | Not high-risk, but document the assessment and register under Article 49(2) |
| 7 | Does it trigger transparency duties regardless of tier? | Article 50 | Disclosure obligations apply even to systems that are not high-risk |
One rule governs every step in that sequence, and it decides the close calls: where the classification is genuinely doubtful, the guidelines resolve the doubt toward high-risk. A market surveillance authority that sees doubt or evidence of an incorrect classification can require the provider to treat the system as high-risk. The direction of that default is the opposite of how a close call usually gets argued internally. An unresolved boundary case is not an argument for the lighter tier, it is an argument for building the file.
Two further things in that sequence are easy to get wrong in practice. The first is step 1: Arthur Cox's read of the guidelines highlights that intended purpose is the decisive indicator, and that a provider must assess the intended use before placing the system on the market or putting it into service. Actual observed use is not required to trigger classification. The second is step 7, which is not a fallback tier so much as a parallel obligation. A chatbot that is nowhere near Annex III still owes users disclosure.
Run the seven steps against your own inventory before reading further: if you cannot name the step at which each system exited the test, you do not yet have a classification record. See how the Privacy & AI Governance Platform holds that record.
Route One: Annex I, Where the Product Decides
The Annex I route has two cumulative conditions. The AI system must be intended as a safety component of a product covered by the Union harmonization legislation in Annex I (or be such a product itself), and that product must be subject to third-party conformity assessment under the same legislation.
The draft guidelines read the second condition more broadly than the statutory text alone suggests. Osborne Clarke's analysis captures the Commission's position: the decisive factor is not whether a notified body's involvement is mandatory, but whether the product is subject to "enhanced regulatory scrutiny," which can include products relying on internal control where harmonized standards apply. That widens the population of in-scope systems, and it does so in exactly the sectors (machinery, medical devices, lifts, radio equipment) where engineering teams have historically treated conformity assessment as a product-safety concern rather than an AI concern.
There is a definitional trap alongside it. Arthur Cox notes the guidelines treat the definition of "safety component" as operating independently of the sectoral legislation: only the Article 3(14) definition in the AI Act governs the Article 6 assessment, so whatever your sectoral regime calls a safety component does not settle the question. For teams that have to reconcile both regimes, the technical requirements and risk classes an AI Act program has to satisfy sit on the other side of this determination, and they are considerably heavier than the classification exercise itself.
The worked examples in the draft show how far functional framing gets you, which is not far. William Fry's Barry Scannell points to a combustion-efficiency optimizer in a household gas appliance: marketed as an efficiency feature, but high-risk because the consequence of failure is carbon monoxide, explosion, or fire. Lift door-timing, vehicle lane-assistance, and agricultural spraying systems land the same way. The test is what happens when the component is wrong, not what the component is sold as doing.
Route Two: Annex III, Where the Presumption Starts
Annex III lists eight headings: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice and democratic processes. A system whose intended purpose matches a listed use case is presumed high-risk under Article 6(2).
The draft guidelines spend most of their Annex III document on the boundary cases, and four clusters are worth reading closely if they touch your portfolio.
In employment, the operative phrase is whether the system materially influences a hiring or promotion decision. Systems that analyze, filter, score, or rank candidates, or that produce per-individual evaluations a human decision-maker relies on, sit inside. Purely procedural functions (structuring CV data, categorizing documents, detecting duplicates, scheduling interviews) sit outside, provided they do not affect the substance of the decision. Thompson Coburn's Brittney K. Mollman and Matthew I. Hafter reduce this to a usable test: "The operational question is whether the system is organizing the record, or shaping the judgment." They also flag the corollary that catches most teams by surprise: adding human review does not by itself move a system out of high-risk territory if its output still materially influences the outcome.
In financial services, DLA Piper's reading of the guidelines sets out concrete definitions for Annex III point 5(b): creditworthiness is the assessment of a person's ability and willingness to meet payment or credit obligations, and a credit score is a quantified representation of that. Essential services include bank accounts, mortgages, and loan extensions, but the guidelines put premium credit cards and leisure loans outside. The fraud-detection exception is to be interpreted narrowly and, importantly, does not extend to anti-money-laundering or counter-terrorist-financing checks. That distinction matters because many institutions run both through one platform. Systems calculating risk-weighted portfolio exposure under internal ratings-based approaches typically fall outside scope where they are not simultaneously assessing individual creditworthiness.
In education and vocational training, Annex III point 3 splits into four use cases: access, admission, or assignment to an institution or programme; evaluation of learning outcomes; assessment of the appropriate level of education a person will receive; and monitoring or detection of prohibited behavior during tests. The guidelines narrow the second of those in a way that matters commercially. Only summative evaluation, the kind that produces a grade or a qualification, carries the system into high-risk territory. Formative tools that let a student practice, get feedback, and improve without driving a final outcome do not qualify on that basis alone. Proctoring is the opposite case: exam-monitoring systems are named in Annex III directly, so a tool bought purely to detect cheating is inside from the start.
Biometrics, Annex III point 1, splits into three routes rather than one: remote biometric identification, biometric categorization that infers protected attributes, and emotion recognition. The trap in that cluster is that it does not sit on the same tier as the rest of Annex III. Emotion recognition in the workplace and in educational institutions is a prohibited practice under Article 5, not a high-risk one, which is precisely why step 2 of the sequence runs before step 4. A team that starts at Annex III will classify a banned system as high-risk and build a conformity file for something it is not allowed to deploy at all.
Across all four clusters, the same anti-circumvention principle applies: distributing functions across several tools does not reduce the classification, because the assessment looks at the overall workflow. Where multiple interconnected AI systems produce combined outputs that materially influence a decision, the guidelines treat them as a single AI system for classification purposes. That is the point where classification stops being a per-model exercise and becomes an inventory problem, which is why an AI system register that holds risk levels, use cases, and named owners in one place does more work here than a spreadsheet of models. The unit you have to classify is the configuration, not the component.
Article 6(3): The Derogation and Its Price
Article 6(3) is the only route out of a presumption established by Annex III, and it is narrower than its reputation. Two things must be true together. First, the system must 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. Second, it must satisfy at least one of four listed conditions.
| Article 6(3) condition | What it is meant to cover | What the draft guidelines say defeats it |
|---|---|---|
| (a) Narrow procedural task | Categorizing, reformatting, structuring, or deduplicating data inside a larger process without passing a value judgement on its content | The moment the system judges rather than organizes, or contributes as part of a complex or agentic system to outputs materially influencing an Annex III decision |
| (b) Improves the result of a previously completed human activity | Three cumulative elements: a human activity, a result it produced, and refinement of that result. "Improve" is read more narrowly than "review" or "revise" | Any improvement that changes the outcome, or a person's rights, legal position, or economic position, rather than polishing what was already decided |
| (c) Detects decision-making patterns or deviations from prior patterns | Ex-post comparison against completed human assessments, without inferring new assessment criteria of its own | Output applied to live cases, or accepted without proper human review, so that it replaces or influences the prior human assessment |
| (d) Performs a preparatory task to a relevant assessment | Indexing, searching, and linking data before the assessment begins, without reaching a conclusion | Preparatory framing where the output in practice drives the outcome, particularly at filtering stages or at scale |
Conditions (a) and (d) look interchangeable and are not. The difference is timing. A preparatory task under (d) happens before the assessment starts, gathering and linking the material someone will later assess. A narrow procedural task under (a) happens inside the assessment but stays confined to mechanical handling of data. Picking the wrong one produces a file that describes a system doing something it does not do, which is worse than picking neither.
The profiling bar deserves the same precision, because it is defined outside the AI Act. The guidelines read "profiling" by reference to the data protection definitions, so a system that uses automated processing of personal data to evaluate, analyze, or predict personal aspects of a natural person is profiling, and is therefore always high-risk under Annex III whatever its architecture looks like. The practical consequence is a sequencing one: you cannot answer step 5 until your data protection team has answered whether the processing is profiling. If those two determinations are made by different people who never compare notes, the classification is guesswork.
Scannell's assessment of how the Commission handled this is direct: the four conditions are, on his reading, exhaustive and to be interpreted narrowly as an exception to a fundamental-rights-protective regime. The guidelines also close the obvious loopholes. Modular and agentic architectures that combine to influence a high-risk decision are assessed as unified systems, so an individual module cannot claim the exemption on its own. And for general-purpose or enterprise AI products, contractual disclaimers do not work: Scannell notes that limitations of use must be clearly, concretely, and coherently described across instructions for use, technical documentation, and promotional material alike. DLA Piper's summary of paragraph 12 puts the same point from the other direction: a provider whose overall presentation suggests a system is broadly applicable across a generality of contexts, without consistently excluding high-risk uses, does not escape classification by asserting the exclusion in terms of service.
Then there is the price of a successful claim. Article 6(4) requires a provider that considers an Annex III system not to be high-risk to document that assessment before placing the system on the market or putting it into service, and to register the system in accordance with Article 49(2). The assessment must be supplied to market surveillance authorities on request. In other words, a derogation is a filing, not a silence — and one whose reasoning a regulator can ask to see years later. Secure Privacy's Assessments module runs AIAs and FRIAs from pre-built templates through configurable approval workflows, with version history retained, which is the shape the Article 6(4) file needs: a dated determination, a named approver, and the evidence the conclusion rested on.
One further caveat has a long tail. The Commission retains delegated power to amend or add to the Article 6(3) conditions, so a derogation that holds today rests on a list that can change. That is an argument for recording which condition you relied on and why, rather than recording only the conclusion.
If your derogation reasoning currently lives in a slide deck or an email thread, move it into a dated assessment with a named approver before the final guidelines land. Templates and approval workflows for AIAs and FRIAs exist for exactly this file.
Who Has to Run the Test: The Article 25 Role Shift
Article 6 assigns the classification duty to the provider, and the Commission's guidance page addresses providers, deployers, and market surveillance authorities alike. If you buy AI systems rather than build them, you are a deployer, and the comfortable assumption is that the assessment belongs upstream. Article 25 is the provision that turns a deployer into a provider without any paperwork changing hands.
Article 25(1) names three triggers. A distributor, importer, deployer, or other third party becomes the provider of a high-risk AI system if it puts its own name or trademark on a high-risk system already on the market, if it makes a substantial modification to a high-risk system that remains high-risk, or if it modifies the intended purpose of an AI system that was not classified as high-risk so that the system becomes high-risk under Article 6. The third trigger expressly reaches general-purpose AI systems. Point a general-purpose assistant at CV screening and you have not procured a tool, you have manufactured an Annex III high-risk system and made yourself its provider.
That is where the classification test stops being someone else's problem. The new provider inherits the Article 6 assessment, the Article 6(4) documentation duty if it wants to claim the derogation, and the Article 49(2) registration. Article 25(2) softens the landing slightly: the original provider stops being the provider for that system but must cooperate closely with the new one and supply the information and reasonable technical access compliance requires. There is a carve-out worth reading against the disclaimer point above, because it cuts the other way. That cooperation duty falls away where the original provider clearly specified that its system is not to be changed into a high-risk AI system. A vendor's exclusion of high-risk uses does not protect the vendor from classification when its own positioning invites those uses, but it can leave a customer who ignores the exclusion holding the entire file with no obligation of help.
The operational conclusion is that procurement, not engineering, is where most Article 25 exposure is created, and it is created by whoever writes the internal use case. Record the intended purpose you actually deploy each purchased system for, alongside the purpose the vendor documented, and treat any divergence as a classification event. Where a register of AI systems tracks vendor-supplied tools and their responsible owners together, that divergence is visible before a regulator finds it.
Where the Guidelines Leave Real Ambiguity
The draft resolves less than a first read suggests, and the honest inventory of what remains open is short but consequential.
"Material influence" is still contextual. DLA Piper's analysis notes the difficulty specifically where support tools drive outcomes at scale or operate at a filtering stage: a tool that only ranks, applied to fifty thousand applicants, is doing something different from the same tool applied to five. In financial services, the guidelines clarify creditworthiness but acknowledge ongoing difficulty in identifying the technical boundaries of an AI system and in assessing the effect of substantial future modifications. In employment, the guidelines themselves concede room for interpretation in borderline cases where a tool is marketed as a support function but drives outcomes in practice.
That last category is the one that changes over time without anyone editing a model, which is a distinct governance problem from getting the initial classification right. How a system's classification drifts as its use case, deployment context, and impact scope shift is the continuous-review counterpart to this article's one-time decision procedure — the two have to be run as one loop, because an Article 6(3) determination made against a 2026 use case is only as good as the trigger that forces you to revisit it.
What the 2026 Deadline Changes Actually Mean
The Digital Omnibus on AI is no longer a proposal. Regulation (EU) 2026/1744 was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, on an accelerated timetable written into the act itself — because the deadline it was amending was days away.
| Obligation set | Original application date | Date under Regulation (EU) 2026/1744 |
|---|---|---|
| Standalone Annex III high-risk systems, Article 6(2) | 2 August 2026 | 2 December 2027 |
| Product-embedded Annex I high-risk systems, Article 6(1) | 2 August 2027 | 2 August 2028 |
| Article 5 prohibited practices | 2 February 2025 | Unchanged, already enforceable |
| General-purpose AI model obligations | 2 August 2025 | Unchanged, already enforceable |
| Article 50 transparency duties | 2 August 2026 | Unchanged, still 2 August 2026 |
| High-risk systems used by public authorities, Article 111(2) | 2 August 2030 | Unchanged, hard date regardless of design changes |
There is a separate timeline for systems that are already running, and it is the one most inventories ignore. Article 111(2) as enacted provides that the Regulation applies to operators of high-risk AI systems placed on the market or put into service before 2 August 2026 only if those systems are subject to significant changes in their design after that date, while providers and deployers of high-risk systems intended for use by public authorities must comply by 2 August 2030 regardless. Significant design change is the trigger, which puts a legacy system one substantial refactor away from full scope. One caveat applies: the Commission's own AI Act Service Desk flags Article 111 as amended by the Digital Omnibus on AI and states that the text it displays has not yet been updated to reflect those amendments, so confirm the operative cutoff against the consolidated text before relying on a legacy position for a specific system.
The Commission's own guidelines page carries the same two headline dates: 2 December 2027 for high-risk systems in areas such as biometrics, critical infrastructure, education, employment, and migration, and 2 August 2028 for systems integrated into products. Earlier drafting of the Omnibus contemplated a conditional trigger tied to the availability of standards and support tools; the version that was agreed replaced that with fixed dates, which is better news for planning than a moving target would have been.
What the extension changes is sequencing, not volume. Classification is upstream of every substantive obligation: the risk management system, the data governance file, the technical documentation Article 13 requires, the logging design, the human oversight design, and the post-market monitoring plan under Articles 72 and 73. A classification decision taken late compresses everything downstream into whatever time is left. Gibson Dunn's advice on the Omnibus agreement is worth repeating in that light: use the additional time, do not wait for it, which for most organizations means running the classification pass now and holding it against a structured implementation sequence rather than restarting the analysis in 2027. And the registration mechanics that attach to both outcomes have their own separate timeline, covered in more detail in the walkthrough of registering a high-risk AI system and what is actually true about the deadline shift.
A Repeatable High-Risk Classification Workflow for a Portfolio
Most organizations do not have one AI system to classify. They have thirty, half of them purchased, several of them assembled from components that were classified separately by different teams. The draft guidelines are written for a single-system assessment, so the portfolio version has to be built around them.
Define the unit of assessment before you assess anything. Because interconnected components producing a combined output are treated as one system, the inventory item is the deployed configuration and its intended purpose, not the model artifact. Two configurations sharing one model are two items.
Capture intended purpose from the evidence a regulator would use. That means the instructions for use, the technical documentation, the product page, and the sales collateral, not an internal description written for the classification exercise. Where those sources disagree, the disagreement is itself the finding, and fixing the collateral is usually cheaper than accepting the wider classification.
Run the seven steps in order and record the exit point. A file that records "not high-risk" without recording which step produced that conclusion is not reviewable, and Article 6(4) assessments are the ones most likely to be read by someone hostile to them.
Attach an owner and a review trigger to every determination. The determination is a statement about use, and use changes. Tie review to specific events (new deployment context, new data source, expanded user population, substantial modification) rather than to an annual calendar.
Keep the derogation file separate and complete. For every Article 6(3) claim: the condition relied on, why the profiling bar does not apply, the significant-risk reasoning, the date, the approver, and the Article 49(2) registration reference.
Work the five steps against one purchased system and one in-house system this week. If the two files come out looking different, the gap is in your process, not in the guidelines. Start from a structured AI system register.
Common Classification Mistakes and How to Fix Them
Most of the errors that show up in classification files are not close legal calls. They are procedural, and they repeat.
| Mistake | Why it happens | The fix |
|---|---|---|
| Starting at Annex III | Annex III is the part everyone has read | Run Article 3(1) and Article 5 first, then the Annex I product route, then Annex III |
| Treating human review as a get-out | Human oversight sounds like it breaks the causal chain | Test whether the output still materially influences the outcome; if it does, review does not move the tier |
| Relying on a terms-of-service exclusion | Legal drafting is faster than fixing product positioning | Align instructions for use, technical documentation, and marketing collateral, then keep the exclusion |
| Classifying models instead of deployments | The inventory was built by engineering, around artifacts | Make the deployed configuration and its intended purpose the inventory unit |
| Claiming Article 6(3) and filing nothing | The derogation reads like an exclusion rather than a step | Produce the Article 6(4) assessment before market placement and register under Article 49(2) |
| Assuming a non-high-risk result ends the work | Article 50 sits outside the tier logic | Check transparency duties separately for every user-facing system |
| Letting a 2026 determination stand unreviewed | Nobody owns the trigger | Attach an owner and event-based review triggers to each determination |
| Assuming a purchased system is the vendor's problem | Deployer status feels like a lighter role than provider | Check the three Article 25 triggers on every tool, especially any general-purpose system repurposed for an Annex III use |
| Leaving systems already in production out of the inventory | The new deadlines read as future-only | Log legacy systems too, because a significant design change pulls them into scope and public-sector deployments have a 2 August 2030 date |
| Confusing narrow procedural task with preparatory task | Conditions (a) and (d) sound alike | Decide by timing: (d) runs before the assessment, (a) runs inside it and stays mechanical |
| Answering the profiling question without data protection input | Profiling is defined outside the AI Act | Get the data protection determination first, then run step 5 against it |
Two of these need someone outside the compliance team. Fixing product positioning is a marketing and product decision, and confirming whether an Annex I product is subject to third-party conformity assessment usually means a conversation with the engineers who own the CE marking file. Neither is inside your control, so raise both early rather than treating them as blockers discovered late.
Secure Privacy's Privacy & AI Governance Platform is built for the part of this you can put on rails. Its AI Governance module registers AI systems with risk levels, use cases, and responsible owners, maps them to applicable regulations including the EU AI Act, flags high-risk deployments through automated compliance checks, and generates audit-ready documentation for regulators and internal oversight. The Assessments module handles the AIA and FRIA work that follows a high-risk determination, and Governance & Maturity benchmarks the program as a whole rather than system by system. It will not make the Article 6 judgment for you, because nothing can, given how much of the test turns on intended purpose and material influence. What it does is make sure that when a market surveillance authority asks why a system was classified the way it was, the answer is a dated record with a named owner instead of a search through old email. Teams still deciding how to organize the wider program can compare approaches in our guides to AI governance for the enterprise and the tooling landscape for AI governance frameworks.
FAQ
Are the Commission's draft Article 6 guidelines legally binding?
No. The Commission's own page states the guidelines are not legally binding, and only the Court of Justice of the European Union can give an authoritative interpretation of Article 6. They still matter in practice, because they express the interpretation market surveillance authorities will work from, so a classification that departs from them needs documented reasoning.
When will the final high-risk classification guidelines be published?
The Commission has said the final guidelines will be adopted by the end of 2026, following the targeted consultation that closed on 23 July 2026. The draft published on 19 May 2026 remains the operative reference until then.
Does being listed in Annex III automatically make my AI system high-risk?
No. Annex III creates a presumption of high-risk status under Article 6(2), which Article 6(3) allows a provider to rebut where the system poses no significant risk of harm and meets at least one of four listed conditions. The one exception with no way out is profiling: a system that performs profiling of natural persons is always high-risk.
Is an AI tool used in education always high-risk?
No. Annex III point 3 covers admission and assignment decisions, evaluation of learning outcomes, assessment of the appropriate level of education, and monitoring for prohibited behavior during tests, so an education tool is high-risk only if its purpose matches one of those. The draft guidelines limit the learning-outcome case to summative evaluation that produces a grade or qualification, which leaves formative practice and feedback tools outside on that basis, while exam-proctoring systems are inside from the start.
What do I have to do if I decide my system qualifies for the Article 6(3) derogation?
Document the assessment before placing the system on the market or putting it into service, and register the system in the EU database in accordance with Article 49(2). The assessment must be provided to market surveillance authorities on request, so it needs to stand on its own as a reasoned record rather than a conclusion.
Can I avoid high-risk classification by splitting a system into smaller components?
No. Where several interconnected AI components produce combined outputs that materially influence an Annex III decision, the draft guidelines treat the configuration as a single AI system for classification purposes. An individual module that would qualify as a narrow procedural task on its own does not qualify when its output feeds a high-risk decision.
If I only deploy AI systems I bought, do I still have to classify them?
Yes, because Article 25 can make you the provider of a system you did not build. A deployer, distributor, or importer takes on provider obligations by putting its own name or trademark on a high-risk system, substantially modifying one, or changing the intended purpose of any AI system (a general-purpose one included) so that it becomes high-risk under Article 6, and the provider obligations include the Article 6 assessment itself.
Do the extended deadlines mean I can postpone classification work?
No, because classification is upstream of every substantive obligation. The Annex III date moved to 2 December 2027 and the Annex I date to 2 August 2028 under Regulation (EU) 2026/1744, but the risk management, documentation, logging, oversight, and post-market monitoring work all depend on the classification being settled first, and the Article 50 transparency duties were not deferred at all.
Do the high-risk rules apply to AI systems we already have in production?
Not immediately, in most cases. Article 111(2) as enacted applies the Regulation to high-risk systems placed on the market or put into service before 2 August 2026 only once they undergo significant changes in their design, with a hard 2 August 2030 date for high-risk systems intended for use by public authorities. The Commission's AI Act Service Desk notes that Article 111 has been amended by the Digital Omnibus on AI and that its displayed text is not yet updated, so check the consolidated wording before relying on a legacy position.
Is a general-purpose assistant like an enterprise chat tool high-risk?
Not by default, but a disclaimer is not what decides it. Where a provider's overall presentation suggests broad applicability across contexts without consistently excluding high-risk uses, and such uses are feasible and reasonably foreseeable, the system can be classified as high-risk regardless of what the terms of service say.
Getting the Classification File Right Before 2027
The hard part of Article 6 is not the reading. It is holding thirty determinations, their owners, their evidence, and their review triggers in a form that still makes sense to a regulator two years after the person who wrote them changed jobs. That is the problem the Privacy & AI Governance Platform was built to remove, so the classification judgment stays with your team and the record-keeping stops being the thing that fails the audit. Talk to us about your AI system inventory before the final guidelines land.
