An AI system is high-risk under the EU AI Act if it takes one of two routes: it is a safety component of, or is itself, a product covered by the Union harmonisation legislation listed in Annex I and required to undergo third-party conformity assessment (Article 6(1)); or its intended purpose falls within one of the eight use-case areas listed in Annex III (Article 6(2)). Annex III systems can be pulled back out through the Article 6(3) derogation, but only on four narrowly interpreted conditions, and never where the system profiles natural persons.
Since 27 July 2026, that test sits inside a changed timetable. Regulation (EU) 2026/1744, the Digital Omnibus on AI, moved the compliance dates for high-risk obligations without touching the classification rules themselves. Most published guidance has not caught up, and a good deal of it now states deadlines that are simply wrong.
This is the working version of the test: how classification actually resolves, where the Commission's 2026 draft guidelines narrow the room organisations thought they had, and what the extra runway is realistically for.
The dates, as they now stand
| Obligation | Applies from | Changed by the Omnibus? |
|---|---|---|
| Article 5 prohibitions (original list) | 2 February 2025 | No |
| Article 4 AI literacy | 2 February 2025 (supervision from 2 August 2026) | Reworded, see below |
| GPAI model obligations (Articles 51 to 55) | 2 August 2025 | No |
| Article 50 transparency (chatbot disclosure, deepfake labelling, synthetic content marking) | 2 August 2026 | No |
| Article 50(2) marking, for generative systems already on the market | 2 December 2026 | Transitional relief added |
| Two new Article 5 prohibitions (non-consensual intimate imagery, CSAM) | 2 December 2026 | New |
| National regulatory sandboxes operational | 2 August 2027 | Deferred from 2 August 2026 |
| High-risk obligations, Annex III standalone systems | 2 December 2027 | Deferred from 2 August 2026 |
| High-risk obligations, Annex I embedded systems | 2 August 2028 | Deferred from 2 August 2027 |
Two things are worth separating carefully, because conflating them is the most common error in circulation right now.
The deferral is fixed-date, not conditional. The Commission's original proposal tied the delay to the availability of harmonised standards. The final text abandoned that mechanism in favour of hard dates. There is no trigger to watch and no scenario in which the dates arrive early.
2 August 2026 was not cancelled. It remains the AI Act's general application date. The Article 50 transparency duties took effect on schedule. An organisation that read "the AI Act was delayed" and stood its programme down has, as of that date, been out of compliance on disclosure and content-marking obligations that carry exposure of up to EUR 15 million or 3% of worldwide annual turnover.
The delay was reported as if the whole regulation had moved. It did not. What moved was the hardest, most expensive part, and the part that was already unbuildable because the standards were not there. Everything that was genuinely ready to apply, applied. The organisations that are exposed today are the ones that treated a headline as a legal analysis.
Route one: Annex I, the product route
Under Article 6(1), an AI system is high-risk where two conditions are met cumulatively:
- 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: medical devices, machinery, toys, lifts, radio equipment, civil aviation, vehicles, and the rest of the CE-marking universe; and
- That product is required to undergo a third-party conformity assessment under that legislation.
Both limbs matter. A product covered by Annex I legislation that can be self-assessed does not pull its AI component into the high-risk regime by this route.
The Commission's draft guidelines read the safety component concept broadly, but they anchor it to real harm: the risk must relate to physical harm to persons or property. Purely financial loss, reputational damage or user inconvenience fall outside. The Digital Omnibus pushed slightly the other way, narrowing the statutory definition to exclude AI used solely for non-safety-related aspects of user assistance, performance optimisation, service efficiency, automation, convenience or quality control.
The practical read: if your product carries a CE mark obtained through a notified body, assume the AI inside it is in scope and work backwards from there. If the AI is purely for convenience or performance and its failure would not endanger health or safety, it likely falls outside Article 6(1).
Route two: Annex III, the use-case route
Article 6(2) classifies as high-risk any AI system whose intended purpose falls in one of eight areas.
| # | Annex III area | Typical systems |
|---|---|---|
| 1 | Biometrics | Remote biometric identification, biometric categorisation, emotion recognition (not simple verification to confirm identity) |
| 2 | Critical infrastructure | Safety components in digital infrastructure, road traffic, water, gas, heating, electricity |
| 3 | Education and vocational training | Admission and assignment, evaluation of learning outcomes, proctoring, level-of-education assessment |
| 4 | Employment and worker management | CV screening and ranking, targeted job advertising, promotion and termination decisions, task allocation, performance monitoring |
| 5 | Access to essential services | Creditworthiness scoring, life and health insurance risk assessment and pricing, public benefits eligibility, emergency call triage |
| 6 | Law enforcement | Risk assessment of offending, polygraph-type tools, evidence reliability evaluation, profiling in detection or investigation |
| 7 | Migration, asylum and border control | Risk assessment, application examination, detection of irregular migration |
| 8 | Administration of justice and democratic processes | Assisting judicial authorities to research and interpret facts and law; influencing election or referendum outcomes |
Intended purpose is what decides this, not architecture. The same underlying model is high-risk in one deployment and out of scope in another. A general-purpose assistant used to summarise meeting notes is not an Annex III system. The same assistant, deployed with the stated purpose of ranking job applicants, is.
That principle cuts both ways, and the Commission's guidelines make the second direction explicit: intended purpose is established from the provider's instructions for use, technical documentation and promotional materials. Marketing copy that promises more than the technical file admits will be read against the provider.
The Article 6(3) derogation, and why it closes faster than teams expect
Landing in Annex III does not automatically end the analysis. Article 6(3) provides an exit, for systems that do not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision-making, where at least one of four conditions is met:
- (a) Narrow procedural task. Transforming unstructured data into structured data, classifying incoming documents, deduplicating records. Mechanical processing, no value judgement.
- (b) Improving the result of a previously completed human activity. The human did the substantive work; the system polishes it.
- (c) Detecting decision-making patterns or deviations from prior patterns, without replacing or influencing the previously completed human assessment absent proper human review. Backward-looking and aggregate, not individual prediction.
- (d) Performing a preparatory task to an assessment relevant to an Annex III use case.
The four conditions are alternative, not cumulative. One is enough. That is the only generous thing about them.
Four ways the derogation fails
It must be read narrowly. The Commission's guidelines are explicit that Article 6(3) is an exception to rules protecting fundamental rights and must be interpreted narrowly. A derogation argument that only works on a generous reading is not a derogation argument. When in doubt, the system is high-risk.
Profiling voids it absolutely. Where the system profiles natural persons, evaluating or predicting aspects of a person's performance, economic situation, health, preferences, interests, reliability, behaviour, location or movements, the derogation does not apply, whichever of the four conditions might otherwise be satisfied. There is no balancing test here. This is the single most under-modelled line in the whole classification framework.
It is assessed at system level, not component level. Where multiple AI components interact and their combined outputs materially influence a decision in an Annex III use case, the guidelines treat the whole as a single AI system. A preprocessing module that looks purely procedural in isolation cannot claim the derogation if it feeds a pipeline that produces employment decisions. For agentic architectures this is decisive, and most component-level derogation analyses written in 2025 do not survive it.
Adding a human does not fix it. The Commission states directly that a provider cannot exempt a system by bolting on a human-involvement requirement. Human oversight is a Chapter III obligation, not a classification lever.
The line teams most often get wrong sits inside condition (a). Extracting text from a CV into structured database fields is a narrow procedural task. Extracting skills, deciding what counts as a skill and for whom, is an evaluation. Structuring input is not the same as judging input, and the second one is where the derogation ends.
In practice almost every derogation file I review fails on the same thing. Someone wrote the analysis for the component they own, not for the decision the system ends up making. The regulator reads the decision. If a person is materially affected at the end of the chain, the fact that your box only sorted the inputs is not the answer you think it is.
Claiming the derogation is itself a compliance obligation
This is the part that surprises people. Article 6(4) requires a provider who concludes that an Annex III system is not high-risk to document that assessment before the system is placed on the market or put into service, and to produce it to national competent authorities on request. Article 49(2) additionally requires that provider to register itself and the system in the EU database.
So the derogation is not an exit from the regime. It is a different, lighter set of duties inside it: a dated written assessment, a public register entry, and an evidentiary position you have to be able to defend later. Under Article 80, market surveillance authorities can open a procedure precisely against systems a provider has classified as non-high-risk, taking database information into account.
An undocumented derogation is not a derogation. It is an unclassified system.
Who this applies to: the scope question non-EU organisations get wrong
Article 2 reaches further than most compliance teams model, and further than the GDPR:
- Providers placing AI systems on the Union market or putting them into service in the Union, irrespective of where they are established;
- Deployers with their place of establishment, or located, in the Union;
- Providers and deployers established in a third country, where the output produced by the AI system is used in the Union.
That third limb is the one that catches US and Swiss organisations. There is no targeting requirement and no intent requirement. The GDPR asks whether you offered goods or services to people in the Union or monitored their behaviour. The AI Act asks a narrower factual question: is the output used here. A score, a ranking, a recommendation or a generated document produced in Chicago or Zug and consumed by a team in Paris brings the system into scope, with no EU entity, no EU staff and no EU infrastructure required.
Non-EU providers of high-risk systems must also appoint an authorised representative established in the Union under Article 22. Swiss organisations should note that Switzerland's domestic approach offers no passporting or equivalence route. A Swiss provider selling into the Union is assessed exactly as a US or Japanese one would be.
Provider or deployer, and the clause that flips it
Obligations split along the role you hold, and organisations routinely hold both.
Providers carry the design and evidence burden: risk management (Article 9), data governance (Article 10), technical documentation (Article 11), automatic logging (Article 12), transparency and instructions for use (Article 13), human oversight design (Article 14), accuracy, robustness and cybersecurity (Article 15), quality management (Article 17), conformity assessment, the EU declaration of conformity, CE marking, registration, and post-market monitoring.
Deployers carry operational duties: using the system in accordance with instructions, assigning competent human oversight, ensuring input data is relevant and sufficiently representative, retaining logs, monitoring operation, informing affected persons where required, and, for certain deployers, carrying out a fundamental rights impact assessment.
Article 25 collapses the distinction. A deployer who puts their own name or trademark on a high-risk system, substantially modifies it, or changes its intended purpose becomes the provider and inherits the full provider obligation set. Fine-tuning a vendor model on your own data and pointing it at an Annex III use case is the common path to this, and it is usually taken by a product team without a compliance review.
The standards gap, stated honestly
There is a widely repeated shorthand that ISO/IEC 42001 certification delivers AI Act compliance. It does not, and the reason is structural.
Under Article 40, presumption of conformity attaches only to harmonised standards whose references have been published in the Official Journal. As of mid-2026, no CEN-CENELEC deliverable under the AI Act standardisation request has been cited in the OJEU. CEN-CENELEC JTC 21 assessed ISO/IEC 42001 against the Act's quality management requirement, found the objectives and definitions insufficiently aligned, and drafted a bespoke European standard (prEN 18286) rather than adopting 42001 directly. EN ISO/IEC 42001:2026 has been adopted into the European catalogue, but adoption as an EN is not the same thing as harmonisation, and a draft prEN confers nothing at all.
The practical consequence is an allocation of burden. A provider aligned to a harmonised standard, once cited, benefits from a rebuttable presumption: a market surveillance authority challenging conformity has to show the standard does not adequately cover the requirement. A provider relying on ISO/IEC 42001 alone keeps the full evidentiary burden and must demonstrate sufficiency from first principles, clause by clause.
None of which makes 42001 a waste. A well-implemented AI management system builds most of the organisational machinery an AI Act quality management system needs: governance, roles, risk process, documented decisions, internal audit, and builds it in an auditable form. It is the right substrate. It is not the shield, and any vendor telling you otherwise is selling you a gap. For the management-system view of that substrate, see the ISO 42001 framework guide.
Certify to 42001 because it forces you to build the machine. Do not certify to it expecting a legal defence, because there is not one in the Official Journal yet. The two things get confused constantly, usually by people selling certificates.
What the extra sixteen months are actually for
The deferral is not relief. The obligations did not change; only the date did. And several of the things that have to be true on 2 December 2027 take longer than sixteen months to build from a standing start.
- Build the inventory. You cannot classify what you have not listed. Most organisations discover their real AI footprint is two to five times what the IT asset register shows, because it arrives embedded in SaaS products nobody procured as "AI". Shadow deployment inside HR, finance and customer operations is the norm, not the exception.
- Date every classification. A classification is a point-in-time judgement about an intended purpose. It has to carry a date, a named owner, the reasoning, and the evidence it rested on. Undated classifications are worthless in an enforcement conversation.
- Set change triggers. Article 111 grandfathering only holds for systems placed on the market before the applicable date and not subsequently subject to significant design changes. The threshold for "significant" is still unsettled, particularly around retraining, material parameter updates and scope extensions, and it may well be crossed sooner than providers expect. Every system needs a defined trigger that forces reclassification.
- Resolve your roles per system. Provider, deployer, importer, distributor, product manufacturer: per system, not per organisation, and reassessed whenever a product team touches a model.
- Track the standards. When the first harmonised standards are cited in the OJEU, the cheapest compliance route changes overnight. Organisations that have mapped their controls to clause level will be able to pivot to it. Organisations holding a pile of unstructured evidence will not.
- Do not stand down on what already applies. Article 50 transparency, the Article 5 prohibitions, GPAI obligations, and the AI literacy duty are all live now. On literacy specifically, the Omnibus rewrote Article 4 from a duty to ensure a sufficient level into a duty to take measures to support its development: a softer obligation of effort, but still binding on every deployer, with national supervision starting 2 August 2026.
Where Acuna fits
Classification is not a document you produce once. It is a live record that has to survive a product change, an ownership change, a vendor's model update and, eventually, a question from a market surveillance authority, and it has to be reconcilable with what your ISO/IEC 42001, ISO/IEC 27001, GDPR, NIS 2, DORA and CRA programmes already say about the same systems.
Acuna is the GRC platform for teams that govern their own AI Act programme, not for teams outsourcing it to a consultancy, and not for teams reconstructing it after the fact. It holds the AI system inventory, the Article 6 classification with its reasoning and date, the Article 6(4) derogation assessments, the role determination per system, and the supporting evidence, in the same repository as every other framework you run.
Map a control once. It counts for every framework. Collect evidence once. Reuse it everywhere it is needed. Built for CISOs, DPOs and Heads of Compliance, and used by organisations across the European Union, the United States and Switzerland. See how a multi-framework programme runs on one control set.
Regulatory References