EU AI Act Update: The European Commission Publishes Draft Guidelines on HRAIs

By Dan Cooper, Marty Hansen, Jadzia Pierce, Anna Sophia Oberschelp de Meneses, Sam Jungyun Choi, Marianna Drake & Madelaine Harrington on June 5, 2026

On 19 May 2026, the European Commission published its long-awaited draft, non-binding guidelines on the classification of high-risk AI systems (“HRAIs”) under the EU AI Act (the “Guidelines”). Across three documents—covering general principles, high-risk classification in the context of regulated products (Annex I), and high-risk use cases (Annex III)—the Commission sets out its approach to one of the AI Act’s central questions: when does an AI system fall within the high-risk regime (and, just as importantly, when does it not)?

Rather than restating every aspect of the Guidelines, this post highlights a number of interpretative points likely to matter most in practice.

Link to 1. Agentic AI Systems 1. Agentic AI Systems

Importantly, the draft Guidelines clarify that complex systems made up of several AI components, including so-called agentic AI systems, must be assessed holistically. The Guidelines state that, where multiple AI components interact and their combined outputs materially influence a decision in a high-risk use case, the system is to be treated as a single AI system. As a result, individual components cannot rely on the Article 6(3) filter in isolation unless they are genuinely separable and do not contribute to a high-risk purpose. Accordingly, even if a component performs only a narrow procedural or preparatory task, it may still be classified as high-risk where, as part of a complex or agentic AI system, it contributes to outputs that materially influence an Annex III use case.

Link to 2. Annex I: Products Falling Under EU Harmonized Legislation 2. Annex I: Products Falling Under EU Harmonized Legislation

As a reminder, the AI Act classifies as high risk any AI system that (i) is either intended to be used as a safety component of a product, or is itself a product covered by the EU harmonization legislation listed in Annex I to the AI Act (“Regulated Product”), and that (ii) legislation requires the Regulated Product to undergo a third-party conformity assessment (Article 6(1)). Many of these product safety laws form part of the EU New Legislative Framework (“NLF”), which establishes a common legal framework governing how products are assessed for compliance and placed on the EU market. The Guidelines emphasize that the AI Act should be read alongside this NLF and the Blue Guide, the Commission’s key guidance on the practical application of EU product safety legislation.

The Guidelines highlight several points of practical importance:

Article 6(1) applies regardless of how the AI system is provided. Article 6(1) applies regardless of whether the AI system is embedded in a product or provided separately (e.g., via software updates, add‑ons, or remote services).
AI systems may be standalone Regulated Products. The Guidelines explain that an AI system is not always just part of a product. In some cases, it can itself qualify as a “product” under EU harmonized legislation (e.g., the Machinery Regulation, which covers not only physical machinery but also certain safety components, including AI-based systems performing safety functions). While it may be less intuitive to think of software as a Regulated Product in its own right, the Commission guidance expressly states that this can be the case where the software falls within the scope of such legislation.
AI systems integrated into consumer products are not automatically high risk. The Article 6(1) criteria must still be met. In many cases, the AI system will not itself qualify as the Regulated Product, but rather as a component of it, although this depends on the scope of the applicable sectoral legislation. Where it qualifies as a component, it will only fall within scope if it constitutes a safety component and the relevant component is subject to a third-party conformity assessment.
AI Act definition of “safety component” controls. The AI Act establishes its own definition of “safety component” in Article 3(14). An AI system will qualify as a safety component if it either (i) performs a safety function, or (ii) its failure or malfunction could endanger health or safety of persons or property. The Guidelines emphasize that this is an autonomous, cross‑sectoral definition that applies independently of, and takes precedence over, any differing definitions in the harmonized legislation listed in Annex I. As a result, high-risk classification under Article 6(1) must be assessed solely against the AI Act definition.
Safety risk must be real, but safety functions will be interpreted broadly. The risk must go beyond theoretical harm and relate to physical harm to persons or property. Purely financial loss, reputational harm, or inconvenience are excluded. Harm to health also covers mental health (e.g., psychological trauma or other serious mental health impacts that significantly affect a person’s ability to carry out everyday activities). At the same time, the Guidelines signal that safety functions will be interpreted broadly, to potentially include: (i) monitoring and detection of hazardous situations; (ii) predictive maintenance where failure could create safety risks; (iii) prevention or mitigation of harm (e.g., shutdown mechanisms); and (iv) supervision of other safety components. In addition, AI systems designed for non-safety objectives (e.g., efficiency or user experience) may still qualify as “safety components” where failure creates or amplifies safety risks (e.g., combustion optimization systems, lane assistance).
Narrow exclusion. As provided in recital 55 of the AI Act, safety components intended to be used solely for cybersecurity purposes are excluded from the notion of a “safety component,” but only when used in critical infrastructure (e.g., energy networks, transport systems, or water supply infrastructure).

Link to 3. Annex III 3. Annex III

