EU AI Act Substantial Modification: When an Update Turns Your Deployer Into a Provider
Article 25 of the EU AI Act says a deployer who substantially modifies a high-risk AI system becomes a provider for that modified system. The provider obligations are heavier than the deployer obligations. Most enterprise teams discover this rule after they have fine-tuned a model, added a retrieval layer, or changed the intended purpose. This piece walks through what the regulation defines as substantial modification, the three updates most likely to trigger it, and the records you need to track every change at the AI request boundary.
Article 25 of the EU AI Act sets up the rule that any deployer who substantially modifies a high-risk AI system becomes a provider for that modified system. The provider obligations are heavier than the deployer obligations: conformity assessment, technical documentation under Article 11, post-market monitoring, and registration in the EU database. The definition of "substantial modification" sits in Article 3(23) and covers changes to intended purpose or changes that affect compliance with high-risk requirements. Most enterprise teams discover this rule after they have already done one of the three things that trigger it.
The August 2, 2026 enforcement date for high-risk systems is the closest deadline. Past that point, an unrecorded substantial modification is a provider obligation in default.
I want to walk through what the regulation defines as substantial modification, the three update patterns most likely to trigger it, and the records you need to maintain at the AI request boundary to defend against the provider-vs-deployer characterization.
Mandate
Article 25 sits in Chapter III of the AI Act, which covers high-risk systems. The general rule is that the provider holds the heavy obligations (conformity assessment, documentation, registration). The deployer holds the lighter obligations (deployment context, human oversight, records under Article 26). Article 25 reroutes the heavy obligations to the deployer in three scenarios.
Scenario 1: Putting your name on the system
A deployer who puts its trademark on a high-risk AI system becomes a provider for that system. This is the white-labeling case. If an internal banking platform ships under the bank's brand and embeds a third-party fraud-scoring model, the bank is the provider for the high-risk fraud-scoring deployment regardless of who built the underlying model.
Scenario 2: Substantial modification
A deployer who substantially modifies a high-risk AI system already on the market becomes a provider for the modified system. The definition of substantial modification under Article 3(23) is "a change to the AI system which is not foreseen or planned in the initial conformity assessment 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 of this Regulation is affected or results in a modification to the intended purpose for which the AI system has been assessed."
The two triggers inside that definition are: changes that affect compliance with high-risk requirements (Articles 8-15), and changes to intended purpose.
Scenario 3: Modifying the intended purpose
A deployer who modifies the intended purpose of an AI system not originally classified as high-risk, such that the system now becomes high-risk under Annex III, becomes the provider of that high-risk system. The canonical example: a general-purpose summarization model originally deployed for customer-service ticket triage gets repointed to screen job applicants. The new purpose puts the system in Annex III scope and the deploying organization is now the provider.
What the heavier obligations actually require
If you become a provider under Article 25, you inherit:
- Conformity assessment under Article 43
- Technical documentation under Article 11 and Annex IV
- Quality management system under Article 17
- Registration in the EU database under Article 71
- Post-market monitoring under Article 72
- Reporting of serious incidents under Article 73
Those are the obligations the original provider took on at the time of placing the system on the market. The deployer who triggers Article 25 inherits them retroactively for the modified system.
Compliance gap
Three update patterns trigger Article 25 in most enterprise deployments. None of them looks like a substantial modification from the engineering side until the regulator asks for the documentation.
Fine-tuning a foundation model on internal data
A deployer who fine-tunes a general-purpose model on internal data and deploys the fine-tuned system into a high-risk use case has changed the system in ways the original provider's conformity assessment did not foresee. Whether the fine-tune counts as substantial under Article 3(23) turns on whether it affects compliance with Section 2 requirements: accuracy, resilience, cybersecurity (Article 15), data and data governance (Article 10), risk management (Article 9). In practice, a fine-tune almost always touches at least one of these. The deployer has become a provider.
Adding a retrieval layer to a procured system
A retrieval-augmented generation system bolted onto a procured chatbot changes the data the model sees at inference. The original provider's data-governance documentation does not cover the retrieval index, its update cadence, its source data lineage, or its access controls. If the retrieval system feeds a high-risk use case, the modification likely triggers Article 25. The deployer is now a provider with retroactive documentation obligations for the retrieval layer.
Changing the intended purpose without retraining
This is the cheapest modification to make and the one most likely to slip through. A model originally deployed for one purpose gets repointed to another by changing the system prompt or the upstream caller. No retraining happens. No version number changes. The intended purpose in the documentation still reflects the original use. If the new purpose puts the system in Annex III, the deployer is the provider for the new high-risk deployment.
Mandate vs. Compliance
The text of Article 25 reads at one level of abstraction. The infrastructure to track which changes count as substantial operates at the AI request boundary.
The disclosure test
When the AI Office or a national competent authority opens an inquiry, the deployer must produce the version history of the system, the dates and natures of changes, the conformity assessment status at each version, and the basis for the deployer's characterization of itself as deployer rather than provider. Most enterprises can produce the application-side changelog. Few can produce the prompt-policy history at per-request granularity that shows what the deployer actually did with the model on production traffic.
Records that survive the inquiry
A defensible position under Article 25 needs three artifacts. A version-stamped policy at the AI request boundary that records every change to system prompt, retrieval data sources, model selection, and intended purpose. A per-decision audit record that ties each production inference to the policy version in effect at that moment. A change log that demonstrates which modifications were foreseen by the original provider's conformity assessment and which were not.
The first artifact lives at the gateway, not the application. The second is the Article 12 record at per-decision granularity. The third is operational documentation that ties policy versions back to procurement records.
Compliance gap
Most deployers have application-side version control. Few have policy-version control at the AI request boundary. The result is that when the inquiry comes, the deployer can produce git history for application code but not the prompt-policy state at the moment an Annex III-relevant decision was made. That gap is the structural reason Article 25 catches enterprises off guard.
DeepInspect
This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between any application and any LLM. Every policy in effect at the gateway carries a version. Every per-decision record references the policy version that governed the decision. The version history is independent of the application that owns the code.
The architectural consequence under Article 25 is that the deployer can demonstrate, request by request, which policy was in effect at the moment of each decision. If a substantial modification is alleged, the policy history shows when the change happened, what changed, and what the production behavior was before and after. The records anticipate the regulator's inquiry rather than retrofit answers to it.
If you are facing the August 2 deadline and you have made model selection, prompt, or retrieval changes since procurement, let's talk.
Frequently asked questions
- Does fine-tuning a foundation model always trigger Article 25?
Not automatically. Article 25 triggers when the fine-tune affects compliance with Section 2 requirements or modifies the intended purpose. A fine-tune that improves accuracy on the same intended purpose, was foreseen in the original conformity assessment, and does not change data governance or risk profile may sit within the original provider's scope. In practice, most enterprise fine-tunes touch at least one Section 2 requirement (data governance under Article 10 almost always changes) and most fall outside the upstream provider's assessment, so they trigger Article 25. The defensible position is to maintain documentation showing the assessment basis for each fine-tune.
- What is the practical difference between deployer and provider obligations?
Deployer obligations under Article 26 cover the operational use of the system: ensuring input data is relevant, human oversight, logging under Article 19, transparency to affected persons. Provider obligations under Chapter III Section 3 cover the system itself: conformity assessment under Article 43, technical documentation under Article 11 and Annex IV, quality management under Article 17, registration in the EU database under Article 71, post-market monitoring under Article 72, and incident reporting under Article 73. The provider holds the heavier conformity and registration obligations, plus the documentation burden that runs to dozens of artifacts.
- How does Article 25 interact with the GPAI exemption under Article 25(4)?
Article 25(4) carves out an exception: substantial modifications by a deployer of a general-purpose AI system that the deployer integrates into a high-risk system do not turn the deployer into the provider of the GPAI model itself, only into the provider of the high-risk integration. The GPAI provider keeps its own obligations on the underlying model. The deployer becomes a provider for the integrated high-risk deployment. The split matters because it limits the documentation the deployer needs to produce: it covers the integration, not the underlying model's training data.
- Are general-purpose chatbots in scope of Article 25 if I add a system prompt?
A system prompt that operates within the original provider's intended purpose is not a substantial modification. A system prompt that repoints the chatbot to an Annex III use case (credit decisioning, employment screening, education access) modifies the intended purpose and triggers Article 25. The line is fuzzy in edge cases. The defensible position is to maintain a version-stamped policy at the AI request boundary and document the basis for each policy change against the original provider's intended purpose. When the regulator asks "when did this system start being used to screen job applicants," the records produce the date.
- What records does the regulator look for in a substantial modification dispute?
The records cluster around three questions. When did the deployer first deploy the system in the disputed configuration. What was the system's prior configuration. What was the provider's intended purpose under the original conformity assessment. The first two are records the deployer should hold at per-request granularity, ideally at the AI request boundary so they are independent of the application. The third comes from procurement records and the original provider's Article 11 technical documentation. The deployer that can produce all three from independent sources is in a defensible position. The deployer that depends on application logs alone is not.