When does a change become 'substantial modification' under the EU AI Act?

“Substantial modification” is one of the most consequential terms in the EU AI Act. When a high-risk AI system undergoes one, Article 43(4) triggers a new conformity assessment. Get the boundary wrong and you ship a system that’s no longer compliant with its declared posture — a Tier 2 fineable offence. Get it right and your retraining cadence stays manageable.

What Article 3(23) actually says

Article 3(23) defines substantial modification as:

a change to the AI system after 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 conditions, all of which must be true:

1. A change to the system
2. Not foreseen in the initial conformity assessment
3. Either affects Chapter III Section 2 compliance (the high-risk requirements) OR modifies the intended purpose

The “not foreseen” clause is the practical key. If your initial assessment documented “we routinely retrain quarterly within these performance bounds,” then routine retraining within those bounds is foreseen — not a substantial modification.

What is and isn’t substantial — practical examples

Substantial modifications (require new assessment)

• Changing the intended purpose. “Was for HR candidate scoring, now repurposed for promotion decisions” — new use case, new bias profile, new risks, new assessment.
• Changing the data the system was trained on in a way that materially affects accuracy. Switching from European HR data to global HR data without updating the bias evaluation. Going from English-only training corpus to multilingual without re-validating performance per language.
• Adding new categories of affected persons. “Was used only for adults, now also assessing minors.”
• Changing the model architecture in a way that affects performance properties. Swapping a calibrated probabilistic model for a generative model.
• Materially changing input or output formats that affect how a deployer can integrate the system.
• Removing or significantly weakening human-oversight features.

Not substantial modifications

• Routine retraining within the documented evaluation envelope. Quarterly retrain, performance stays within published bounds, no new data categories.
• Bug fixes that don’t change behavioural properties.
• UI / UX redesigns that don’t change what the system does.
• Infrastructure migrations (changing cloud provider, scaling up compute).
• Performance optimisations that don’t change outputs.
• Adding new languages if the additional languages were foreseen in the initial assessment.

Borderline cases

• Adding a new model version (fine-tuning to a new base model). If the new model’s behavioural properties match the documented profile, not substantial. If the new model is materially different in accuracy or bias characteristics, substantial.
• Lowering thresholds. Changing a confidence threshold from 0.8 to 0.7 — if the foreseen monitoring envelope covered both, not substantial. If 0.7 wasn’t foreseen, it is.
• Adding a new feature flag. If the feature changes intended use, substantial. If it’s a UI option that doesn’t change AI outputs, not.

The “foreseen in the initial assessment” trick

The cleanest way to keep routine changes out of “substantial” territory is to explicitly foresee them in your initial assessment documentation.

What to write into your Annex IV technical documentation upfront:

• “The system is retrained monthly. Retraining within these performance bounds (accuracy ≥ X, fairness ≥ Y) does not constitute substantial modification.”
• “The system supports the following languages today: EN, DE, FR. Addition of further EU languages within the same family does not constitute substantial modification provided per-language accuracy meets the same bounds.”
• “The system’s confidence threshold can be adjusted between 0.6 and 0.9 by the deployer. Adjustments within this range are foreseen.”

Document the envelope. Operate within it. You’re not substantially modifying — you’re operating within the assessed parameters.

If you blow the envelope (model accuracy drops below the bound, new language fails the fairness check, deployer pushes threshold below 0.6), that’s the trigger for a fresh assessment.

The deployer side — Article 25(1) and 25(4)

Article 25 codifies an important rule: a deployer who modifies a high-risk AI system in certain ways becomes a provider with respect to that modified system. Modifications that trigger this:

• Putting one’s own name or trademark on a high-risk system already placed on the market
• Making a substantial modification to the system
• Modifying the intended purpose so the system now falls in a different Annex III use case

For SaaS deployers buying high-risk AI from vendors, the practical advice: don’t customise the model itself. Fine-tuning, retraining on customer data, or building your own classifier on top of the vendor’s API can flip you into provider status without you intending to.

This is one of the most common AI Act traps. A buyer thinks they’re a deployer (light Article 26 obligations); they “customise” the AI; they’re now also a provider (full Articles 9–17 obligations).

What documentation a re-assessment requires

When a substantial modification triggers a new assessment, you don’t redo the whole technical documentation. You update the affected sections and re-execute the assessment for those sections:

• Update Annex IV section 2 (system description) with the modification
• Re-evaluate risk per Article 9 in light of the change
• Update data governance documentation if data changed
• Re-test for accuracy and bias per Article 15
• Update the declaration of conformity with the new date
• Update the EU database entry per Article 49(2)

If the original assessment was internal control (Annex VI), the re-assessment is also internal. If the original was third-party (Annex VII), the notified body may need to be involved for the re-assessment too — depending on what changed.

Practical advice — design for “foreseen modifications”

For SaaS providers running high-risk AI, the cheapest insurance is a generous initial assessment envelope:

• Document a wide-but-bounded retraining cadence
• Document an evaluation envelope (accuracy, fairness, robustness) with realistic bounds
• Document the supported deployment configurations (thresholds, languages, customer profiles)
• Document the maintenance and update process — explicitly call out routine updates as foreseen

This keeps day-to-day engineering inside the envelope. Re-assessment is reserved for actual material changes — once or twice a year, not every sprint.

Recordkeeping — the missing piece

Article 12 already requires logs. For substantial-modification governance, add:

• A changelog of every meaningful system change
• A flag per change: foreseen / borderline / substantial
• Reviewer name and timestamp on each flag
• Linkback to the relevant assessment documentation

The reviewer notes layer of Maditon is built for this. When you make a change, you record the call. When a supervisory authority asks “show me your modification governance,” you have the audit trail.