Substantial Modification Under the EU AI Act

A substantial modification is a post-market change to an AI system that either affects the system's compliance with the high-risk requirements or alters the intended purpose for which the system was originally assessed. The term is formally defined in Article 3 of Regulation (EU) 2024/1689 (point 23). Its practical weight is considerable: get this wrong and a company that started as a deployer can end the day as a provider, with the full Article 16 obligation stack to match.

The EU AI Act definition

Article 3 of Regulation (EU) 2024/1689 defines substantial modification as a change to an AI system after it has been placed on the market or put into service that satisfies two conditions: it was not foreseen or planned in the provider's initial conformity assessment, and it produces one of two outcomes — it affects the system's compliance with the high-risk requirements, or it results in a modification to the intended purpose for which the system was assessed.

Both triggers carry equal legal weight. The first is primarily technical: a change that degrades or reconfigures the system in ways that bear on the Article 9 risk management system, the Article 11 technical documentation, the Article 15 accuracy requirements, or the Article 14 human oversight measures. If the original conformity assessment's assumptions no longer hold, the modification is likely substantial.

The second trigger is broader and easier to stumble into. Intended purpose means the use for which the AI system is designed, including the specific context and conditions of use. A vendor tool redeployed for a materially different purpose can trip this trigger even if the underlying model weights are unchanged.

The "not foreseen or planned" qualifier is the key limiting condition. A provider who explicitly scoped future modifications into the original conformity assessment — documented the planned update pathway and maintained a QMS under Article 17 that covers it — has a defensible argument that changes within that scope are not substantial. The absence of that documentation is what turns routine product evolution into a compliance event.

Why it matters: the Article 25 role-shift

Article 25 of Regulation (EU) 2024/1689 governs responsibilities along the AI value chain. Its central rule is this: a deployer, distributor, importer, or other third party that substantially modifies a high-risk AI system is treated as a provider for that system and takes on the provider's obligations under Article 16.

The provider obligation stack under Article 16 is not light. It includes establishing a quality management system (Article 17), preparing technical documentation to the Annex IV standard (Article 11), conducting an Article 43 conformity assessment, drawing up the EU Declaration of Conformity under Article 47, affixing CE marking under Article 48, registering the system in the EU database under Article 49, and maintaining post-market monitoring under Article 72 with serious-incident reporting under Article 73. A deployer who fine-tunes a vendor model, extends its scope, or rebrands it without recognising the role-shift can suddenly owe all of this.

Article 25 also catches two further scenarios alongside substantial modification. Placing your own name or trademark on a high-risk AI system that you did not originally develop also converts you to a provider. So does modifying an AI system's intended purpose such that it now falls into a high-risk category under Article 6 and Annex III — even if the system was originally minimal- or limited-risk and no physical change to the model was made.

The conformity assessment consequence flows directly from Article 43. Providers of high-risk AI systems in most Annex III categories must carry out an internal conformity assessment under Annex VI before placing the system on the market or putting it into service. For systems in Annex III point 1 (biometric identification and categorisation), the Annex VII notified-body route generally applies. A substantial modification effectively resets the clock: the previous conformity assessment no longer covers the changed system, and a fresh assessment is required before the modified system is deployed.

Examples

Understanding where the line falls is easier through concrete cases.

Fine-tuning a model on proprietary data. A recruitment software company buys access to a general-purpose hiring model, assessed and documented by the original vendor as covering structured candidate screening. The company fine-tunes it on its own hiring outcomes database. This is a candidate: the modification was not planned in the vendor's assessment, and it changes the model's behaviour in a use that sits squarely in Annex III point 4 (employment, worker management, access to self-employment). If it is substantial, the company steps into the provider role under Article 25.

Changing an AI system's intended purpose. A creditworthiness model placed on the market for lender use — a high-risk use under Annex III point 5(b) — is licensed by a data analytics firm and repurposed to score suppliers for procurement risk. The underlying model may be identical, but the intended purpose has shifted, engaging the Article 3 trigger and requiring an assessment under Article 25.

Rebranding a vendor tool. A health IT integrator takes a clinical-decision-support module, adds its own branding, and sells it under its own product name. No modification to the model was made — but Article 25 still treats the integrator as a provider because it placed its own name on the system. The Article 16 stack follows.

