Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›EU AI Act (High-Risk Security)
EU · Regulation 2024/1689

EU AI Act high-risk security compliance

how to meet Article 15 accuracy, robustness and cybersecurity for high-risk AI systems

The EU AI Act (Regulation (EU) 2024/1689) sets binding cybersecurity duties for high-risk AI systems. Article 15 requires that these systems achieve appropriate accuracy, robustness and cybersecurity across their lifecycle, and Article 15(5) demands resilience against attempts to alter their use, outputs or performance, including AI-specific attacks such as data poisoning, model poisoning, adversarial evasion and confidentiality attacks.

Most high-risk obligations under Articles 8 to 15 were delayed by the Digital Omnibus and now apply from 2 December 2027 for standalone Annex III systems (2 August 2028 for AI embedded in regulated products). That window is the time to build the secure development, AIBOM transparency, logging and runtime evidence the Act expects.

Talk to our advisory team Read Article 15
At a glance
Art. 15Accuracy, robustness and cybersecurity duty
2 Dec 2027High-risk Annex III obligations apply (Digital Omnibus delay)
€35M / 7%Max fine for prohibited-practice breaches, global turnover
1 Aug 2024AI Act entered into force
Regulation (EU) 2024/1689 (Artificial Intelligence Act)
Why this matters

A binding cybersecurity standard for the AI systems regulators consider high-risk

The AI Act is the first horizontal law to put AI-specific security on a legal footing. For high-risk systems, Article 15 turns robustness and cybersecurity from a best practice into a conformity-assessment obligation: the system must perform consistently across its lifecycle and resist attempts by unauthorised parties to alter its behaviour. (Art 15)

Article 15(5) is explicit about the threat model. Technical solutions must address AI-specific vulnerabilities, naming data poisoning, model poisoning, model evasion (adversarial examples), confidentiality attacks and model flaws. These sit alongside the conventional software-supply-chain and application-security risks every system carries, which is where most concrete, testable evidence is produced. (Art 15(5))

The Digital Omnibus pushed the bulk of the high-risk regime to 2 December 2027 (and 2 August 2028 for AI inside Annex I regulated products). Treat that as runway, not relief: the accuracy metrics, adversarial testing, logging (Art 12), risk management (Art 9) and quality management system (Art 17) the Act expects take real time to stand up and document.

How O3 helps

Find it before attackers do. Catch it if they try. Fix it fast.

Across these requirements, O3 runs one continuous loop on your own software so issues surface, get caught, and get fixed before they become an incident.

1 · Find it first

Test like an AI-assisted attacker

An agentic pentest probes your app across 50+ vulnerability classes the way a real attacker chains them, so exploitable flaws surface in your build before someone outside finds them.

2 · Catch it live

Detect and block exploitation at runtime

A kernel-level eBPF agent watches process trees and syscalls, recognises an attack sequence as it unfolds, and restricts the offending process on the spot rather than taking down the host.

3 · Fix it fast

Auto-patch what is reachable

Reachability ranks what genuinely matters, then autofix opens a pull request with the change, so remediation starts inside tight fix windows instead of sitting in a queue.

Risk-based prioritisation

From alert flood to a short list

KEV + EPSS + reachability turn a raw scan into the few findings that actually need action now.

Raw findings in dependency tree~12,400
Vulnerable & version-matched~4,700
Reachable in your code~1,360
KEV / high-EPSS · act now~370

Illustrative funnel. Reachability removes the bulk of unexploitable noise before triage.

Article 15(1)

How to define and declare accuracy levels for a high-risk AI system

Article 15(1) requires high-risk systems to achieve an appropriate level of accuracy that is consistent throughout the lifecycle, and 15(3) requires the relevant accuracy metrics to be declared in the instructions for use. Vague claims will not survive conformity assessment.

AI Act Art. 15(1)AI Act Art. 15(3)
Choose accuracy metrics that match the intended purpose (precision, recall, F1, error rates for the relevant subpopulations) and document why they are appropriate.
Establish measurement conditions and report results against a representative test set, recording known limitations and degradation cases.
Declare the metrics and their measurement conditions in the instructions for use, as required by Article 15(3).
Re-evaluate accuracy on a defined cadence and after material model or data changes so the declared figures stay truthful across the lifecycle.
Article 15(4)

How to make a high-risk AI system robust and fault-tolerant

Article 15(4) requires high-risk systems to be as resilient as possible to errors, faults and inconsistencies that may occur within the system or its environment, including from interaction with people or other systems. Feedback loops that compound errors must be addressed.

AI Act Art. 15(4)
Identify failure modes from edge cases, malformed inputs, distribution shift and degraded upstream services, and define expected behaviour for each.
Build technical redundancy, fallback and fail-safe plans so a fault does not silently produce unsafe outputs.
For systems that keep learning after deployment, design controls so feedback loops cannot be poisoned or compounded into biased outputs.
Test robustness against the documented failure modes and keep the evidence as part of the technical documentation.
Article 15(5)

