Regression testing after substantial modification
We re-test a high-risk AI system after a model, data or version change against the accuracy, robustness and cybersecurity requirements of Art. 15. The change is classified against the Art. 3(23) definition and the Art. 43(4) criteria in the modification register of PR-43-MOCK v1.0, and the tests the change invalidates are re-run under PR-15-ROB v1.0. The provider receives an assessment memo, a delta test report and an updated traceability matrix. Art. 15 applies to Annex III systems from the Annex III date Deferred; the limits are on what we cannot do.
Deliverables
The set is designed to satisfy three records an assessor asks for after a change: the modification record per release under Art. 17(1)(a), the evidence that performance stays consistent across versions under Art. 15(1), and the technical file index that names which evidence a change invalidated. The three items are an assessment memo, a test report and a traceability matrix; the specification and a synthetic sample of each type are on the deliverables page.
| Deliverable | Type | Format | Designed to satisfy |
|---|---|---|---|
| Substantial-modification impact assessment against Article 43 criteria | Assessment memo | PDF with Markdown source | |
| Delta test report on affected obligations after a model or version change | Test report | PDF with Markdown source; CSV result tables; JSON run manifest | |
| Updated traceability matrix and evidence-pack index | Traceability matrix | XLSX; CSV; Markdown table for the technical file |
Who this is for
- Annex III providers
- Annex I manufacturers
- GPAI providers
A provider of an Annex III system carries the Art. 15(1) requirement that the system performs consistently throughout its lifecycle, and a released model version is the unit against which that consistency is shown. A manufacturer embedding AI in an Annex I product already runs a technical file and a quality system under the sectoral law, so the AI-specific re-test results are written to sit inside the existing technical file and to name the version they hold for. A provider of a general-purpose AI model with systemic risk re-runs the Art. 55(1)(a) evaluation and adversarial testing when the model version changes. The mitigation effectiveness element under Art. 55(1)(b) re-tests each mitigation with the same evaluation and attack set; the Safety and Security chapter of the GPAI Code of PracticePublished describes that record.
The applicable date for the high-risk case is the regulation entry behind the urgency line, with its verified source; the Annex I date Deferred and the GPAI date In force govern the other two groups:
Scope
The engagement covers one change, or one release that bundles several changes, to an AI system or model for which baseline evidence already exists: a prior test report with its environment manifest, and a traceability matrix that maps each obligation element to that evidence. Three groups of work are in scope. First, the change classification. Every change since the last assessment is listed in the modification register of PR-43-MOCK v1.0 and classified as pre-determined, other or substantial. The classification follows the Art. 3(23) definition and the Art. 43(4) rule that, for a system that continues to learn after placing on the market, a change pre-determined at the initial assessment and described in Annex IV section 2(f) is not a substantial modification. Second, the delta re-test. The re-test triggers recorded in the lifecycle performance monitoring record name which reports the change invalidates. Those testable elements of Art. 15 are re-run under PR-15-ROB v1.0 against the new version, with the version consistency run that compares the new version with each released one. Third, the re-issue of the traceability matrix and the evidence-pack index with the invalidated evidence marked and the new evidence linked.
The re-test uses the same method category as the baseline so that the delta is comparable: ISO/IEC TR 24029-1:2021Published supplies the statistical, formal and empirical categories, and ISO/IEC 24029-2:2023Published supplies the formal-property procedure, under which a property shown for the baseline version does not carry over and is re-established over the same bounded input region for the new version. The metric categories and the perturbation classes follow prEN 18229-2Draft, and the AI-specific threat list behind Art. 15(5) follows prEN 18282Enquiry. Neither JTC 21 document is cited in the Official Journal, one being at draft and one at enquiry stage: they are evidence of the state of the art, and no presumption of conformity attaches to them because no harmonised standard is cited in the Official Journal as of the anchor date shown on the standards page.
Out of scope are the first baseline, which is the robustness and adversarial testing service, and the decision that a change is a substantial modification, which belongs to the provider, its notified body and its counsel; the assessment memo records the evidence and the reasoning for that discussion. The new conformity assessment that Art. 43(4) starts after a substantial modification is a separate procedure and is not testing. The post-market monitoring system under Art. 72, which collects performance data over the lifetime of the system and supplies one of the triggers for a re-test, is a process element checked by PR-17-QMS v1.0; this service consumes its data and does not operate it. Bias re-measurement after a data change belongs to PR-10-BIAS v1.0, and the update of the instructions for use where a declared level moved belongs to PR-11-DOC v1.0. Each result is a measured value next to the level declared for the baseline; the judgement whether that level remains the appropriate one under Art. 15(1) stays with the provider.
What we test
The table lists every testable element of the covered obligation with the protocol that runs it and the artifacts it produces for the record; after a change, only the elements the modification register marks as invalidated are re-run, and the delta test report names the ones left unchanged with the baseline report they still rest on.
| Obligation | Testable element | Protocol | Artifacts |
|---|---|---|---|
| Art. 15 | 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)) | PR-15-ROB v1.0 |
|
| 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)) | PR-15-ROB v1.0 | ||
| 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) | PR-15-ROB v1.0 | ||
| 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) | PR-15-ROB v1.0 | ||
| 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) | PR-15-ROB v1.0 | ||
| 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 | PR-15-ROB v1.0 | ||
| 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) | PR-15-ROB v1.0 |
Regulation (EU) 2024/1689 sets no numeric threshold in Art. 15, so every pass criterion comes from a six-level hierarchy. Level one is a harmonised standard cited in the Official Journal, and none is cited as of the anchor date, so no presumption of conformity exists for any criterion. Level two is a JTC 21 draft, stated with its stage: prEN 18229-2Draft for metric categories and prEN 18282Enquiry for the threat list, neither of which publishes a numeric pass level. Level three is an ISO/IEC document such as ISO/IEC 24029-2:2023Published, which supplies result semantics rather than a number. Level four is a Commission guideline or code of practice; for a model with systemic risk the acceptance criteria come from the provider's Safety and Security Framework under the GPAI Code of PracticePublished. Level five is NIST AI RMF 1.0Published or a sector framework, used for the metric selection rationale. Level six is the state of the art, justified by the provider. In a re-test the pass criterion is the level declared in the instructions for use for the baseline; where the change moves that level, the target-justification step of PR-15-ROB v1.0 records the new target, its source level and the reason it fits the context of use, and the report shows the measured value next to both the old and the new target.
Protocols used
Two versioned protocols run the engagement; each page states every step with the standard clause, Act provision or procedure note it derives from.
- PR-15-ROB v1.0Robustness and adversarial testing protocolv1.0
- PR-43-MOCK v1.0Pre-conformity mock assessment protocolv1.0
PR-43-MOCK v1.0 supplies the change side of the work. Its modification register step lists each change since the last assessment and classifies it as pre-determined, other or substantial under Art. 43(4) and Art. 3(23); its re-assessment trigger record names, for each substantial modification, the route that applies again and the evidence it invalidates; its sampled re-test result record and evidence-pack index update produce the delta rows and the re-issued index. The protocol is a dry run: it is not a conformity assessment under Art. 43, it issues no certificate, and a classification in the register is a technical reading of the definition that binds neither a notified body nor a market surveillance authority. A passing sample shows that the sampled evidence reproduces and says nothing about the elements outside the sample.
PR-15-ROB v1.0 supplies the test side. It re-runs the invalidated testable elements of Art. 15 against the new version: accuracy on the held-out and distribution-shifted sets with the version consistency table, perturbation and fault-injection results, the feedback-loop record for a system that continues to learn, and the attack set for each Art. 15(5) class, with prompt injection, jailbreak and system-prompt leakage added for a system built on a language model. It produces the risk-driven test report and the lifecycle performance monitoring record with the re-test triggers for the new version. A result holds for the model version in the environment manifest, the test sets in the provenance record and the conditions in the condition register, and a further change to any of them invalidates it again. The protocol does not show that a declared level is the appropriate one, and an adversarial result holds only for the attack methods, budgets and access levels in the recorded attack set.
Engagement shape
The engagement is ongoing and scoped per request: each model, data or version change is one re-test, and the request names the change and the baseline it moves from. The readiness assessment is the entry service and fixes which obligations are in scope; the first baseline comes from the robustness and adversarial testing service or from a prior test report the provider holds. The provider supplies the change and release records with the classification the provider assigned, the baseline test reports with their environment manifests and the traceability matrix, the lifecycle performance monitoring record with its re-test triggers, model access at the new version with a version hash, the Annex IV section 2(f) description of pre-determined changes for a system that continues to learn, the instructions for use in the current release, and the post-market monitoring data where the trigger came from the field under Art. 72(2).
The work follows the order of the protocols. Preparation writes the modification register, classifies each change, records the evidence each change invalidates, writes the environment manifest for the new version, and fixes the test sets by hash, either the baseline sets or updated sets with their provenance recorded. Execution re-runs the invalidated tests against the new version and runs the version consistency comparison across the released versions. Analysis compares each measured value with the declared level and with the baseline value and records meets or does not meet, together with the difference per metric. Reporting writes the assessment memo, the delta test report and the updated traceability matrix with the evidence-pack index and the re-test triggers that invalidate the new results.
What we cannot do
- We do not perform conformity assessments where a notified body is required.
- We do not issue CE marking or the EU Declaration of Conformity.
- We are not a notified body.
- We do not give legal opinions on classification or liability.
- We test against requirements, prepare evidence, and structure documentation; compliance decisions remain with the provider or deployer, their notified body, and their counsel.
For this service the limit means that the substantial-modification impact assessment is a reasoned technical assessment of a change against the Art. 3(23) definition, for discussion with counsel and, where one is involved, the notified body; it is not the Art. 43(4) decision and no new conformity assessment follows from it. The delta test report states measured values for the new version next to the declared level; it does not state that the modified system meets Chapter III, Section 2.
What the client must have ready
The documentation and process elements of the covered obligation are inputs to the re-test; the list below is generated from the obligation record.
Art. 15Accuracy, robustness and cybersecurity
- Declaration of the accuracy levels and the relevant accuracy metrics in the instructions for use, with the metric definitions, the test-set description and the measurement conditions (Art. 15(3)) documentation
- Rationale for the level of accuracy, robustness and cybersecurity chosen as appropriate for the intended purpose, with the source of each target (Art. 15(1)) documentation
- Description of the technical and organisational measures taken for resilience to errors, faults and inconsistencies (Art. 15(4), first subparagraph) documentation
- Description of the technical redundancy solution and the backup or fail-safe plan where one is used (Art. 15(4), second subparagraph) documentation
- Design description of how a continuously learning system limits feedback loops and the mitigation measures that address them (Art. 15(4), third subparagraph) documentation
- Cybersecurity risk assessment that shows the technical solutions are appropriate to the relevant circumstances and the risks, and that records, for each attack class in Art. 15(5), whether a measure applies and the reason where one is omitted as not appropriate (Art. 15(5), second and third subparagraphs) documentation
- Re-measurement of accuracy, robustness and cybersecurity after each model, data or operating-environment change, with a defined trigger, so that consistent performance is shown across the lifecycle (Art. 15(1)) process
- Operation of the organisational measures for resilience: fault handling, incident escalation and the operating procedures that respond to errors and inconsistencies in service (Art. 15(4), first subparagraph) process
- Operation of the feedback-loop mitigation measures while the system continues to learn, with periodic review of learned behaviour (Art. 15(4), third subparagraph) process
- Ongoing prevention, detection, response, resolution and control of AI-specific attacks: vulnerability management, threat monitoring and the response path for a detected attack (Art. 15(5)) process
The inputs take the form the protocol pages specify: an inference endpoint or container image for the new version with its hash, the baseline reports and run records as digital documents with their run manifests, a change log with a version identifier and a change classification per entry, and dataset files with a dataset card per set where the change touched the data. A missing input is recorded as missing in the report; the protocols do not substitute a value for it.
Questions
What is a substantial modification under the AI Act?
Art. 3(23) of Regulation (EU) 2024/1689 defines a substantial modification as a change to an AI system after placing on the market or putting into service that was not foreseen in the initial conformity assessment and that affects whether the system meets Chapter III, Section 2 or modifies the assessed intended purpose. Under Art. 43(4) a substantially modified system undergoes a new conformity assessment; for a system that continues to learn after placing on the market, a pre-determined change described in Annex IV section 2(f) is not substantial. The modification register of PR-43-MOCK classifies each change against the Art. 3(23) definition.
How does ISO/IEC 24029 apply to robustness testing after a model change?
ISO/IEC TR 24029-1:2021 is a published technical report that sorts robustness assessment methods into statistical, formal and empirical categories. A re-test under PR-15-ROB uses the same category for each robustness property as the baseline report, so that the new value is compared with the baseline value under the same method, sample size and confidence interval. A statistical estimate for the new version is a new measurement. The robustness test report records the method per property, the baseline value, the new value and the difference.
What does ISO/IEC 24029-2 add to a re-test after a model change?
ISO/IEC 24029-2:2023 is a published standard that gives the formal-method procedure for showing a robustness property over a bounded input region and the content of a formal result report. A formal result is tied to the weights it was computed on and does not transfer to a new version. Under PR-15-ROB each formal property is re-established over the same region for the new version; an undetermined result is recorded as undetermined, not as a pass. The robustness test report states the region, the property and the outcome per version.
What is an LLM jailbreak, and does a model update change the result?
An LLM jailbreak is an input crafted so that a language model produces an output its safety measures withhold. PR-15-ROB adds jailbreak, prompt injection and system-prompt leakage to the Art. 15(5) attack set for a language-model system, each with a recorded method, budget, access level and success criterion. An adversarial result holds for the model version tested and the recorded attack set, so a model update re-runs that set against the new version. For a model with systemic risk, the Art. 55(1)(b) mitigation effectiveness record shows the change per attack.
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.