EU AI Act Annex III Draft Guidelines: What Changed

On 19 May 2026, the European Commission published three draft chapters of guidelines on the classification of high-risk AI systems under Article 6 of the EU AI Act. The chapters cover the general principles, Annex I (the product-safety route under Article 6(1)), and Annex III (the use-case route under Article 6(2)), and they are out for stakeholder consultation. They work from the post-Omnibus timetable agreed politically on 7 May 2026: 2 December 2027 for Annex III obligations and 2 August 2028 for Annex I obligations, subject to formal adoption.

The first wave of commentary will describe these guidelines as a contraction: critical infrastructure narrowed, law enforcement evidence handling narrowed, judicial administration tools narrowed, and election logistics narrowed. From that summary alone, a CISO or CIO scanning the headlines will conclude that there is less work to do and that waiting for adoption is a defensible posture.

That conclusion misses the rotation underneath. The narrowing hit narrow vertical markets most enterprises were never in. The broadening hit categories the typical larger enterprise actually sits in: employment AI under Point 4, insurance products under Point 5(c) for life and health insurers, and education and L&D AI under Point 3. The product-safety route under Article 6(1) was tightened in parallel and can catch businesses with physical-product portfolios in machinery, medical devices, automotive, aviation, marine, or rail where an AI system is itself a covered product or a safety component and the sectoral law requires third-party conformity assessment. For many larger enterprises, the live question after the draft guidelines is whether their AI touches hiring, workforce decisions, credentialed training outcomes, health or life insurance risk assessment, or safety-relevant functions in regulated products.

This post walks through the rotation, names which Annex III points moved in which direction and by how much, walks through the Article 6(1) product-safety changes that most commentary will skip, examines what the Article 6(3) filter actually allows after the draft guidelines, and closes on the distinction between Commission interpretation and binding law.

1. What's in the EU AI Act high-risk AI guidelines

The Commission released the three chapters as drafts pursuant to Article 6(5) AI Act. The general principles chapter handles cross-cutting concepts: the definition of an AI system, the role of intended purpose, and the Article 25(1) flow-through that pulls distributors, importers, deployers, and other third parties into provider obligations where they rebrand a high-risk AI system, substantially modify a high-risk system so that it remains high-risk, or change the intended purpose of an AI system (including a GPAI system) that was not high-risk so that it becomes high-risk (¶14 general principles). The Annex I chapter handles the product-safety route. The Annex III chapter handles the use-case route across the eight broad areas: biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and border control, and administration of justice.

The drafts will be further consulted with the European Artificial Intelligence Board before the Commission adopts them (¶5 general principles), and they work from the post-Omnibus timetable of 2 December 2027 for Annex III obligations and 2 August 2028 for Annex I obligations, subject to formal adoption of the Omnibus package. The operative obligations begin on those dates regardless of where the final guideline text lands. Section 11 returns to the distinction between operative text and Commission interpretation.

2. Did the EU AI Act high-risk scope shrink? Why most commentary will get this wrong

The first wave of coverage will frame the draft guidelines as a contraction. Critical infrastructure narrowed through a CER Directive linkage, law enforcement evidence handling shrank to authenticity and integrity assessment, judicial administration tools lost a long list of internal court use cases, and election logistics narrowed via a "specifically intended" test that excludes general content recommenders. Section 8 below walks through each of these in detail. From that summary, a senior technology leader could conclude that the AI inventory can wait.

That conclusion misses where the carve-outs apply. The categories that narrowed sit in narrow vertical markets, and they help critical-infrastructure operators that are not designated under the CER Directive, law-enforcement vendors selling indexing or translation tools, court-administration tooling vendors, and political-campaign logistics platforms. Few enterprise customers operate in those segments. For the small number of vendors operating in them, the carve-outs are real and consequential. For everyone else, the carve-outs are background context, although procurement counterparts can still demand high-risk evidence in critical infrastructure even when CER designation status is not disclosed (¶191 Annex III).

