When does a deployer become a provider under the EU AI Act?
Updated 9 August 2026 for Regulation (EU) 2026/1744.
Three triggers, all in Article 25(1): putting your name or trademark on a high-risk AI system, substantially modifying one so that it stays high-risk, or repurposing a system into a high-risk use. Each makes you the provider, with the full Article 16 obligations.
Quick answer
- Article 25(1): a "distributor, importer, deployer or other third-party" caught by a trigger "shall be considered to be a provider" and "shall be subject to the obligations of the provider under Article 16".
- Re-badging (point (a)) — the only trigger whose obligations a contract can reallocate: "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated".
- Substantial modification (point (b)) — defined in Article 3, point (23), anchored to the initial conformity assessment; where fine-tuning crosses it is unsettled.
- Repurposing (point (c)) — changing the intended purpose of a non-high-risk system, including a general-purpose AI system, so it becomes high-risk under Article 6.
- The initial provider drops out and owes cooperation (Article 25(2)) — unless it clearly specified its system was not to be changed into a high-risk one.
What are the three triggers in Article 25(1)?
Article 25(1) names the parties — "any distributor, importer, deployer or other third-party" — and attaches the consequence: whoever meets a trigger "shall be considered to be a provider of a high-risk AI system" and "shall be subject to the obligations of the provider under Article 16". All three triggers concern systems "already placed on the market or put into service" — the switch is about what you do with someone else's system after it ships.
Role definitions and the two obligation lists are in provider vs deployer; this guide unpacks the switch. The stakes are ahead, not behind: Article 16 applies to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028 (Article 113, third paragraph, point (c), as amended by Regulation (EU) 2026/1744).
When does white-labelling make you the provider?
Point (a) is the re-badging trigger. License a vendor's AI recruitment-screening engine and ship it to your customers under your own brand: the system is high-risk, your trademark is on it, and Article 25(1), point (a) makes you its provider.
It is the only trigger that names contracts: it applies "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated". The obligations — not the trigger — can be reallocated: a white-label agreement can leave the quality management system, technical documentation and conformity assessment with the original developer. If the agreement is silent, everything in Article 16 sits with the party whose name is on the system. A re-badging deal should therefore allocate the list obligation by obligation — and no such mechanism exists for points (b) and (c).
When is a modification "substantial"?
Article 3, point (23) defines a substantial modification as "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 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" (Article 3, point (23)).
Two limbs, both anchored to the provider's paperwork: the change was not foreseen in the initial conformity assessment, and it either affects compliance with the Section 2 requirements or changes the assessed intended purpose. Swapping the underlying model, retraining on your own data, changing decision thresholds, or disabling an oversight feature are all candidates — whether each one qualifies depends on what the original assessment foresaw. Article 43(4) carves out one case explicitly: for systems that continue to learn, changes "pre-determined by the provider at the moment of the initial conformity assessment" and recorded in the technical documentation are not a substantial modification.
Where routine fine-tuning falls is genuinely unsettled. The Regulation does not say, and the Commission guidelines promised on Article 25 and on substantial modification — Article 96(1), points (a) and (c) — carry no statutory deadline. Until then, treat any reading as provisional and document your assessment against both limbs. The neighbouring question — when a change costs an existing system its grandfathering — is covered in the legacy-systems guide.
When does repurposing a system make you the provider?
Point (c) covers systems that were not high-risk at all — "including a general-purpose AI system". Take a general document-analysis assistant and deploy it as your CV-shortlisting tool: recruitment is an Annex III use, so the system becomes high-risk under Article 6(2), and the party that modified the intended purpose becomes its provider. "Intended purpose" is what the original provider specified in its instructions, marketing and technical documentation (Article 3, point (12)) — using a tool well outside that specification is where point (c) risk begins. Run the change through the classification method before you make it, not after.
One boundary: point (c) is about AI systems. If you build on a general-purpose AI model, the model provider's separate Chapter V regime applies upstream — see GPAI obligations.
What does the switch actually cost you?
The chapeau is explicit: the new provider "shall be subject to the obligations of the provider under Article 16". That means ensuring compliance with the Section 2 requirements, running an Article 17 quality management system, holding the technical documentation, passing the Article 43 conformity assessment before placing on the market or putting into service, drawing up the EU declaration of conformity, affixing CE marking and registering under Article 49(1).
For a substantial modification the bill arrives even without a single external customer: Article 43(4) requires a new conformity assessment "regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer". And becoming the provider does not end your deployer role — if you still use the system under your authority, you carry the Article 26 duties alongside Article 16.
What happens to the original provider?
Article 25(2) removes them: once a trigger occurs, the provider that initially placed the system on the market or put it into service "shall no longer be considered to be a provider of that specific AI system". They are not released outright — the initial provider must "closely cooperate" with the new provider, make available the necessary information, and provide "the reasonably expected technical access and other assistance" needed to meet the obligations, in particular the conformity assessment. Regulation (EU) 2026/1744 replaced Article 25(2) and gave that duty a floor: where relevant, it includes "making available of technical documentation sufficient to assess compliance with the requirements laid down in Article 16", "informing the new providers about known limitations and failure modes" and "providing the new providers with targeted technical access, including for testing and validation".
The carve-out matters as much as the duty: the paragraph "shall not apply in cases where the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system and therefore does not fall under the obligation to cooperate with the new providers and hand over the documentation". A vendor that writes that specification into its terms owes neither cooperation nor handover — and a deployer who transforms the system anyway becomes a provider expected to produce technical documentation without the vendor's internals. Two flanking rules complete the picture: Article 25(4), whose first subparagraph was replaced in 2026, requires the high-risk provider and any third party supplying "an AI system, AI model, tools, services, components, or processes" used or integrated in a high-risk AI system to specify "by written agreement" the information and technical access needed for compliance — the duty does not apply to third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence — and Article 25(5) preserves intellectual property rights and trade secrets. Both paragraphs now carry named penalty exposure: Article 99(4), point (da), inserted by the same regulation, covers "obligations of providers and operators pursuant to Article 25(2) and (4)" — fines up to EUR 15 000 000 or, for an undertaking, 3 % of total worldwide annual turnover for the preceding financial year, whichever is higher; for small mid-cap enterprises the new Article 99(6a) takes whichever is lower.
What this means for you
If you're a provider: Decide which side of Article 25(2) you are on. If you do not want handover and cooperation duties towards a customer who transforms your system, specify clearly in your terms that it is not to be changed into a high-risk AI system. If you allow white-labelling, put the Article 25(1), point (a) obligation allocation in the agreement, and paper component suppliers with Article 25(4) written agreements.
If you're a deployer: Inventory every modification your team has made to a vendor's system — model swaps, retraining, threshold changes, new use cases — and test each against the two limbs of Article 3, point (23), and every new use against Article 6. That analysis needs an owner per system: Complipath's register keeps a named owner and the classification reasoning on every system, so when a modification question arrives, the record already exists.
Has anything you changed moved the role?
Classify your system now — 7 questions on the main line, plus follow-ups where they apply, no account, and the classification runs in your browser: answers stay there unless you choose to keep the result.
FAQ
Does fine-tuning a vendor's model make us the provider? Unsettled. The test is Article 3, point (23): was the change foreseen in the initial conformity assessment, and does it affect Section 2 compliance or the intended purpose? Fine-tuning can satisfy that test or miss it; Commission guidelines promised under Article 96(1) have no statutory deadline. Document your assessment either way.
Can a contract stop us from becoming the provider? No. Provider status follows from the triggers themselves. Under Article 25(1), point (a), the caveat "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated" lets a contract reallocate the obligations; points (b) and (c) offer not even that. Whoever meets a trigger is the provider.
Do we stop being a deployer once we become the provider? No. If you keep using the system under your authority, you remain a deployer. You then carry both lists — the Article 16 provider obligations for the system you now answer for, and the Article 26 deployer duties for your own use of it — the same both-roles position as in-house development.
Does the switch apply if we only use the modified system internally? Yes. Article 43(4) requires a new conformity assessment after a substantial modification "regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer". Internal-only use is no shield — "putting into service" includes supply for own use (Article 3, point (11)).
Sources: Regulation (EU) 2024/1689 (EUR-Lex), Articles 3, 6, 16, 25, 43, 96, 99 and 113, as amended by Regulation (EU) 2026/1744 (EUR-Lex), which replaced Article 25(2) and the first subparagraph of Article 25(4), inserted Article 99(4), point (da), and replaced Article 113, third paragraph, point (c). Article 25(1) is unamended. The boundary of "substantial modification" under Article 25(1) (including fine-tuning): no guidance settling it is in our source corpus as of 12 August 2026 — the Commission guidelines foreseen by Article 96(1), points (a) and (c) carry no statutory deadline; verify before relying. Case law sits outside our corpus altogether, and this guide does not report whether a court has ruled. Treat any reading as provisional.