EU AI Act Vendor Contracts: What to Actually Require From Your AI Suppliers

Most of the EU AI Act conversation is aimed at the companies building AI. But the majority of companies don't build AI, they buy it. They drop a third-party model or tool into their product or their operations and move on. If that's you, here's the uncomfortable part: you have your own obligations as a deployer, and your vendor's compliance failures can quietly become your problem.

The single most effective place to protect yourself isn't a policy document or a compliance tool. It's the contract you sign with the vendor. That's the lever, and most companies leave it completely slack.

Why the contract is your main lever

Article 26 gives deployers of high-risk AI concrete duties: use the system according to its instructions, assign competent human oversight, monitor operation, and keep the logs the system generates. The catch is that you physically cannot do most of that without information that only the provider has.

You can't "use the system according to its instructions" if the instructions are three paragraphs of marketing. You can't keep the logs if the vendor doesn't give you access to them. You can't monitor for the risks the provider already knows about if they never disclosed them. Article 25, which governs responsibilities along the AI value chain, assumes information flows down the chain from provider to deployer. If that flow is broken, your compliance is broken, and it's broken in a way you can't fix on your own.

Start with who's who

Before any specific clause, the contract should state plainly, for each AI system it covers, who is the provider and who is the deployer under the AI Act. It sounds obvious. It routinely isn't in the contract at all.

This matters because the roles carry different obligations, and because you can accidentally becomea provider. If you substantially modify a high-risk system, or put your own name on it, or use it for a purpose the original provider didn't intend, the Act can treat you as a provider with the full weight of provider obligations. The contract should nail down the intended purpose and the boundaries of your use, so you know which side of that line you're on. Our deployer vs provider guide covers where that line sits.

The clauses to actually require

Here is the practical list. If your AI vendor contract doesn't address these, you're carrying risk you don't need to.

• Compliance confirmation. The provider warrants that, where the system is high-risk, they have completed the required conformity assessment, and that they will maintain the system's compliance status for the life of the contract.
• Documentation and instructions for use. The provider commits to supplying complete instructions for use and the technical information you need to meet your own obligations. Not marketing collateral. The actual Article 13 material. If it's thin, you can't comply, so make adequacy a condition.
• Logging access. You have a contractual right to the logs the system generates, in a usable form, for as long as you need them. Article 26 requires deployers to keep these; you can only keep what you can get.
• Notification duties. The provider must notify you of substantial modifications to the system, of compliance incidents or serious incidents, and of any regulatory investigation touching the system. You cannot react to what you're not told.
• Change control. Model updates, retraining, or changes to intended purpose don't happen silently under your feet. Material changes come with notice and, ideally, the right to assess before they go live.
• Indemnity for their failures. If a regulator fines you because of the provider's own AI Act compliance failure, or because their training data infringed third-party IP, that liability should sit with them. Indemnities should cover regulatory penalties from the provider's failures, IP infringement in training data or outputs, and losses from defective outputs.
• Audit or evidence rights. For high-risk systems especially, the ability to request evidence of compliance, or a right to audit, so "we're compliant" is verifiable rather than a promise.

The EU wrote model clauses (use them)

Here's the part almost nobody takes advantage of. You don't have to draft these from scratch. The EU already did.

The Public Buyers Community, a European Commission initiative, published Model Contractual Clauses for the procurement of AI (the MCC-AI), with an updated version in March 2025. There are two:

• MCC-AI High-Risk — the full version, built around the Chapter III obligations for high-risk AI systems.
• MCC-AI Light — for systems that aren't high-risk but still carry some risk. It mirrors the high-risk version but drops the heavier items: the supplier's quality management system, conformity assessment, EU database registration information, and the buyer's audit right.

They come with commentary explaining how and when to use them. They were written for public-sectorprocurement, so they're not a drop-in for every private contract. But they've become a recognised best-practice reference for private AI contracting too, and they're a far better starting point than a blank page or a generic SaaS template that never heard of the AI Act.

The data and fine-tuning trap

One area that catches people: data you hand the vendor. If you share data to fine-tune or customise a model, the contract needs to say what happens to it. Who is responsible for the governance of that data under Article 10. Whether your data trains models used by other customers. What happens to it when the contract ends.

This is also where AI Act obligations and GDPR collide, so the data terms in an AI vendor contract have to do double duty. Vague data clauses are how a deployer ends up responsible for training data they never actually controlled.

What to do before you sign

• Classify the system first. High-risk and limited-risk deployments need different contract depth. If you don't know the tier, start with a free classification.
• Pull the MCC-AI (high-risk or light, matching your tier) and use it as your checklist of what to ask for.
• Test documentation adequacy before signing, not after. If the instructions for use won't let you meet Article 26, that's a reason to renegotiate or walk.
• Get the notification and indemnity clauses in writing. These are the two that protect you when something actually goes wrong.
• Revisit existing contracts too. Most AI tools were signed before anyone thought about the AI Act. Renewal is your chance to fix the terms.

The through-line is simple. As a deployer, you are relying on someone else to have built and documented their AI properly, and the AI Act still holds you responsible for how you use it. The contract is where you turn "we trust our vendor" into "we can prove what our vendor owes us." For the wider set of duties that come with using someone else's AI, start with our guide to deployer obligations.