A scale-up licenses an AI screening tool, fine-tunes the underlying model on its own data and puts its own logo on the interface before rolling it out to customers. The CTO sees a product improvement. The legal counsel should see something else: the moment the company may stop being a deployer and become a provider, inheriting the full set of provider obligations under the AI Act.
The direct answer sits in Article 25(1) of the AI Act. A deployer (or distributor, importer or any other third party) becomes the provider of a high-risk AI system in three situations: when it puts its own name or trademark on a high-risk system already placed on the market, when it makes a substantial modification to such a system that leaves it high-risk, or when it changes the intended purpose of an AI system (including a general-purpose AI system) in a way that turns it into a high-risk system. In all three cases, the provider obligations of Article 16 shift to you, and the original supplier is no longer considered the provider of that specific system.
Note the hinge in that sentence: Article 25 is about high-risk systems. For most internal generative AI applications that are not high-risk, the article simply does not apply. But the reasoning behind it, who is the provider of which system and why, is something every organisation that builds on or adapts AI needs to be able to demonstrate.
The three routes of Article 25(1)
Route 1: your name or trademark on a high-risk system
The first route is the most underestimated. Whoever puts their name or trademark on a high-risk AI system that has already been placed on the market or put into service becomes the provider of that system. The legislator's logic mirrors product regulation: whoever presents a product to the world as their own carries the responsibility that comes with it.
For white-label arrangements, this is the core provision. An HR tech company that sells a purchased candidate screening tool to clients under its own brand is the provider of that tool, even if not a single line of code was changed under the hood. The provision does leave room for contractual arrangements that allocate the obligations differently, but that requires a deliberate, documented agreement with the original supplier. Swap the logo and arrange nothing else, and the obligations are simply yours.
Route 2: substantial modification of a high-risk system
The second route concerns intervening in the system itself. Whoever makes a substantial modification to a high-risk AI system already on the market, in such a way that it remains high-risk, becomes the provider. What counts as "substantial" is defined in Article 3(23): a change not foreseen or planned in the provider's initial conformity assessment that affects compliance with the high-risk requirements or changes the intended purpose.
That element of foreseeability is the key criterion in practice. A provider of a high-risk system can specify in its documentation which adjustments, configurations and even which forms of continued learning fall within the assessed envelope. Stay inside it and the original provider remains the provider. Step outside it, for instance by retraining the model on your own data in a way the supplier never anticipated, and route 2 comes into play. For those who recognise the vocabulary: this concept comes straight from product regulation such as the Machinery Regulation and the Medical Device Regulation, where substantial modifications likewise trigger a fresh conformity assessment.
Route 3: a change of purpose that makes a system high-risk
The third route is the most interesting one for generative AI practice. Whoever modifies the intended purpose of an AI system that was not classified as high-risk, including a general-purpose AI system, in such a way that it becomes high-risk, is the provider of that new high-risk system. What matters here is not how much you change the model, but what you use it for.
A generic chatbot API is not a high-risk system. Build an application around it that ranks job applicants, grades exams or triages requests for essential services, and you are deploying that generic system for a purpose listed in Annex III. You defined the intended purpose, so you are the provider of the resulting high-risk system. Under Article 25(2), the original model supplier must reasonably cooperate by providing the information and technical access you need to meet your obligations, unless it has clearly specified that its system is not to be changed into a high-risk system.
What this means for fine-tunes, white-labels and RAG
GPT fine-tunes. Two layers run through each other here, and you need to keep them apart. At the model level, fine-tuning rarely makes you a provider: the European Commission's guidelines on GPAI obligations use an indicative threshold under which only very large-scale retraining (in the order of one third of the original training compute) creates a new model provider. Virtually no business fine-tune comes anywhere close. At the system level, the picture changes: if your fine-tuned application serves an Annex III purpose, you are the provider of a high-risk AI system, via route 3 or simply directly, because you developed a system and put it into service under your own name. Compute is irrelevant there; intended purpose is decisive.
Your own name on purchased tools. Route 1 in its purest form. The practical question is always the same: is the underlying system high-risk? If so, agree contractually who carries which obligation, or accept that they are yours. If not, rebranding does not by itself create provider status under Article 25, but as a deployer you remain bound by, among other things, the transparency obligations of Article 50 once they apply to your use case.
RAG applications. Retrieval augmented generation does not modify the model, so route 2 rarely applies. But whoever builds a RAG application and puts it into service under its own name, internally or externally, is developing an AI system and is its provider in the ordinary sense of Article 3. The classification question is then identical: does the application serve an Annex III purpose? An internal knowledge assistant that summarises policy documents almost certainly does not. A RAG system advising on benefit claims or creditworthiness sits in a different category.
Not high-risk? Then no Article 25, but the reasoning remains
The reassuring message for most innovation teams: internal copilots, summarisation tools and customer service assistants are usually not high-risk systems, and Article 25 then does not apply. What remains is the reasoning itself. For each application you must be able to substantiate what the intended purpose is, whether that purpose touches Annex III, and who holds which role in the chain. That documentation belongs in your AI inventory; why that register is the foundation of everything else is covered in our article on the AI inventory.
The timeline gives breathing room, not a free pass. Through the Digital Omnibus (a political agreement that, as of mid-2026, has not yet appeared in the Official Journal), the standalone high-risk obligations of Annex III apply from 2 December 2027; AI embedded in regulated Annex I products follows on 2 August 2028. But the transparency obligations of Article 50 apply from 2 August 2026, and full GPAI enforcement starts on that same date. Moreover, the contracts you sign today on white-labels and fine-tunes will determine who carries the conformity assessment later. In the Netherlands, the Autoriteit Persoonsgegevens (the Dutch data protection authority, in a coordinating role) and the RDI are preparing for supervision; the government submitted the implementing bill that formally allocates those roles in April 2026.
In practice this comes down to four steps. Inventory which AI systems you use, adapt or resell. Record per system what the intended purpose is and whether it touches Annex III. For every white-label and fine-tune arrangement, check the contracts on the allocation of Article 25 obligations and the original provider's duty to cooperate. And anchor this in a governance structure that repeats the assessment whenever the purpose or the system changes; how that relates to certification is explained in ISO 42001 versus the EU AI Act. For the full timeline and obligations per role, see our AI Act Explorer. And for organisations that want to set up this role assessment structurally, from inventory to contract clauses, Embed AI offers a pragmatic governance approach.