Article 15 EU AI Act: accuracy, robustness and security

What EU AI Act Article 15 asks for in accuracy, robustness and cybersecurity

If you place a high-risk AI system on the EU market, Article 15 requires that it reach an appropriate level of accuracy, robustness and cybersecurity, and that it perform consistently throughout its lifecycle. The provision has three strands: declared accuracy, resilience to errors, faults, inconsistencies and feedback loops, and defenses against attacks that target the model or its data, such as data poisoning, model poisoning, adversarial examples, model evasion and confidentiality attacks. They are one requirement because a model that is accurate on a clean test set but can be steered by poisoned training data or manipulated inputs does not perform consistently in use. Article 15(3) also asks that accuracy levels and the metrics used to measure them be declared in the instructions for use, so the metrics you choose, the thresholds you test against and the datasets you test on all become part of the evidence an assessor will read.

Three things usually make this hard. First, metrics are often chosen late or never written down, so there is no declared baseline to test against. Second, retraining or fine-tuning can change behavior silently, and a system that keeps learning after deployment must be monitored for feedback loops from biased outputs, which means someone must own drift detection and a rule for when a retrained model needs fresh validation. Third, the evidence is split. Data scientists hold the metrics and test results, security teams hold the threat model and vulnerability records, and platform engineers hold the logs and pipelines. Before you start, decide who owns each element, which declared metrics go into the instructions for use, and which attack classes your threat model covers. Confirm with your legal team and any notified body how Article 42 presumptions apply to your system, since a certificate under the Cybersecurity Act may cover only part of Article 15.

Which systems, data and teams Article 15 reaches

Four scoping questions decide how much Article 15 work an organization carries: which annex the system falls under, whether it keeps learning after deployment, what model it is built on, and who owns each layer. Answer them first, because each one adds a distinct set of tests, controls and owners to the plan.

Annex III or Annex I classification

An Annex III system is a standalone high-risk use case, while an Annex I system is a product or safety component covered by sectoral product law. The classification sets the applicable date: the 2026 amendment moved the Chapter III Section 3 requirements to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems. Confirm which route applies before you size the accuracy and security testing, because Annex I providers may fold Article 15 evidence into an existing product file.

Continuous learning after deployment

A system that keeps learning in production must address feedback loops, where biased or degraded outputs feed back into later training data and amplify errors. This adds a monitoring pipeline that tracks accuracy drift against the declared metrics, a gate that decides when a model update is validated, and a rollback path. Systems that are fixed at release need regression testing on each change instead, so ask whether any learning happens after launch.

Third-party or self-hosted general-purpose model

A system built on a third-party general-purpose model inherits accuracy and vulnerability behavior that the deployer cannot fully inspect, so the team must test the integrated system against its intended purpose and document what the upstream provider supplies. A self-hosted model adds work on the serving stack, including model artifact integrity, access controls on weights and inference endpoints, and patching of the runtime. Ask the upstream provider which documentation and evaluation results they will share.

Cybersecurity Act and Cyber Resilience Act routes

Article 42(2) presumes compliance with the Article 15 cybersecurity requirements for systems certified under a scheme adopted under the Cybersecurity Act, Regulation (EU) 2019/881, to the extent the certificate covers them. Article 42(3), added in 2026, extends a similar presumption to high-risk systems that fall under the Cyber Resilience Act, Regulation (EU) 2024/2847, and meet the conditions of its Article 12(1). Check whether a certificate or CRA route covers your system's cybersecurity scope, since a partial match leaves gaps you must test yourself.

Model, infrastructure and endpoint owners

Article 15 controls cross three ownership layers that often sit in different teams: the data science team owns the model and its evaluation, the platform team owns the training and serving infrastructure, and the IT or security team owns the endpoints where the system runs and where operators work. Name one owner for each layer and one owner for the Article 15 evidence file. Unassigned layers usually surface as gaps in data poisoning defenses and patch coverage during an assessment.

Vulnerability and code scanning scope

