Every high-risk AI system goes through changes after it lands on the market. Vendors release new model versions. Prompt templates get tuned. RAG corpora ingest new sources. Agents add tools. Thresholds get recalibrated. The question that hangs over every change is the one regulators ask first: did this change require Article 43(4) re-conformity assessment, or did it sit safely inside the Annex IV §2(f) pre-determined-change carve-out? Get the answer wrong in one direction and you have shipped a substantial modification without re-assessment, a textbook Article 99(3) finding at €15M / 3% of global turnover. Get the answer wrong in the other direction and you have throttled the engineering team with notified-body recall on changes that never needed it. This lesson is the Article 3(23) definition broken open, the twelve-change playbook walked one by one, the §2(f) carve-out's actual scope, and the change-control gate design that keeps an AI Officer defensible across a 200-system portfolio.

Article 3(23) - The Substantial Modification Definition

The definition in Article 3(23) is precise enough to litigate against. A "substantial modification" is "a change to the AI system following its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment carried out by the provider and as a result of which the compliance of the AI system with the requirements set out in Chapter III Section 2 is affected or results in a modification to the intended purpose for which the AI system has been assessed."

Three elements compound:

• Post-market change. The system has already been placed on the market or put into service. Changes before market-placement are absorbed in the initial conformity assessment under Articles 16(f) and 43.
• Not foreseen or planned in the initial conformity assessment. If the change was pre-described in the Annex IV technical file under the §2(f) carve-out, it is foreseen. If it was not, it is unforeseen.
• Affects Chapter III Section 2 compliance OR modifies the intended purpose. Chapter III Section 2 covers Articles 8 through 15: risk management system, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, accuracy / robustness / cybersecurity. If the change affects any of these, the modification is substantial. If it modifies the intended purpose for which the system was assessed, the modification is substantial.

The "or" between Chapter III Section 2 compliance and intended-purpose modification is disjunctive. Either trigger is sufficient. The combined construction is broader than many engineering teams realize at first read.

Article 43(4) is the operational consequence: a substantial modification requires the provider to perform a new conformity assessment in accordance with the procedure of Article 43. The provider cannot escape this through quality-management-system entries alone; the conformity assessment itself must be re-run on the modified system. Where the original assessment involved a notified body under Annex VII, the notified body is re-engaged. Where it ran under Annex VI internal control, internal control is re-performed.

Article 25(1)(b) is the second consequence: where a downstream actor (typically a deployer) makes the substantial modification, the downstream actor becomes the provider of the modified system under Article 25 and inherits the full Article 16 obligation set. The original provider is notified under Article 25(2) and cooperates by providing access to the technical documentation. This is the cross-walk to lesson 008's actor-classification framework: substantial modification is where downstream parties most commonly cross from deployer to provider.

Annex IV §2(f) - The Pre-Determined-Change Carve-Out

Annex IV is the high-risk-system technical documentation specification. Its second main section covers the AI system itself, and §2(f) addresses continuously learning and self-updating systems specifically. The text requires the technical file to describe "the pre-determined changes to the high-risk AI system and its performance, together with all the relevant information related to the technical solutions adopted to ensure continuous compliance of the high-risk AI system with the relevant requirements set out in Chapter III Section 2 of this Regulation."

This is the carve-out. Changes that are pre-described in the technical file as foreseen and planned at the time of the initial conformity assessment do NOT trigger Article 43(4) re-assessment when they occur. The mechanism turns on three documentation requirements:

• What changes may occur. The technical file must describe the categories of change that the system will undergo: model retraining cadences, vector-store corpus updates, prompt-template adjustments within parameter bounds, threshold recalibration within calibrated ranges, etc.
• Bounds within which they may occur. The technical file must specify the parameter envelopes, retraining cadence (e.g., monthly), data-source categories (same-domain corpora only), prompt adjustment ranges (no new tool grants), threshold drift ranges (e.g., ±3 percentage points from calibrated baseline).
• Monitoring mechanisms. The technical file must describe how continuous compliance with Chapter III Section 2 is maintained, drift monitoring on accuracy / robustness; bias monitoring on fairness; output sampling on transparency obligations; logging discipline under Article 12.

