What the EU AI Act Actually Requires for Cybersecurity (And Where Enterprises Are Exposed)

The EU AI Act contains specific cybersecurity requirements. Article 15 names the threats. Article 73 sets reporting deadlines. Article 9 mandates continuous risk management.

But most coverage of the Act buries the cybersecurity provisions inside a general compliance overview. That framing misses what makes these requirements hard for enterprises: most organizations consume AI through models and vendor products they don’t control, which creates a supply chain gap between what the Act demands and what you can actually enforce.

What Cybersecurity Threats Does the EU AI Act Require You to Defend Against?

Article 15 of the AI Act requires high-risk AI systems to “be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities.” It names four specific threat categories:

• Data poisoning
• Model poisoning
• Adversarial examples
• Confidentiality attacks or model flaws

The Act doesn’t just say “defend against these.” Article 15 requires measures to “prevent, detect, respond to, resolve and control for” these attacks. That language maps to a full response cycle and therefore prevention alone isn’t enough. You need detection capability, response processes, and ongoing controls. Article 9 reinforces this by requiring a “continuous iterative process planned and run throughout the entire lifecycle,” with “regular systematic review and updating.”

There are two important scoping points. First, Article 15(5) says technical solutions shall include these measures “where appropriate.” That qualifier means you defend against the threats relevant to your specific system, not all four categories equally for every deployment. A biometric identification system and an internal chatbot have different threat profiles.

Second, not every system in the Annex III high-risk categories is automatically high-risk. Article 6(3) provides a derogation, but it has a two-part test. The system must not pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing the outcome of decision-making.

And it must meet one of four conditions: it performs a narrow procedural task, improves the result of a previously completed human activity, detects patterns without replacing human assessment, or performs a preparatory task. In practice, treat this as a two-part test where both parts must hold. There is one hard stop: the derogation never applies where the system performs profiling of natural persons. An Annex III system that profiles people is always high-risk. That carve-out matters for the obvious examples. An AI tool that ranks or scores job applicants is likely profiling, so it would not qualify even with a human reviewer in the loop. A tool that performs a purely preparatory task, such as extracting fields from submitted documents before a human assessment, might.

If this derogation applies, Article 6(4) requires the provider to document the assessment before the system goes to market. As a deployer, you should verify that your vendor has this documentation on file and can produce it on request from authorities.

Who Is Responsible for Cybersecurity When You Didn’t Build the Model?

Most enterprises don’t build AI models. They call APIs from OpenAI, Anthropic, or Google. They deploy Microsoft Copilot. They license SaaS products with AI embedded inside. The Act holds these organizations responsible for their AI deployments, but the models sit outside their perimeter.

The Act splits the world into providers (those who develop or place AI systems on the market) and deployers (those who use them). Most enterprises are deployers. Article 26 defines deployer obligations that carry real cybersecurity weight: use systems per provider instructions, assign competent human oversight, actively monitor operation, ensure input data is relevant and sufficiently representative to the extent you control it, retain system logs for at least six months, and suspend use if the system presents a risk.

But these deployer obligations assume the underlying model is sound. Article 15’s core cybersecurity requirements (resilience against data poisoning, model poisoning, adversarial attacks, confidentiality attacks) primarily fall on the provider. As a deployer, you own your side: input data, monitoring, oversight, usage compliance. You don’t own the security of the base model’s training pipeline or its weights.

The problem is that you’re still exposed if the model fails. If a poisoned model produces harmful outputs in your deployment, the regulatory consequences hit you too. Your monitoring should have caught it. Your oversight should have flagged it. Your incident reporting obligations still apply.

What Does Your AI Vendor Owe You Under the Act?

Chapter V of the Act (Articles 51-56) creates a separate regulatory framework for General-Purpose AI models: models trained on broad data that serve a wide range of tasks. GPT-4, Claude, Gemini, Llama, and Mistral all fall here.

All GPAI model providers must, under Article 53: maintain technical documentation covering training, testing, and evaluation; make capability and limitation information available to downstream providers; put in place a copyright compliance policy; and publish a training data summary.