Each layer the cybersecurity requirement reaches needs its own scanning scope: operating system and installed applications on endpoints and servers, and source repositories and infrastructure code in the build pipeline. Protected branches keep unreviewed changes out of the model and serving code, and static analysis in CI catches insecure code in the pipeline that produces the model. Inventory every host and repository that touches the system before you set these scopes, because a missed component is the most common blind spot.

How an assessor tests Article 15 accuracy and cybersecurity evidence

This table maps each Article 15 test area to the approach an assessor typically takes, the evidence they ask for, and the gaps they often find. Read it as a checklist of what to prepare before a review. The national market surveillance authority or notified body decides how deep each test goes, so confirm scope with them early.

Test area	Assessment approach	Evidence requested	Common findings
Declared accuracy and metrics	Checks that accuracy levels and metrics are stated in the instructions for use and match the intended purpose	Instructions for use, metric definitions, test reports tied to the declared values	Metrics declared without test data, or metrics that do not reflect the deployed population
Consistency over the lifecycle	Compares performance across releases, retraining cycles and deployment environments	Versioned evaluation records, regression test results, monitoring dashboards	No baseline kept, so drift after retraining cannot be shown
Resilience to errors and faults	Reviews how the system behaves on bad inputs, missing data and component failures	Fault injection or error-handling test records, fail-safe and fallback design documents	Fallback paths untested, or failures that silently return unreliable outputs
Feedback-loop handling	Examines whether systems that learn after deployment can amplify biased outputs, and what controls limit that	Design of learning updates, approval gates for retraining, bias monitoring logs	Continuous learning enabled without documented safeguards or review
Data and model poisoning defenses	Traces controls over training and fine-tuning data sources, pipeline access and model artifacts	Data provenance records, pipeline access logs, integrity checks on datasets and model files	Unrestricted write access to training data or unsigned model artifacts
Adversarial examples and evasion	Reviews robustness testing against manipulated inputs and checks whether results are repeated after changes	Adversarial test plans and results, documented residual risk and accepted limits	Robustness claimed without any adversarial testing on record
Confidentiality attacks	Assesses protection against extraction of training data, model parameters or sensitive outputs	Access controls on model endpoints, rate limits, logging, test results for extraction attempts	Model endpoints exposed without authentication or output logging
Vulnerability management	Checks how software components are inventoried, patched and tracked against known vulnerabilities, and how cybersecurity evidence maps to Article 42 routes	Software inventory, scan reports, patch records, secure change control, any Cybersecurity Act or Cyber Resilience Act certificates	Inventory incomplete for model-serving infrastructure, or scans run once and never repeated

Implementing Article 15 in a sequence that produces evidence

This sequence turns the Article 15 requirements for accuracy, robustness and cybersecurity into a set of tested, versioned and monitored controls, each leaving an artifact an assessor or market surveillance authority can inspect. The organization owns the outcome, while an implementation partner can prepare the systems and records that show it.

Define accuracy metrics and thresholds
The provider and its product, data science and risk owners agree which accuracy metrics fit the system's intended purpose, the populations it will affect and the errors that matter most to health, safety and fundamental rights. Each metric gets a numeric acceptance threshold and a written justification for why that threshold is appropriate. The output is a metrics report that names each metric, its threshold, the reasoning and the owner who approved it. The step is done when the same metrics appear in the instructions for use, as Article 15(3) requires, and in the technical documentation.
Build a held-out test harness
Engineering builds a repeatable test harness that measures each agreed metric on validation and test data kept separate from training data. The harness should record the model version, dataset version, random seeds and environment so any run can be reproduced later. Results are written to a test log that a reviewer can rerun. The step is complete when a new model version cannot be promoted without a passing run against the agreed thresholds, and the test log is linked to that release.
Test errors, faults and fail-safes
Testers inject errors, missing or malformed inputs, out-of-range values, dependency outages and inconsistent outputs, then observe how the system behaves. Where the design relies on redundancy, such as a backup model, a rules-based fallback or a fail-safe that hands control to a human or halts output, the team tests that the fallback engages and recovers. The output is a fault test report with each scenario, the expected behavior, the observed behavior and any defect raised. Teams should confirm with their assessor how much fault coverage they need for their risk profile.
Monitor drift and feedback loops after deployment
Operations sets up monitoring of production inputs and outputs against the baseline metrics from step one, watching for data drift, performance decline and outputs that could feed back into future training and reinforce bias. Alerts route to a named owner with a documented response path, and any retraining is handled as a new versioned release that repeats the earlier tests. The output is a monitoring record of metric trends, alert history and the decisions taken on each alert. The step is done when a sustained drop below threshold triggers a documented review.
Harden pipeline and runtime against tampering
Security engineers protect the code, data and model artifacts that can be altered to change behavior, which covers data poisoning, model poisoning, adversarial inputs and unauthorized changes. Controls include protected branches that restrict who can push or merge, scanning of code in continuous integration, integrity checks on training data and model files, access restrictions on the model registry and vulnerability tracking across the operating system and installed software. Open-source options such as GitLab protected branches, Semgrep in CI/CD, Wazuh vulnerability detection and Fleet can produce logs for these checks. The output is a hardening baseline, scan reports and a change log tied to each release. The team should confirm with its assessor whether the Article 42 presumptions apply through a Cybersecurity Act certificate or the Cyber Resilience Act route.

