Skip to content
All posts

The EU AI Act's: Article 15

Most organisations think about AI risk in terms of bias, explainability, or data governance. Cybersecurity is treated as a separate concern, something the IT or security team handles independently of the AI compliance work.

That separation no longer holds under the EU AI Act.

Article 15 of the EU AI Act imposes explicit cybersecurity obligations on providers of high-risk AI systems. These are not general security best practices. They are legal requirements, tied to conformity, and they apply throughout their lifecycle.

If your organisation is building or deploying high-risk AI and has not yet considered Article 15, this is the gap that needs closing before 2 August 2026.

What Article 15 actually says

Article 15 requires that high-risk AI systems are designed and developed to achieve an appropriate level of accuracy, robustness, and cybersecurity and that those properties are maintained throughout the system's lifetime.

On cybersecurity specifically, the article sets out five categories of attack that providers must protect against:

  • Data poisoning (attacks targeting the training data set)
  • Model poisoning (attacks on pre-trained components)
  • Adversarial examples and model evasion (inputs crafted to cause incorrect outputs)
  • Confidentiality attacks (extracting sensitive information from the model)
  • Model flaws (vulnerabilities in the architecture or design)

These are not hypothetical attack vectors. They are documented, reproducible, and in some cases already being exploited in the wild.

The Act does not prescribe specific technical controls, but it does require that providers demonstrate through conformity assessment that their system is resilient against these threats.

Why is this different from standard cybersecurity

Most organisations have cybersecurity programmes. Most of those programmes are not designed to address AI-specific attack surfaces.

Traditional security controls , such as firewalls, access management, encryption, and patch management, are necessary but not sufficient for AI systems. The attack vectors listed in Article 15 operate at the model layer, not the infrastructure layer.

Data poisoning, for example, is not stopped by a firewall. It targets the integrity of the training pipeline. Adversarial examples are not malware; they are carefully constructed inputs that cause the model to make incorrect predictions, often without triggering any conventional security alert.

Addressing these threats requires a different methodology: one that tests the AI system itself, not just the environment it runs in.

The conformity assessment question

For high-risk AI systems, conformity assessment is the formal process through which providers demonstrate compliance before placing the system on the market.

Article 15 is part of that assessment. Providers will need to show that they have considered the cybersecurity attack vectors listed in the Act, that they have taken appropriate technical measures, and that those measures are documented in the technical file.

For many systems, this assessment is conducted internally. For others, particularly those in Annex I sectors (medical devices, critical infrastructure, biometrics), it involves a notified body.

In either case, unsupported assertions are not sufficient. Providers need technical evidence: testing records, threat models, and mitigation documentation. "We have a security programme" is not a conformity argument.

What good looks like in practice

Organisations that are taking Article 15 seriously are building cybersecurity into the AI development lifecycle from the start, not treating it as a pre-launch checklist item. In practice, that means:

  • Threat modelling at design stage — identifying which attack vectors are relevant to the system's architecture and use case
  • Adversarial testing before launch — structured testing against evasion, poisoning, and extraction techniques
  • Training data integrity controls — provenance tracking, access controls, and anomaly detection in the data pipeline
  • Monitoring in deployment — detecting distributional shift and potential adversarial activity in production
  • Incident response for AI systems — processes for detecting, investigating, and remediating AI-specific security events

This is not a one-time exercise. The lifecycle requirement in Article 15 means that cybersecurity must be maintained and reassessed as the system evolves.

Article 15 is one of the most technically demanding provisions in the EU AI Act. It requires providers to think about security at the model level, not just the infrastructure level and to produce evidence that they have done so.

Most organisations are not there yet. The attack vectors named in the Act are not widely tested for. The link between AI security and regulatory conformity has not been established in most compliance programmes. And the deadline is less than two months away.

Periculo offers AI security testing against the attack vectors specified in Article 15, supporting providers in building the technical evidence needed for EU AI Act conformity. As a CREST-accredited consultancy, our findings carry the independent credibility that notified bodies and regulators will expect. Talk to us about what your system needs.