The categories that broadened occupy the centre of the enterprise market. Point 4 (employment) caught more of the workforce stack than the original text suggested. Point 5(c) (insurance) gained new included segments (long-term care, personal pensions, credit life, public health insurance with AI risk assessment) and never had the fraud-detection escape hatch that Point 5(b) (credit) does. Point 3 (education) had its filter mechanism functionally closed for learner-trajectory systems by a profiling presumption. And Article 6(1) (the product-safety route, examined separately below) became harder to under-classify through architecture choice. For an enterprise reader operating in any of those categories, the compliance perimeter implied by the Commission's draft interpretation is wider than the original Annex III text suggested at first glance.

On honest assessment, the draft guidelines are proportionality-heavy. Annex III is "an exhaustive list" aimed at avoiding "unnecessary regulatory burdens for the majority of AI systems falling within the areas listed" (¶65 Annex III), and Article 6(3) exists to keep narrow procedural or preparatory tools outside high-risk classification. Many support tools stay outside high-risk treatment when they avoid individual evaluation, substantive decision influence, profiling, or safety-component status. The rotation matters after that proportionality triage: the live perimeter has moved toward HR decisioning, learner-trajectory decisions, health and life insurance risk assessment, and safety-relevant AI in regulated products.

3. EU AI Act Annex III changes at a glance

The graphic is the takeaway. The sections below back it up with paragraph references, so anyone disputing a single row can be pointed at the source text.

4. Employment AI under EU AI Act Annex III: why Point 4 just got broader

Point 4 of Annex III covers "employment, workers' management and access to self-employment." The draft guidelines walked through what each of those phrases means. The cumulative effect extended the regulation's reach substantially.

On personal scope, the Commission anchored the definition of "worker" in CJEU case law on Article 45 TFEU: "the essential feature of being a worker is that, for a certain period of time, a person performs services for and under the direction of another in return for remuneration" (¶239 Annex III). That definition is already broader than the typical reader's image of an employee. The draft guidelines then added that "the notion of 'worker' must be considered as just one element of the broader expression 'employment, workers' management and access to self-employment'" (¶239 Annex III).

On "access to self-employment," the draft guidelines pulled in self-employed individuals such as "persons working as independent contractors, service providers or performing independent professions" who "rely on access to contracts or assignments to secure their livelihood" (¶241 Annex III). Recital 57 AI Act recognises that platform workers are in scope. The Commission went further and clarified that "freelancers, independent professionals, service providers, and platform workers regardless of contractual status fall within the personal scope of the use cases listed in point 4 of Annex III wherever AI systems mediate or condition their access to work opportunities" (¶241 Annex III).

The workplace, in turn, is as broad as the personal scope. The draft guidelines cite the Commission's Guidelines on prohibited artificial intelligence practices, which define "workplace" as "any specific physical or virtual space where natural persons engage in tasks and responsibilities assigned by their employer or by the organisation they are affiliated to, for example in case of self-employment" (¶241 Annex III, citing the prohibited-practices guidelines). Virtual collaboration spaces are in. Distributed workforces are in.

Workers' management is in scope at every stage of the employment relationship: "recruitment processes, work allocation, monitoring and worker evaluation, as well as decisions on promotion, remuneration or termination" (¶240 Annex III). Recruitment in particular includes onboarding "where the outcome of an AI system performing such a process may affect access to work" (¶248 Annex III).

There is a second consequence to bake in. Article 5(1)(f) AI Act prohibits AI systems that infer emotions of natural persons in workplaces or education institutions, with a narrow exception for medical or safety reasons. The draft guidelines remind providers that where a Point 4 system also falls within the Article 5 prohibition, "the prohibition will prevail and the system will remain unlawful" (¶242 Annex III). Emotion-recognition HR tools used to infer emotions of workers are therefore prohibited unless the medical or safety exception applies. Article 6 high-risk status does not apply once a prohibition is in play.

