Buying AI software: what the vendor contract must cover

Which points must a contract with an AI vendor secure? At a minimum a data processing agreement under Article 28 of the General Data Protection Regulation, as soon as the vendor processes personal data on your behalf, and for a high-risk system the instructions for use required by Article 13 of the AI Act. Everything else builds on these two mandatory pieces.

Stand: 2026-09-22

Most companies sign whatever the vendor puts in front of them. That is understandable, because the offer looks finished and the price is right. But a vendor's standard terms are written for the vendor, not for you, and the legal responsibility for using the AI stays with the company that bought it. Miss that, and you buy a tool while inheriting a risk.

Why the vendor's standard terms are not enough

The moment you run AI software in your business, you occupy two roles at once. Under data protection law you are the controller, because you decide the purpose and means of the processing. Under Regulation (EU) 2024/1689, the AI Act, you are usually the deployer, because you use the system under your own authority. Both roles carry duties, and you can only meet those duties if the vendor supplies what you need.

Standard terms rarely do that. They cover liability limits, availability and payment, which are the vendor's interests. Whether your customer data leaves the EU, whether the system feeds model training, and whether you receive the documentation a supervisory authority may demand from you, is often absent or phrased in a way that does not help you. The contract is the one place where you can lock these points down before you sign. Afterwards you negotiate from a weaker position.

The data processing agreement is mandatory, not optional

If the vendor processes personal data on your behalf, and almost any AI that touches email, contracts, HR files or customer requests does, then Article 28 of the General Data Protection Regulation requires a written data processing agreement. Without one, the processing is exposed even when everything runs cleanly on the technical side.

The agreement must name the subject matter, duration, nature and purpose of the processing, along with the types of data and the categories of people affected. Article 28(3) then lists eight points that every such agreement must contain. The processor acts only on your documented instructions. The people involved are bound to confidentiality. Technical and organisational security measures under Article 32 apply. Sub-processors are used only with your authorisation and under the same duties. The vendor helps you respond to requests from data subjects. It helps you with breach notifications, data protection impact assessments and consultations with authorities. At the end of the contract it deletes or returns all data. And it keeps evidence available for audits and tells you when, in its view, one of your instructions breaches data protection law.

This list is not a wish list but binding law, in force since 25 May 2018. Check the draft the vendor hands you against it, point by point. If one is missing, the agreement is incomplete, and the gap lands on you rather than the vendor when it matters.

The hardest question: does the vendor train on your data?

This is the question management asks first, and it has a clear legal edge. Under Article 28(3)(a) a processor may handle your data only on documented instructions. Improving the vendor's own models with your inputs is not processing on your behalf, it is a purpose of the vendor's own. Without an explicit basis in the contract, that is not covered, as we read it.

Do not rely here on a reassuring conversation, rely on the wording. A sensible clause rules out training on your content by default and permits it only under a separate, revocable agreement. Alongside it comes the question of where the data sits, because a transfer to a third country opens its own chapter of documentation duties. And it includes how long inputs are stored and whether they are genuinely deleted after processing. With many cloud services the answer depends on the plan you booked: the business tier with a data processing agreement treats data differently from the freely available service. What applies is decided by the contract you sign, not by the marketing page.

What the AI Act adds on top

Up to here it was about data protection. The AI Act lays a second layer over it. If you deploy a high-risk system under Annex III, for example to screen job applications or assess creditworthiness, Article 13 obliges the provider to supply instructions for use. They must describe the characteristics, capabilities and limitations of the system clearly and completely, together with the provider's contact details. This is not an accessory. Your own deployer obligations under Article 26, to use the system as instructed, to assign competent human oversight, and to keep the automatically generated logs for at least six months, are simply impossible to meet without this information. Ask for the instructions for use as part of the contract, not as a later extra.

For systems below the high-risk threshold, Article 50 usually applies, the transparency duty that has been in force since 2 August 2026. A chatbot must reveal that it is a machine, and AI-generated content must be marked in a machine-readable way. Settle in the contract who implements that marking technically, the vendor through the product or you in your own presence. Keep one role in view: whoever substantially modifies a bought-in system or passes it on under their own name can become a provider themselves and inherits that far heavier set of duties. When that switch flips, we set out in deployer or provider.

The clauses no law requires and that still count

Beyond the statutory duties, a handful of clauses decide whether the purchase still holds up in three years. Fix where the data is stored, ideally inside the EU, because that simplifies the data protection review structurally. Agree a lead time before the vendor swaps the underlying model, because a silent model change can alter established workflows overnight. Secure a clean exit, with an export of your data in a common format and a clear deletion confirmation. And settle liability for third-party rights, in case the AI outputs contain someone else's content.

None of these clauses is legally forced, and none is expensive as long as it is negotiated before you sign. After signing they are often no longer available at all. That is the real reason to take the contract seriously before the product wins you over.

The shortest contract is the one you do not need

Every one of these clauses addresses the same underlying problem: your data sits with a third party, and you have to claw back by contract what you gave away by handing it over. When the AI runs on your own hardware instead, most of that contract surface disappears, because there is no processor whose behaviour you have to secure. Local AI moves control back from the contract text into your own network, and the question of training on your data answers itself. More on that on our page about data sovereignty.

This text sets out the legal position as we understand it and does not replace individual legal advice. Which clauses your particular purchase needs is best checked against the actual offer in a pilot project.