When Putting Your Brand on a Vendor Model Makes You the Provider

Procurement signs a licence for a CV-screening tool built by a small vendor. It works well, so the product team asks for the vendor's logo to come off the careers portal and yours to go on, under a name marketing invented. Nobody in that meeting thinks they are making a regulatory decision. Under Article 25 of the EU AI Act, they may just have moved the entire high-risk compliance burden from the vendor onto your organisation.

This is the most commonly misunderstood point in the Act, and it is misunderstood in one direction: organisations assume that because they bought the system rather than built it, they are a deployer and will stay one. Three ordinary commercial acts — white-labelling, substantially modifying, repurposing — convert a deployer, distributor or importer into a provider.

The three triggers in Article 25

Article 25(1) treats a distributor, importer, deployer or other third party as a provider of a high-risk AI system, carrying the Article 16 obligations, where it does any of the following.

• Puts its name or trademark on a high-risk AI system already on the market, subject to the qualifier "without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated".
• Makes a substantial modification to a high-risk AI system already on the market, such that it remains high-risk.
• Modifies the intended purpose of an AI system — including a general-purpose AI system — that was not classified as high-risk, such that it becomes high-risk under Article 6.

The third limb catches organisations building on general-purpose models. A general-purpose chat or document-analysis system is not high-risk in the abstract; point it at sifting job applications, scoring creditworthiness or triaging benefit claims and you have given it an intended purpose within Annex III. You are then the provider of a high-risk system nobody manufactured as one.

What "substantial modification" actually means

Article 3(23) defines it as a change made after placing on the market that was not foreseen or planned in the provider's initial conformity assessment, and that either affects compliance with the high-risk requirements or changes the intended purpose assessed. The test is not how much effort the change took. Retraining on your own data within an envelope the provider documented and assessed is not a substantial modification; retraining outside it, adding a decision function never assessed, or wiring in a data source that changes what the outputs mean, probably is. The vendor's instructions for use are where that boundary lives; if they do not describe one, treat the silence as a procurement finding.

Who the duty falls on

Plainly: the duty falls on whoever performs the triggering act, from the moment they perform it. If your organisation puts its brand on the system, your organisation is the provider of it. Not the vendor, not the group parent, not the integrator — unless one of those did the branding or the modifying.

Article 25(2) completes the transfer: the initial provider is no longer the provider of that system, and must cooperate closely with the new one, making available the information, technical access and assistance needed. That cooperation duty falls away where the initial provider clearly specified that its system is not to be changed into a high-risk one. Vendors have noticed, and "do not repurpose" clauses are becoming common — read them before assuming you can lean on their documentation.

Two points get missed. No vendor is needed: "putting into service" covers supplying a system for your own use, so a team that builds an internal high-risk system and switches it on is a provider. And the carve-out in limb (a) allocates obligations between the parties; it does not obviously change what a market surveillance authority sees when it reads the name on the product. An indemnity is not a compliance strategy.

What changes on the day you become the provider

Obligation	Provider	Deployer
Risk management system (Art 9)	Yes, throughout the lifecycle	No
Training data governance (Art 10)	Yes	No — but input data must be relevant and representative (Art 26)
Annex IV technical documentation (Art 11)	Yes	No
Human oversight (Art 14)	Build the capability in	Assign competent, trained, authorised people
Conformity assessment, EU declaration, CE marking	Yes	No
EU database registration (Art 49)	Yes, before placing on the market	Public authorities and EU bodies only
Post-market monitoring and incident reporting	Yes	Report incidents to the provider and authorities
Authorised representative in the Union (Art 22)	Yes, if established outside the EU	No

The last row matters disproportionately for UK organisations. A UK company that brands an EU-marketed high-risk system as its own becomes a third-country provider and must appoint an authorised representative in the Union by written mandate — a relationship to negotiate, not a form to file.

The fine-tuning question

Keep two concepts apart. Becoming the provider of a high-risk system is governed by Article 25 and turns on intended purpose. Becoming the provider of a general-purpose AI model is a separate question, arising when you fine-tune someone else's model. The recitals indicate a downstream modifier's obligations should be limited to the modification itself, and Commission guidelines propose an indicative threshold based on the compute used for the modification relative to the original training run. Those guidelines are not binding law, so check the current text before relying on them — and staying below the threshold does nothing under Article 25, where modest fine-tuning plus a high-risk intended purpose still makes you the provider.

Checklist before any rebrand, integration or repurposing goes live

• Is the system, as we intend to use it, within Annex III or a safety component under Annex I? Record the reasoning either way.
• Whose name and trademark appear in the interface, the documentation, the terms of service and the end-user contract?
• Does the vendor state an intended purpose, and does ours differ from it?
• Does the vendor's contract prohibit turning the system into a high-risk one, and would that remove its duty to hand over documentation?
• Do we have Annex IV technical documentation, or enough to write our own?
• If we become the provider, who signs the EU declaration of conformity, and on what evidence?
• Which named individual owns post-market monitoring and the incident reporting route?

Limits of this guidance, and when to take advice

This is general guidance, not legal advice on your systems, and three real uncertainties should temper it. Harmonised standards supporting the high-risk requirements are still being developed, so what counts as sufficient documentation is not yet fixed. The application timeline for parts of the high-risk regime has been the subject of proposed amendment at EU level — verify the dates that apply when you read this. And how far contractual allocation under Article 25(1)(a) survives contact with a market surveillance authority is untested.

Take specialist advice before white-labelling into a regulated sector, on any notified-body route, where a system is a safety component under Annex I, and where responsibility spans group entities in different jurisdictions. The exposure is real: up to 3% of global annual turnover for most AI Act obligations, up to 7% for prohibited practices, and up to 4% under UK or EU GDPR where personal data is involved. The UK has no equivalent provider and deployer regime, but UK organisations are caught where they place systems on the EU market or the output is used in the Union — and UK GDPR duties on automated decision-making apply either way.