For any larger enterprise, the implication is short. Applicant tracking systems, performance management, internal mobility, task allocation, contingent workforce and freelancer AI, and any AI system that uses the virtual workplace to recruit, select, allocate tasks, monitor, evaluate, or affect work-related terms all sit inside Point 4. Audit the AI inventory against the broader personal scope and the broader workplace definition. If anything in that inventory infers emotions of workers outside the medical or safety exception, that system leaves the high-risk track entirely and lands in the unlawful category.

5. Insurance AI under EU AI Act Annex III: new scope for LTC, pension, and credit life

Point 5(c) of Annex III covers "AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance." The draft guidelines expanded the practical reach of that phrase considerably.

On inclusions, the Commission stated that health and life insurance "should also be considered to cover private long-term care insurance, since that constitutes a health insurance service within the meaning of point 5(c) of Annex III" (¶317 Annex III). The same paragraph pulled in "personal pension products in so far as these can have a significant impact of a person's livelihood in old age" (¶317 Annex III). Credit life insurance attached to mortgages sits inside Point 5(c) where it constitutes a payment-protection obligation on the borrower (¶318 Annex III). Public health insurance with AI risk assessment on natural persons is in (¶319 Annex III). Private health insurance in countries with universal public care is in (¶320 Annex III).

What stays out is narrow: motor, home, and car insurance; insurance-based investment products under PRIIPs Article 4(2); claims management; and product design at portfolio level (¶314-321 Annex III).

The sharpest difference between Point 5(c) (insurance) and Point 5(b) (credit scoring) is the fraud-detection exception. Point 5(b) provides one. Under ¶307 Annex III, an AI system whose main intended use is fraud detection can sit outside the creditworthiness use case even where it consumes related data. Point 5(c) provides no equivalent exception. The draft guidelines say so directly: "In contrast to the use case listed in point 5(b) of Annex III, point 5(c) does not provide an exception for fraud detection. Therefore, an AI system intended to be used for risk assessment or pricing in the case of health and life insurance will be classified as high-risk even if it also has a feature that can be used for fraud detection" (¶321 Annex III).

The architectural implication for insurers is concrete. A risk-assessment system with a bolted-on fraud feature is in scope. Only a genuinely distinct fraud system, separable in its own right, falls outside Point 5(c). Insurers that built risk assessment and fraud detection on shared model infrastructure now face an architectural decision: separate the systems sufficiently to make the fraud component distinct in its own right, or accept Point 5(c) high-risk classification for the bundled system.

For an enterprise reader operating in long-term care, personal pension, credit life, or public health insurance, Point 5(c) is now a primary compliance obligation. Treat it as load-bearing.

For banks, lenders, payment providers, and asset managers that sit outside life and health insurance, Point 5(b) on credit scoring and creditworthiness is the relevant story, and it narrowed in the draft guidelines. Pricing-only systems even where they consume creditworthiness data, legal-entity assessment, customer classification, personalised marketing, pre-application support and complaint handling, post-grant internal credit-exposure monitoring, collateral evaluation, margin and leveraged trading credit, and non-essential private services such as stocks, complex instruments, premium credit cards, and leisure or travel loans all sit outside Point 5(b) (¶300-308 Annex III). The fraud-detection exception in ¶307 carves out systems whose main intended use is fraud detection. AML/CFT systems are not covered by the fraud exception and land in Point 5(b) only where they are "functionally linked and simultaneously intended to be used for" creditworthiness evaluation (¶309 Annex III), which raises an architectural separation question for banks that built AML and credit-scoring on shared model infrastructure. IRB and Solvency II internal models used solely for capital calculation under prudential regulation sit outside; mixed-purpose systems that also feed origination decisions remain in (¶323-325 Annex III). For a non-insurance financial-services CISO, Point 5(b) needs its own classification analysis before any system in this portfolio gets treated as high-risk by default.

6. Education AI under EU AI Act Annex III: why the filter mechanism won't help for learner-trajectory systems

Point 3 of Annex III covers AI systems used in "education and vocational training." The draft guidelines defined the territory broadly and then quietly closed the filter mechanism for the systems that evaluate learner trajectories.

