EU AI Act Article 25: When You Become the AI 'Provider'

Most agencies I speak to treat the EU AI Act as someone else’s problem. They use AI tools, so they assume the heavy obligations sit upstream with OpenAI, Anthropic, or whichever vendor built the model. Almost none of them have read Article 25. This clause moves the provider’s entire obligation set onto ordinary businesses through work they do every week.

This is the most overlooked liability transfer in the Act for creative, marketing, consulting, and research agencies. It does not require you to build a model. It requires you to put a logo on something, adjust it, or point it at a new job. These are the exact activities agencies are paid for.

You are probably not the “provider” you think you are

The EU AI Act splits the world into roles. Your obligations depend entirely on which role you occupy. A provider develops an AI system and places it on the market. A deployer uses one under its own authority. Distributors and importers move systems along the chain.

Agencies almost always assume they are deployers. It is the comfortable read: you licensed a tool, you use it for clients, and the compliance burden belongs to whoever made it. For a genuine deployer of a high-risk system, the duties are real but contained. They cover human oversight, monitoring, and using the system as instructed.

The provider role carries far more weight. Providers of high-risk AI systems carry conformity assessment, technical documentation, the quality management system, registration in the EU database, and post-market monitoring. The regulator holds the provider responsible when the system causes harm. If you assume you are a deployer when the law sees you as a provider, this is not a paperwork error. It is the difference between light-touch obligations and the full regime.

The three ways Article 25 flips you into a provider

Article 25(1) sets out exactly when a distributor, importer, deployer, or other third party becomes “considered to be a provider” of a high-risk system. This party then takes on the Article 16 provider obligations. There are three triggers, and each one maps onto something agencies do routinely.

Trigger (a) catches agencies off guard most often. Putting your name on a high-risk system already placed on the market makes you its provider. The exception is when your contract with the original maker allocates the obligations differently. The moment you present a tool to a client as your product, you may have adopted its entire legal weight.

Trigger (c) is the sleeper. It covers general-purpose AI systems that were not originally classified as high-risk. This includes the everyday chat and automation models teams reach for. If you point one of those at a use listed in Annex III, you have not just deployed a tool. You have created a high-risk system and become its provider.

What actually lands on you the moment you flip

Here is the part that turns an abstract clause into a genuine operational problem. Article 25(1) states that once you become the new provider, the original provider “shall no longer be considered to be a provider of that specific AI system.” The upstream vendor steps out of the frame for that instance. The responsibility stops with you.

You might expect the original maker to at least hand over what you need to comply. Article 25 does oblige them to cooperate and to “make available the necessary information” and reasonable technical access. But there is a carve-out. This duty does not apply where the original provider “clearly specified that its AI system is not to be changed into a high-risk AI system.”

If a vendor’s terms say the tool must not become a high-risk system, and you do it anyway, they owe you nothing. You then become the provider of something you cannot fully document.

This is where the flip bites hardest. Conformity assessment and technical documentation need deep access to how the system was built and tested. An agency that becomes a provider through trigger (a) or (c) often has none of that, and no contractual right to demand it. You inherit the obligations without inheriting the information needed to meet them.

The contract clause that decides who carries the risk

Article 25(4) is the quiet lever most teams never pull. It requires a provider that integrates a third party’s tools, services, or components into a high-risk system to agree, in writing, the information, capabilities, technical access, and other assistance needed for compliance. The one exception covers tools provided under a free and open-source license.

In plain terms, the paperwork you sign with your AI suppliers now decides your exposure. A written agreement that guarantees access to documentation and technical detail marks the difference between a compliable position and an impossible one. Without an agreement, the flip in Article 25(1) can leave you legally accountable with nothing to work from.

So before you integrate any AI tool that could touch a high-risk use, treat the contract as the control, not an afterthought. Demand written terms covering documentation access, technical cooperation, and a clear statement of intended purpose. Treat a vendor’s refusal to provide them as the risk signal it is.

What to do about it, before you touch another AI tool

Article 25 is manageable once you stop assuming it does not apply to you. Based on the agencies I have worked with, here is the order to tackle it in.

First, map which of your AI uses could be high-risk in the first place. Article 25 only flips you into a provider for high-risk systems, so this step decides whether any of it is relevant. The Annex III test is the fastest way to check the uses agencies most often stumble into. Recruitment and scoring rank chief among them.

Second, audit your work for the three triggers: name, modify, repurpose. Go through your live client engagements and ask honestly whether you are branding, substantially modifying, or repurposing anyone’s system into a high-risk use. This is a one-afternoon exercise that most teams have never run.

Third, fix the contracts before the next integration. Put the Article 25(4) written agreement in place, secure documentation and technical-access rights, and record the intended purpose of every system in a register. This proves what it was, and was not, meant to do.

None of this requires a legal department. It requires you to read your own work the way a regulator does. Accept that “we just use the tool” is not the safe harbor agencies assume it to be.

Article 25 is not an edge case buried in the Act for hyperscalers to worry about. It describes with precision what agencies and small teams do every single week: brand things, adapt things, repurpose things. The risk is not that the law is unreasonable. The flip from user to provider happens silently, through ordinary work, and you only discover it when someone asks for the technical file you never had.

If you integrate AI tools into client work and you are not sure which side of Article 25 you sit on, that uncertainty is itself the finding. Get in touch → and we can map it before it maps you.

Related reading on The Science Talk

This piece pairs with the Article 4 AI-literacy explainer on The Science Talk, which gives useful background on how the Act’s obligations reach ordinary organizations, not just AI developers.

Browse all Perspectives or get in touch →