How the Article 42 presumptions change the cybersecurity evidence

Article 42 changes how a provider can show that the cybersecurity requirements of Article 15 are met, but it does not make them disappear. A presumption of conformity narrows the evidence you must produce, and it applies only to the part of the system that the certificate or compliance route actually covers. Article 42(2) presumes compliance with the Article 15 cybersecurity requirements for a high-risk system certified under a scheme adopted under the Cybersecurity Act, Regulation (EU) 2019/881, but only to the extent the certificate covers that system. The first task is therefore a scope comparison: list the components inside the certificate boundary (for example, the hosted inference service, the model registry and the admin console) and list everything outside it, such as the training pipeline, the data stores and the deployer-side integrations.

Article 42(3), added in 2026, applies a similar presumption to high-risk systems that fall under the Cyber Resilience Act, Regulation (EU) 2024/2847, and meet the conditions of its Article 12(1). The presumption only works if you can show that your system is within the CRA and meets those conditions, so the classification question comes first. Confirm the CRA conditions with your legal adviser, and do not assume that a product being a CRA product automatically places every part of an AI system inside the presumption. Keep a dated record of the classification decision and the reasoning behind it, because an assessor will ask for it.

Whichever route applies, the uncovered parts of the system still need Article 15 evidence produced in the usual way. For those components, vulnerability detection on endpoints, such as the software inventory matching that Wazuh performs against its vulnerability repository, and code review controls, such as the protected branches described in GitLab's documentation, remain the evidence that shows ongoing control. Before you rely on a presumption, ask the certification body and your legal adviser to confirm in writing which assets, interfaces and lifecycle stages the certificate or CRA route covers, and plan the remaining evidence against the gaps they identify.

Evidence that passes an Article 15 review and how to keep it current

An assessor testing Article 15 looks for evidence that each claim about accuracy, robustness and cybersecurity can be traced to a specific model release, test run and environment. The cards below cover six artifacts that connect those claims to the system as it runs, with the refresh step that keeps each one current between audits.

Declared metrics in instructions for use

Article 15(3) requires accuracy levels and the metrics used to measure them to be declared in the instructions for use. An assessor will ask which test dataset, population and operating conditions sit behind each published figure, and whether the figure matches the release actually deployed. Refresh the declaration whenever a model version changes, and record the test data version and conditions next to every number so the figure can be reproduced.

Versioned test reports per release

Each model release needs its own test report showing the metrics, thresholds and pass or fail outcome against predefined criteria. Assessors check that the report names the exact model artifact, code commit and dataset hash it covers, and that no release ships without one. Tie every report to a release identifier and store it in the same repository as the build, so a reviewer can move from a deployed version to its evidence in one step.

Robustness and adversarial test results

Article 15(5) expects measures against data poisoning, adversarial examples, model evasion and confidentiality attacks. Assessors will ask for test plans that name the attack types considered, the results against each, and the remediation applied when a test failed. Keep the test suite under version control, rerun it on each release, and record which attack classes were out of scope and why, so the gap is visible rather than implied.

Feedback-loop and drift monitoring records

