Cyber-Capable AI Compliance: : Three Regimes – the Same Model

WithWhen the European Parliament sits down in Strasbourg this week to assess the EU’s readiness for cyber-capable AI, the unusual thing is the framing. The briefing names Anthropic’s Mythos and OpenAI’s GPT-5.5-Cyber as a category, not as two models from two labs. That category sits inside three legal regimes at once, and cyber-capable AI compliance is now the deployer’s problem in all three of them.

Treat this as the working assumption for the next eighteen months. A frontier model designed to identify and exploit software vulnerabilities is software under the Cyber Resilience Act. It is in scope of the EU AI Act, and likely a general-purpose AI model with systemic risk depending on training compute. Any deployer that is also an essential or important entity under NIS2 carries a third layer of risk-management and incident-reporting obligations. None of the three regimes was drafted to govern the same object, yet all three now describe it.

Three regimes, one cyber-capable AI compliance problem

Each regime sits in a different policy file, written by a different team, in a different year. The deployer does not get to wait until they are reconciled. They overlap operationally, and the operational obligations bite first.

The AI Act layer

Provider obligations for general-purpose AI with systemic risk live in Article 51 and the articles that follow. The cybersecurity requirement for high-risk AI systems sits in Article 15. Deployer obligations attach through Article 26 whenever the system is used in a high-risk context, regardless of how the provider classifies its model. 22Academy has a useful primer on GPAI obligations for the systemic-risk threshold. The practical point: deployer obligations do not wait for the provider to finish its conformity assessment.

The NIS2 layer

NIS2 imposes risk-management measures under Article 21 and incident-reporting obligations under Article 23 on essential and important entities across critical sectors. Cyber-capable AI features here twice: as a supplier risk the deployer must assess, and as a tool the threat actor will increasingly reach for. The deployer’s NIS2 framework needs to acknowledge both readings, or it will fail on first audit.

The CRA layer

The Cyber Resilience Act sets essential cybersecurity requirements for products with digital elements, requires conformity assessment and imposes vulnerability-handling obligations on manufacturers. A cyber-capable AI model embedded in a product becomes a CRA question. So does one integrated into a product the deployer ships, the moment it leaves a research sandbox.

Where the three regimes overlap

The overlap is not theoretical. Incident-reporting timelines under NIS2 sit alongside post-market monitoring under the AI Act and vulnerability-disclosure duties under the CRA. Security testing expectations show up as red-teaming under the AI Act, risk-management measures under NIS2 and conformity-assessment evidence under the CRA. Logging and traceability run through all three. The deployer who tries to run three separate compliance projects, one per regime, will pay for the same control three times and still leave gaps.

The deployer’s single control map

The answer is a single control map. One table, with one column for the control and three columns for the regimes that trigger it. Three example controls make the structure obvious.

Take the red-team report. Under the AI Act, it is part of the provider’s systemic-risk evaluation and the deployer’s evaluation-report review.  NIS2, it is evidence of risk-management under Article 21. Under the CRA, it feeds the conformity assessment. One artefact, three obligations satisfied.

Consider the incident notification. NIS2 requires an early warning within twenty-four hours and a full notification within seventy-two. The AI Act imposes serious-incident reporting under Article 73. The CRA requires manufacturers to notify exploited vulnerabilities. The deployer’s playbook needs to fire all three in the right order, not pick one.

Or the vendor security questionnaire. The same questionnaire surfaces supplier risk under NIS2, vendor-governance evidence under the AI Act and product-security assurance under the CRA. 22Academy has documented the recurring traps that hit deployers who skip this. One questionnaire, sharpened for cyber-capable AI compliance, replaces three.

Cyber-capable AI compliance in the next 30 days

Three actions are within reach for any deployer this month. First, inventory which AI systems in use today plausibly fall in the cyber-capable category. Do this even if the provider has not labelled them that way. Second, check that vendor questionnaires ask about model capabilities relevant to cyber-offensive use, not just data-handling. Third, confirm that the incident-reporting playbook references all three regimes and the legal counsel routing for each.

The political backdrop will move. The Reuters wire on US safety-review proposals shows the same category being addressed from a different jurisdiction with different instruments. EU deployers should expect more regulatory layering, not less. The Parliament’s own briefing treats this as an open file; so should you.

One map, three regimes

The most useful thing about a single control map is what it teaches over time. The deployer who reads NIS2, the AI Act and the CRA on a single page can tell which actor any new obligation attaches to. Provider, deployer, manufacturer and importer each carry different duties, and the map keeps them visible. That is the skill the next eighteen months will demand. It is the part of operational AI governance that gets harder, not easier, with delay.

Start the control map this week. By the time the next regime lands, you will already know which column it belongs to.