Article 53(2) carves out a partial exception: providers of models released under a free and open-source license, with weights and architecture publicly available, are exempt from the first two duties. The copyright policy and the training data summary still apply to everyone, and the exception falls away entirely if the model is classified as systemic risk.

The second point matters for the supply chain. Article 53(1)(b) requires GPAI providers to share this information with providers of AI systems who integrate the model into their own systems. If your organization builds products or systems on top of a GPAI model, you’re entitled to this documentation. If you’re a pure deployer (just using the system as-is), the obligation doesn’t extend to you directly, though you can still make it a contractual requirement in your vendor agreements.

GPAI models are classified as systemic risk when they have high-impact capabilities. Training compute above the threshold in Article 51(2) (currently 10^25 FLOPs) creates a presumption of such capabilities, which the provider can try to rebut, and frontier models from major providers generally qualify. The Commission can also designate models based on capabilities or impact. Once classified, these providers carry heavier obligations under Article 55.

You should also ask vendors about their training data governance. For GPAI models, the relevant hook is Article 53 with Annexes XI and XII, which require documentation of how training data was acquired, selected, and curated. Article 10 separately requires high-risk AI systems to follow documented data governance practices, including data provenance, bias examination, and gap analysis. If you’re trying to assess whether a model has been subjected to data poisoning, you need visibility into how the training data was governed.

What to demand from vendors, grounded in the Act:

• Risk classification: is the model designated as systemic risk?
• Article 53 technical documentation: what portions relevant to your deployment can you access?
• Adversarial testing results and protocols used (systemic risk models).
• Cybersecurity protections against model theft, unauthorized access, and safety measure circumvention.
• Training data governance practices and provenance documentation.
• Incident notification commitments for downstream deployers.

One shortcut worth knowing. Article 42(2) provides a conformity presumption: high-risk AI systems certified under a cybersecurity scheme pursuant to the EU Cybersecurity Act (Regulation 2019/881) are presumed to comply with Article 15’s cybersecurity requirements, provided the scheme’s references have been published in the Official Journal of the European Union and the certificate covers those requirements. Not every certification under 2019/881 will meet that condition, so check for the Official Journal publication before relying on this shortcut. If you’re choosing between AI products and one carries an EU cybersecurity certification, it reduces your compliance burden.

When Does Using an AI Model Make You the Provider?

Article 25 defines three situations where a deployer takes on full provider obligations, including Article 15 cybersecurity requirements and conformity assessment:

Rebranding: You put your name or trademark on a high-risk AI system already on the market. Common in white-label scenarios: you license a vendor’s AI and sell it under your brand.

Substantial modification: You modify a high-risk AI system in a way that it remains high-risk. Fine-tuning a model on new data, changing its architecture, or significantly altering its behavior can qualify. There’s no bright line in the Act for what counts as “substantial,” but if the modification affects the system’s performance or risk profile, treat it as potentially triggering.

Repurposing into high-risk: You take an AI system that wasn’t classified as high-risk (including a GPAI model) and change its intended purpose so it becomes high-risk. This is the trigger that catches the most enterprises off guard. Your company deploys a general-purpose chatbot for internal knowledge management (minimal risk). A business unit starts using it to screen job applicants by ranking resumes (Annex III high-risk). By changing the intended purpose, your organization may have made itself the provider.

The consequences of this action: full provider obligations under Article 16, including quality management systems, technical documentation, conformity assessment, and the complete Article 15 cybersecurity requirements.

Article 25(2) says the original provider must cooperate and provide technical access to help you meet your obligations. But that duty falls away where the original provider has clearly specified that its system is not to be changed into a high-risk system, and many model providers’ terms of use do exactly this. Don’t assume your vendor agreement handles this. Check the terms before you modify or repurpose anything.

You should audit how AI tools are actually being used across your organization, not just how they were intended to be used. If any use has drifted into an Annex III category, assess whether Article 25 has been triggered.