Where a system keeps learning after deployment, Article 15(4) requires attention to feedback loops from biased outputs. Assessors look for logged drift metrics, alert thresholds, the dates alerts fired and the decisions taken in response, including retraining or rollback. Confirm with your monitoring stack how long these records are retained and whether they can be exported with the model version attached, since drift findings are only useful when they point to the release that produced them.

Vulnerability scan and patch records

Article 15 cybersecurity obligations cover the infrastructure that hosts the model as well as the model itself. Vulnerability detection tools such as Wazuh and Fleet produce inventories and findings for operating systems and installed applications on monitored endpoints. Assessors will ask for scan history, the time from finding to patch, and exceptions with approvals. Refresh the vulnerability database on a fixed schedule and keep an offline copy where the environment requires it.

Access and change control records

Assessors test whether only authorized people can alter model code, training data and deployment pipelines, and whether each change is reviewed before it reaches production. Evidence includes branch protection settings, approval records, access reviews and logs of forced pushes or bypassed checks. Export the protected branch configuration on a schedule, and confirm that a change to a model or dataset cannot reach a release without the approval recorded in the test report.

What meeting Article 15 costs in money and effort

This table compares the cost components of meeting Article 15 accuracy, robustness and cybersecurity obligations, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote request, since DeployOpen does not publish a price list and every figure depends on the agreed scope.

Cost component	One-time or recurring, and who is paid	What drives it up, and how to keep it down
Engineering time for metric design and test harnesses	Mostly one-time build, then recurring upkeep. Paid to the internal team or implementation partner for declared metrics and repeatable test suites.	Up with the number of models and metrics declared in instructions for use. Down by reusing one harness across systems and fixing metric definitions early.
Compute for repeated testing	Recurring. Paid through cloud or data center capacity the organization owns or rents.	Up with retraining frequency and regression test scope. Down by scheduling full runs on releases and smaller checks on each commit.
Tooling and licenses	Recurring where commercial. Open-source options such as Wazuh, Fleet, GitLab Community Edition and Semgrep Community Edition remove license spend, but hosting and administration still carry staff time.	Up with the number of endpoints and repositories in scope. Down by confirming each community edition covers the required features and languages before purchase.
Security testing of the model and its APIs	Periodic, often fixed-scope, paid to an external testing provider or internal red team. Covers data poisoning, adversarial examples and evasion checks described in Article 15(5).	Up with the number of endpoints, untrusted input channels and agent tool access. Down by defining a bounded test scope with written rules of engagement.
Ongoing monitoring and patch upkeep	Recurring. Paid to operations staff or a retainer provider for vulnerability correlation, feedback loop monitoring and patching.	Up with the number of hosts, software packages and model updates in production. Down by automating vulnerability detection and setting a clear retesting trigger.
External testing or review	Periodic, paid to an independent reviewer or assessor when the organization wants a second opinion before market placement.	Up with system risk, the number of conformity routes involved and reviewer availability. Down by preparing evidence packages in advance and scoping the review tightly.
Assessor work	Paid to the assessor or notified body where a third-party route applies. The organization owns its controls, and only the independent assessor issues the conformity result.	Up with the number of systems, documentation volume and re-assessment after substantial change. Down by keeping test evidence traceable to Article 15 clauses from the start.

Self-hosted open-source tools that produce Article 15 security evidence

The four tools below produce cybersecurity evidence for Article 15: vulnerability records for endpoints and software, change control on source code, and code scanning results. They support the security side of Article 15 only. They do not show declared accuracy, resilience to feedback loops or adversarial robustness of the model, which need their own test evidence. Confirm coverage in your own environment before relying on any tool's output.

Endpoint vulnerability detection with Wazuh

Wazuh (GPL-2.0-only) collects a software inventory from each agent and correlates it with its CTI vulnerability repository, or with a locally hosted offline copy, to flag vulnerabilities in the operating system and installed applications of monitored endpoints. For Article 15(5), this gives a dated record of known vulnerabilities on the hosts that run or support the AI system. Check that the offline copy is refreshed on a schedule you can document, and confirm that GPL-2.0-only obligations are reviewed by your legal team if you modify the software.

