EU AI Act Readiness: Article 15 Cybersecurity Requirements Explained

The full requirements for high-risk AI systems under the EU AI Act became enforceable on August 2, 2026. If your organization builds or deploys AI in a high-risk category, that deadline has already passed — this is not a future obligation to plan around, it is a present one to close gaps against.

Most of the attention on the AI Act has gone to bias, transparency, and human oversight. For security teams, the article that matters most is Article 15 — the one that treats cybersecurity as a legal conformity requirement, not a best practice.

What Counts as High-Risk

The AI Act sorts systems into risk tiers, and the obligations that took effect August 2 apply specifically to systems listed in Annex III: AI used in areas like employment and worker management, access to essential services including credit scoring, critical infrastructure, law enforcement, migration and border control, and the administration of justice. If your product makes or materially influences decisions in any of these categories, it is almost certainly in scope regardless of how the product is marketed.

Classification depends on what the system actually does, not on its name or how it is described in marketing material — the same core-functionality principle that governs classification under the Cyber Resilience Act.

Article 15: Accuracy, Robustness, and Cybersecurity

Article 15 requires that high-risk AI systems be designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently across all three throughout their lifecycle — not just at the point of initial certification.

The cybersecurity piece specifically requires resilience against attempts by unauthorized third parties to alter a system's use, outputs, or performance by exploiting vulnerabilities — explicitly including adversarial attacks, data poisoning, and model evasion. This is a materially different threat model from traditional application security. You are not just defending against someone breaking into a server; you are defending against someone manipulating the model's behavior through the inputs it was designed to accept.

The Act's own language — cybersecurity measures appropriate to the relevant circumstances and the risks — deliberately does not specify a fixed control set. Standardization work is underway to give that phrase concrete technical meaning: draft European standards are in progress, including one specifically addressing cybersecurity specifications for AI systems, though as of this writing they remain in draft and public-enquiry stages rather than finalized and citable.

What Is Actually In Scope: The Entire Action Layer

The detail most teams miss is scope. Article 15 does not stop at the model. If a high-risk AI system uses agents that call APIs — internal microservices, third-party platforms, or tool-calling protocols like MCP — that entire action layer falls under the cybersecurity and logging obligations, not just the model's direct output. In a multi-agent architecture, every agent performing a high-risk function in the chain is understood to be in scope, not only the one making the final decision.

Practically: if you are building an AI system that plans, calls tools, and takes actions rather than just returning text, your compliance boundary is the whole pipeline — authentication between agents, the permissions each tool call carries, and the logging that lets you reconstruct what happened after the fact.

The CRA Connection

If you have read our CRA guide, the overlap here should be obvious: cybersecurity work you have already done to satisfy the Cyber Resilience Act's essential requirements can support your AI Act Article 15 obligations, and vice versa. The Act includes a presumption-of-conformity mechanism for high-risk AI systems that already hold cybersecurity certification under the EU Cybersecurity Act framework — meaning certification work is not necessarily duplicated across regimes if it is structured correctly from the start.

This is also where a security team that understands both engineering and the legal text earns its keep: mapping a single technical control set against two separate regulatory checklists, instead of building parallel compliance programs that solve the same problem twice.

The Digital Omnibus Update

Worth knowing if you are reading anything published before mid-2026: a new simplification regulation — the Digital Omnibus on AI Regulation — entered into force on July 27, 2026, with several of its provisions, including one addressing how Article 15 cybersecurity interacts with CRA compliance, becoming applicable on the same August 2, 2026 date as the core high-risk obligations. This is recent enough that a meaningful share of AI Act compliance guidance circulating right now predates it. If you are working from documentation older than a few weeks, it is worth confirming it accounts for this change.

Penalties

Breaches of high-risk system obligations, including Article 15, carry fines of up to €15 million or 3% of global annual turnover. The higher maximum — €35 million or 7% — is reserved for the small set of outright prohibited practices under Article 5, not for high-risk system non-conformity, but 3% of global turnover is still a figure that gets attention at the board level.

Building an AI Act-Ready Security Program

• Map your systems against Annex III first. Classification drives everything else, and it is easy to under-scope an internal tool that is quietly making high-risk decisions.
• Extend threat modeling to cover the action layer, not just the model. If agents call tools, the authentication and permissioning between those calls needs the same scrutiny as the model itself.
• Build adversarial resilience into evaluation, not just functional testing. Standard QA does not test for data poisoning or adversarial inputs — that requires a deliberately adversarial testing practice, the same instinct that drives penetration testing in traditional product security.
• Check for CRA overlap before building parallel documentation. If your organization is already doing CRA compliance work, look for where that evidence can be reused rather than reproduced.
• Watch the standardization track. The draft European standards addressing Article 15's accuracy, robustness, and cybersecurity requirements are still being finalized — once cited, they will be the practical route to demonstrating conformity, similar to how harmonised standards function under CRA.

Frequently Asked Questions

Does Article 15 apply to AI systems I purchase rather than build?

Yes, indirectly. As a deployer rather than a provider, your obligations are lighter than the provider's under Article 26, but you still carry responsibility for using the system as intended and maintaining appropriate human oversight — and a provider's Article 15 failures become your operational risk regardless of who is legally on the hook.

Are small companies exempt from Article 15?

No. The Act does not provide a general SME exemption from Article 15's substantive requirements, though some procedural and documentation obligations elsewhere in the Act do scale with company size.

How does this affect agentic AI and MCP-based systems specifically?

If a high-risk classified system uses agents that call tools or APIs, that entire action layer is understood to fall within Article 15's cybersecurity scope — not just the underlying model. This is a newer interpretive question the standardization work is still catching up to, and it is worth revisiting as guidance develops.

What's the difference between Article 15 and general cybersecurity best practice?

Article 15 makes cybersecurity a conformity requirement tied to CE marking and market access, not a voluntary best practice. Non-conformity is not just a security risk — it is a market-access problem, enforced with penalties comparable to the CRA and GDPR.

If you are navigating both CRA and AI Act obligations for the same product line, get in touch and start with our CRA Scope Check if classification is still an open question.