Article 15 requires high-risk AI systems to reach appropriate accuracy, robustness and cybersecurity and keep performing across their lifecycle. It names AI specific attacks: data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws. Security teams need controls for these on top of ordinary application security.
What Article 15 requires
The article covers several areas:
- Performance: appropriate accuracy, robustness and cybersecurity, consistent over the lifecycle.
- Disclosure: accuracy levels and metrics stated in the instructions for use.
- Resilience: tolerance of errors, faults and inconsistencies, with redundancy or fail-safe plans where useful.
- Feedback loops: systems that learn after deployment must reduce the risk of biased outputs feeding future inputs.
- Cybersecurity: resistance to unauthorised third parties trying to alter use, outputs or performance by exploiting vulnerabilities.
Technical solutions should, where appropriate, prevent, detect, respond to, resolve and control attacks. The named threats map to familiar concerns.
The named attacks in plain terms
- Data poisoning: tampering with training data so the model learns something wrong.
- Model poisoning: tampering with pre-trained components reused in training.
- Adversarial examples or model evasion: inputs crafted to make the model err.
- Confidentiality attacks: attempts to extract data or model information.
- Model flaws: weaknesses in the model itself.
Mapping to controls
Data poisoning: track data provenance, restrict who can write to training sets, validate and sample new data, keep snapshots so you can roll back.
Model poisoning: treat downloaded models and fine tuning bases as supply chain inputs. Record source and hash, prefer formats that cannot run code on load, scan before use and review licences.
Evasion: test with perturbed and adversarial inputs, set input validation, monitor for drift and spikes of odd requests.
Confidentiality: limit output detail where practical, rate limit queries, control who can reach the model and its weights, and keep sensitive data out of training unless needed.
Feedback loops: review retraining data for output contamination and compare behaviour across releases.
Ordinary security still applies
Most real incidents on AI products still come from ordinary weaknesses: exposed keys, vulnerable dependencies, loose permissions. The ML pipeline, notebooks and serving stack are software with a bill of materials. Include them in your inventory, patching and secrets hygiene.
Evidence for auditors
Keep threat models naming the Article 15 attacks, test results, the model and dataset inventory, access control reviews and incident records. Safeguard can scan dependencies and generate SBOMs for the code around a model, and its free scan is at gold.safeguard.sh/scan. It does not test model robustness itself.
The article applies from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, per the page we read.
Test the controls you claim. A table of attack types with no evidence is a wish list. Run at least a basic poisoning drill on a staging dataset and an evasion test against your classifier, and record the results and fixes.
Quick check
Is model poisoning the same as data poisoning?
No. Data poisoning manipulates training data. Model poisoning manipulates pre-trained components used in training.
Does Article 15 replace normal application security?
No. It adds AI specific threats to the expectation of general cybersecurity.
Sources
- AI Act Article 15, accuracy, robustness and cybersecurity (an unofficial reader; confirm wording against the Official Journal)
Last reviewed: 19 October 2026.
