Why does it matter so much whether we are a deployer or a provider under the EU AI Act?

Because the two roles carry obligations that differ by an order of magnitude in cost. A deployer of a high-risk system uses it according to the instructions, assigns competent human oversight, keeps the logs it controls, monitors operation, informs affected workers, and reports serious incidents up the chain. A provider designs and documents the risk management system, builds and maintains the Annex IV technical file, runs the conformity assessment, affixes the CE marking, registers the system in the EU database, operates a quality management system, and carries post-market monitoring for the life of the product. Most companies buying AI have no capacity to do the second list, which is why the contract terms that keep you on the first list are worth more than any discount you could negotiate.

What actually turns a deployer into a provider?

Article 25 sets out three triggers. Putting your name or trademark on a high-risk system already on the market — ordinary white-labelling — is one. Making a substantial modification to a high-risk system is the second. Changing the intended purpose of a system, including an AI system not previously classified as high-risk, so that it becomes high-risk is the third. Two of those three are things commercial teams do routinely without asking a lawyer: rebranding an embedded vendor tool as your own feature, and pointing an existing tool at a new decision it was not sold for.

Do we need the vendor's technical documentation, or is that only the provider's problem?

You need enough of it to discharge your own duties and to survive a role flip. As a deployer you need the instructions for use in detail, because using the system outside them is both a compliance failure and, depending on how far outside, a route to becoming a provider. If a trigger does fire and you become the provider, you inherit an obligation to produce a technical file for a system you did not build — which is impossible unless the original provider is contractually required to cooperate. That cooperation clause costs nothing at signature and is unobtainable afterwards.

How long do we have to keep AI system logs?

The Act requires deployers to keep automatically generated logs that are under their control for a period appropriate to the intended purpose, and at least six months unless other Union or national law says otherwise. The practical problem is the phrase 'under their control': in most SaaS deployments the logs sit in the vendor's infrastructure under the vendor's own retention policy, which is frequently shorter than six months and adjustable by the vendor without notice. Pin the retention period and the export mechanism in the contract, or you will be answerable for records you cannot produce.

Our vendor is outside the EU. Does that change the analysis?

It changes the enforcement path, not your obligations. A provider established outside the Union that places a high-risk system on the EU market must appoint an authorised representative in the Union, and you should ask for that appointment in writing before you sign. If the vendor has not made one, you are buying from a supply chain that is not itself compliant, and market surveillance pressure will travel to the party that is established in the EU and reachable — frequently the deployer.

EU AI Act Vendor Contracts: The Clauses That Keep You a Deployer

The Role Question Is a Procurement Question

Most EU AI Act guidance starts with classification: is the system high-risk? That is the right first question, and our high-risk classification guide works through it. The second question is the one that determines your budget, and it is answered almost entirely by documents your commercial team signs: are you the provider or the deployer?

Deployer duties are real but bounded: use the system according to its instructions, assign human oversight to people with the competence and authority to exercise it, ensure input data is relevant and sufficiently representative for the intended purpose where you control it, monitor operation, keep the logs under your control, inform workers before deploying a high-risk system at work, and pass serious incidents up to the provider and the market surveillance authority.

Provider duties are a product organisation: a documented risk management system, an Annex IV technical file kept current, data governance for training and testing sets, logging designed into the system, a quality management system, conformity assessment and CE marking, registration in the EU database, and post-market monitoring with corrective action. A company that bought a tool cannot retrofit that. So the entire commercial objective is to not become the party that owes it — and the trigger conditions are written in your contracts and your product roadmap, not in the law's risk annexes.

The Three Ways You Become the Provider

1. You put your name on it. Affixing your trademark to a high-risk system already placed on the market makes you the provider of that system. This is the trigger that catches the most companies by surprise, because white-labelling an embedded vendor capability as "our AI assistant" is a marketing decision that never reaches legal review. If you resell, embed, or brand someone else's high-risk AI, the default outcome is that you own provider obligations for it.
2. You substantially modify it. A change to a high-risk system after it has been placed on the market, not foreseen in the provider's initial conformity assessment, that affects compliance or changes the intended purpose. Fine-tuning on your own data, altering decision thresholds, or wiring in a second model can all reach this line — the detail is in our substantial modification guide.
3. You change the intended purpose. Take a tool sold for one job, point it at a decision listed in Annex III, and you have made a high-risk system out of something that was not one. The classic version: a general summarisation or ranking feature quietly becomes the first filter in a hiring or credit workflow because a team found it useful there.

Note what these have in common. None of them is a legal event. Each is a product, marketing, or operations decision made at ordinary speed by people who do not think of themselves as making a regulatory choice. The control is not a policy document; it is a gate in the change process plus contract terms that make the vendor tell you when their side moves.

The Clauses to Negotiate Before Renewal