The §2(f) carve-out is powerful but not unlimited. It cannot stretch to changes that materially shift behavior or risk profile. A claim that "any prompt change is within scope because the technical file says prompts can change" fails because the §2(f) bounds must be specific. A claim that "any retraining is within scope because the technical file says retraining can occur" fails for the same reason: the data-source categories, the cadence, the monitoring all have to be specified at the level that would let a regulator verify pre-determination.

Practical 2026 patterns: routine monthly retraining on same-domain data within accuracy-drift bounds, covered by §2(f); RAG corpus refresh with same-domain documents within volume bounds, covered by §2(f); prompt-template wording adjustments within behavior-equivalence bounds, covered by §2(f); threshold recalibration within a documented ±3pp envelope tied to a calibration KPI, covered by §2(f); security patches for prompt-injection mitigations and equivalent maintenance, typically covered by §2(f) as security updates.

Practical exclusions: foundation-model swap (new architecture, new behavior), not §2(f); adding a new tool to an agent, not §2(f) (changes blast radius); cross-domain data-source ingestion, not §2(f); intended-purpose expansion, not §2(f); language addition, not §2(f) (new affected-person population). For each excluded category, Article 43(4) re-assessment is the path.

The Twelve-Changes Walkthrough - Decisions With Reasoning

The L3 practitioner needs the analytic reflex on the twelve canonical change categories. Each row resolves to one of three dispositions: pre-determined (covered by §2(f); log and proceed); minor (outside §2(f) but not affecting Chapter III Section 2 nor intended purpose; log and proceed); substantial (Article 43(4) triggered; re-conformity assessment owed).

Change 1 - Prompt Update

Disposition: depends. A minor wording change within the pre-determined-change scope (e.g., grammar polish, clarification of an existing instruction, formatting tweak) is pre-determined under §2(f) where the technical file describes prompt-template adjustment bounds. A new system prompt that introduces new behaviors (new instructions, new persona, new task scope) sits outside the bounds and is a substantial modification, the prompt change is the design change in a prompt-engineered system.

Test: does the change alter what the system does, what audiences it speaks to, or what guardrails it enforces? Yes → substantial. No → pre-determined.

Change 2 - Retraining

Disposition: depends. Routine retraining on same-domain data within the Annex IV §2(f) pre-described cadence and data-source envelope is pre-determined. Retraining on materially different data (new domain, new affected-person population, new task data) is a substantial modification: the model behavior, fairness profile, and accuracy distribution shift in ways that affect Chapter III Section 2.

Test: is the new training data within the documented data-source categories, volume, and domain scope? Yes → pre-determined. No → substantial.

Change 3 - New Tool Added to Agent

Disposition: typically substantial. Adding a new tool to an agent expands the tool surface, changes the blast radius (new actions the agent can take), and changes the risk profile (new failure modes, new attack vectors via OWASP LLM06 excessive agency and the OWASP Agentic top-10 goal-hijack class). Article 9 risk-management-system documentation must be refreshed; Article 13 transparency documentation refreshed; Article 14 human oversight implications re-evaluated.

Test: the answer is almost always yes, new tool = new blast radius. Article 43(4) re-assessment is the path. Engineering teams should expect to gate tool additions through the change-control review for high-risk agents.

Change 4 - New Data Source for RAG

