A passing regression suite does not answer whether an AI change stays within the purpose and constraints previously assessed. Before promotion, freeze a before/after evidence dossier, identify the affected controls and route unresolved purpose, responsibility or conformity questions to an accountable reviewer. Automate evidence checks and routing—not a legal verdict that a modification is or is not substantial.
This article proposes an engineering handoff for platform teams and Heads of AI. It is not legal advice or a conformity assessment. Qualified counsel must determine scope, roles, applicable dates, exceptions and the legal significance of a specific change. A prompt, model or retrieval update is not automatically a substantial modification; an unchanged model is not proof that the system's purpose stayed unchanged.
Separate three questions before changing the release gate
The first question is technical: does the candidate satisfy the approved quality, security and operational tests? The second is factual: what changed relative to the assessed system and purpose? The third is legal: do those facts require a different responsibility allocation or conformity process? These questions share evidence but have different decision owners.
Article 3(23) defines substantial modification in relation to a post-market or post-service change not foreseen or planned in the initial provider conformity assessment, with an effect on compliance with Chapter III Section 2 requirements or a modification of the assessed intended purpose. The Commission's Article 3 reference is useful context, but its amendment disclaimer means it must be read alongside the current text, not treated as an up-to-date legal rulebook.
Article 25(1) distinguishes, among other circumstances, substantial modification of an already high-risk system that remains high-risk from changing the purpose of a previously non-high-risk system so that it becomes high-risk. Rebranding is another stated circumstance. Article 43(4) addresses a new conformity assessment after substantial modification of an already assessed high-risk system, including continued use by the current deployer. Do not collapse role review and conformity review into a single checkbox.
The same paragraph's provision for systems that continue to learn concerns changes and performance predetermined by the provider at initial conformity assessment and documented under Annex IV point 2(f). A later roadmap entry saying “we planned to improve the model” is not evidence of that original documented scope. Nor is this provision a blanket exemption for all updates.
Source review on 21 September 2026 used the current EUR-Lex consolidation and the amending Official Journal instrument. Complete numbered provisions were cross-checked against a retained PDF of that consolidation because the fresh HTML extraction omitted some paragraphs. The consolidation is a documentation aid; the authentic acts are the Official Journal texts. Application provisions differ across routes and have been amended. The gate below is a proposed engineering policy, not a claim that every cited obligation applies to every deployment today.
Build a change dossier, not another inventory
Start with a stable system ID and two immutable release references: the assessed baseline and the candidate. Do not compare only the last deployment with the new one. Several small releases can cumulatively move beyond the assessed baseline even if each individual diff looks modest. Retain the intermediate chain as supporting evidence.
The LLM release bundle provides reproducible component identity and rollback. This dossier adds a different join: which assessed purpose, documented constraints and responsibility decision those components supported. A bundle checksum proves byte integrity, not regulatory scope.
Use the following proposed dossier template. The examples are hypothetical field contents, not supplier statements or a prescribed legal form. Every substantive assertion needs an evidence reference and owner; unknown is a valid state, but not a release approval.
| Dossier field | Assessed baseline | Proposed candidate | Evidence and owner |
|---|---|---|---|
| System and release | System ID; assessed bundle digest | Same identity or proposed identity change; candidate digest | Deployment registry; release owner |
| Purpose and affected users | Quoted purpose; document revision; authorised workflow | Explicit purpose delta; users; decision authority | Instructions and process design; product owner |
| Predetermined change scope | Original assessment reference; exact documented limits | Claimed fit, conflict or unknown | Original technical documentation; provider liaison |
| Components and dependencies | Model, prompt, retrieval, tools, interface revisions | Added, removed and changed revisions | Manifest diff; platform owner |
| Controls and tests | Assessed oversight, logging and input constraints | Impact map; new tests; unresolved failures | Test artifacts; control owners |
| Responsibilities and handoff | Entity, actor decision and reviewed route | Possible role change; supplier evidence gaps | Counsel-controlled decision; legal/compliance owner |
Keep evidence in an access-controlled store. The release manifest should contain references, revisions and digests, not raw personnel files or unrestricted supplier documents. Record who can access the underlying evidence and what happens when access is revoked. A resolvable URL is not enough if the assigned reviewer cannot read it.
Decision table: route facts, never declare legal status
Use two independent axes: component change and purpose/context change. A code diff can detect a new tool permission; it cannot determine whether a new workflow materially changes who is affected or how output is used. Require the process owner to confirm those facts explicitly.
| Observed change | Evidence to collect | Engineering disposition | Question for accountable review |
|---|---|---|---|
| New model or prompt; purpose stated unchanged | Baseline/candidate tests; original change scope; control impact | Hold if scope or impact is unresolved | Does the documented assessment cover these facts? |
| Same model; recommendation now triggers a decision | Old/new process map; affected people; authority and oversight | Hold changed decision capability | Has intended purpose or actor responsibility changed? |
| Retrieval corpus adds a new document class | Input limits; corpus provenance; unsupported-input and output tests | Review affected route before promotion | Are assessed constraints or controls affected? |
| Learning update claimed inside predetermined scope | Original assessment passage; Annex IV 2(f) reference; measured bounds | Validate evidence, then route under approved policy | Is the claimed predetermined-change basis actually applicable? |
| New branding, legal entity or supplier boundary | Contracts; branding; system identity; information/access gaps | Open responsibility review | Which Article 25 circumstances and exceptions are relevant? |
| No meaningful scope delta; all evidence complete | Signed factual delta; current scoped decision; passing technical gates | Eligible for authorised release decision | Does the existing approval remain valid for this candidate? |
“Hold” here means hold candidate promotion under the proposed internal policy. It is not a generic instruction to stop a running industrial system. Runtime safety, incident reporting and any legally required suspension need their own approved procedures; a release exception cannot override them.
A decision tree that ends with a reviewer
Read the diagram as evidence routing. If the baseline purpose, assessment reference or candidate identity is missing, return evidence-incomplete and assign the missing item. If those references exist, compare purpose, affected users, output authority and controls. A changed or unknown answer opens scope review. If those facts are unchanged, check the claimed documented change scope and affected test results; unresolved scope still opens review, while failed tests return technical rework.
The final automated state is review-ready, not compliant, not non-substantial and not approved. An authorised decision record identifies the reviewed dossier revision, candidate digest, permitted scope, conditions, reviewer authority and any expiry or reopening trigger. A separate release controller checks that record together with technical acceptance before promotion.
Invalidate the decision when its bound evidence changes. If a candidate is amended after review, do not carry forward the previous approval because the ticket number stayed the same. Use a compare-and-swap on the dossier revision or digest at the promotion boundary. Replayed approval events must be idempotent and must not authorise a different candidate.
Supplier cooperation is part of the evidence path
The amended Article 25(2) makes the cooperation material more explicit: relevant technical documentation, known limitations and failure modes, and targeted technical access including testing and validation. It also retains a stated exception where the initial provider clearly specified that its system is not to be changed into a high-risk system. Do not treat missing documents as automatically obtainable or assume an unlimited right to model weights.
The amended first subparagraph of Article 25(4) explicitly includes an AI model in the supplier categories for the written information-and-assistance arrangement. Its free/open-source exception is qualified and excludes general-purpose AI models from that exception. The Commission's Article 25 page still flags that its displayed text has not been updated; the operative amendment, not its summary, grounds these details.
Operationally, track requested evidence, supplier response, access conditions, unresolved limitations and the responsible procurement or legal owner. A supplier refusal becomes a visible review constraint, not an empty string that passes schema validation. Protect confidential material and trade secrets; useful cooperation does not imply unrestricted disclosure.
Worked example: unchanged weights, changed authority
Consider a hypothetical assistant that drafts internal maintenance notes. A proposed workflow now turns the same output into a prioritised work order without the previous operator confirmation. The model digest is unchanged, but tool permissions, decision authority and human oversight differ. This example does not classify the system as high-risk or conclude that the change is substantial.
The dossier should retain the prior instructions and process map, the candidate write permission, the removed confirmation step, affected users/assets and the fallback path. Test whether unsupported advice can create an order, whether cancellation stops in-flight writes and whether the operator can reconstruct why an order was proposed. Passing language-quality tests alone cannot answer these questions.
The product owner confirms what the workflow is intended to do. Platform and operations owners demonstrate the controls. Legal/compliance review the factual change and the relevant responsibility and conformity route. Only a scoped decision plus passing technical gates can authorise the candidate under this proposed policy. If review limits use to draft-only mode, enforce that limit in permissions rather than a warning paragraph.
A change initiated by a harm signal should retain its link to the post-market risk feedback loop. Urgency does not erase the assessment baseline. Use a reviewed emergency-change process with explicit authority, scope and retrospective evidence duties; do not let an “incident fix” label become a permanent bypass.
Test the gate before making it mandatory
Check missing evidence: remove the original purpose document and verify that the result is evidence-incomplete, never unchanged by default.
Check cumulative drift: submit a candidate through several individually small edits and verify comparison against both the assessed baseline and the immediately previous release.
Check stale approval: approve one dossier revision, change a tool permission and replay the old approval. Promotion must fail because the candidate binding differs.
Check supplier uncertainty: record a missing change-scope statement or unavailable test access. The system must route the gap to an owner without inventing a provider assertion.
Check separation of decisions: passing regression tests must not close legal review, and a legal review record must not override a failed safety or security test.
Check downstream reconciliation: once a reviewed purpose, entity or lifecycle change is approved, trigger the registration and deployment-inventory handoff where the separately reviewed route requires it. Do not automatically create a new regulatory entry for every release.
Keep the review cost visible
Too many automatic escalations create a sign-off queue that teams bypass; too few hide purpose changes behind apparently routine model maintenance. Use reviewer-approved factual templates and impact mappings to narrow repeated work, while retaining an explicit unknown path. A language model may suggest a document diff, but source passages and accountable confirmation must remain visible.
Measure evidence-incomplete age, repeated missing fields, reopened decisions and review effort. These are process metrics, not a compliance score. Keep the gate at promotion and relevant change boundaries rather than retrieving legal documents on every inference call. That reduces runtime coupling but leaves a monitoring obligation in your operating design: detect changed supplier terms, interface behaviour and scope assumptions between reviews.
Start with one pending change and reconstruct its baseline, candidate and missing decisions. I help platform and compliance teams implement the evidence schema, testable routing and release binding; qualified counsel owns the legal assessment. The useful outcome is a reviewer who can explain the proposed change and a deployment pipeline that cannot silently substitute a different one.
