Why this rule catches businesses by surprise
Most companies approach the EU AI Act by deciding which box they sit in. If you build AI, you are a provider and you carry the heavy obligations. If you buy AI and use it, you are a deployer and you carry a lighter set. It is a comfortable distinction, and for many businesses it is accurate.
Article 25 of the AI Act is the provision that dissolves it. Under Article 25, a distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system in three defined circumstances – and once that happens, the full weight of Article 16 lands on them. Risk management, data governance, technical documentation, conformity assessment, CE marking, registration, post-market monitoring. Everything.
The businesses most exposed are rarely AI developers. They are software companies that white-label a vendor’s engine, integrators who bundle third-party models into their own product, and ordinary companies that take a general tool and point it at a consequential decision.
The three triggers
You put your name or trademark on it
Article 25(1)(a) is the cheapest way to become a provider and the one companies stumble into most often. If a high-risk AI system has already been placed on the market and you put your own name or trademark on it, you are the provider. No modification is needed. No code has to change. Rebranding alone does it.
This limb comes with an important qualifier that the other two do not have: it applies “without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated”. In other words, the parties can agree in writing who carries which duties. That contractual lever exists only for the branding trigger – it does not rescue you under (b) or (c).
You substantially modify it
Article 25(1)(b) catches a business that makes a substantial modification to a high-risk system already on the market, where it remains high-risk afterwards. “Substantial modification” is defined in Article 3(23) as a change after placing on the market which was not foreseen or planned in the provider’s initial conformity assessment, and which either affects the system’s compliance with the Chapter III requirements or changes the intended purpose it was assessed for.
The definition does real work here. Changes the original provider anticipated and covered in its conformity assessment – routine updates, configuration within documented parameters – are not substantial modifications. Changes that fall outside that envelope are.
You change what it is used for
Article 25(1)(c) is the trigger that most often catches deployers. If you modify the intended purpose of an AI system that is not classified as high-risk – including a general-purpose AI system – in such a way that it becomes high-risk under Article 6, you become the provider.
This is the most common real-world route. Take a general assistant that was never high-risk, point it at screening job applications or assessing creditworthiness, and the use case drags it into Annex III. You did not build a model. You changed a purpose, and the Act treats that as an act of provision.
What happens to the original provider
Once one of these triggers fires, the business that originally placed the system on the market stops being its provider. It does not simply walk away, however. Article 25(2), which the Digital Omnibus on AI amended in July 2026, requires the initial provider to cooperate closely with the new provider and to supply the information, reasonably expected technical access and other assistance needed to meet the Act’s obligations, particularly around conformity assessment.
The Omnibus made that duty more concrete by spelling out its minimum content: making available technical documentation sufficient to assess compliance with Article 16, informing the new provider about known limitations and failure modes, and providing targeted technical access including for testing and validation.
There is a significant carve-out. The cooperation duty does not apply where the initial provider has clearly specified that its system is not to be changed into a high-risk AI system. That single sentence is the most important contractual clause in this area, and it cuts both ways. If you are the upstream supplier, it is your escape hatch. If you are the downstream integrator, it is the clause that leaves you holding a system you cannot document.
Article 25(5) preserves intellectual property rights, confidential business information and trade secrets throughout, so cooperation does not mean unlimited disclosure.
Does fine-tuning make you a provider?
This is the question we are asked most, and the answer depends on which kind of provider you mean.
For high-risk systems under Article 25, fine-tuning is not itself a listed trigger. You are caught only if you also brand the system as yours, if the fine-tuning amounts to a substantial modification of a system that was already high-risk, or if it changes the intended purpose into a high-risk use. The decisive fact is usually what you deploy it for, not the technical act of adjusting weights.
For general-purpose AI models, a separate regime in Chapter V applies. Recital 109 of the AI Act states that where a model is modified or fine-tuned, the obligations of a general-purpose AI model provider should be limited to that modification – for example by supplementing existing technical documentation with information about the changes and any new training data sources. The Commission’s guidelines on the scope of obligations for providers of general-purpose AI models indicate that a downstream modifier becomes a model provider only in exceptional circumstances, using a compute-based threshold as an indicator. That threshold is guidance rather than statutory text, and it should be treated as such.
Contracts along the value chain
Article 25(4) requires the provider of a high-risk AI system and any third party supplying an AI system, AI model, tools, services, components or processes used in it to specify by written agreement the information, capabilities, technical access and assistance needed for compliance. The Digital Omnibus added “AI model” to that list in July 2026, closing a gap where a supplier of a bare model could argue it fell outside the written-agreement duty.
Suppliers making tools, services, processes or components publicly available under a free and open-source licence are excluded from this duty – but that carve-out expressly does not extend to general-purpose AI models. A free and open-source model supplied into a high-risk system is still inside Article 25(4).
Praktiskt exempel
A Swedish HR technology company licenses a candidate-scoring engine from a German vendor, wraps it in its own interface, and sells it to Nordic employers as its own product under its own brand. It writes no model code and changes no algorithm.
Under Article 25(1)(a) it is the provider. Employment and worker management sits in Annex III, so the system is high-risk, and the Swedish company owes the complete Article 16 package – including a conformity assessment it cannot perform without documentation it does not hold. Its contract with the German vendor is silent on AI Act allocation and contains no cooperation clause.
Had it negotiated an Article 25(4) written agreement at the outset, and used the contractual allocation permitted under limb (a), the position would look entirely different. The cost of fixing this after signature is an order of magnitude higher than the cost of drafting it before.
Vanliga misstag som företag gör
The first is treating white-labelling as a commercial decision rather than a regulatory one. Marketing teams rebrand vendor technology routinely, and nobody asks whether the underlying system is high-risk.
The second is assuming a contract can allocate away every obligation. It cannot. The express contractual carve-out in Article 25 attaches only to the name-and-trademark trigger. Substantial modification and change of intended purpose reclassify you regardless of what your contract says. Contracts allocate risk between the parties; they do not rewrite who the regulator holds responsible.
The third is failing to notice the upstream opt-out. If your supplier has clearly specified that its system is not to be turned into a high-risk system, it owes you no cooperation and no documentation. Businesses discover this at the point they need the technical file, which is far too late.
The fourth is thinking that the deferral of the high-risk regime to December 2027 means the contractual work can wait. The contracts you are signing today will still be in force then.
Rekommenderade åtgärder
Map every AI system in the business and record, for each one, whether you brand it, whether you have modified it, and what you actually use it for. Those three questions map exactly onto the three triggers.
Review supplier contracts for the two clauses that matter: an Article 25(4) written agreement covering information, technical access and assistance, and an explicit allocation of obligations where you are rebranding. Check whether any supplier has stated that its system is not to be converted into a high-risk system, and price that risk accordingly.
Put a change-control gate around modifications to purchased AI, so that a product decision to repurpose a tool triggers a legal review before it ships. Where you supply AI to others, decide deliberately whether you want the Article 25(2) opt-out in your own terms – and be honest with customers about what it means for them.
Vanliga frågor
If we only resell a system without rebranding it, are we a provider?
Not under Article 25(1)(a), which requires you to put your own name or trademark on the system. Distributors and importers have their own separate obligations under the AI Act, but they are not the same as provider obligations. The moment your brand goes on the product, the analysis changes.
When do these obligations actually start applying?
Article 25 sits in Chapter III, which the Digital Omnibus on AI deferred. The obligations apply from 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I systems. The contractual protections, though, need to be in the agreements you sign now.
Can we simply ask our supplier for the technical documentation?
You can ask, and where Article 25(2) applies they must cooperate and provide documentation sufficient to assess compliance, information on known limitations and failure modes, and targeted technical access. But if they have clearly specified that the system is not to be changed into a high-risk system, that duty falls away – and their intellectual property and trade secrets are protected in any event.
Slutsats
Article 25 is short, and it reallocates responsibility for an entire regulatory regime. Putting your name on a high-risk system, substantially modifying one, or repurposing an ordinary system into a high-risk use all make you the provider, with the full Article 16 obligation set attached. Only the first of those can be softened by contract. The businesses that manage this well treat branding, modification and repurposing as gated decisions, and they fix their supply contracts long before the high-risk regime applies. Lawgent helps businesses work out where they sit in the AI value chain, negotiate the contractual protections that Article 25 makes possible, and avoid inheriting provider obligations they never intended to take on.