Disposition: depends. A same-domain corpus update within the §2(f) data-source envelope (e.g., adding new product documentation to a product-support chatbot's retrieval index) is pre-determined. A new-domain source (e.g., adding legal-opinion documents to a customer-service RAG; adding medical literature to a finance assistant) is a substantial modification, the system's effective scope and the affected-person interactions change.

Test: does the new source fall within the documented domain scope and volume envelope of the original Annex IV technical file? Yes → pre-determined. No → substantial.

Change 5 - Foundation-Model Swap (e.g., Claude 3 → Claude 4)

Disposition: substantial. A foundation-model swap is one of the clearest substantial-modification cases. The model is the system's reasoning engine; swapping it means a new behavior distribution, a new accuracy profile, a new robustness profile, a new fairness profile, a new attack-surface profile (different jailbreak resistance, different prompt-injection susceptibility), and typically a new GPAI-provider relationship. Article 9 risk-management-system documentation refreshed; Article 10 data governance considerations re-evaluated for any fine-tuning data; Article 13 transparency documentation refreshed; Article 15 accuracy / robustness / cybersecurity evaluations re-run.

Test: the answer is always yes, different foundation model = different system. The §2(f) carve-out cannot reach foundation-model swaps because the swap is not a pre-determined change in any meaningful sense (the architecture, training process, and behavior of the new model are not foreseen at the time of the original assessment). Re-conformity assessment is owed.

Change 6 - Threshold Adjustment

Disposition: depends. Minor calibration within the §2(f) envelope (e.g., shifting a confidence threshold by 1pp to re-tune precision-recall trade-off) is pre-determined where the envelope is documented. A threshold change that materially shifts the decision distribution (e.g., 10pp threshold drop that doubles the population flagged by a hiring AI; threshold change that crosses a regulatory bright line like the EEOC four-fifths rule) is a substantial modification: the affected-person impact, fairness profile, and accuracy / robustness picture shift.

Test: does the threshold change cross the documented envelope, OR does it materially shift the decision distribution against the original Chapter III Section 2 evaluation? Yes → substantial. No → pre-determined.

Change 7 - Scope Expansion (e.g., HR Tool Extended to Credit Decisions)

Disposition: substantial, intended-purpose change. Scope expansion is the canonical Article 3(23) intended-purpose-modification trigger. The system was originally assessed for one purpose (HR screening, Annex III §4) and is now being used for another (credit decisions, Annex III §5(b)). The intended purpose has changed; the Chapter III Section 2 evaluation framework changes; and under Article 25(1)(c) the deployer that authorizes the expansion may become the provider of the high-risk system if the original system was minimal-risk.

Test: the answer is always yes for cross-Annex-III-category expansion. The path is full Article 43(4) re-assessment plus actor-classification refresh per lesson 008.

Change 8 - Language Addition (e.g., Adding Spanish to an English-Only Model)

Disposition: typically substantial. Language addition introduces a new affected-person population whose interactions with the system have not been evaluated. The accuracy distribution in the new language is unknown until evaluated. The fairness profile across the new linguistic group is unknown. The translation pathway (if any) introduces a new failure mode. The Article 13 transparency-to-deployers documentation must be updated to reflect the new supported language. The Article 15 accuracy / robustness evaluations must be re-run in the new language. The §2(f) carve-out cannot cover language addition because the new-language behavior is not pre-determined by training on the old language alone.

Test: nearly always yes. The only exception is a system designed and assessed from the start as multilingual with the new language explicitly in scope of the original assessment, which usually means the language addition is not actually new.

Change 9 - Latency Optimization (e.g., Caching, Batching)

Disposition: typically NOT substantial. Latency optimization that preserves the behavior of the system, output-equivalent caching, request batching, infrastructure-side acceleration, does not affect Chapter III Section 2 compliance and does not modify intended purpose. The optimization is a maintenance change; logs and ML-BoM update suffice. Where the optimization changes behavior (e.g., approximate caching that returns near-equivalent rather than identical outputs, batch-window decisions that affect time-to-decision in a high-stakes context), the analysis flips and the change becomes substantial.

Test: does the optimization change the system's outputs, decision latency in a way that affects affected-person experience, or behavior in any measurable way? No → not substantial. Yes → substantial (consider as a behavior change rather than an optimization).

Change 10 - Prompt-Injection Patch (Security Mitigation)

Disposition: typically NOT substantial. Security mitigations, input filters, output validators, guardrail-prompt updates that block known attack patterns, are typically pre-described in the §2(f) maintenance scope as security updates. The technical file should explicitly list "security patch updates for known prompt-injection patterns and equivalent guardrail tuning" as a foreseen maintenance category. With that documentation in place, a prompt-injection patch ships through change-control with logging only.

Test: is the change a security mitigation that does not modify the system's intended behavior on legitimate inputs? Yes → pre-determined / maintenance. No (e.g., the mitigation also restricts legitimate behaviors significantly) → substantial.

Change 11 - Evaluation Criteria Change

Disposition: depends. Changing the method of evaluation without changing behavior (e.g., adopting a new benchmark suite for the same KPIs; rotating the evaluator on the same test set) is not substantial. Changing evaluation criteria in ways that lead to different deployment decisions (e.g., relaxing acceptance thresholds, dropping a previously-required fairness metric, removing a previously-required jailbreak-resistance baseline) is substantial, the change effectively modifies the Chapter III Section 2 compliance evidence base.

Test: does the new evaluation regime lead to different go / no-go deployment decisions, or remove evidence required for the original conformity assessment? Yes → substantial. No → log and proceed.

Change 12 - UI Change

Disposition: typically NOT substantial. Presentation changes, color schemes, layout reflow, button-label tweaks, that do not change system behavior, do not change the Article 50 disclosure surface, and do not change the human-oversight pathway (Article 14) are not substantial. Where a UI change removes or alters Article 50(1) chatbot disclosure, Article 50(2) synthetic-content markings, Article 26(9) decision-affected-person notification surface, or Article 14 human-override controls, the change crosses into substantial territory because Chapter III Section 2 compliance evidence is affected.

Test: does the UI change affect Article 50 disclosure surfaces, Article 14 oversight pathways, Article 26(9) notifications, or Article 13 transparency-to-deployers presentation? Yes → substantial. No → log and proceed.

Change-Control Gate Design - The L3 Operating Pattern

The twelve-change playbook only works inside a change-control gate that consistently runs the analysis. The L3 practitioner designs the gate to handle every change with a defensible audit trail. The operating pattern in 2026:

Step 1 - Trigger detection. Trigger events include: vendor model-release notifications (GPAI providers' Annex XII updates; SaaS release notes); internal deployment plans (engineering's release-train approvals); security patches (security-team-issued mitigations); third-party data-source changes (RAG team's corpus refresh); customer-driven scope requests (product team's expansion proposals); operational tuning (data-science team's threshold adjustments). Each trigger source feeds the gate through a standardized intake form that captures the change category, scope, owner, target deployment date, and the change-control team's initial classification.

Step 2 - Routing to AI Officer for Article 43(4) analysis. Every change above a minimum threshold is routed to the AI Officer (or designated AI Governance Lead). The AI Officer runs the three-question analysis:

• Question 1 - Is the change within Annex IV §2(f) pre-determined scope? Pull the technical file. Compare the change against the documented pre-determined-change description (categories, bounds, monitoring mechanisms). If within bounds, the change is pre-determined.
• Question 2 - Does the change affect Chapter III Section 2 compliance? Walk Articles 8-15. Does the change affect the risk management system? Data governance? Technical documentation? Record-keeping? Transparency to deployers? Human oversight? Accuracy / robustness / cybersecurity? Yes on any → substantial.
• Question 3 - Does the change modify the intended purpose? Compare against the originally-assessed intended purpose. New use case? New affected-person population? New regulatory category? Yes on any → substantial; also triggers Article 25(1)(b) or 25(1)(c) actor-transfer analysis.

Step 3 - Decision: pre-determined / minor / substantial. The AI Officer's classification is documented in the change log with the reasoning. The three dispositions:

• Pre-determined, change ships through normal release with §2(f) monitoring; change log entry; no Article 43(4) action.
• Minor, change is outside §2(f) but not substantial; ships through normal release; change log entry; ML-BoM and model-card refresh as needed.
• Substantial, change is blocked from release pending Article 43(4) re-conformity assessment.

Step 4 - Substantial-modification path. When the disposition is substantial, the AI Officer triggers the re-conformity sequence:

• Refresh Annex IV technical file. Update Sections 1-9 to reflect the modified system. The §2(f) pre-determined-change description may also need updating if the change exposes a category the original §2(f) failed to anticipate.
• Run the Article 43 procedure. Annex VI internal control for non-biometrics Annex III systems; Annex VII Module H with notified body for biometrics under Annex III §1 and for systems where the provider has not applied harmonised standards. Notified body re-engagement follows the notified-body engagement playbook (lesson 052).
• Refresh the Article 47 declaration of conformity. The original declaration becomes obsolete; the modified system needs a new declaration signed by the AI Officer or authorized signatory.
• Refresh Article 71 EU database registration. The system registration in the EU database must reflect the modified system (lesson 054 covers this in detail).
• Refresh the model card and system card. Both internal model-card refresh (covering accuracy, robustness, fairness, intended use updates) and external system-card refresh (covering downstream-deployer documentation).
• Refresh the ML-BoM under CycloneDX 1.7. The modified system has a new ML-BoM that captures the change in components, weights, datasets, and dependencies.
• Coordinate with Article 25(2) cooperation. If the substantial modification is upstream-provider-driven (e.g., the GPAI provider has changed the base model), the cooperation framework with the upstream provider is activated. If the modification is downstream-driven, the downstream party that becomes the new provider must notify the original provider and exchange technical documentation.

Step 5 - Change-log documentation. Every change, pre-determined, minor, or substantial, gets a change-log entry with: change identifier; date; description; AI Officer classification; analysis reasoning; affected articles; downstream actions; sign-offs. The change log is the artifact the regulator inspects to evaluate change-control operating-effectiveness.

Step 6 - Coordination with adjacent processes. Change-control coordinates with: the incident-response process (where a change correlates with an incident pattern); the post-market monitoring process under Article 72 (where the change-related metrics are tracked); the notified-body engagement process (where re-engagement is needed); the procurement-contract process (where contractual change-control clauses must be invoked per lesson 008); the audit committee briefing cadence (where material change-control events are reported).

Cross-Walks - ISO 42001, NIST AI RMF, and the Model-Card Refresh

The Article 43(4) change-control gate aligns with ISO 42001 Annex A control A.6.4 (management of change) and NIST AI RMF Manage 2 (risks identified and prioritized are managed throughout the lifecycle) and Manage 4 (risk treatments, including response and recovery, are documented and monitored regularly). The mapping helps the AI Governance Lead present a single change-control story across the three frameworks at audit:

• EU AI Act Article 43(4) / Article 3(23) / Annex IV §2(f), change classification with substantial-modification trigger; pre-determined-change carve-out; conformity-assessment re-engagement.
• ISO 42001 A.6.4 management of change, documented change-control process; classification; impact assessment; authorization; review.
• NIST AI RMF Manage 2 + Manage 4, lifecycle risk management with change-driven re-evaluation; documented response actions; monitoring of change-related risks.
• Model card refresh cadence, every substantial change triggers model-card refresh; minor changes trigger change-log entries and selective updates; pre-determined changes feed the §2(f) monitoring evidence base.
• ML-BoM refresh under CycloneDX 1.7, every substantial change yields a new ML-BoM version; minor changes yield an ML-BoM diff entry; pre-determined changes yield a §2(f) monitoring entry.
• Article 72 post-market monitoring: change-control feeds the PMM evidence base; PMM signals (drift, fairness regressions, incident patterns) feed back into change triggers.
• Article 73 serious-incident reporting, where a change correlates with a serious incident, the change-control record is incident-evidence and may need to flow into the Article 73 reporting package.

Six Common Mistakes - Where Change-Control Programs Fail

Mistake 1 - No change-control gate at all. Engineering ships changes without classification analysis. Drift accumulates. The first regulator audit catches a substantial modification that was not re-assessed. The penalty exposure under Article 99(3) is €15M / 3% per failure. Remediation requires building the gate retroactively, classifying the backlog, and running re-conformity on the substantial modifications already in production.

Mistake 2 - Over-broad pre-determined-change carve-out. The Annex IV §2(f) section in the technical file is written so broadly that almost any change is claimed to be pre-determined ("the system may be retrained at any cadence on any data" / "prompts may be updated as needed"). The carve-out fails on regulator inspection because the bounds are not specific. Remediation requires rewriting §2(f) with category-specific cadence, data-source, parameter, and monitoring documentation that a regulator can verify.

Mistake 3 - Missing the language-addition trigger. The product team adds Spanish, French, German, and Mandarin support to a customer-service AI over six months without ever running the substantial-modification analysis. The expanded language coverage is treated as a feature rollout rather than a change to the system's affected-person population and Chapter III Section 2 evaluation surface. Remediation requires retroactive Article 43(4) re-assessment and a process change to route language additions through the change-control gate.

Mistake 4 - Missing the threshold-shift trigger. The data-science team adjusts a credit-scoring threshold to optimize a business KPI. The 8pp threshold change materially shifts the decision distribution but is treated as a routine tuning operation. The fairness profile shifts; the affected-person population at the margin doubles; the Chapter III Section 2 evaluation no longer reflects the deployed system. Remediation requires re-conformity, fairness re-evaluation, and a change to the threshold-management process to route material threshold shifts through the gate.

Mistake 5 - Siloed change-control from notified-body engagement. The change-control team classifies a change as substantial. The Annex IV refresh happens. But no one informs the notified body, and the notified-body re-engagement does not occur. The Article 47 declaration of conformity is refreshed without the underlying assessment having been re-run. Audit catches the gap. Remediation requires integrating change-control with the notified-body engagement playbook (lesson 052) so that substantial-modification disposition automatically triggers notified-body coordination where applicable.

Mistake 6 - Weak change-log documentation. The change log captures the change but not the reasoning, not the AI Officer's classification analysis, not the affected articles, not the downstream actions. At audit the program cannot show change-control operating-effectiveness because the evidence is too thin. Remediation requires upgrading the change-log template to require classification reasoning, article-by-article impact analysis, downstream action tracking, and sign-off attribution.

Key Takeaways

• Article 3(23) defines substantial modification with three compounding elements. Post-market change; not foreseen or planned in the initial conformity assessment; affects Chapter III Section 2 compliance OR modifies the intended purpose. The "or" is disjunctive; either trigger is sufficient.
• Article 43(4) is the operational consequence. Substantial modification requires a new conformity assessment under Article 43; the modified system needs a new Article 47 declaration and Article 71 EU database update.
• Article 25(1)(b) is the actor consequence. Where a downstream actor makes the substantial modification, they become the provider of the modified system with full Article 16 obligations.
• Annex IV §2(f) is the pre-determined-change carve-out. Continuously learning systems can pre-describe changes (categories, bounds, monitoring mechanisms). Pre-determined changes do NOT trigger Article 43(4) re-assessment.
• Twelve-change playbook resolves to three dispositions. Pre-determined (within §2(f) scope; log and proceed), minor (outside §2(f) but not substantial; log and proceed), substantial (Article 43(4) re-assessment owed).
• Foundation-model swap, new agent tool, scope expansion, language addition are typically substantial. The §2(f) carve-out cannot reach these. They materially shift behavior or scope.
• Latency optimization, prompt-injection patch, UI change are typically NOT substantial. Behavior-preserving changes; security mitigations; presentation tweaks. Always re-check that Article 50 disclosure and Article 14 oversight surfaces are unaffected.
• Prompt updates, retraining, RAG data sources, threshold adjustments, evaluation criteria depend on scope. Inside §2(f) bounds and behavior-equivalent = pre-determined; outside bounds or behavior-shifting = substantial.
• The change-control gate is the L3 operating pattern. Trigger detection → AI Officer analysis (three questions) → decision (pre-determined / minor / substantial) → substantial-modification re-conformity sequence → change-log documentation → coordination with adjacent processes.
• Cross-walks to ISO 42001 A.6.4 and NIST AI RMF Manage 2 + Manage 4 keep one change-control story across frameworks. The gate generates the evidence base for all three audit programs.
• Six common mistakes recur in 2026 programs. No gate at all; over-broad §2(f); missing language-addition trigger; missing threshold-shift trigger; siloed change-control from notified-body engagement; weak change-log documentation. Each carries a defined remediation pattern.