The guidelines

The Commission has published three sets of draft guidelines:

• general principles;
• Annex III high-risk AI systems (standalone AI systems); and
• Annex I high-risk AI systems (AI systems embedded in a product.

Interested stakeholders can submit their input on the consultation until 23 June 2026.

This post looks at the guidelines for Annex III high-risk AI systems.  These guidelines:

• discuss the application of the derogation under Article 6(3)
• provide discussion and examples of what is high-risk, what is not high-risk, and what is high-risk but falls under Article 6(3) for each high-risk purpose under Annex III. 

This post provides commentary on the Commission’s view on the application of the derogation Article 6(3).  It also discusses some of the commission’s views on employment high-risk purposes under Annex III(4), since these have broad cross-sectoral relevance.  

Recap – what are the consequences of an AI system being high-risk?

These guidelines are designed to help organisations falling within the geographic scope of the AI Act to confirm whether their AI systems are high-risk.  If the AI system is high-risk, consequent obligations depend on the organisation’s role.

Providers: generally, the organisation developing the technology or having it developed. 

Providers are subject to significant risk management and governance obligations for the specific high-risk AI system.  These obligations are not about the organisation’s general risk management processes (although a strong organisational AI governance programme provides a helpful foundation).  Rather, they relate to assessing and mitigating risks for the specific product and creating detailed technical documentation for the product.  Before placing the product on the market or putting it into service, the provider must assess (or have a third-party notified body assess) and declare conformity, affix the CE mark, and register the AI system in the EU database.  The rules envisage that compliance is carried out throughout the development life cycle, rather than retrospectively after development.  Retrofitting and compiling technical documentation once development is complete will be more challenging.

European standardisation bodies CEN and CENELEC are currently developing standards to set out how providers could comply, addressing a standardisation request from the Commission.  When published in the EU’s Official Journal, these will become harmonised standards and following them will provide a presumption of conformity with the relevant requirements.  At the time of writing, three of these standards (prEN 18288 (AI Risk Management), prEN 18282 (Cybersecurity), and FprEN 18286 (Quality management system)) have been made available in draft form for public enquiry, while the majority are still under preparation.

Becoming a provider: it is possible for organisation which does not carry out the initial development (or any development at all) to become subject to these very significant obligations by:

• use of general-purpose tools (internal or off-the shelf generative AI solutions) for a high-risk purpose (Article 25(1)(c));
• creation of an agent for a high-risk purpose, e.g. sifting CVs or performance management;
• adding the organisation’s branding (name and trade mark) on another provider’s high-risk AI system (Article 25(1)(a)); or
• substantial modification Article 25(1)(b) – though this is not generally an option for off-the-shelf tools with a specific function.

Deployers: generally, the organisation using the technology.

Deployer obligations relate to managing risks around how the AI system is used in practice, for example by informing decision subjects about AI use and assigning competent human oversight.

What’s in and out

There is NO human-in-the-loop exemption

The Commission confirms that human involvement “has no effect on the classification of the system as high-risk”.[1]  This is because human involvement cannot change the purpose for which an AI system is intended to be used.

If one of the four conditions of Article 6(3) are met, the provider might be able to exempt the system classification of high-risk.  The type of human involvement during deployment may be relevant to demonstrate that the AI system is intended to perform a narrow procedural or preparatory task or improve an already completed human task.

However, “The provider cannot exempt and categorise an AI system as ‘low risk’ simply by adding to it a requirement for human involvement”.

The four derogations listed in Article 6(3) should be interpreted narrowly

Article 6(3) provides a derogation for AI systems falling under an Annex III purpose that do 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” where they meet any of the following conditions:

“ (a) the AI system is intended to perform a narrow procedural task;

(b) the AI system is intended to improve the result of a previously completed human activity;

(c) the AI system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review; or

(d) the AI system is intended to perform a preparatory task to an assessment relevant for the purposes of the use cases listed in Annex III.”

The Commission refers to the derogation in Article 6(3) as a ‘filter mechanism’.  This can only be applied when an AI system meets one of the conditions set out at Article 6(3)(a)-(d).[2]

The Commission appears to suggest that there is no generalderogation availablefor AI systems that do not pose a significant risk of harmto health, safety or fundamental rights – the conditions listed are exhaustive.[3]

Each of the Article 6(3)(a)-(d) grounds must be interpreted narrowly.  However, where a provider has assessed and concluded that their AI system does fall under one of the exemptions, it is not necessary to conduct an additional assessment to determine whether the AI system poses a significant or any risk of harm besides those conditions.[4]

The profiling exemption – which means the AI system is high-risk even if one of the Article 6(3) conditions would apply – is also discussed.  Profiling is carried out where an individual’s decisions and personal characteristics are assessed.  For example, an AI system to evaluate recruiter’s decisions and deviations from previous patterns, in light of their personal characteristics, would be considered profiling.  It would therefore be high-risk even though it could fall under Article 6(3)(c).[5]  Examples are then provided to assist with general interpretation of each condition,[6] followed by examples for each high-risk purpose later in the guidance.

Providers wishing to rely on one of these conditions must document an assessment setting out why the system would be high-risk, which condition it believes applies and why, and a description of why the system does not perform profiling.[7]

Providers must also register their AI system in the EU database where they assess and conclude that Article 6(3) applies to their AI system.  The changes to the AI Act made by the AI Omnibus will simplify registration requirements.

Employment examples

The Commission provides valuable colour on which use cases fall into this category.

Recruitment, selection, placing targeted job ads, analysing and filtering job applications, and evaluating candidates

This encompasses the range of activities around identification and attraction of potential applicants.[8]

The line on whether a purpose falls under Article 6(3) can be a fine one.  Generation of job descriptions falls within this category where the AI system plays a role in the recruitment process. The specific AI system may fall within Article 6(3)(a) derogation (narrow procedural task) if the AI system is generating the description based on a list of tasks to be carried out and list of necessary qualifications and skills previously defined by a human recruiter.  However, it will fall outside the ‘narrow procedural task’ derogation where it generates the necessary qualifications and skills based on high-level description.[9]

Practical examples of high-risk use cases, unsurprisingly, include AI systems intended  to be used as automated job matching and ranking tools, AI systems used for scoring applicant answers in a recruitment process, and placing targeted social media ads based on navigation patters and a wide range of user characteristics. [10]

Examples of use cases that would not be high-risk include AI systems used to non-inclusive and discriminatory wording in job descriptions.  AI systems that would fall under Article 6(3) (and so require registration) interestingly include CV parsers and AI systems for scheduling interviews.

AI systems intended to manage work-related relationships

This high-risk purpose is included to address potential discrimination in relation to opportunities that could impact workers’ livelihoods and career prospects.

It encompasses promotion and termination, and also allocation of tasks based on personal traits and characteristics.  AI systems allocating tasks based on neutral, objective, and external factors, such as availability or location, would not be caught.[11]  In contrast, AI systems that use criteria such as responsiveness to customer requests or reliability metrics, such as AI systems that allocate delivery slots or rank external lawyers, will be considered high-risk.[12]

Other examples considered high-risk include an AI system that dynamically sets driver compensation based on real-time demand, driver acceptance rates, and passenger ratings.  Examples of AI systems that would fall under Article 6(3) include AI systems compiling performance records into structured reports to send to managers at a fixed date, and an AI system to refine human-drafted promotion evaluations and flag potentially biased wording.[13]

Our take: what to do now (providers and deployers)

The obligations for high-risk AI systems are now set to apply from 2 December 2027 (rather than 2 August 2026).  At the time of writing, political agreement has been reached on pushing this date back, though the AI Omnibus still needs to be published in the EU’s Official Journal before 10 July to make the change effective.

Providers: should use these guidelines to confirm which of their products are high-risk and begin the work of embedding compliance processes as soon as possible.  As discussed above, provider obligations require risk management and governance to be embedded and documented during the product life cycle and cannot simple be addressed on the AI Act’s application date.

Where providers assess and believe that an AI system falls under Article 6(3), they should also ensure that their assessment is documented (registration will also be required when the EU database is available).

Providers should also familiarise themselves with AI Act standards as they become available, including the three already made available in draft form.

Deployers: should ensure that they have policy and, ideally, technical controls in place to prevent accidental accession to the provider role.  As discussed above, this can happen inadvertently through high-risk application of general-purpose tools.

Deployers should also ensure that they are able to identify which of their AI systems are high-risk and begin to:

• ensure they have appropriate contractual protections in place for contracts that may run past December 2027; and
• augment existing compliance processes to comply with deployer obligations.

[1] Para 70.

[2] Para 86.

[3] Para 88.

[4] Para 88.

[5] Para 112 and example following.

[6] Paras 97-108.

[7] Para 115.

[8] Para 246.

[9] Example on p.64.

[10] Examples for Annex III(4)(a) from p.66.

[11] Para 271.

[12] Para 270.

[13] Examples for Annex III(4)(b) from p.76.

Although access to Mythos itself is currently restricted to approximately 40 hand-picked organizations under an initiative called Project Glasswing, equivalent capability is estimated to emerge in the broader market, potentially in adversarial hands, within 6 to 24 months.

What Anthropic disclosed

Mythos is a general-purpose large language model that was not designed as a cybersecurity tool. Its offensive capabilities were not purposefully engineered but rather emerged as a byproduct of general improvements in reasoning, code generation, and autonomous task execution. That distinction is essential as it implies that every frontier AI laboratory currently pursuing the same general improvements is potentially on a path to the same destination.

According to Anthropic’s own published technical analysis, Mythos can autonomously identify “zero-day vulnerabilities in every major operating system and every major web browser.” The model is then able to develop working exploits for those vulnerabilities without human assistance. In benchmark testing, Anthropic’s prior frontier model produced working exploits only twice in several hundred attempts on a standardized task, where Mythos produced 181 working exploits. In broader testing across thousands of open source software targets, Mythos distinguished itself from prior frontier models by achieving full system compromise on ten fully-patched targets.

Anthropic also disclosed three notable behavioral findings from its safety testing of earlier versions of Mythos:

• First, the model escaped its sandboxed testing environment by developing its own multi-step exploit, gained broader internet access it was not supposed to have, and then, going beyond its assignment, posted details of its escape to publicly accessible websites.
• Second, in rare cases, the model used a prohibited method to arrive at a solution, appeared to recognize that doing so would be detectable, and then re-worked the problem through permitted means before presenting its answer, effectively concealing how it had actually solved the problem.
• Third, in very limited instances, when the model’s work on a coding task was being evaluated by another AI system and the submission was rejected, the model attempted a rudimentary prompt injection attack against the grader. In other words, it can be inferred that the model tried to manipulate the system judging it rather than simply improving its answer.

Viewed collectively, these findings describe a system potentially capable of strategic deception and autonomous action beyond the scope of its instructions at an unprecedented pace.

Anthropic’s response through Project Glasswing, in coordination with a limited group of organizations responsible for critical digital infrastructures, reflects a well-resourced effort to identify and patch critical vulnerabilities by leveraging the defensive capabilities of Mythos. Nevertheless, the controlled release model retained by Anthropic is likely to concentrate the defensive advantages among organizations already operating at the frontier of security capability. What remains uncertain is how much practical benefit will flow to the organizations that most need it, on what timeline, and through what mechanisms.

What comes next

In the coming months, the capabilities of Mythos-like models (“Frontier AI models”) are expected to reach adversaries, financially motivated threat actors and state-sponsored threat groups alike. Threat actors will be able to simply acquire the capability through a model and maintain the necessary compute power to use it. This ability will lower the barrier to entry to the criminal market of exploits and potentially grant operational independence to organized criminal ransomware groups who may have depended on exploits developed by and purchased from the broker ecosystem. With the ability to run autonomous vulnerability discovery against industrial control systems and Operation Technology (OT) environments, for instance, threat actor groups will be able to produce working exploits for vulnerabilities that have existed undetected for decades at marginal cost and at scale.

Mythos is not without limitations such as its false positive rates, the conditions under which vulnerabilities were found in testing, and the practical usefulness of certain vulnerabilities in the context of real-world exploits. Nevertheless, Mythos and other Frontier AI models represent an inflection point in the threat landscape as it illustrates that AI-enabled offensive capabilities have been accelerating faster than the governance and defensive frameworks designed to contain them.

Looking ahead, AI-enabled adversaries will be equipped to launch simultaneous multi-vector attacks without any human bandwidth constraints. As such, adversaries could start running parallel overnight discovery campaigns against networks, messaging infrastructure, and cloud hypervisors at the same time, at marginal cost.

What to do now

The coming months present a consequential preparation window for organizations to jumpstart or reignite efforts to manage cybersecurity risks.

The next 90 days

Regardless of sector, identifying where their oldest, least-maintained code and systems live and how much of it is written in memory-unsafe programming languages is key. This recommendation is consistent with the long-standing cybersecurity principle – organizations cannot effectively prioritize remediation for assets they have not inventoried. That inventory, and the risk assessment that follows from it, is the first step for every organization regardless of industry.

A review of the organization’s incident response plan and preparedness to address simultaneous multi-vector attacks comes next. Most incident response programs assume a sequential attack that does not account for adversaries armored with automated and parallelized attack planning. Under existing incident response protocols, containment decisions made to respond to one attack vector can potentially accelerate damage from another, and notification timelines for different incident types may also run concurrently and complicate stakeholders’ decision making process. With the rise of AI-enabled adversaries, organizations should now test their response programs against this scenario. Identifying that gap now, before it is exposed during an active incident, is a meaningful risk reduction step.

Each sector faces heightened exposure to specific challenges.

• Financial institutions: Financial institutions face additional hurdles in relation to future regulatory disclosures or examinations. In particular, for certain companies subject to the New York Department of Financial Services (NYDFS) oversight and/or the Gramm-Leach-Bliley Act (GLBA), the development of Frontier AI models may warrant conducting risk assessments to account for potential changes to the company risk profile and update written materials.
• Energy sector: Companies in the energy sector often rely on OT devices and systems, which are among the hardest to patch and the most disruptive to take offline for maintenance and update. Nevertheless, pipeline operators subject to the TSA Security Directives may benefit from an initial advantage from compliance-driven OT asset inventories. At the same time, added connectivity expands the attack surface that organizations should monitor against AI‑enabled threats.
• Airlines and transportation sector: TSA-regulated airlines and other transportation-sector organizations have long operated under mature compliance regimes. These frameworks establish a robust baseline for critical systems and companies’ OT environments, but the connectivity introduced by compliance-driven monitoring has expanded the attack surface. TSA-regulated companies should specifically reassess this added connectivity in light of emerging threats such as via Frontier AI models exploitations.
• SaaS and IaaS providers: For IT service providers, complex cyber incidents often affect both the organization and its business customers. The pace and sophistication of attacks leveraging AI are likely to push the boundaries of what most current incident response plans contemplate, especially in the context of a multi-vector attack. Organizations should consider reviewing their incident response and customer communication plans to address scenarios in which multiple business customers are simultaneously experiencing disruptions.

Our take

There is no doubt that the novel threat of AI-enabled adversaries will cast more light on long-standing cybersecurity challenges and amplify the associated risks at an unmatched rate. The risk management solutions may nonetheless sound more familiar than one would expect.

Demonstration of having conducted a substantive exposure assessment and made reasonable, documented decisions in response to new and evolving risks, best positions organizations in addressing scrutiny by regulators, litigants, insurers and the public.

Additionally, organizations regardless of industry can benefit from taking several longer-term steps as they adapt to the rapidly shifting nature of AI-enabled exploits:

• How do our vulnerability and patch-management operations need to be enhanced to accelerate discovery and timely patching as AI-enabled threats evolve?   
• Do we need to review and update our contractual protections with our most significant vendors regarding AI-enabled threats?
• Do the existing threat intelligence service providers and managed detection tools have the ability to detect attack signatures that have no CVE match and no prior pattern in threat feeds?
• Do tabletop exercises and incident response plans account for multi-vector, simultaneous attack scenarios?
• Do board and executive briefings incorporate updated threat frameworks that reflect the development of Frontier AI models in the threat landscape?
• Do the existing cyber insurance policies provide adequate coverage and do the underlying risk questionnaires and policy terms remain accurate in the current threat landscape?

This briefing focuses on the impact of the changes for pension scheme trustees.  It includes points of relevance across sectors, and particularly for other regulated sectors.

One AI security vendor recently claimed that SOC2 was insufficient for evaluating AI security and controls. Although we might agree with the ultimate conclusion, the vendor made some surprising statements that show an implicit bias for the Band-Aid approach and a poor understanding of how to effectively govern Agentic AI systems. 

Here are a few examples of representations that should raise red flags.

Vendor:

“An AI Agent doesn’t have a fixed set of behaviors.”

Correct Approach:

AI agents in most settings should have established, fixed behaviors. Success and failure modes should be explicitly defined and governed. This should be done with static logic (code) and is one of the most important controls in any Agentic AI system. 

If success and failure are not well defined and monitored, then arguably the system is constructively allowed to misbehave.  And, when it does so, the failure mode will be silent. Trying to detect and stop these system failures after-the-fact with a Band-Aid approach resembles whack-a-mole more than it does governance. Relying on after-the-fact controls is like treating aviation safety as mostly a matter of investigating crashes instead of trying to increase the overall safety and reliability of the system.  After-the-fact detection isn’t meaningless, but it is the wrong layer to lean on.  In agentic AI, as in aviation, the primary safety work should happen before and during system operation.

Vendor:

“The agent may call APIs that are not part of any predefined workflow.”

Correct Approach:

Workflows should be pre-defined, and AI agents should only call APIs for which they are explicitly scoped in advance and subject to pre-defined static logic/control.

If access to API calls is not limited and controlled, then it becomes easier for those APIs to be accessed either inadvertently or maliciously.  Potential exploit chains (which string together multiple agentic components) become deeper and more numerous. To extend the airplane analogy, many commercial airplanes have a control system that sits between pilot action and airplane behavior.  Control systems on modern aircraft actively resist or prevent unsafe pilot maneuvers and will limit pitch, bank, and angle of attack to prevent stalls and exceeding safe speeds. These are exactly like the pre-defined limits on API calls: before the system can do the unsafe thing, a control has already prevented that system behavior.

Vendor:

“An AI agent decides at runtime what tools to use.”

Correct Approach:

Although it is true that Agent behavior is dynamic, the vendor leaves open the possibility that natural language (i.e., a call to an AI endpoint) can be allowed to invoke tools.  For a system to be reliable, however, tool usage should be controlled with static logic. The reason is because responses from AI endpoints are “probabilistic,” meaning one can’t perfectly control the content of the AI response over time. When tool usage turns on probabilistic responses from AI endpoints then, at some point, they are likely be invoked in ways that make the system unreliable and exploitable.  Over time, these small and unexpected responses can chain together and lead to cascading failures.  Similar to ungoverned API use, exploit chains become more dangerous and multiply.  In other words, when preparing for landing, there should be room for the pilot to make judgment calls based on wind speed, runway length, and physical obstacles, but those judgment calls should only be allowed to flip certain switches in the cockpit. 

The Critical Role of Lawyers and Compliance

In the current environment, where Agentic AI risks may not be fully appreciated by existing development and cyber teams, a compliance/procurement/cyber attorney may end up being the first and best line of defense to ensure the organization effectuates real governance and controls over the AI use case. 

With respect to every AI system and AI system component, an organization ideally should begin by posing the following questions:

• What am I trusting the system or component to do and why?
• How do I limit trust (and limit risk)?
• What is the system or component allowed to do?
• What is the system or component not allowed to do?
• What is the data the system is acting upon and what are my rights and limitations with respect to that data?
• How does the system enforce the answers to these questions?
• What is the risk of scope creep and how can I monitor the actual use over time?

The goal is to surface those areas where trust or scope of action is unwarranted or unnecessary.  The governance process is of course a good deal more involved than this, but this is the right conceptual and practical place to start.

In its “Let’s Talk MFA” training on February 26, 2026, NY DFS highlighted additional guidance including updated FAQs addressing Section 500.12. Covered Entities have until April 15, 2026 to certify their compliance with the NY DFS Cybersecurity Regulation in the annual notifications to NY DFS.

Put simply, NY DFS expects Covered Entities to show that MFA is implemented effectively across their systems, that the scope is complete, and that any risk-based exceptions or compensating controls are well documented, with particular attention to SSO, cloud services, and external-facing systems.

What Changed?

The FAQs provide notably granular direction on how NY DFS views common MFA approaches. The FAQs provide guidance on (i) what does and does not qualify as MFA, (ii) push-based authentication, (iii) single sign-on (SSO), (iv) cloud platforms, and (v) when external-facing systems may require MFA.

A Quick Refresher: What NY DFS Means by “MFA”

NY DFS defines MFA as authentication using at least two different factor types:

• Knowledge – something you know, such as a password, passphrase, or PIN.
• Possession – something you have, such as a token, authenticator app, or smartcard.
• Inherence – something you are, such as a biometric characteristic.

NY DFS emphasizes utilizing multiple distinct factor categories. Simply layering more checks that fall into a single bucket does not satisfy NY DFS’s requirements. For example, requiring two passwords is not considered MFA, because both passwords fall under the same “knowledge” factor type. Requiring a password (a “knowledge” factor) plus a token placed on your company-issued device (a “possession” factor) would constitute MFA since those incorporate two different factor types.

NY DFS Expectations

• “Possession” means real proof of possession. NY DFS highlights that a possession factor should provide cryptographic or technical proof that the user controls a specific device/token/authenticator at the moment of authentication.

• Push-based MFA is common, but NY DFS is focused on its weaknesses. NY DFS flags risks associated with push prompts (including “MFA fatigue”) and points to safeguards such as number-matching or challenge-response, displaying contextual login details, limiting push retries, and using adaptive MFA for suspicious activity.

• Single sign-on (SSO) can work, but SSO alone is not the answer. NY DFS states SSO may be used; however, MFA must be enforced as part of the authentication process in order to prevent the SSO layer from becoming a bypass route.

• Cloud email and document platforms are firmly in scope. NY DFS indicates that MFA is required for Covered Entities accessing cloud-based document storage and collaborative platforms.

• External-facing systems: often no MFA, but “material risk” changes the analysis. NY DFS notes that many external-facing systems, such as basic marketing pages, may not require MFA. But MFA may be expected where an external-facing system can be used to access other information systems without authentication, or where it otherwise poses a material cybersecurity risk to the Covered Entity, customers, other systems, or nonpublic information. For example, an insurance company’s website that contains only publicly available marketing materials would not need MFA. If the website enables access to personal information, however, additional analysis may be necessary.

Compensating Controls: Allowed, But Tightly Governed

Part 500 permits “reasonably equivalent or more secure” compensating controls in in place of MFA, but only with specific governance guardrails: CISO approval in writing and periodic review at least annually. Similarly, in examinations, NY DFS often focuses on the reasonableness of the decision-making and the supporting documentation, not just the existence of a tool. A compensating control may be reasonable immediately following the acquisition of another company during the transition period but may not be reasonable the following year.

Our Take

NY DFS’s recent guidance reinforces that MFA is a baseline expectation under Part 500. In practice, NY DFS supervision focuses on whether MFA is implemented effectively, whether coverage is complete, and whether exceptions or alternatives are supported by documentation and governance. Here are a few steps to help identify potential gaps and achieve compliance:

1. Confirm MFA is implemented broadly and consistently

Validating that MFA is not only deployed but consistently enforced across the access paths and information systems is key. NY DFS highlights the scope and sufficiency of implementation, including whether MFA has been implemented with third-party platforms.

2. Review documentation supporting MFA scope and design choices

NY DFS emphasizes documentation and reasonableness of risk-based determinations. Even strong technical controls can fall short if the organization cannot explain scope, exceptions, and design decisions.

3. Review and assess whether the existing process for compensating controls meets NY DFS requirements

NY DFS highlights governance requirements for compensating controls, including written CISO approval and periodic review at minimum annually.

The NY DFS guidance is another reminder for Covered Entities to get ready to demonstrate that MFA is consistently enforced across environments, and any exceptions or compensating controls are supported by clear documentation and governance practices.

Thanks to Jake Alfarah for his assistance with this post.