1. Role allocation, stated explicitly. A recital that identifies the vendor as provider and you as deployer for each system in scope, with a list of the acts that would change that allocation. This does not bind a regulator, but it forces both sides to agree in writing what the system is for — which is exactly the fact an intended-purpose dispute turns on.
2. Instructions for use as a deliverable. Article 13 requires the provider to supply instructions containing the intended purpose, performance characteristics and known limitations, human oversight measures, and expected lifetime and maintenance. Name that document in the contract, require it in a durable form, and require it to be reissued on material change. You cannot prove you used a system according to instructions you were never given a stable copy of.
3. Advance notice of changes that affect conformity.Standard SaaS terms reserve the vendor's right to change the service at will. For a high-risk system that is backwards: you need enough notice to reassess oversight, retrain reviewers, and check whether the change is one the provider has re-assessed or one that quietly lands on you.
4. Log retention, export, and a six-month floor. Fix the retention period at or above your statutory minimum, define the export format and interface, and require the vendor to preserve logs beyond the default on a litigation or authority hold. Retention that the vendor can shorten unilaterally is not retention.
5. Annex IV and conformity cooperation. Access to the declaration of conformity and CE marking evidence; the EU database registration entry; and a commitment to cooperate — including providing the technical information reasonably required — if a modification or rebranding makes you a provider. This is the single clause that converts an unsurvivable role flip into a manageable one.
6. Serious incident cooperation, on a clock. Deployers must inform the provider and, in defined cases, the authority. That is only possible if the vendor tells you what happened, promptly, in writing. Put a defined hour count on it rather than "without undue delay", and tie it to your incident reporting workflow.
7. Authorised representative confirmation. For a non-EU provider, the name and contact details of the Union authorised representative, warranted current for the term. See our authorised representative explainer for what that appointment actually covers.
8. GPAI flow-down. Where your vendor builds on a general-purpose model from a third party, require the upstream documentation and usage restrictions to flow down to you, along with notice if the upstream model is swapped. A model substitution beneath a stable product name is invisible from your side and can change everything you asserted about performance.
9. Testing permission. An express statement that your own evaluation, red-teaming, and monitoring of the system do not breach the acceptable use policy. Many AUPs prohibit benchmarking or probing, which would make your oversight duties literally a breach of contract.
10. An honest indemnity conversation. Ask which claims the indemnity excludes, not what it covers. Fines are frequently uninsurable and commonly excluded; if the answer is that regulatory exposure sits with you, that is a legitimate position and worth knowing before you price the deal.

The Rebranding Trap, Concretely

A mid-market HR platform licenses a third-party CV-ranking engine and surfaces it in-product as "Smart Shortlist." Nothing about the model changed. The vendor still trains it, still evaluates it, still ships updates. But the customer sees the platform's brand on a high-risk system, and Article 25 reads on that fact directly.

The fix is not always to abandon the branding — that may be the product. The fix is to decide deliberately, and if you take the provider role, to obtain by contract the artefacts you will need to discharge it: technical documentation, evaluation results, data governance evidence, and a commitment from the underlying vendor to support conformity assessment and post-market monitoring. A provider role you chose with a cooperation clause behind it is workable. A provider role you acquired through a naming decision, discovered during an authority inquiry, is not.

The same reasoning applies inside a group of companies. Where a parent buys and a subsidiary re-badges, the analysis follows the trademark and the market placement, not the org chart.

Diligence Questions That Beat a Compliance Brochure

Do you classify this system as high-risk, under which Annex III point, and what is the stated intended purpose you assessed against?
Show us the instructions for use as delivered to customers — not the marketing datasheet.
Is the system registered in the EU database, and can we see the entry?
Which of our configuration options could constitute a substantial modification, and where is that boundary documented?
What logs are generated, where are they stored, what is the default retention, and how do we export them?
How quickly do you notify customers of a serious incident, and through which channel?
Who is your Union authorised representative?
If we brand the feature under our own name, what support will you provide for the obligations that transfers to us?
Which general-purpose model sits underneath, and will you tell us if you replace it?

Frequently Asked Questions

Is a contract clause enough to keep us out of provider status if we rebrand anyway?

No, and that is worth being blunt about. Article 25 attaches to conduct — placing a high-risk system on the market under your name, modifying it substantially, or changing its intended purpose. A private agreement cannot undo the legal consequence of conduct you actually engaged in. What the contract does is different and still valuable: it prevents the conduct from happening by accident, and it obtains the cooperation you would need if you decide to do it on purpose.

We are a US SaaS company with EU customers. Are we the provider or the deployer?

Frequently both, for different systems. You are likely the provider of the AI features you build into your own product and place on the EU market, and the deployer of tools you use internally on EU staff or applicants. Companies get into trouble by picking one identity and applying it everywhere. Build the inventory system-by-system and record the role and reasoning for each. Our guide for US SaaS selling into Europe walks the wider obligation set.

The vendor refuses to change anything in their standard terms. Is this exercise wasted?

Not wasted, but redirected. Where you cannot amend, ask for the same content as a written side letter or an addendum — many vendors will provide documentation and notice commitments they will not restructure a master agreement to accommodate. Where you get nothing at all, that answer is itself a procurement finding: record it, compensate with tighter human oversight and narrower deployment, and factor it into renewal. Documented compensation for a known gap is a defensible posture; silence is not.

Do these clauses matter for AI that is not high-risk?

A reduced version does. Limited-risk systems carry transparency duties — telling people they are interacting with an AI system, and marking synthetic content — and you need to know from the vendor whether the product does that natively or expects you to. GPAI-derived features carry documentation expectations upstream. The log, change-notice, and testing-permission clauses are worth having for any consequential system regardless of classification, because they are what make monitoring possible at all.

How does this interact with our existing GDPR data processing agreement?

It sits beside it. A DPA allocates roles for personal data processing — controller, processor, subprocessors, transfers, security. The AI Act allocates roles for the system — provider, deployer, importer, distributor. The two role sets do not map onto each other, and a company can be a controller and a deployer, or a processor and a provider, in any combination. Draft the AI terms as a distinct addendum and do not assume the privacy paper reached the conformity, logging, or modification questions, because it did not.

Start With the Renewal Calendar, Not the Policy

The useful first artefact is a three-column list: every AI system that touches an EU decision or EU users, the role you believe you hold for it, and the date the agreement renews. That list tells you when each negotiation window opens and which systems have no window at all because nobody knows who sold them.

Ninety days before each renewal, send the diligence questions above. The answers will resolve most of what your risk register currently records as unknown — and where a vendor will not answer, you will have learned it while you still have the leverage of a signature to withhold.