Changes that are not substantial. Routine bug-fix patches that were anticipated in the provider's original QMS and documented as within-scope updates do not trigger substantial modification. Performance optimisations that improve accuracy without changing the intended purpose are also unlikely to be substantial — provided they were planned for. The test is whether the original conformity assessment still accurately covers the system as deployed today.

How to manage the risk

Most organisations changing or integrating AI systems do not have a formal review process that asks the Article 3 question before deployment. The modification happens — a fine-tune here, a scope extension there, a vendor component under your own branding — and the compliance status shifts without anyone noticing.

Document changes against the definition before deploying. A short written assessment each time: does this change the intended purpose? Does it affect compliance with the high-risk requirements in Articles 9–15? Was it foreseen in the original conformity assessment? Three questions, recorded with the reasoning. This creates both an audit trail and an early-warning mechanism.

Brief your procurement and integration teams on Article 25. Engineers extending vendor tools are making compliance decisions without knowing it. Legal and compliance needs to be upstream of deployment, not reviewing after the fact.

For high-risk AI systems, maintain a change log tied to the Article 11 technical documentation. Every modification touching model architecture, training data, intended purpose, or operating conditions should be assessed and marked as either within scope of the existing conformity assessment or triggering a fresh one.

Confir's rule-based classification engine encodes the Article 25 role-determination logic deterministically: the same intake answers will always produce the same role finding. If a modification is assessed as substantial, Confir re-classifies the affected system and flags the Article 16 obligations that now apply — the rule that fired is visible and auditable.

Frequently Asked Questions

Does substantial modification only apply to high-risk AI systems?

The Article 3 definition of substantial modification applies to AI systems generally, but the legal consequences under Article 25 that matter most — the role-shift to provider and the fresh conformity assessment requirement under Article 43 — attach specifically to high-risk AI systems. If the modified system is not high-risk, the definition may still be relevant for other purposes (such as updating technical documentation or the EU Declaration of Conformity), but the provider-role conversion is the principal concern for Annex III systems.

If I fine-tune a vendor model but the vendor documented the fine-tuning pathway, am I still a provider?

Not necessarily. If the vendor's conformity assessment explicitly anticipated the fine-tuning — described the permitted modification pathway and the QMS procedures covering it — then fine-tuning within those parameters is arguably not a "not foreseen or planned" change. Get that scoping confirmed in writing and verify your specific fine-tuning stays within it. If it goes beyond the documented scope, the analysis shifts.

Can the deployer and the original provider share the conformity assessment work?

There is no formal shared-assessment mechanism in the Regulation. The original provider's technical documentation can serve as a useful base, but the company carrying out the substantial modification is responsible for ensuring the full assessment covers the modified system. Contractual arrangements may allocate documentation duties between the parties, but they do not shift the legal responsibility under Article 25.

Does changing a system's interface or user experience count as substantial modification?

A pure UI change that does not affect the AI system's behaviour, outputs, intended purpose, or the conditions of use described in the conformity assessment is unlikely to be substantial. However, if the interface change effectively expands the scope of use — for example, making the system accessible to a new category of users or use case not covered in the original assessment — the intended-purpose trigger may be engaged. The assessment is always fact-specific.

When does Article 43 require a notified body for the fresh conformity assessment?

For most Annex III categories, the conformity assessment for a substantially modified system follows the Annex VI internal self-assessment procedure, as it would for the original system. The Annex VII notified-body route applies primarily to AI systems falling under Annex III point 1 (remote biometric identification and categorisation systems), where harmonised standards are not applied. For all other Annex III categories, an internal assessment by the new provider is the standard procedure.

What penalty applies if a company fails to carry out a fresh conformity assessment after a substantial modification?

Failing to conduct a required conformity assessment is non-compliance with the high-risk obligations. Under Article 99(4), the maximum fine is €15,000,000 or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For SMEs and start-ups, Article 99(6) caps the fine at the lower of the percentage and the fixed amount.

Related terms

• Provider vs deployer under the EU AI Act
• Provider obligations: the Article 16 stack
• Deployer obligations under the EU AI Act
• Conformity assessment under Article 43
• EU AI Act conformity assessment: the full process
• Intended purpose