The Guidelines address all Annex III high-risk use cases. This post highlights interpretative clarifications that are likely to be most relevant to commercial deployments. We highlight four key areas: general principles for Annex III systems and the Article 6(3) filter, biometric AI systems, employment, and the fraud detection exception.

Link to A. General Principles for Annex III Systems: Intended Purpose and the Article 6(3) Filter A. General Principles for Annex III Systems: Intended Purpose and the Article 6(3) Filter

Intended Purpose. The “intended purpose” of the AI system – including how it is described across product materials – is central to high-risk classification (i.e., if the intended purpose of an AI system is one of the uses set out in Annex III, it will qualify as high-risk). The Guidelines emphasize that providers must describe the envisaged use clearly and consistently across all relevant materials, including instructions for use, technical documentation, and marketing or sales content. Where a system is intended for use across multiple contexts or applications, each should be clearly defined so that the high-risk assessment can be conducted on a case-by-case basis.

With respect to general-purpose AI (“GPAI”) systems and systems designed to support multiple use cases, providers are expected to describe all envisaged applications, as classification must take into account the full range of intended uses. The Commission states that if the provider’s materials present the system as broadly applicable across many contexts and do not consistently exclude high-risk uses, the system’s intended purpose will be deemed to include high-risk uses where they are feasible and reasonably foreseeable. The Commission also makes clear that merely asserting that high-risk uses are excluded (e.g., in terms of service) is insufficient where the provider’s overall presentation, examples, or product positioning effectively provides for or promotes such high-risk uses.

The Article 6(3) Filter. The Guidelines also set out the Commission’s views on the application of the Article 6(3) filter, under which certain systems that would otherwise fall within high-risk use cases may nevertheless be excluded because they do not pose a significant risk to health, safety, or fundamental rights. The Guidelines take the view that this exclusion applies only where specific conditions are met, including that the system does not perform profiling and does not materially influence decision-making outcomes. The Commission emphasizes that this is a limited exception and should be interpreted narrowly.

The Guidelines provide detail on the four exhaustive but alternative scenarios in which the filter may apply: (i) where the system performs a narrow procedural task; (ii) where it improves the result of a previously completed human activity; (iii) where it is used to detect patterns or deviations in past decision-making; or (iv) where it carries out a preparatory function in support of a human-led assessment. Across these scenarios, the distinction between a system supporting and substantively influencing a decision is central.

The Commission also clarifies that the presence of human involvement does not, in itself, exclude a system from classification as high-risk, as this does not change the system’s intended purpose. While human oversight may be relevant to certain aspects of the filter, it is not determinative.

To rely on the Article 6(3) filter, providers must carry out and document an assessment before placing the system on the market or putting it into service, as well as register the AI system in the EU database established pursuant to Article 71. The Guidelines include examples illustrating how the different conditions may apply in practice and highlight the importance of maintaining supporting documentation.

Link to B. Biometric AI Systems B. Biometric AI Systems

Annex III also addresses a number of biometric AI use cases that are directly relevant to private-sector deployments, including remote biometric identification (“RBI”), biometric categorization, and emotion recognition. The Guidelines set out the Commission’s view on how these categories should be interpreted in practice, particularly for companies deploying AI in customer-facing or workplace contexts.

Distinction between identification and authentication. The Guidelines confirm that remote biometric identification captures systems used to identify individuals without their active involvement (typically at a distance) by matching their biometric data against information in a database. This is potentially broad and may extend beyond traditional security or surveillance contexts to include certain commercial use cases. At the same time, the Guidelines draw a clear distinction with biometric verification or authentication systems, which generally fall outside scope where the individual actively presents themselves (e.g. device unlocking or building access control). This distinction between passive identification and active participation will be critical for product design and positioning.

Narrower scope for biometric categorization. By contrast, biometric categorization is more narrowly framed. The use case only applies where systems use biometric data to infer sensitive or protected characteristics (such as health status or ethnicity). This excludes many common forms of categorization (e.g. based on age or gender), but captures certain advanced analytics use cases that derive new insights from behavioral or physiological signals. The Guidelines’ focus on “inference” underscores regulatory concern with systems that move beyond identification to generate potentially sensitive conclusions about individuals.
Broad treatment of emotion recognition systems. The Guidelines confirm that emotion recognition systems are high risk, with potentially wide-ranging implications for commercial applications. These systems infer emotions or intentions from biometric signals such as voice, facial expressions, or posture, and the Guidelines specifically reference use cases such as call center analytics, user engagement tools, and wearable technologies. At the same time, the Guidelines distinguish such systems from those detecting purely physical states (e.g. fatigue or drowsiness), which are generally outside scope where no emotional or psychological inference is involved. The Guidelines also underscore that although many use cases are permissible (even if high risk), in workplace and educational institution contexts, emotion recognition systems may be completely prohibited under Article 5.
Broad definition of biometric data and focus on intended use. Across all three categories, the Guidelines adopt a broad concept of biometric data, encompassing not only physical identifiers (e.g. facial images), but also behavioral signals such as gait, keystrokes, or voice patterns. As elsewhere in Annex III, however, classification ultimately depends on the system’s intended purpose and deployment context, meaning that similar technologies may fall inside or outside the high-risk regime depending on how they are positioned and used.

