Your Vendor Can Leave You Holding The Provider Obligations

Your vendor can write one sentence into a contract that leaves you carrying the provider obligations. You would then need documentation you have no right to demand.

That sentence already exists in the AI Act. It has sat in Article 25 since 2024, and almost nobody reads that far.

Three ways provider obligations change hands

Article 25 governs responsibilities along the AI value chain, and it is where provider obligations change owner. A distributor, importer, deployer or other third party becomes the provider of a high-risk AI system in three circumstances. The full provider obligations under Article 16 then transfer with the role.

The first is rebranding. Put your name or trademark on a high-risk system already on the market and you are the provider of it. The Act allows contractual arrangements that allocate the duties differently, so you can negotiate this one. Negotiation does not touch the other two.

The second is substantial modification. Change a high-risk system already on the market so that it stays high-risk. The provider obligations move to you.

The third is repurposing, and it is the trap. Take a system nobody classified as high-risk, a general-purpose one included. Modify its intended purpose so it becomes high-risk under Article 6, and you are now the provider.

Note the boundary carefully

All three triggers turn on high-risk classification. Repointing an ordinary chatbot at an ordinary task moves nothing. Repointing a general-purpose model at CV screening counts as a different act entirely. Employment sits in Annex III.

That is the distinction most vendor conversations skip. The question is never whether you modified the system. It is whether the modification lands the system in a high-risk category.

Your vendor can decline to help you

Here is the sentence worth reading twice.

When the role changes hands, the original provider stops being the provider of that system. It must then cooperate closely with the new one, handing over information and reasonable technical access. That duty falls away, however, where the initial provider has clearly specified that nobody may turn its system into a high-risk one. The vendor then keeps its documentation.

So the worst outcome sits within reach today. You repurpose a tool into a high-risk use, you inherit the provider obligations, and your supplier may lawfully hand you nothing. Conformity assessment, technical documentation and post-market monitoring all become yours, built from scratch, on a system you did not design.

What the Omnibus just changed

Regulation (EU) 2026/1744 reached the Official Journal on 24 July 2026 and took effect on 27 July. It amends Article 25 directly.

Two things moved. The amendment now spells out the cooperation duty in detail, covering the information and the targeted technical access the original provider must supply. More pointedly, a breach of that duty now sits inside the penalties in Article 99(4). Those fines reach 15 million euros or 3% of global annual turnover, whichever is higher.

Read that as leverage. Where the escape clause does not apply, your supplier now faces a real number for stonewalling you.

The deferral is runway, not relief

The same regulation pushed the high-risk deadlines back. Stand-alone systems classified under Article 6(2) and Annex III now apply from 2 December 2027. Systems embedded in regulated products under Article 6(1) and Annex I apply from 2 August 2028.

Fifteen months sounds generous. It is not. Teams are fixing your role right now, inside procurement cycles and product roadmaps that will still be running in December 2027. The role you back into during the runway is the role you arrive with.

How provider obligations arrive inside the organisation

Nobody schedules a meeting to pick up provider obligations. It happens sideways.

Fine-tuning is the common trip

A data team fine-tunes a general model on internal records to make it better at sorting applications. Nobody calls that a substantial modification, because it felt like configuration. If the resulting system decides or materially influences who gets hired, the provider obligations arrived with the training run. Nobody logged the moment.

White-labelling is the other one. Marketing puts the company logo on an embedded vendor tool and ships it to customers. People who have never read Article 16 make that branding call. The same blur shows up when a vendor swaps the model behind a product by region, which turns one purchase into several systems to document.

Neither team is careless. Both are doing exactly the job in front of them. Nobody told either one that certain edits move the provider obligations onto their employer. Call that an AI literacy gap with a price tag, and note that it sits between departments rather than inside any one of them.

Four questions before the next AI contract

• Does the supplier’s contract forbid turning the system into a high-risk one? If so, you lose any claim on their documentation the moment you cross that line.
• Which of your planned uses touch an Annex III category? Employment, education, credit, essential services and law enforcement are where ordinary tools become high-risk ones.
• Who signs off fine-tuning and retraining, and do they know that the provider obligations can follow the change?
• What did your written agreement under Article 25(4) actually secure? The Act requires suppliers of integrated tools and components to agree the information and technical access you need. Free and open-source components fall outside it.

One practical note on standards. CEN and CENELEC published EN 18286 on quality management systems on 22 July 2026. It is the first European standard supporting the AI Act, and the rest should follow across late 2026 and early 2027. If you end up carrying provider obligations, that is the shape of the evidence you owe. It also raises the bar on what you ask a supplier to prove about model lineage.

Roles are a governance decision, not a legal footnote

The useful reframe is this. Provider and deployer are not descriptions of what kind of company you are. They are outcomes of decisions your teams make about naming, modifying and repurposing. The AI Act reassigns the role without asking anyone.

Which means somebody in your organisation needs to hold a current answer to a simple question. For each AI system we run, are we the deployer or the provider, and what would change that.

Most organisations cannot answer it today. If yours is working through that mapping, the Future Prep Applied AIGP course suits the people who have to do it. Role allocation across the value chain is where the course starts.