The most common thing I hear in a procurement conversation about AI is a version of this: they handle the compliance, it’s in the contract.
Does buying an AI system transfer compliance to the vendor?
Buying an AI system does not move the obligations to your vendor. Under the EU AI Act you can become the provider of a system you bought, by putting your name on it or substantially modifying it. Even as a deployer, some duties sit on you directly, including deepfake and public-interest text disclosure under Article 50.
Sometimes that’s true. Often it’s true for less than people think, and occasionally it’s the opposite of true, because the act of buying and then adapting a system is exactly what turns you into the party carrying the obligations.
This is the least understood distinction in the EU AI Act and it’s not a legal subtlety. It changes who does the work.
The two roles
A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its own authority in a professional capacity.
Most companies assume they’re always the deployer because they bought the thing. That assumption is where the trouble starts.
Three ways buyers become providers
You put your name on it. If you take a system and offer it under your own brand, you’re the provider of that system as far as the Act is concerned. The vendor’s compliance work covers the vendor’s product. It doesn’t follow your logo onto your interface. Anyone running a white-labelled assistant should read this twice.
You substantially modify it. Change what the system does, or how it does it, beyond what the original provider intended, and the obligations can transfer to you. This is the one that catches product teams, because substantial modification isn’t a thing you plan to do. It’s a thing that happens in month three, when you fine-tune on your own data, chain it into a workflow it wasn’t designed for, or point it at a use case the vendor never contemplated.
You change the purpose. Take a general tool and apply it to something the provider didn’t intend, particularly if that use lands in a higher risk category, and you can find yourself holding provider duties for a product you didn’t build.
None of these require bad faith or ignorance. They’re all things a competent product team does as a matter of course.
What sits on you even when you stay a deployer
This is the part that gets skipped entirely.
Under Article 50, applicable since 2 August 2026, disclosure of deepfakes is the deployer’s obligation. So is disclosure of AI-generated text published to inform the public on matters of public interest. So is informing people exposed to emotion recognition or biometric categorisation.
Marking synthetic output in a machine-readable format is the provider’s job. Telling your users what they’re looking at is yours. Your vendor can’t do the second one for you, because it happens in your product, to your users, in your interface. I wrote about what Article 50 asks a product team to build in more detail.
Deployers also carry ongoing duties that no contract removes: using the system according to the instructions, assigning human oversight to people with the competence and authority to exercise it, and monitoring operation.
Why the contract does less than you think
A vendor contract allocates liability between you and the vendor. It doesn’t allocate obligations between you and a regulator.
If you’re the provider under the Act, you’re the provider, and an indemnity clause changes who pays afterwards rather than who was required to do the thing. That’s a useful distinction to have straight before somebody tells the board that compliance is contractually covered.
There’s a practical consequence for product work. You need to know your role before you design the feature, because provider duties are largely about how the system is built and documented, and those are decisions you make early or not at all.
The questions I ask before buying
Are we putting our name on this? If the answer is yes, assume provider duties and price them into the decision.
What will we change in the first six months? Ask this honestly. Fine-tuning on your data, chaining it into another system, adapting the prompt layer to a new use case — write down what’s likely, because that list is your substantial modification risk.
What is the intended purpose the vendor declares, and is ours inside it? Get this in writing. It’s the reference point for whether you’ve changed the purpose.
What does the vendor give us for our own obligations? Not their compliance documentation, yours. Can they support your disclosure requirements, your logging, your oversight arrangements? A vendor who has thought about this will have an answer ready.
Can we test on our own data before signing? The same question I’d ask for build or buy generally, and it matters twice as much here, because you can’t assess a system’s failure modes from a demo and you’ll be accountable for them either way.
If you’re in financial services, there’s a second layer
DORA asks a parallel set of questions about third-party providers, concentration risk and exit arrangements, and it does not care that the third party is supplying a model rather than a database. Being the deployer under the AI Act doesn’t make you less accountable for the resilience of a critical dependency. I’ve written about how DORA reads AI systems separately.
What I’d actually do this month
Take your inventory of AI systems and add one column: provider or deployer, with the reason. A maybe doesn’t count. Force the answer.
You’ll find three or four where nobody knows, and one where the honest answer is uncomfortable. That column is the most useful hour of governance work available to you right now, and it costs nothing but the argument.
Common questions
Does buying an AI system transfer compliance to the vendor?
No. A contract allocates liability between you and the vendor; it does not allocate obligations between you and a regulator. If you hold provider duties under the EU AI Act, an indemnity clause changes who pays afterwards rather than who was required to act.
When does a deployer become a provider under the EU AI Act?
Three common routes: placing the system on the market or into service under your own name or trademark, substantially modifying it beyond what the original provider intended, or changing its purpose to something the provider did not contemplate, particularly into a higher risk category.
What is substantial modification?
A change to what the system does or how it does it that goes beyond the original provider's intent. In practice it rarely looks like a decision: it looks like fine-tuning on your own data, chaining the system into a workflow it was not designed for, or pointing it at a new use case in month three.
What obligations does a deployer have that the vendor cannot cover?
Under Article 50, applicable since 2 August 2026, disclosure of deepfakes and of AI-generated public-interest text sits with the deployer, as does informing people exposed to emotion recognition or biometric categorisation. Deployers must also use the system according to instructions, assign human oversight to people with the competence and authority to exercise it, and monitor operation.
Who has to mark AI-generated content, the vendor or us?
Machine-readable marking of synthetic output is the provider's obligation. Telling your users what they are looking at happens in your product, to your users, and is yours.
What should you ask an AI vendor before buying?
Whether you will be putting your own name on the system, what you realistically expect to change in the first six months, what intended purpose the vendor declares and whether yours falls inside it, what support they offer for your own obligations rather than theirs, and whether you can run your own evaluation on your own data before signing.
Does DORA apply to bought AI systems in financial services?
DORA's requirements on third-party providers, concentration risk and exit arrangements apply regardless of whether the third party supplies a model or a database. Holding the deployer role under the AI Act does not reduce accountability for the resilience of a critical dependency.
I’m an AI product manager working across fintech, SaaS, and regulated enterprise — currently leading AI and workflow product at T-Systems International. If you’re building AI governance into a product right now and want to compare notes, I’m at csincsakf@gmail.com or on LinkedIn.
If you are working out which role you hold across a set of bought AI systems, that is the kind of question I take on as fractional work.