How to defend against data poisoning, model poisoning and evasion

Article 15(5) is the core cybersecurity duty: the system must be resilient against unauthorised third parties altering its use, outputs or performance by exploiting vulnerabilities, and technical solutions must address AI-specific attacks. The Act names data poisoning, model poisoning, model evasion (adversarial examples) and confidentiality attacks.

AI Act Art. 15(5)
Map the AI-specific threats in 15(5) to your pipeline: where training data enters, where models are stored and loaded, and where inference is exposed.
Protect the training-data and model supply chain with provenance, integrity verification and access control so poisoning has no easy path in.
Run adversarial and evasion testing against the deployed model, and validate inputs and outputs to limit confidentiality and manipulation attacks.
Document the technical solutions and residual risk against each named threat so a conformity assessor can trace the mitigation.
Where O3 helps

O3 covers the software-security side of this threat model rather than ML robustness itself: malicious-dependency detection and SLSA/cosign provenance reads help protect the model and data supply chain from tampering, and agentic DAST/pentest exercises the application surface around the model. The model-level robustness against adversarial examples remains an ML engineering responsibility.

Annex IV · AIBOM

How to inventory models, datasets and components for a high-risk AI system

Annex IV technical documentation requires a clear description of the system's components, data and design choices. An AI bill of materials (AIBOM) is the practical way to keep an auditable inventory of models, datasets, libraries and their provenance, which also underpins the 15(5) supply-chain controls.

AI Act Annex IVAI Act Art. 15(5)
Build a machine-readable inventory of every model, dataset, framework and third-party dependency the system relies on, with versions and sources.
Record provenance and integrity for each component so you can prove what went into the system and detect substitution.
Use a standard format such as CycloneDX so the inventory is portable across tools and reusable for CRA, NIS2 and procurement evidence.
Keep the inventory current as models and dependencies change, and link it to the Annex IV technical documentation.
Where O3 helps

O3 produces an AIBOM in CycloneDX that inventories AI models and datasets, alongside SBOM/HBOM, giving a single machine-readable record of components and provenance for the Annex IV documentation and the 15(5) supply-chain controls.

Articles 9 & 17

How to run AI risk management and a quality management system

Article 9 requires a continuous risk management system covering the system's lifecycle, and Article 17 requires a documented quality management system. Article 15 robustness and cybersecurity must be planned, tested and maintained inside these processes rather than bolted on.

AI Act Art. 9AI Act Art. 17
Stand up an iterative risk management process (Art 9) that identifies, estimates and mitigates risks across the lifecycle, including the 15(5) attack vectors.
Document policies, procedures and responsibilities in a quality management system (Art 17) covering data governance, testing and post-market monitoring.
Define acceptance criteria and testing procedures for accuracy, robustness and cybersecurity, and record results.
Review and update the risk and quality records after incidents, model changes and new threat intelligence.
Article 12 · logging

How to log and monitor a high-risk AI system in operation

Article 12 requires high-risk systems to automatically record events (logs) over their lifetime to enable traceability and post-market monitoring. Runtime visibility also gives you the evidence needed to detect the manipulation and exfiltration attacks Article 15(5) anticipates.

AI Act Art. 12AI Act Art. 15(5)
Define which events to log for traceability: inputs, decisions, model versions, errors and security-relevant events, in line with Article 12.
Protect log integrity and retention so records remain trustworthy for incident analysis and supervisory requests.
Monitor the runtime environment for anomalous behaviour, unexpected egress and exploitation attempts against the system's software stack.
Feed monitoring findings back into risk management and accuracy re-evaluation.
Where O3 helps

O3's eBPF runtime agent and L7 deep packet inspection add detection at the infrastructure layer: process-tree and syscall monitoring, attack-chain detection, and egress baselining to flag exfiltration or data-tunnelling around the AI system. This complements, but does not replace, the application-level logging Article 12 requires.

Software stack

How to secure the software stack around a high-risk AI model

A high-risk AI system is more than its model. The serving code, APIs, data pipelines and dependencies are conventional software with conventional vulnerabilities, and exploiting them is one way to alter the system's outputs under Article 15(5). Standard secure development closes that path.

AI Act Art. 15(5)AI Act Art. 9
Run static analysis and dependency scanning across the serving and pipeline code to find injection, secret leakage and known-vulnerable components.
Prioritise findings by real exploitability so the team fixes what actually reaches the AI system first.
Remediate quickly with tracked fixes, and keep dependencies patched to avoid known exploitable vulnerabilities.
Pentest the exposed inference and management interfaces the way an attacker would.
Where O3 helps

This is core O3 territory: SAST with source-to-sink taint analysis, SCA against OSV, function-level reachability to rank exploitable vulnerabilities, secret scanning, EPSS+KEV prioritisation, autofix/auto-PR, and agentic DAST/pentest across 50+ vulnerability classes secure the software surrounding the model.

The whole framework