On scope, the Commission anchored "educational institutions" in the prohibited-practices guidelines, which read the phrase as covering "both public and private institutions, with no limitation on the types or ages of pupils or students, or the specific environment (online, in person, in a blended mode, etc.)" (¶211 Annex III). The definition extends to "not only formal educational and vocational training institutions, but also non-formal institutions, such as adult education and continuing educational institutions, which may offer personalised learning and skill development opportunities" (¶212 Annex III).

The Commission also added vocational training assignment systems to the scope. AI systems intended to match job seekers or employees with vocational training programs are explicitly classified as high-risk (¶218 Annex III).

The largest practical shift in Point 3 is the profiling presumption in ¶215 Annex III. The draft guidelines state:

"AI systems falling within the use cases listed in point 3 of Annex III will often involve the automated processing of personal data to evaluate the personal aspects of a natural person, in particular to analyse or predict aspects related to that person's academic or vocational training path. Such systems will often perform profiling of natural persons and may lead to automated decision-making within the meaning of Article 22 GDPR. They should always be classified as high-risk, even if the system fulfils the conditions of the filter mechanism listed in Article 6(3) AI Act."

That last sentence is the operative move for any education AI that evaluates a learner's trajectory. Article 6(3) is the filter that exempts a use-case-listed system from high-risk classification if it does narrow procedural work, improves a previously completed human activity, detects deviations from prior decision-making patterns, or performs preparatory work. The filter never applies to systems that perform profiling. The Commission's position is that education AI usually performs profiling and the filter usually does not apply. Narrow preparatory or identity-verification tasks may still qualify for the filter; learner-trajectory evaluation systems do not.

For EdTech vendors, corporate learning and development teams running personalised learning, and recruitment-adjacent vocational-assignment systems, the operative obligation is straightforward. Plan compliance around the Annex III high-risk obligations directly. Do not bank on the filter as an escape route for any system that scores or evaluates a learner.

7. What the draft guidelines mean for the EU AI Act Article 6(1) product safety route

The entire Annex III conversation concerns one of two paths to high-risk classification. The product-safety route under Article 6(1) is the other. It catches AI systems that are themselves a product, or a safety component of a product, covered by Union harmonisation legislation listed in Annex I AI Act, where the product is required to undergo third-party conformity assessment under that sectoral legislation. The list of harmonised sectors is closed: machinery, toys, lifts, ATEX equipment, radio equipment, pressure equipment, recreational craft, cableways, gas appliances, medical devices, in-vitro diagnostics, automotive, aviation, marine, and rail.

The Annex III rotation does not touch Article 6(1). For any enterprise making physical products or selling into the harmonised sectors, Article 6(1) is where most of the AI exposure sits, and the draft guidelines made the classification harder to under-claim.

The most important Article 6(1) change is the Commission's rejection of the Module A interpretation. Module A is the internal-control conformity assessment route allowed by some sectoral legislation. Some commentators read the original text of Article 6(1) as letting a manufacturer opt out of high-risk classification by relying on Module A and harmonised standards. The draft guidelines reject that interpretation. The Annex I chapter states: "The fact that the Union harmonisation legislation may allow a manufacturer to rely on internal control based on harmonised standards, as one procedural option, does not affect the classification of an AI system as high-risk under Article 6(1) AI Act" (¶57 Annex I). It continues: "The choice of conformity assessment module provides manufacturers with procedural flexibility for demonstrating compliance, but it does not confer discretion on the manufacturer to determine the risk classification of an AI system for the purposes of the AI Act" (¶57 Annex I). The decisive factor for Article 6(1) classification is whether the underlying product is subject to enhanced regulatory scrutiny under the sectoral legislation (¶58 Annex I). The Annex I chapter also flags Article 40 AI Act, which requires consistency between the harmonised standards under the AI Act and the harmonised standards under the Annex I sectoral legislation; manufacturers building against one set of standards should expect the other to follow.