Vulnerable software detection with Fleet

Fleet (MIT) matches the software installed on enrolled hosts against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its output shows which hosts carry which vulnerable packages, which supports the resilience and patching evidence auditors ask for under Article 15. Confirm that the advisory sources cover every operating system in your AI infrastructure, because a source that does not cover a platform leaves that platform untested.

Protected branches in GitLab

GitLab Community Edition (MIT) protected branches restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. These settings give evidence of controlled change to model code, training pipelines and deployment configuration, which supports the cybersecurity requirement against tampering. Verify the settings on each release branch and export them as dated evidence, since a branch left unprotected is a gap that a configuration screenshot taken today will not reveal next quarter.

Code scanning with Semgrep

Semgrep Community Edition (LGPL-2.1-only) scans code in languages including Python, Go, Java, JavaScript, TypeScript, Rust and Terraform, using community or custom rules. Run inside CI/CD, it produces a repeatable scan record for each commit, which supports secure development evidence. Check the supported language list against your stack, and note that community rules do not cover every vulnerability class, so custom rules and a documented rule set are needed to show what was tested.

Who does what: your team, an implementation partner and the assessor

Your organization remains the provider (or deployer) and owns the Article 15 position. Accuracy, robustness and cybersecurity are not properties a vendor can declare on your behalf. Your people decide what performance is acceptable for the intended purpose, which residual risks are tolerable, and whether the system is ready to release. Those decisions must be traceable to named individuals.

Declared metrics: Choose the accuracy levels and metrics that go into the instructions for use under Article 15(3), and document why they fit the intended purpose.
Risk decisions: Record which robustness and cybersecurity risks you accept, which you mitigate, and who approved each choice.
Model and data owner sign-off: Obtain written approval from the people accountable for the model and training, validation and test data before each release.
Release records: Keep the version, test results, approvals and known limitations for every release that changes model behavior.
Feedback loop oversight: Assign an owner to review drift and biased outputs for systems that keep learning after deployment.

Confirm that each of these owners is named in your governance policy before any partner begins work.

Questions about Article 15 cost, effort and what the work needs from you

Can our team meet Article 15 without an outside partner?

Yes, in principle. Article 15 is a provider obligation, and the organization that places the system on the market owns the controls and the evidence. A partner is useful when your team lacks time, the adversarial testing skills, or an independent view of its own work. Before deciding, check whether your engineers can declare accuracy metrics in the instructions for use, run and document robustness tests against data poisoning and adversarial examples, and keep security evidence current across the lifecycle. The text of the Article is short, so the gap is usually in test design and record keeping, not in understanding the words. Confirm the requirements with your legal and compliance advisers, since the Act's obligations depend on how your system is classified.

What does Article 15 need from our data science and security teams?

Data science owns the accuracy and robustness evidence. It must choose metrics, set declared accuracy levels, test performance across the system's lifecycle, and show how the model behaves under erroneous or inconsistent inputs. Where a system keeps learning after deployment, data science must also monitor feedback loops that could feed biased outputs back into the model. Security owns the defenses against attacks that alter use, outputs or performance, including data and model poisoning, evasion, confidentiality attacks and model flaws. In practice, security needs a threat model for the AI pipeline, test results, and a way to show that controls such as access restrictions on training data and code review are operating. Both teams should agree on one set of records so an assessor can trace a declared metric back to the test that produced it.

How long does Article 15 work take?

Timing depends on the scope: the number of high-risk systems, how far your existing test and security processes already reach into the AI pipeline, and how many attack scenarios your risk management process identifies. The deadlines come from the 2026 amendment to the Act, which moved the high-risk rules to 2 December 2027 for Annex III systems and to 2 August 2028 for Annex I product systems. Work the plan backward from those dates, and treat the start of testing as the constraint, because metrics and attack results need time to stabilize before they go into the technical file. Ask any provider for a schedule that ties each Article 15 deliverable to a named owner and a date.

What drives the cost of meeting Article 15?