Link to C. Employment C. Employment

Category 4 of Annex III addresses employment-related intended use cases. Point 4(a) focuses on recruitment and selection, while point 4(b) covers decisions impacting employment, employee monitoring, and task allocation. Several points are worth highlighting:

Conjunctive phrases read as alternatives. Both points 4(a) and 4(b) of Annex III include conjunctive clauses that the Guidelines interpret disjunctively. For example, “analyse and filter job applications” in point 4(a) is, according to the Guidelines, not limited to “AI systems that always perform both functions simultaneously.” In point 4(b), the reference to systems that “monitor and evaluate” is, according to the Guidelines, intended to cover systems that “monitor ‘or’ evaluate workers’ performance or behaviour.”
“Decisions” interpreted functionally. The Guidelines interpret “decision” broadly to include both acts and omissions, and not to be“limited to unilateral modifications of contract or relationship in the strict sense.” At the same time, the use case “cannot be stretched to include all day-to-day or operational decisions,” and a threshold of “significance” must be met. The examples of out-of-scope decisions are relatively limited, however—including, for example, “allocation of office space and break or lunch time within the context of an assigned shift (as long as no changes occur to the total break and lunch time enjoyed by the worker).”
Platform work. In the platform work context, the Guidelines indicate that AI systems used to enact suspensions or deactivations may fall within the “promotion or termination of work-related relationships” clause. It further notes that “where an AI system definitively suspends a platform account, the effect is to deprive the individual of access to their professional activity,” suggesting that suspension decisions may be in scope even where they do not amount to formal termination. The Guidelines also identify compensation-related AI systems as in scope, including “AI system[s] for pricing and pay determination in platform work.”
Task allocation based on personal traits or behavior. Point 4(b) captures AI systems “intended to be used to allocate tasks based on individual behavior or personal traits or characteristics.” According to the Guidelines, behavioral indicators, including “punctuality, responsiveness to customer requests, reliability metrics, or performance ratings”—fall within scope of “personal traits or characteristics.” The Guidelines distinguish these from “neutral, objective and external factors,” such as allocating work based on “possession of a required professional accreditation.”
Scope of monitoring and evaluation. The Guidelines take a broad view of what constitutes “performance” and “behaviour.” “Performance” includes both quantitative outputs (e.g., output speed) and qualitative indicators such as performance assessments, while “behaviour” may include, among other things, punctuality, client responsiveness, and “patterns of interaction with colleagues.” However, the Guidelines carve out systems used “exclusively to meet external legal or regulatory obligations” or “exclusively for medical and safety reasons or to protect property and company assets,” provided they are not also used for monitoring or evaluation purposes. Intended use will therefore be critical in determining scope.

Link to D. Clarifications on the “Fraud Detection” Exemption D. Clarifications on the “Fraud Detection” Exemption

Point 5(b) of Annex III to the AI Act classifies AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score as high risk, except where they are used for the purpose of detecting financial fraud. The Commission appears to interpret this exception narrowly:

Main intended use. The Guidelines clarify that the exception can only apply to AI systems whose “main” intended use is fraud detection. By way of illustration, the Commission considers an AI system that is mainly used “for pattern recognition and anomaly detection” in this context may benefit from the exception under point 5(b), even if its output may be used for creditworthiness assessment or credit-scoring.
AML/CFT distinction. The Guidelines distinguish AI systems intended to be used for detecting financial fraud from those used for anti-money laundering and countering the financing of terrorism (“AML/CFT”), noting that the latter are not covered by the financial fraud detection exception under point 5(b) because they are regulated by separate EU legislation and are not related to financial fraud. Thus, AML/CFT systems that are functionally linked to and simultaneously intended to be used for creditworthiness evaluation or credit-scoring will fall within point 5(b) and be classified as high risk.
No equivalent exception for life and health insurance. Finally, the Commission highlights that AI systems intended to be used for risk assessment or pricing in the case of life and health insurance cannot benefit from a similar “fraud detection” exception. An AI system intended for such risk assessment or pricing remains high-risk even where it has a fraud detection capability. A fraud detection feature will only fall outside the high-risk categorization in this context if it could be deemed a standalone AI system, separate from the AI system used for risk assessment or pricing.

Looking Ahead

The Guidelines remain in draft form and are open for public consultation until 23 June 2026. They were published against the backdrop of recently proposed changes to the AI Act, which postpone the application of the AI Act’s provisions on HRAIs until next year (2 December 2027) and the year after (2 August 2028), depending on the HRAI in question. For more on these proposed changes, see our post here.

This post was written with the assistance of Erin Lynch, a trainee solicitor in the London office.