The Commission also clarified the safety-component definition. Article 3(14) AI Act defines a safety component through either of two triggers: intent-based (the provider intends the system to prevent or mitigate physical harm) or consequences-based (failure or malfunction would endanger persons or property). Examples in the draft guidelines include lane assistance whose stated intent is user experience but whose failure could cause a collision; lift door timing whose stated intent is efficiency but whose failure could cause injury; agricultural spraying whose stated intent is chemical optimisation but whose failure could harm nearby persons. A provider can lose control of Article 6(1) classification through system architecture alone.

The general principles chapter added a further reach. Article 25(1) AI Act flow-through pulls distributors, importers, deployers, and other third parties into provider obligations if they put their name or trademark on a high-risk AI system already placed on the market, make a substantial modification to a high-risk system, or change its intended purpose (¶14 general principles). A deployer who rebrands or repurposes a high-risk vendor system becomes a provider.

For enterprises with physical-product portfolios, Article 6(1) exposure became clearer and harder to under-classify under the draft guidelines. The AI Act does not in itself extend the scope of the harmonisation legislation listed in Annex I; the tightening sits in classification mechanics, with the sectoral scope unchanged. The Annex III "shrink" headline does nothing for any of this. Audit the product portfolio against the Annex I harmonisation list and the safety-component triggers, and treat Module A as unavailable for opting out of high-risk classification.

8. Which Annex III categories narrowed and who actually had that exposure

Four Annex III points narrowed substantially in the draft guidelines, and the carve-outs mostly matter to providers and deployers outside the typical enterprise customer base.

Critical infrastructure: Point 2

The Commission tied Point 2 classification to formal designation under the Critical Entities Resilience (CER) Directive. The reference in Article 3(62) AI Act to the CER Directive "should be understood in a way that an AI system is classified as a safety component in critical infrastructure (hence as high-risk) only if used by an entity identified as a critical entity by a Member State under the CER Directive" (¶190 Annex III). Many utilities and infrastructure operators in the EU have not yet been formally designated under the CER Directive, so the practical reach of Point 2 depends as much on Member State designation activity as on Commission interpretation.

Beyond the CER linkage, the draft guidelines added a direct-physical-protection test that excludes pure optimisation, forecasting, "mere conduit" cybersecurity work, quality assurance of installations, and precautionary anomaly detection routed to a human operator (¶181-184 Annex III). The worked example in the guidelines is striking. Even a grid imbalance forecast whose malfunction could "affect grid stability, which can lead to malfunctioning in electricity supply" is excluded from Point 2, because the link to direct physical harm is too indirect (example following ¶206 Annex III).

The market this carve-out helps is real but narrow. Most larger enterprises do not operate CER-designated infrastructure.

Law enforcement evidence handling: Point 6

Point 6(c) on evidence reliability shrank to evaluation of authenticity, integrity, source reliability, and internal consistency. The draft guidelines explicitly excluded collecting, structuring, indexing, clustering, timeline reconstruction, translation, transcription, semantic search, and multimodal retrieval from the scope (¶365 Annex III). This is a substantial carve-out for legal-tech and police case-management AI. It is aimed almost entirely at vendors selling into law enforcement, which is not where a typical B2B enterprise sits.

Justice administration: Point 8(a)

The Commission excluded most internal court tooling from the scope of Point 8(a). The carve-outs include speech-to-text and court transcription, citizen-facing chatbots on court websites, press-release and accessible-summary drafting, case assignment by specialisation or workload, document anonymisation, internal communication tooling, address lookup, fee verification, e-signature, and advanced search tools that retrieve without assigning meaning (¶419 Annex III). What remains in scope: decision and judgment drafting, small-claims auto-orders, precedent selection that analyses the facts of the case, and AI assistants suggesting legal reasoning from multiple sources. Legal-tech vendors whose customers are law firms are largely out, because attorneys do not act "on behalf of" the court within the meaning of the use case (¶416 Annex III). For an enterprise reader who is not selling case-management software to a judiciary, this is non-binding context.

Elections: Point 8(b)

