Robustness and adversarial testing protocol (PR-15-ROB)
PR-15-ROB tests the accuracy, robustness and cybersecurity of an AI system against the levels its provider declares and the thresholds its risk management file records. It applies to high-risk AI systems under Art. 15, Art. 9 and Art. 13, and to general-purpose AI models with systemic risk under Art. 55. Every step names the standard clause or Act provision it derives from. The protocol produces the accuracy, robustness, adversarial and feedback-loop test reports an assessor asks for, with the record each step leaves behind.
| Field | Value |
|---|---|
| Protocol | PR-15-ROB |
| Version | v1.0 |
| Articles | |
| Derived from |
|
PR-15-ROB v1.0 is built from ISO/IEC TR 24029-1:2021Published, ISO/IEC 24029-2:2023Published, prEN 18229-2Draft, prEN 18282Enquiry, the published OWASP Top 10 for LLM Applications, the published MITRE ATLAS knowledge base and the Safety and Security chapter of the GPAI Code of PracticePublished.
Scope
The protocol covers two kinds of system. The first is a high-risk AI system under Art. 6 and Annex I or Annex III of Regulation (EU) 2024/1689, for which the Art. 15 accuracy, robustness and cybersecurity requirements apply from the Annex III application date Deferred or the Annex I application date Deferred. The second is a general-purpose AI model with systemic risk under Art. 51, for which the Art. 55 evaluation, adversarial testing and model cybersecurity duties apply from the GPAI application date In force.
For a high-risk AI system the protocol covers the seven testable elements of Art. 15, the six testable elements of Art. 9 that are test results rather than documents, and the five testable elements of Art. 13 that compare a declared level with a measured one. For a model with systemic risk it covers the four testable elements of Art. 55 that are test results, and it confirms the Art. 51(2) classification gate from the PR-CLS v1.0 record in step 2. The protocol applies to neural networks and to other machine-learned models. Steps marked "for a language model" apply only to a system built on a language model and add prompt injection, jailbreak and system-prompt leakage to the attack set.
The protocol does not cover the documentation and process elements of the same articles. The accuracy declaration, the cybersecurity risk assessment and the redundancy description are inputs; PR-11-DOC v1.0 checks their content and consistency. The lifecycle re-measurement process and the risk management cycle belong to PR-17-QMS v1.0. Subgroup and bias measurement belong to PR-10-BIAS v1.0; this protocol only compares a declared group performance with the disaggregated results already recorded. The classification of the system and the training compute calculation belong to PR-CLS v1.0; this protocol takes that record as a gate. The protocol does not test the physical infrastructure of a model under Art. 55(1)(d), the serious incident path under Art. 55(1)(c), the hosting platform beyond the AI-specific attack surface, or testing in real-world conditions under Art. 60. It is not a conformity assessment; the limits are stated on what we cannot do.
Articles covered
| Article | Testable element | Steps |
|---|---|---|
| Art. 15(1) | Accuracy on a held-out test set, measured with the metrics declared in the instructions for use, is at or above the declared level (Art. 15(1) and 15(3)) | 3, 9, 14, 33 |
| Art. 15(1) | Accuracy holds on a distribution-shifted set and across the released model versions, so that the system performs consistently throughout its lifecycle (Art. 15(1)) | 10, 15, 34 |
| Art. 15(4) | Outputs stay within the declared performance under input perturbation, noise, malformed input, edge cases and inconsistent signals from natural persons or connected systems (Art. 15(4), first subparagraph) | 6, 7, 17, 18, 19 |
| Art. 15(4) | The technical redundancy, backup or fail-safe solution takes over and holds the declared behaviour when a component fault is injected, where such a solution exists (Art. 15(4), second subparagraph) | 20 |
| Art. 15(4) | For a system that continues to learn, feeding its own possibly biased outputs back as inputs does not move performance beyond the declared level, and the mitigation measure activates as documented (Art. 15(4), third subparagraph) | 22, 42 |
| Art. 15(5) | The system resists each attack class named in Art. 15(5), third subparagraph: data poisoning of the training set, model poisoning of pre-trained components, adversarial examples or model evasion, confidentiality attacks such as model extraction and membership inference, and exploitation of model flaws, with prompt injection included for systems built on a language model | 11, 12, 23, 24, 25, 26, 27, 28, 38 |
| Art. 15(5) | The cybersecurity measures detect, respond to, resolve and control a simulated unauthorised attempt to alter the use, outputs or performance of the system (Art. 15(5), first and third subparagraphs) | 30 |
| Art. 55(1) | Model evaluation under Art. 55(1)(a): for each identified systemic risk, an evaluation is run with a named protocol and tool set that reflects the state of the art, and the result is recorded against a stated acceptance criterion | 13, 31, 44 |
| Art. 55(1) | Adversarial testing under Art. 55(1)(a): a red-team campaign with defined attack classes, elicitation methods and a success criterion per attack is executed against the model, and each outcome is recorded | 12, 27, 31, 38, 44 |
| Art. 55(1) | Mitigation effectiveness under Art. 55(1)(b): each safety mitigation is re-tested with the same evaluation and attack set, and the change from the pre-mitigation baseline is measured | 32 |
| Art. 55(1) | Model cybersecurity under Art. 55(1)(d): unauthorised access to model weights, model extraction through the serving interface, training-data poisoning and prompt injection are attempted under a documented threat model, and the result of each attempt is recorded | 11, 23, 26, 27, 29 |
| Art. 55 | Systemic-risk classification gate under Art. 51(2): cumulative training compute is calculated from the training records in floating point operations and compared with the presumption in Art. 51(2), with the calculation method recorded | 2 |
| Art. 9(6) | The system performs consistently for its intended purpose across the operating conditions recorded in the risk management file, with a result per condition (Art. 9(6)). | 5, 16, 35 |
| Art. 9(8) | Each test in the risk management file runs against a prior defined metric and probabilistic threshold, and the result either meets the threshold or does not (Art. 9(8)). | 4, 35, 43 |
| Art. 9(5) | The residual risk of each hazard after the adopted measures is measured and compared with the acceptance criterion recorded for that hazard, and the overall residual risk is compared with the overall criterion (Art. 9(5)). | 4, 36 |
| Art. 9(5) | Each technical risk management measure adopted under Art. 9(2)(d), such as an input check, a filter, a fallback or a guardrail, activates on the hazard scenarios it addresses and produces the recorded effect (Art. 9(5)(a) and 9(5)(b)). | 21 |
| Art. 9(2) | The system's behaviour under each reasonably foreseeable misuse condition recorded under Art. 9(2)(b) is observed and recorded against the expected behaviour. | 5, 16, 35 |
| Art. 9(9) | Where the Art. 9(9) consideration identifies a likely adverse impact on persons under the age of 18 or other vulnerable groups, the test set contains cases that represent those groups and the results are reported for them. | 5, 16, 43 |
| Art. 13(3) | The accuracy level and metrics declared in the instructions for use under Art. 13(3)(b)(ii) match the result of a test on a held-out set under the declared conditions of use. | 3, 14, 33, 39 |
| Art. 13(3) | The robustness and cybersecurity levels declared in the instructions for use under Art. 13(3)(b)(ii) match the result of perturbation and adversarial tests under the declared conditions of use. | 3, 17, 18, 19, 25, 26, 27, 30, 33 |
| Art. 13(3) | The known and foreseeable circumstances declared under Art. 13(3)(b)(ii) and (iii) reproduce the declared change in performance or the declared risk when the system runs under those circumstances. | 5, 16, 35 |
| Art. 13(3) | The performance declared for specific persons or groups under Art. 13(3)(b)(v) matches the disaggregated results recorded in the technical documentation. | 37 |
| Art. 13(3) | Each statement in the instructions for use on intended purpose, input data specifications, pre-determined changes, human oversight measures and log mechanisms (Art. 13(3)(b)(i), (b)(vi), (c), (d) and (f)) matches the corresponding section of the Annex IV technical documentation. | 39 |
Inputs required
| Input | Format | Provided by |
|---|---|---|
| Model access at a fixed version | Inference endpoint or container image with the version hash and the interface specification | Client |
| Model weights and training pipeline access, where the threat model puts them in scope | Read access to the weight store and the training repository, with the access levels named in the threat model | Client |
| List of pre-trained components used in training | Component inventory with source, version and hash per component | Client |
| Training, validation and test data with lineage | Dataset files with a dataset card per set: source, collection period, labelling method, split rule | Client |
| Held-out set and distribution-shifted set | Sample lists with hashes and a provenance record; assembled in step 10 from the client data and the condition register | Protocol |
| Instructions for use with the declared levels | Digital document with the Art. 13(3)(b)(ii) declaration: metric names, levels, test conditions, known circumstances | Client |
| Technical documentation, Annex IV sections 2(g) and 2(h) | Validation and testing procedures description; cybersecurity measures description | Client |
| Risk management file | Hazard register, prior defined metrics and probabilistic thresholds, residual risk acceptance criteria, adopted technical measures, misuse conditions | Client |
| Redundancy, backup or fail-safe description, where one exists | Component list, fault modes handled, expected takeover behaviour | Client |
| Continuous-learning design description, where the system learns after placing on the market | Learning trigger, update cycle, feedback-loop mitigation measure and its activation condition | Client |
| Cybersecurity risk assessment | The Art. 15(5) attack class applicability with the reason where a class is omitted | Client |
| Version history and release records | List of released model versions with hashes and release notes | Client |
| For a model with systemic risk: Safety and Security Framework and risk scenarios | The Framework document with systemic risk scenarios, evaluation protocols, tool sets and acceptance criteria | Client |
| For a model with systemic risk: training compute determination record | PR-CLS output with the calculation method and the Art. 51(2) comparison | PR-CLS output |
| Environment manifest | Model version hash, inference configuration, random seeds, tool versions; written in step 1 | Protocol |
Steps
Preparation
Record the system identity, model version hash, inference configuration, random seeds and tool versions in one manifest.
Record Environment manifest with the model version hash
[AIAssuranceLabs procedure]
Confirm the high-risk classification or the Art. 51 systemic-risk classification from the
PR-CLSrecord.Record Classification gate record with the reference to the training compute calculation
[Regulation (EU) 2024/1689, Art. 6 and Art. 51(2)]
Extract the declared accuracy metrics and levels, and the declared robustness and cybersecurity levels, from the instructions for use.
Record Declared-level extract with metric names, levels and test conditions
[Regulation (EU) 2024/1689, Art. 15(3) and Art. 13(3)(b)(ii)]
Extract the prior defined metrics, probabilistic thresholds, hazards, acceptance criteria and technical measures from the risk management file.
Record Threshold register and hazard test map
[Regulation (EU) 2024/1689, Art. 9(5) and 9(8)]
List the operating conditions, foreseeable misuse conditions, known circumstances and vulnerable-group cases from the file and the instructions.
Record Condition register with one entry per condition, circumstance and group case
[Regulation (EU) 2024/1689, Art. 9(2)(b), 9(9) and Art. 13(3)(b)(iii)]
State each robustness goal as a property, an input region, a metric and a bound.
Record Robustness goal statement per goal
[ISO/IEC TR 24029-1:2021, clause on robustness goals and their statement]
Select a statistical, formal or empirical method for each goal and record the reason.
Record Method selection record with the reason per goal
[ISO/IEC TR 24029-1:2021, clauses on statistical, formal and empirical methods]
Define each metric with its formula, its unit, its direction of improvement and its test conditions.
Record Metric definition sheet
[prEN 18229-2, draft, clause on accuracy metric declaration]
Record the target for each metric and the provider's justification against the context of use.
Record Target justification record with the source of each target
[NIST AI RMF 1.0, Measure 1.1]
Assemble a held-out set untouched by training or model selection, and a distribution-shifted set from the condition register.
Record Test set provenance record with sample counts and hashes
[AIAssuranceLabs procedure]
Write the threat model: assets, attacker access levels, and the applicability of each Art. 15(5) attack class.
Record Threat model
[prEN 18282, enquiry, clause on AI-specific threats]
Map each attack class to OWASP LLM entries and ATLAS techniques; record a success criterion per attack.
Record Attack set with a success criterion per attack
[MITRE ATLAS, techniques AML.T0020, AML.T0018, AML.T0043, AML.T0024, AML.T0051 and AML.T0054]
For a model with systemic risk, list each risk scenario with its evaluation protocol, tool set and acceptance criterion.
Record Systemic risk evaluation plan
[GPAI Code of Practice, Safety and Security chapter, Measures 2.2, 3.2 and 4.1]
The target justification record of step 9 has one entry per metric. The layout below is synthetic; the values are placeholders and carry no measured result.
metric:
id: <metric id from the metric definition sheet>
formula: <formula or reference to the definition sheet>
unit: <unit>
direction: <higher-is-better | lower-is-better>
declared_level: <value from the instructions for use, step 3>
prior_threshold: <value from the risk management file, step 4, or "none">
target:
value: <value the provider sets>
source_level: <1 to 6 in the source hierarchy>
source: <document and clause, or "state of the art">
justification: <one sentence against the context of use>
test_conditions: <test set id, conditions, environment manifest id>
recorded_by: AIAssuranceLabs
system_version: <model version hash from step 1>Execution
Run the held-out set through the frozen model; record every input, output and declared metric value.
Record Held-out run log with every input, output and metric value
[prEN 18229-2, draft, clause on accuracy assessment]
Run the distribution-shifted set and each released model version under the same configuration; record the metrics.
Record Shifted-set and version run log
[Regulation (EU) 2024/1689, Art. 15(1)]
Run each operating, misuse and vulnerable-group case from the condition register; record the output per case.
Record Condition run log with a result per case and per group
[Regulation (EU) 2024/1689, Art. 9(6), 9(2)(b) and 9(9)]
Apply each perturbation class to the held-out inputs: noise, malformed input, edge cases and inconsistent signals.
Record Perturbation run log per class and magnitude
[prEN 18229-2, draft, clause on perturbation classes for robustness assessment]
Sample perturbations at the recorded magnitudes and estimate each metric with a confidence interval.
Record Statistical robustness estimate with interval and sample size
[ISO/IEC TR 24029-1:2021, clause on statistical methods]
State each formal property over its bounded input region, run the verifier, and record proven, falsified or undetermined.
Record Formal result per property, with the counterexample where falsified
[ISO/IEC 24029-2:2023, clauses on stating robustness properties and reporting results]
Inject each component fault named in the redundancy description; record takeover, output behaviour and recovery.
Record Fault injection log with takeover and recovery per fault
[Regulation (EU) 2024/1689, Art. 15(4), second subparagraph]
Trigger each technical risk management measure with its hazard scenario; record activation and the observed effect.
Record Measure activation log
[Regulation (EU) 2024/1689, Art. 9(5)(a) and 9(5)(b)]
For a continuously learning system, feed outputs back as inputs for the recorded cycles; record drift and mitigation activation.
Record Feedback-loop run log with the metric per cycle
[Regulation (EU) 2024/1689, Art. 15(4), third subparagraph]
Insert labelled poison samples into a training copy at the recorded rate; retrain and measure the trigger effect.
Record Data poisoning result with the poison rate and the trigger success
[MITRE ATLAS, AML.T0020 Poison Training Data]
Replace one pre-trained component with a modified copy; measure the output change on the trigger set.
Record Model poisoning result
[MITRE ATLAS, AML.T0018 Manipulate AI Model and AML.T0010 AI Supply Chain Compromise]
Generate adversarial examples with the recorded methods and budgets; record the evasion rate per method.
Record Evasion result per method and budget
[MITRE ATLAS, AML.T0043 Craft Adversarial Data and AML.T0015 Evade AI Model]
Run membership inference, model inversion and model extraction queries through the serving interface; record each result.
Record Confidentiality attack result per sub-technique
[MITRE ATLAS, AML.T0024 Exfiltration via AI Inference API, sub-techniques .000 to .002]
For a language model, run direct and indirect prompt injection, jailbreak and system-prompt leakage cases; record each outcome.
Record Prompt attack log with the outcome per case
[OWASP Top 10 for LLM Applications, LLM01 and LLM07; MITRE ATLAS, AML.T0051, AML.T0054 and AML.T0056]
Exercise each model flaw listed in the threat model; record whether the flaw was exploited.
Record Model flaw result per listed flaw
[Regulation (EU) 2024/1689, Art. 15(5), third subparagraph]
Attempt access to model weights and the training pipeline at each access level in the threat model.
Record Weight and pipeline access attempt log
[GPAI Code of Practice, Safety and Security chapter, Measure 6.2 and Appendix 4.1]
Simulate an unauthorised attempt to alter use, outputs or performance; record detection, response, resolution and control.
Record Security control response log with timestamps
[Regulation (EU) 2024/1689, Art. 15(5), first and third subparagraphs]
For a model with systemic risk, run each planned evaluation with elicitation; record the result against its criterion.
Record Evaluation result per systemic risk
[GPAI Code of Practice, Safety and Security chapter, Measure 3.2 and Appendix 3.2]
Re-run the evaluation and attack set after each mitigation; record the change from the pre-mitigation baseline.
Record Mitigation effectiveness delta per mitigation
[GPAI Code of Practice, Safety and Security chapter, Measure 5.1]
Analysis
Compare each held-out, robustness and cybersecurity result with its declared level; record meets or does not meet.
Record Declared-level comparison table
[Regulation (EU) 2024/1689, Art. 15(3) and Art. 13(3)(b)(ii)]
Compare the shifted-set and version results with the held-out result; record the difference per metric.
Record Consistency table across sets and versions
[Regulation (EU) 2024/1689, Art. 15(1)]
Compare each condition result with its prior defined threshold and the declared circumstance effect; record the outcome.
Record Condition outcome table
[Regulation (EU) 2024/1689, Art. 9(8) and Art. 13(3)(b)(ii) and (iii)]
Derive the residual risk per hazard from the measure results; compare with the hazard criterion and the overall criterion.
Record Residual risk comparison per hazard and overall
[Regulation (EU) 2024/1689, Art. 9(5)]
Compare the group performance declared in the instructions with the disaggregated results in the technical documentation.
Record Group performance comparison
[Regulation (EU) 2024/1689, Art. 13(3)(b)(v)]
Classify each attack outcome against its success criterion; tag it with the OWASP entry and ATLAS technique id.
Record Attack outcome matrix
[AIAssuranceLabs procedure]
The attack outcome matrix of step 38 has one entry per attack in the attack set. The layout below is synthetic; the values are placeholders.
{
"attack_id": "<id from the attack set, step 12>",
"art_15_5_class": "<data poisoning | model poisoning | adversarial examples | confidentiality | model flaw>",
"owasp_llm": "<LLM01 to LLM10, or null for a system without a language model>",
"atlas_technique": "<AML.T....>",
"access_level": "<from the threat model, step 11>",
"method": "<method and budget as recorded>",
"success_criterion": "<criterion recorded in step 12>",
"observed": "<measured value with unit>",
"outcome": "<resisted | not resisted | not applicable, with reason>",
"control_response": "<detected | responded | resolved | controlled, per step 30, or null>",
"system_version": "<model version hash from step 1>",
"evidence": ["<log file id>", "<log file id>"]
}Reporting
Write the accuracy and declared-level report; cross-reference other instructions-for-use statements to the
PR-11-DOCconsistency report.Record Accuracy test report and declared-level verification test report
[prEN 18229-2, draft, clause on the structure of the accuracy declaration]
Write the robustness report with statistical, formal, fault-injection and fail-safe results grouped by method category.
Record Robustness test report
[ISO/IEC TR 24029-1:2021, clause on assessment methods; ISO/IEC 24029-2:2023, clause on reporting results]
Write the adversarial and cybersecurity report per Art. 15(5) attack class with the threat model and outcomes.
Record Adversarial and cybersecurity test report
[prEN 18282, enquiry, clause on AI-specific threats]
Write the feedback-loop record with the metric per cycle and the mitigation activation cycle.
Record Feedback-loop mitigation test record
[Regulation (EU) 2024/1689, Art. 15(4), third subparagraph]
Write the risk-driven test report per hazard, condition, group case and threshold for the risk management file.
Record Risk-driven test report
[Regulation (EU) 2024/1689, Art. 9(8)]
For a model with systemic risk, write the evaluation report per risk and the adversarial campaign record.
Record Model evaluation report per systemic risk and adversarial testing campaign record
[GPAI Code of Practice, Safety and Security chapter, Measure 7.3]
Record the re-test triggers: model, data and operating-environment changes that invalidate each report; archive all records with hashes.
Record Lifecycle performance monitoring record with re-test triggers and the archive index
[Regulation (EU) 2024/1689, Art. 15(1)]
Thresholds and criteria
Regulation (EU) 2024/1689 sets no numeric threshold in Art. 15, Art. 9, Art. 13 or Art. 55. Art. 15(1) requires an appropriate level; Art. 15(3) requires the provider to declare the level and the metrics; Art. 9(8) requires prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose; Art. 55(1)(a) requires evaluation against protocols that reflect the state of the art. Every pass criterion in this protocol therefore comes from one of the six levels below, and the step that records it is named.
| Level | Source | What it supplies to this protocol | Step |
|---|---|---|---|
| 1 | Harmonised standard cited in the Official Journal | None is cited as of the anchor date shown on the standards page, so no presumption of conformity exists for any criterion in this protocol | none |
| 2 | prEN 18229-2Draft | Metric categories, the declaration structure and the perturbation classes; the draft publishes no numeric pass level | 8, 17, 39 |
| 2 | prEN 18282Enquiry | The AI-specific threat list behind Art. 15(5); the enquiry draft publishes no numeric pass level | 11, 41 |
| 3 | ISO/IEC TR 24029-1:2021Published | Method categories and the form of a robustness goal; no numeric pass level | 6, 7, 18 |
| 3 | ISO/IEC 24029-2:2023Published | The result semantics for a formal property: proven over the stated region, falsified with a counterexample, or undetermined | 19 |
| 4 | GPAI Code of PracticePublished | Measure 4.1: the provider sets the systemic risk acceptance criteria in its Safety and Security Framework; the protocol takes them as input | 13, 31 |
| 5 | NIST AI RMF 1.0Published | Measure 1.1: the rationale for selecting each metric and target | 9 |
| 6 | State of the art, justified by the provider | The target per metric and the reason it fits the context of use | 9 |
The pass criterion for each element is then one of the following. The declared level from the instructions for use is the criterion for held-out accuracy, robustness and cybersecurity (step 33). The prior defined threshold from the risk management file is the criterion for each condition and misuse case (step 35). The acceptance criterion per hazard and the overall criterion from the risk management file are the criteria for residual risk (step 36). The success criterion recorded per attack in step 12 is the criterion for each attack outcome (step 38). A formal property passes when the verifier result over the stated input region is proven, not falsified or undetermined (step 19). A fail-safe passes when the declared behaviour holds after the injected fault (step 20). A feedback-loop test passes when performance stays within the declared level and the mitigation activates as documented (step 22). A systemic risk evaluation passes against the acceptance criterion in the evaluation plan (step 31), and a mitigation is effective when the change from baseline has the direction and size the plan states (step 32).
Where no published threshold exists for a metric, step 9 records the provider's target, its source level and the justification. The protocol reports the measured value next to that target; it does not set the target.
Outputs
| Artifact | Contents | Deliverable |
|---|---|---|
Accuracy test report on held-out and distribution-shifted sets (PR-15-ROB output) | Metric definitions, test set provenance, environment manifest, held-out and shifted-set results, version consistency table, declared-level comparison | Accuracy report on held-out and distribution-shifted sets with declared metrics for instructions for use, in Robustness and adversarial testing |
Declared-level verification test report (PR-15-ROB output) | Each declared accuracy, robustness and cybersecurity level next to the measured result, with meets or does not meet, and the cross-reference to the PR-11-DOC consistency report | Accuracy report with declared metrics for instructions for use, in Robustness and adversarial testing |
Robustness test report with perturbation, fault-injection and fail-safe results (PR-15-ROB output) | Robustness goals, method selection, statistical estimates with intervals, formal results per property, fault injection log, measure activation log | Robustness report with perturbation, noise and edge-case results by method category, in Robustness and adversarial testing |
Adversarial and cybersecurity test report covering the Art. 15(5) attack list (PR-15-ROB output) | Threat model, attack set, attack outcome matrix per Art. 15(5) class with OWASP and ATLAS tags, security control response log | Adversarial and red-team report mapped to the OWASP LLM Top 10 and MITRE ATLAS, in Robustness and adversarial testing |
Feedback-loop mitigation test record for a continuously learning system (PR-15-ROB output) | Cycle count, metric per cycle, drift, mitigation activation cycle, comparison with the declared level | Feedback-loop test results for continuously learning systems, in Robustness and adversarial testing |
Risk-driven test report (PR-15-ROB output) | Result per operating condition, misuse condition and vulnerable-group case against the prior defined threshold; residual risk per hazard and overall; measure activation results; written for the Art. 9 risk management file | Delta test report on affected obligations after a model or version change, in Regression testing after substantial modification |
Model evaluation report per systemic risk (PR-15-ROB output) | Evaluation plan, protocol and tool set per risk, elicitation method, result against the acceptance criterion, mitigation effectiveness delta | Capability and misuse-potential evaluation report aligned to the GPAI Code of Practice, in GPAI evaluation support |
Adversarial testing campaign record (PR-15-ROB output) | Campaign design, attack classes, elicitation methods, success criterion and outcome per attack, model version tested, weight and pipeline access attempt log | Adversarial testing and jailbreak-resistance documentation, in GPAI evaluation support |
Lifecycle performance monitoring record with re-test triggers | The model, data and operating-environment changes that invalidate each report, and the archive index with hashes | Updated traceability matrix and evidence-pack index, in Regression testing after substantial modification |
The specification and a synthetic sample of each deliverable are on the deliverables page.
Limitations
A result of this protocol holds for the model version in the environment manifest, the test sets in the provenance record and the conditions in the condition register. A change to any of these invalidates the result; step 45 records the triggers.
The protocol measures against a declared level, a prior defined threshold or a recorded acceptance criterion. It cannot show that the level, threshold or criterion is the appropriate one for the intended purpose. That judgement belongs to the provider under Art. 15(1) and Art. 9(5), and to its notified body and counsel where a conformity assessment follows.
A statistical robustness estimate carries the confidence interval and sample size recorded in step 18; it is not a proof. A formal result holds only over the bounded input region stated in step 19; an undetermined result is recorded as undetermined and is not a pass. An adversarial result holds for the attack methods, budgets and access levels in the attack set; the protocol cannot show the absence of attacks outside that set. A feedback-loop test simulates the recorded number of cycles and does not reproduce field deployment.
The protocol takes the Art. 15(5) applicability decisions in the cybersecurity risk assessment as input. Where the provider records a class as not appropriate, the protocol records that decision and does not test the class; PR-11-DOC v1.0 checks that the reason is documented.
For a model with systemic risk, the protocol runs the evaluations the provider's Safety and Security Framework names. It is not the independent external evaluation described in Appendix 3.5 of the Safety and Security chapter of the GPAI Code of PracticePublished unless the engagement is scoped as one, and it does not test the physical infrastructure under Art. 55(1)(d).
The draft standards named in the derivation line can change before citation in the Official Journal. A later version of this protocol follows any change; the revision history records it.
The classification gate in step 2 depends on the Art. 6 outcome. For an Annex III system that the provider assesses as not high-risk under Art. 6(3), the registration duty is an unsettled point; the protocol records the PR-CLS result and does not decide the point.
Sources
ISO/IEC TR 24029-1:2021Published: overview of robustness assessment methods for neural networks, with the statistical, formal and empirical method categoriesISO/IEC 24029-2:2023Published: methodology for the use of formal methods to assess robustness properties of neural networksprEN 18229-2Draft: AI trustworthiness framework, part 2, accuracy and robustnessprEN 18282Enquiry: cybersecurity for AI systemsGPAI Code of PracticePublished: Safety and Security chapter, Commitments 2 to 7 and Appendices 3 and 4NIST AI RMF 1.0Published: Measure function, metric selection rationale- OWASP Top 10 for LLM Applications, published; entries
LLM01Prompt Injection,LLM02Sensitive Information Disclosure,LLM04Data and Model Poisoning andLLM07System Prompt Leakage are used - MITRE ATLAS, published knowledge base; techniques
AML.T0010,AML.T0015,AML.T0018,AML.T0020,AML.T0024,AML.T0043,AML.T0051,AML.T0054andAML.T0056are used - Regulation (EU) 2024/1689, consolidated text, Art. 6, 9, 13, 15, 51 and 55
Revision history
Each version of PR-15-ROB is anchored to the regulation entry whose verified-on date governs the standards as they stood when the version was written.
| Version | Note | Anchor |
|---|---|---|
| v1.0 | Initial version, written from the standards in the derivation line as they stood on the verified-on date of the entry. | Verified on K&L Gates, EU Digital Omnibus on AI Enters Into Force (31 July 2026) |