Every high-risk security obligation mapped to a concrete, vendor-neutral way to meet it

All 22 requirement areas, each with the reference and a vendor-neutral note on how teams meet it.

11Art. 15
Accuracy, robustness and cybersecurity
6Arts. 9-14
Risk, data, documentation, logging, oversight
5Arts. 17, 43, 72-73 & Annex IV
QMS, conformity and post-market
Requirement area
Accuracy levels appropriate to purposeArt. 15(1)Define and validate fit-for-purpose accuracy metrics
Consistent performance across lifecycleArt. 15(1)Re-test accuracy after data and model changes
Benchmarks and measurement methodsArt. 15(2)Use recognised benchmarks and document method
Declare accuracy metrics in instructionsArt. 15(3)Publish metrics and conditions to users
Robustness and fault toleranceArt. 15(4)Build redundancy and fail-safe behaviour
Control post-deployment feedback loopsArt. 15(4)Prevent compounding biased or poisoned outputs
Resilience to unauthorised alterationArt. 15(5)Harden access, integrity and exposed surfaces
Defend against data poisoningArt. 15(5)Protect and verify training-data provenance
Defend against model poisoningArt. 15(5)Sign and integrity-check model artifacts
Defend against evasion / adversarial inputsArt. 15(5)Run adversarial testing and input validation
Defend against confidentiality attacksArt. 15(5)Limit model and data exposure at inference
Continuous risk management systemArt. 9Iterate risk identification across lifecycle
Data and data governanceArt. 10Validate dataset quality and representativeness
Technical documentationArt. 11, Annex IVDocument design, data and components fully
Automatic event loggingArt. 12Record events for traceability and monitoring
Transparency and instructions for useArt. 13Give clear capability and limitation guidance
Human oversight measuresArt. 14Enable effective human intervention controls
Quality management systemArt. 17Document policies, testing and responsibilities
Component and dependency inventory (AIBOM)Annex IVMaintain machine-readable model and data inventory
Conformity assessment before marketArt. 43Demonstrate Article 15 evidence to assessor
Post-market monitoringArt. 72Monitor performance and security in operation
Serious incident reportingArt. 73Report serious incidents to authorities

Build the software-security evidence Article 15 expects

O3 maps to the software-security side of EU AI Act high-risk obligations: AIBOM for model and dataset transparency, SAST, SCA and function-level reachability to secure the stack around the model, malicious-dependency detection and provenance reads to protect the model supply chain, agentic DAST/pentest, and eBPF runtime and egress monitoring for operational evidence. Model-level ML robustness stays with your AI engineering team.

Read Article 15
FAQ

Common
questions.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • Article 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity, and to perform consistently across their lifecycle. It also requires declaring accuracy metrics in the instructions for use, building fault tolerance, and making the system resilient against unauthorised parties altering its use, outputs or performance.
  • Article 15(5) requires technical solutions that address AI-specific vulnerabilities. It explicitly names data poisoning, model poisoning, model evasion (adversarial examples), confidentiality attacks and model flaws. The system must resist attempts by unauthorised third parties to exploit these to alter its behaviour.
  • The AI Act entered into force on 1 August 2024. Following the Digital Omnibus, most high-risk obligations under Articles 8 to 15 apply from 2 December 2027 for standalone Annex III systems, and from 2 August 2028 for AI embedded in Annex I regulated products. Confirm against the final adopted text, as the delay was provisionally agreed in 2026.
  • The Act does not use the term AIBOM, but Annex IV technical documentation requires a clear description of the system's components, data and design choices. An AI bill of materials in a standard format such as CycloneDX is a practical way to maintain that auditable inventory of models, datasets and dependencies, and it supports the Article 15(5) supply-chain controls.
  • Providers and deployers of high-risk AI systems placed on or used in the EU market. High-risk systems are defined in Annex III and through AI embedded in products covered by Annex I harmonisation legislation. Compliance is demonstrated through conformity assessment under Article 43.
  • Article 15 adds AI-specific concerns: accuracy declarations, robustness to errors and feedback loops, and resilience to data and model poisoning and adversarial evasion. But a high-risk system is still built on conventional code, APIs and dependencies, so standard secure development, vulnerability management and runtime monitoring remain essential to closing the exploitation paths Article 15(5) anticipates.
  • Fines scale with the breach. Prohibited-practice violations can reach up to €35 million or 7% of global annual turnover. Breaches of other obligations, including those for high-risk systems, carry lower but still significant caps, with amounts adjusted for SMEs. National authorities and the AI Office supervise enforcement.
  • On the software-security side. Tools can inventory models and dependencies (AIBOM), protect the model and data supply chain with provenance and malicious-dependency detection, secure the serving code with SAST, SCA and reachability, pentest the exposed interfaces, and monitor runtime egress. Model-level ML robustness against adversarial examples remains an AI engineering responsibility.

See O3 Security in Action

See why security and engineering leaders trust O3
to secure their entire software supply chain.