The Commission added a "specifically intended" test for Point 8(b). The draft guidelines say "the AI system would have to be specifically intended to have an effect on the electorate's choice or turnout" (¶437 Annex III). General content recommender systems that incidentally surface political content, GPAI systems with safeguards (a chatbot that declines to give voting advice, for example), campaign management, donor analytics, and human-reviewed generative drafting of political content all sit outside Point 8(b). What remains in scope is AI-targeted political advertising, AI-enabled political chatbots and spokespersons, voter advice applications, and constituency boundary analysis. Again, this is a narrow vendor space.

The rotation thesis turns on a simple point. The four narrowing moves are real, and each one mostly helps a narrow audience that does not include enterprises sitting in scope through employment, insurance, or education AI, or through any Article 6(1) physical-product portfolio. Procurement counterparts can still ask for high-risk evidence in critical infrastructure even when CER designation status is not disclosed (¶191 Annex III).

9. How the EU AI Act Article 6(3) filter just got tighter, including for agentic AI

Article 6(3) AI Act is the relief valve for Annex III. It says an AI system that falls within an Annex III use case is not classified as high-risk if it (a) performs a narrow procedural task, (b) improves the result of a previously completed human activity, (c) detects decision-making patterns or deviations without replacing prior human assessment, or (d) performs a preparatory task. Profiling kills the filter unconditionally.

The draft guidelines tightened the filter in six concrete ways.

One. Narrow-interpretation rule. Because the filter is an exception from fundamental-rights protection, the conditions must be read narrowly (¶88 Annex III). The default position cuts against the provider invoking the exception.

Two. Profiling kills the filter absolutely. Article 6(3) excludes AI systems that perform profiling from the filter (¶89 Annex III, cross-referring to Article 4(4) GDPR). The draft guidelines unpack profiling into three cumulative elements: automated processing, personal data, and evaluation of personal aspects. "While the element of automated processing will always be fulfilled with regard to AI systems, providers must determine whether the data input of the system includes personal data and whether the system is intended to be used to evaluate personal aspects relating to a natural person" (¶111 Annex III). The test for AI systems therefore comes down to personal-data input plus evaluation of personal characteristics. Once those conditions are present, the filter does not apply at all.

Three. Complex-system anti-circumvention catches split architectures and agentic AI. This is the most consequential interpretive move in the draft guidelines for the agentic AI conversation. ¶75 Annex III reads:

"Where several AI systems form part of a more complex AI system, so that their combined intended purpose or joint outputs materially influence an individual decision, the combined configuration is treated as a single AI system for the purpose of high-risk classification. To avoid circumvention of the high-risk classification rules by system design, split architectures are assessed as a whole. [...] This principle also extends to complex, interconnected setups like agentic AI systems that coordinate and interact through linked actions as long as these linked actions or components serve in conjunction an intended high-risk purpose."

In plain English: the Commission rejected the strategy of decomposing a high-risk system into individually low-risk components to claim each piece falls outside Article 6 or qualifies for the filter. Agentic AI is named explicitly. The combined configuration is the unit of classification, although ¶76 Annex III preserves genuinely separable components serving distinct, separable functions, which can still sit outside the combined assessment. For governance teams, the operational consequence is system-level classification: the workflow, its linked components, and its intended high-risk purpose need one combined classification analysis. Genuinely separable procedural or preparatory components remain available, but the burden of demonstrating separability sits with the provider.

Four. Narrow procedural excludes value judgements. The "narrow procedural task" condition does not cover anything with a value judgement, scoring, or ranking (¶93 Annex III). Many use cases that look procedural in marketing copy fail this test in practice.

Five. Improvement cannot change rights or economic position. The "improves human result" condition does not apply where the AI system meaningfully changes the rights or economic position of the data subject (¶96 Annex III). The improvement must stay technical without altering the substance of the prior human assessment.