Four factors drive most of the cost. The first is the number and complexity of high-risk systems in scope. The second is the amount of adversarial and robustness testing you need, which depends on the attack surface of each model and its data pipeline. The third is how much tooling you already run: vulnerability detection, code scanning and access controls in CI/CD pipelines reduce manual work, while missing tooling adds build and run costs. The fourth is whether the system keeps learning after deployment, which adds recurring monitoring. Costs fall into one-time work (test design, first evidence set, documentation) and recurring work (retesting after model changes, vulnerability updates, monitoring). When you request a quote, ask for each line to be split into one-time and recurring items, and ask who performs each task.

Does a cybersecurity presumption under Article 42 remove the need for testing?

No. Article 42 gives a presumption of conformity with the Article 15 cybersecurity requirements only in narrow cases: a certificate under a scheme adopted under the Cybersecurity Act (Regulation (EU) 2019/881) that covers the relevant parts of the system, or, from the 2026 amendment, a system that falls under the Cyber Resilience Act and meets the conditions of its Article 12(1). A presumption covers cybersecurity only, not accuracy, robustness against AI-specific attacks or resilience to feedback loops, and it applies only to the extent the certificate or conditions actually cover your system. Check the certificate scope line by line against your intended purpose and architecture. Confirm the applicable conditions with your legal adviser and the certificate holder before you rely on it.

Why must the assessor be independent of the team that prepared the evidence?

An assessor must be independent so that its conclusion is not shaped by the people who built the system or wrote its controls. Independence protects the value of the evidence: a report written by the team that designed the tests cannot easily show that the tests were a fair check. In an AI Act context, the organization owns its controls and an implementation partner can prepare systems, test environments and evidence, but only an independent auditor, assessor or certification body issues reports or certificates. Where the Act requires a notified body, that body must be independent of the provider. Ask any firm you hire to state in writing which role it plays, and keep preparation and independent assessment as separate engagements.

What should a written scope cover before Article 15 work starts?

A written scope should name the systems in scope and their intended purpose, the Article 15 requirements each deliverable addresses, and the roles of your team and any partner. It should list the accuracy metrics to be declared and the test methods for robustness, poisoning, adversarial examples and feedback loops. It should identify the tools in use, such as the open-source platforms your team will run in its own environment, and the evidence each one produces. The scope should set deliverables, acceptance criteria, a schedule tied to the 2 December 2027 and 2 August 2028 dates, and the quote split into one-time and recurring items. Finally, it should state what is excluded, including any independent assessment, which is not performed by the preparing firm. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

How DeployOpen scopes and prepares Article 15 evidence

DeployOpen plans and prepares the accuracy, robustness and cybersecurity evidence that Article 15 expects, inside the client's own infrastructure. The organization remains responsible for its high-risk system and its declarations, and only an independent assessor or notified body can issue conformity results.

How we scope

We agree a written scope that names the high-risk AI system, its intended purpose and the Article 15 requirements it must meet.
The scope lists which accuracy metrics, robustness tests and security controls are in and which remain with the client.
Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any work begins.
Ongoing support and continuous testing can be added later as a retainer once the initial scope is delivered.

How we build

We deploy self-hosted open-source tooling in the client's cloud accounts, data centers or air-gapped networks to collect Article 15 evidence.
We configure vulnerability detection, such as Wazuh and Fleet, against the client's endpoints and software inventory.
We set protected branches in GitLab and scan code with Semgrep in CI/CD to support secure change control for model and system code.
We help document accuracy declarations, resilience measures and security controls so they match the system as built.

How we hand over

We deliver the configured systems, runbooks and a written record of which Article 15 controls each component supports.
We produce test results for accuracy, error handling and adversarial or poisoning checks, with the methods and limits stated.
We document open gaps and the owner who must close them, so the client can decide what to fix before assessment.
We do not issue audit reports, attestations or certificates; the client engages an independent assessor for those.

How we support

We walk the client's compliance and engineering teams through the evidence so they can answer assessor questions directly.
We agree with the client which evidence is refreshed after each model update, retraining or security change.
We can support the client through the independent assessment by answering technical questions and supplying additional records.
Ask any provider, including DeployOpen, to confirm in writing which Article 15 evidence it delivers and which it does not.

Article 15 Accuracy, robustness and cybersecurity