Article 25(1)(b) substantial modification:
when a deployer becomes a provider
Article 25(1) of the EU AI Act has three triggers that turn a deployer, distributor, importer, or third party into a providerwith the full set of Article 16 obligations. Substantial modification is the trigger most often misread in enterprise SaaS contexts where customers fine-tune, wrap, or extend the underlying model. Here’s where the line sits and what crossing it actually means.
The one thing to understand
Substantial modification under Article 3(23) is “a change to an AI system after its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment.” The test is anchored to the conformity assessment scope, not to magnitude. A small change outside the initial assessment scope can be substantial. A large change inside the assessment scope is not.
The three triggers under Article 25(1)
Each trigger independently makes a non-provider into a provider for Regulation purposes.
Rebranding
You put your name or trademark on a high risk AI system that has already been placed on the market or put into service. Reselling under your own brand makes you the provider for compliance purposes, even if you did not develop or modify the system.
Substantial modification
You make a substantial modification to a high risk AI system that has already been placed on the market or put into service, in such a way that it remains a high risk AI system. The key term is "substantial modification" (Article 3(23)): a change that is not foreseen or planned in the initial conformity assessment.
Modifying intended purpose
You modify the intended purpose of an AI system, including a general purpose AI system, that was not initially classified as high risk, in such a way that it becomes a high risk AI system. This trigger applies even when no technical modification is made: changing the documented use case alone can flip classification.
Where the substantial modification line sits
Article 3(23) anchors the definition to the initial conformity assessment scope. Changes outside that scope are substantial; changes within it are not.
Likely crosses the line
- •Re-training the model on a significantly different dataset
- •Changing the model architecture or replacing core components
- •Altering decision thresholds in ways that affect risk profile or accuracy
- •Adding new use cases the original provider didn't anticipate
- •Modifying the system to extend it into a new Annex III category
Likely does NOT cross the line
- •Routine security patches that don't change capability
- •UI adjustments that don't change the system's outputs
- •Parameter tuning within the documented ranges in the technical file
- •Bug fixes for known issues already in the provider's known-issues list
- •Configuration changes explicitly foreseen in the instructions for use
None of these are absolute rules. The honest answer for borderline cases is: read the provider’s technical file and instructions for use carefully, and where the change is not clearly foreseen, treat it as substantial unless a defensible legal opinion says otherwise. The cost of guessing wrong (you become the provider and inherit Article 16 obligations without being prepared) is higher than the cost of one classification review.
What you inherit when you cross the line
Article 16 lists the obligations attaching to providers of high risk AI systems. Cross the substantial modification line and these all attach to you for the modified system.
Risk management system (Article 9)
Establish and maintain a risk management system spanning the entire lifecycle of the high risk AI system.
Data and data governance (Article 10)
Ensure training, validation, and testing data meet quality criteria. Manage representative, relevant, and bias-mitigated datasets.
Technical documentation (Article 11)
Draw up and keep up-to-date technical documentation per Annex IV before placing on the market.
Record-keeping and logs (Article 12)
Design the system to allow automatic recording of logs covering operation, identification of substantial modifications, and risk monitoring.
Transparency and information to deployers (Article 13)
Provide instructions for use that are clear, comprehensive, and sufficient for deployers to comply with their own Article 26 obligations.
Human oversight design (Article 14)
Design and develop the system so that it can be effectively overseen by natural persons.
Accuracy, robustness, cybersecurity (Article 15)
Achieve appropriate levels of accuracy, robustness, and cybersecurity throughout the lifecycle.
Quality management system (Article 17)
Put in place a quality management system to ensure compliance with the Regulation.
Conformity assessment and CE marking
Run the applicable conformity assessment procedure under Article 43, draw up the EU declaration of conformity, affix the CE marking, and register the system in the EU database.
Article 25(1) also makes clear: where the substantial modification trigger fires, the initial provider “shall no longer be considered to be a provider of that specific AI system for the purposes of this Regulation.” The compliance baton transfers to you for that modified system. Your existing Article 26 deployer obligations still attach (see August 2: what attaches for deployers), but the provider stack lands on top.
The cooperation duty (Article 25(2))
Article 25(2) requires the initial provider to “closely cooperate with new providers and shall make available the necessary information and provide the reasonably expected technical access and other assistance” needed for the new provider to comply with the Regulation.
The cooperation duty has an important carve out: it does not apply if the initial provider “clearly specified that its AI system is not to be changed into a high-risk AI system.” In practice this means initial providers can disclaim cooperation obligations through clear contractual language stating the system is not intended to be modified into high risk territory. If you are the customer and you modify anyway, the provider has no statutory duty to help you comply, although your existing contract may still require it.
For enterprise SaaS deployments where modification scope is genuinely uncertain (think model fine-tuning, custom guardrails, retrieval augmentation, multi-system orchestration), negotiate the cooperation duty explicitly into the contract rather than relying on the statutory baseline.
Written agreements under Article 25(4)
Article 25(4) requires that, for high risk AI systems, the provider and any third party supplying tools, services, components, or processes used or integrated into the high risk system shall, by written agreement, specify the necessary information, capabilities, technical access, and other assistance based on the generally acknowledged state of the art.
Two practical points. First, free and open-source tools are excluded from this written agreement requirement, which is why some open source AI ecosystems are simpler to integrate from a contracting standpoint. Second, the AI Office may develop and recommend voluntary contract terms, which when published will become the practical baseline for these agreements.
Practical implementation
A modification governance programme for organisations running high risk AI systems they did not develop themselves.
Map your current modification practice
For each high risk AI system you deploy, document what changes you currently make: re-training cadence, fine-tuning data, threshold adjustments, architecture variations. Confirm each against the provider's instructions for use to identify which are foreseen and which are not.
Get explicit "no high risk modification" wording from your providers
Article 25(2) carve-out: the initial provider is not liable for your modifications if it "clearly specified that its AI system is not to be changed into a high-risk AI system." Negotiate this language into your contracts where appropriate. This shifts the analysis onto your shoulders if you do modify, but it also removes ambiguity about provider cooperation duties.
Negotiate written agreements under Article 25(4)
Where you are a high risk provider sourcing components, tools, or services from third parties, written agreements must specify the information, capabilities, technical access, and assistance needed for your compliance. Open-source tools are excluded. The AI Office may publish voluntary contract terms.
Run a modification approval gate
Stand up an internal approval gate for any change to a high risk AI system. The gate asks: is this modification foreseen in the technical file or instructions for use? If no, route to legal/compliance to assess whether it crosses Article 25(1)(b).
Document the analysis
For any modification that lands close to the substantial modification line, document the analysis: what changed, why it does or doesn't fall within foreseen modifications, what risk classification analysis was done. This becomes the audit trail if a supervisory authority asks.
Plan for provider transitions
If you do cross the substantial modification line, you become the provider for that modified system. The original provider "shall no longer be considered to be a provider of that specific AI system for the purposes of this Regulation." Your team inherits Article 16 obligations end to end. Have a runbook ready for this transition.
Where this matters most
Article 25(1)(b) lands hardest in enterprise SaaS contexts where customers fine-tune, wrap, or extend a vendor’s AI system on their own data and deploy it in Annex III use cases. Examples: a customer building an agent on top of a process intelligence platform; a hospital fine-tuning a radiology classifier on its own scans; a bank wrapping a credit scoring API with its own decision logic; a recruiting platform configuring a job matching algorithm with its own scoring weights.
In each of these patterns, the customer’s configuration sits in a grey zone between “intended use as documented” (no provider status change) and “substantial modification” (provider status change). The vendor’s instructions for use and conformity assessment scope are the controlling documents. If those documents do not contemplate the customer’s configuration, the customer is on the substantial modification side of the line and inherits Article 16 obligations for that deployment.
For deployers running these patterns, the practical posture is: assume substantial modification status by default, run a formal classification analysis, and seek explicit contractual language from the vendor either expanding the instructions for use to cover your configuration (so it’s foreseen) or invoking the Article 25(2) carve out (so the vendor disclaims downstream cooperation).
Run an Article 25 analysis on your AI configuration
ActComply analyses where your specific deployment pattern sits against the substantial modification line. Send us one integration pattern and we return a written read on which side of Article 25(1)(b) it lands, which Article 16 obligations attach if it crosses, and the contractual language to negotiate with your vendor.
Assess your AI systems free →No credit card required
Related guides
More EU AI Act compliance pieces from ActComply.
EU AI Act Compliance Checklist
All 27 obligations across high risk, limited risk, general provider, and GPAI categories.
EU AI Act Risk Classification
Walk through the four risk tiers and how to classify your AI system.
High Risk AI Systems
Annex III categories and what counts as high risk under the AI Act.
Omnibus Update
How the May 2026 provisional agreement shifts high risk deadlines, and what stays unchanged.
Article 26 Deployer Obligations
All twelve Article 26 obligations attaching to every deployer of a high risk system on August 2.
Article 27 FRIA Scope
Who the Fundamental Rights Impact Assessment actually applies to, and what fills the gap when it doesn't.
Article 27 FRIA Template
Working one page template covering the six Article 27(1) inputs, with PDF download.
Article 50 Transparency Obligations
Provider and deployer obligations across chatbots, generative content, emotion recognition, and deep fakes.
GPAI Provider Obligations
Article 53 + 55 obligations for general purpose AI model providers, plus the 10 July 2025 Code of Practice.