Six. Registration and penalty. Using the filter requires documented self-assessment and registration in the EU database under Article 71 (¶114 Annex III). Misclassification under the filter triggers Article 99 penalties (¶117 Annex III). The filter therefore creates a registration trail: a provider that classifies a system as not-high-risk under Article 6(3) leaves an Article 6(4) record, with the level of public visibility depending on the use case (Article 49 keeps some sections non-public for points 1, 6, and 7, and limits Point 2 to national registration). A provider that classifies the same system as not-Annex-III-at-all and does not engage the filter creates no equivalent record and remains invisible until challenged. That asymmetry creates a perverse incentive to under-engage the filter. Whether the Commission addresses it in the final guidelines is open.

The net effect is that the filter is much narrower than the text alone suggests. For most Annex III-listed use cases, the operative compliance plan should treat the substantive high-risk obligations as the working assumption and the filter as a bonus to be confirmed case by case.

The filter still does real work for genuinely procedural and preparatory functions, and the draft guidelines list examples. Credential verification, CV parsing, interview scheduling, candidate acknowledgements, voluntary training feedback, exam-quality checks, grade calculators, factual case-handler chatbots, translation, transcription, court pre-classification of documents, advanced search across case law, metadata extraction, and judicial style editing can sit outside high-risk classification when they stay procedural, preparatory, or limited to improving completed human work. The classification task is to triage the workflow against its intended purpose and decision impact, and to separate genuinely independent support functions where the draft guidelines support that separability.

10. Why waiting for the final EU AI Act high-risk guidelines is a strategic mistake

A defensible-looking response to the draft guidelines is to wait, because the drafts will be further consulted (¶5 general principles) and the final text could shift. Why build compliance against an interpretation that might change?

Pricing compliance on the most permissive interpretation of draft guidance fails on three independent risk vectors.

Regulatory risk. The Commission can tighten the guidelines before adoption based on stakeholder feedback. Several of the most consequential moves in the current draft (the CER linkage in ¶190 Annex III, the "specifically intended" gloss for elections in ¶437 Annex III, the profiling presumption for education in ¶215 Annex III) are precisely the moves stakeholder consultation can revise in either direction. Compliance built against today's text may need revisiting if the final version tightens further.

Litigation risk. Market surveillance authorities and national courts are not bound by Commission guidelines. MSAs can evaluate classification, require compliance, demand corrective action, and impose Article 99 penalties on providers that misclassify under the filter (¶117 Annex III). A provider that classified a system as not-high-risk because the draft guidelines suggested it could be is exposed if an MSA reads the operative text differently. The CJEU has the final word on interpretation, which can take years; an MSA inspection, by contrast, does not.

Procurement risk. Enterprise buyers and government tenders will demand evidence of EU AI Act compliance against the operative text, regardless of how lenient the draft guidance appears. AI governance and management-system frameworks like ISO 42001 require evidence of governance against the binding regulatory baseline. Adjacent obligations under NIS2 (cybersecurity for essential entities) and DORA (operational resilience for financial-services entities) compound the procurement evidence requirements but operate on their own terms.

The timeline closes the option to wait. The post-Omnibus timetable sets Article 6(2) and Annex III obligations on 2 December 2027 and Article 6(1) and Annex I obligations on 2 August 2028, subject to formal adoption of the Omnibus package. Governance build-out for a multi-system enterprise is genuinely 18 to 24 months: AI inventory, classification, risk management documentation, registration workflows, conformity assessment evidence, post-market monitoring, human oversight controls. Companies starting now are ready in late 2027. Companies treating Annex III as a free pass while they wait for adoption will be twelve months behind when procurement counterparts ask for evidence in late 2026 and the AI Office, the AI Board, and the national MSAs begin pre-deadline communications.

The right posture is to read the draft guidelines as the most authoritative current enforcement signal and the regulation itself as the source of binding obligations. Build compliance against the regulation. Section 11 closes on why that distinction is the most durable part of this analysis.

11. These are draft Commission guidelines, not law

This post just walked through ten sections of Commission analysis. Step back from the analysis for a moment.

The chapters published on 19 May 2026 are draft Commission guidelines issued pursuant to Article 6(5) AI Act. The general principles chapter says, in paragraph 6, exactly what they are:

"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 ('CJEU')."