What Counts as a Serious AI Incident and How Fast Do You Have to Report It?

Article 3(49) defines a serious incident as one that directly or indirectly leads to: the death of a person or serious harm to health; a serious and irreversible disruption of critical infrastructure management; an infringement of EU law obligations protecting fundamental rights; or serious harm to property or the environment.

This is a high bar. A model producing inaccurate outputs isn’t automatically a serious incident. A model whose inaccurate outputs lead to someone being wrongly denied healthcare, causing serious harm to their fundamental rights, could be.

The reporting duty in Article 73 sits primarily on providers. As a deployer, your route runs through Article 26(5). When you identify a serious incident, you must immediately inform the provider first, then the importer or distributor and the market surveillance authority. If you cannot reach the provider, Article 73 applies to you directly.

Reporting timelines under Article 73:

• Standard serious incidents: report immediately after establishing a causal link (or reasonable likelihood of one) between the AI system and the incident. The hard outer limit is 15 days from when the provider or deployer becomes aware of the incident, regardless of whether causality has been established by then.
• Widespread infringements or critical infrastructure disruptions: immediately, no later than 2 days.
• Deaths: immediately after establishing or suspecting a causal link, no later than 10 days.

Initial incomplete reports are allowed, followed by a complete report.

However, there is a detection problem: Traditional security incidents have observable signatures: unauthorized access logs, exfiltration alerts, service disruptions. AI-specific incidents often don’t. A poisoned model update might not trigger any alerts. The model still runs, still produces outputs, but its behavior has shifted in ways that are hard to detect without targeted evaluation. Adversarial inputs might look like normal queries. Confidentiality attacks happen through the system’s intended interface.

Your monitoring obligations under Article 26(5) require more than uptime checks and error logs. You need mechanisms to detect behavioral drift, unexpected output patterns, and anomalous query patterns. Article 26(5) also imposes a suspension obligation: if you have reason to believe your AI system presents a risk, you must suspend use and notify the provider and market surveillance authority. “Reason to believe” is a lower bar than “confirmed incident.”

What Should Enterprise Security Teams Do Now?

Under the May 2026 Digital Omnibus agreement, the main high-risk system deadlines are expected to shift to December 2, 2027 (Annex III systems) and August 2, 2028 (AI in regulated products). This is a provisional political agreement, and if it is not formally adopted before August 2, 2026, the original AI Act deadlines apply from that date as written. Plan against the new dates, but watch the adoption process closely this summer.

But the AI literacy mandate (Article 4) and GPAI model obligations have been enforceable since February and August 2025, respectively.

Build an AI inventory: Know what AI systems you run, what GPAI models they’re built on, who the providers are, and how each system is actually being used. Include shadow AI: SaaS products with embedded AI, employees using personal AI accounts, tools adopted outside procurement.

Classify each system using Article 6: Apply the Article 6(3) derogation where it fits and document your reasoning. Check for use-case drift into high-risk categories.

Map vendors against Chapter V obligations: For each GPAI model, identify systemic risk classification and request Article 53 documentation. Build these requests into procurement.

Audit for Article 25 provider triggers: Review actual AI usage for rebranding, substantial modification, or repurposing into high-risk contexts. Pay special attention to teams fine-tuning models or building products on GPAI APIs.

Develop AI-specific threat models: Use Article 15’s four named threat categories as a starting framework. Assess which threats apply to each deployment and where your detection and response gaps are.

Scope incident response for AI: Define what a serious incident looks like for your deployments, grounded in Article 3(49). Map Article 73’s tiered timelines into your playbook. Build detection for behavioral drift and anomalous outputs.

Address AI literacy now: This is already enforceable. Training should cover AI-specific threats (prompt injection, data leakage, adversarial manipulation), not just generic awareness.

The organizations that build this foundation now will meet the high-risk deadlines as a procedural step. Those that wait will be trying to inventory, classify, and restructure vendor relationships under time pressure, which is how compliance programs produce gaps.