That sentence does not retract any of the analysis above. It locates it. The hierarchy:

1. The EU AI Act. Binding law.
2. Recitals to the AI Act. Interpretive aids, not operative.
3. Commission guidelines. The Commission's interpretation of how the operative text should apply. Influential.
4. CJEU rulings. Authoritative interpretation.

The draft guidelines describe themselves accurately in ¶450 general principles as "a first interpretation with practical examples of the classification of AI systems," and they sit within the wider Article 96 guidance regime, which covers classification, prohibited practices, transparency, substantial modification, and the relationship with the Annex I harmonisation legislation. They are a strong signal of enforcement posture from the institution that initiates infringement proceedings and convenes the AI Board. The ceiling of obligations sits in the operative text of the regulation. ¶451 general principles flags that the guidelines may be updated and that Annex III itself is reviewable annually under Article 7 via delegated acts.

There are at least two places in the current drafts where the guidelines reach beyond what the operative text plainly says. The CER linkage in ¶190 Annex III adds a "critical entity" designation criterion that is not obviously inside Article 3(62) AI Act. The "specifically intended" gloss at ¶437 Annex III tightens the Point 8(b) operative language ("intended to be used to influence the outcome of an election or referendum or the voting behaviour of natural persons") by adding the word "specifically." Both interpretations are defensible, and both are also contestable. A provider whose system falls outside the guidelines' interpretation but inside the plain meaning of the operative text is in a defensible position before the Commission, and exposed before a market surveillance authority or in litigation that turns on the operative text.

This is the practical implication. Build compliance against the operative text of the EU AI Act, and treat the draft guidelines as enforcement intel: the best available signal of how the Commission expects Article 6 to apply between now and adoption. The operative text sets the ceiling of obligations; the guidelines suggest where enforcement attention will land first.

Where the guidelines tighten what the text says, plan for the stricter interpretation anyway. Stakeholder consultation can move adoption in either direction. The consultation that softens the Commission's most stretched interpretations is the same consultation that can sharpen them. A provider that has built against the operative text is robust to either outcome. A provider that has built only against the current draft's most permissive interpretation is exposed to both.

What to do this week

The single highest-value move this week is an AI inventory pass against the categories that broadened in the draft guidelines: Point 3 (education and vocational training), Point 4 (employment, workers' management, access to self-employment), and Point 5(c) (life and health insurance, including LTC, pension, and credit life). For any physical-product portfolio in the harmonised sectors (machinery, medical devices, automotive, marine, aviation, rail), add an Article 6(1) decision-tree pass: safety-component triggers (intent-based or consequences-based) and the closed Module A loophole. For agentic AI deployments, treat ¶75 Annex III as the working classification rule: classify the combined configuration.

For a CISO, CIO, or CTO at a larger enterprise, the board-facing priority order is Point 4 employment AI first (broadest scope, most likely caught at any large company), Article 6(1) physical-product portfolios second (the silent expansion through the Module A closure), and Point 5(c) or Point 3 third where the business has insurance, pension, or L&D AI in scope. Pull the inventory owners into the conversation now: HR systems lead, learning and development lead, insurance product owners where applicable, product safety, procurement, legal, and AI governance. Add to the vendor onboarding and renewal checklist the items that will define defensible evidence in late 2026 and 2027: intended-purpose declaration, Annex III classification per system, Article 6(3) self-assessment with EU database registration if the vendor claims the filter, profiling analysis on personal-data systems, and Article 25 repurposing-risk check on any vendor system you rebrand, modify, or redirect to a new purpose.

Build the compliance program against the EU AI Act itself, using the draft guidelines as the current enforcement signal and the consultation process as the watchlist for classification changes. The post-Omnibus application dates (2 December 2027 and 2 August 2028) are set, subject to formal adoption.

Modulos works with enterprises on the AI inventory, classification, and lifecycle governance that the AI Act, ISO 42001, and NIST AI RMF all require. Request a demo to see how the platform operationalises compliance against the operative text, ahead of the December 2027 deadline.