AI stopped being a feature and became a supply chain. A single workflow now draws on a hosted model, a vendor that wraps it, a retrieval layer holding your data, and often a sub-model the vendor did not build. Each relationship is governed by a contract, and most of those contracts were drafted for ordinary software.
That gap is the problem. A standard SaaS master services agreement handles availability, support, fees and data protection. It rarely says who is provider and who is deployer, what happens when the model version changes, how long logs are kept, or what you receive if the relationship ends. Those are the terms that matter.
This article sets out the clause areas a buyer of AI services should ask for, why each exists, and how to hold the resulting duties as tracked obligations rather than paragraphs in a signed file. It is general information for commercial counsel, not legal advice.
What the regulation changes for a buyer of AI services
Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, entered into force in August 2024 and applies in phases rather than all at once. Provisions on prohibited practices and AI literacy apply first, with other obligations, including those attaching to high-risk systems, phasing in later. The structure is risk-based, so what a party must do depends on the system and on the role that party holds.
- A risk-based structure, under which obligations scale with the use case rather than the technology, so one model can sit inside a low-obligation workflow and a heavily regulated one at the same company.
- Provider and deployer roles, which carry different duties and cannot be assumed by default, since the role depends on how a system is placed on the market and how it is used.
- Phased application, meaning obligations arrive on different timelines, so a contract signed today has to accommodate duties not yet operative for either party.
- General-purpose AI model duties, including technical documentation and transparency expectations on the model side, which shape what a vendor can hand over on request.
- Model contractual clauses, published by the European Commission’s community of practice for public buyers, developed for public procurement and used voluntarily, which give private buyers a drafting reference.
None of that becomes contract language on its own. A regulation allocates duties, and a buyer discharges its share using evidence that mostly sits with the vendor. Documentation, logs, model cards, evaluation results and change notices are things you either negotiated a right to receive or did not. The clause set is where exposure becomes manageable.
A buyer can be asked to show how a system was overseen and how it behaved on a given date, while every one of those artifacts lives inside a vendor platform. Without access, retention and a route to documentation in the agreement, your compliance program depends on a supplier’s goodwill.
The clauses standard SaaS paper does not carry
Most AI vendor agreements today are SaaS templates with an acceptable use policy bolted on. They are silent on the questions a regulator, an auditor or an incident review asks first. Five clause areas account for most of that silence, and none are unusual requests once a vendor has met them a few times.
- Role allocation, and what happens when it changes. State which party is provider and which is deployer for each service, and add a reclassification mechanism. Fine-tuning or changing a system’s intended purpose can move a buyer toward provider duties it never planned for.
- Training data provenance and IP indemnity. Ask what the model was trained on at a level the vendor can stand behind, and pair it with an indemnity covering third-party intellectual property claims arising from training data and generated output.
- Model change and version notification. Require advance notice of version changes, material retraining and deprecation, with a notice period and a pinned version option for sensitive workflows. A silent upgrade moves accuracy and cost without any change to your contract.
- Logging and record retention. Set what is logged, how long it is kept and how you retrieve it. Buyers need input and output records to evidence oversight, and default vendor retention is often shorter than the period a buyer must cover.
- Sub-processor and sub-model disclosure. Extend the sub-processor concept to sub-models and inference providers. A vendor routing prompts to a third-party model changes your exposure, so require notice, a right to object and a current list.
A five-step path to AI-ready vendor agreements
Step 1, Inventory Where AI Already Sits
Start by finding the AI you already bought. It is usually embedded in tools procured as ordinary software, so the inventory comes from contract text rather than an application list. Search the executed portfolio for model, inference, training and automated decision language, then confirm each hit with the business owner.
Step 2, Classify Role And Risk Per Service
For each identified service, record the intended use, the role your organization holds and whether the use touches an area the regulation treats as sensitive. Classification is a judgment for counsel with the business, not a field a system can infer, but it belongs on the contract record once made.
Step 3, Build The AI Clause Set
Draft a standard AI schedule and fallback positions rather than negotiating each deal from scratch. Cover role allocation, provenance and indemnity, change notice, oversight support, logging, evaluation, sub-model disclosure, documentation access and exit. Store it in the clause library so a reviewer sees deviations against a known position.
Step 4, Turn Documentation Duties Into Obligations
Documentation access, model cards, evaluation refreshes, change notices and sub-model list updates are dated commitments. Convert each into a scheduled obligation with an owner and an expected artifact, so a vendor that stops publishing evaluation results generates an exception, a discipline described in third-party risk contract automation.
Step 5, Contract The Exit Before You Need It
Agree in advance what you receive on termination. At minimum, your inputs and generated outputs in a usable format, the logs covering your retention window, and any documentation you relied on to evidence oversight. Exit terms written after a relationship sours are the most expensive in the agreement.
See an AI clause set applied to your vendor paper
Walk through role allocation, model change notice, logging and documentation access against a sample of your executed AI and SaaS agreements.
Oversight, evaluation and the interaction with your DPAs
Human oversight is a shared duty in practice. The buyer designs the review step, but the vendor supplies what makes review meaningful, so ask for explainability support proportionate to the use case, confidence signals where they exist, and a description of known limitations. Evaluation is the other half. Accuracy and benchmark commitments should say what was measured, on what data, how often it is refreshed and what happens when performance drifts, because a number quoted once at signature ages badly. Data protection terms usually already exist, so the work is reconciling rather than duplicating. Confirm whether prompts and outputs are personal data and how the AI schedule sits alongside existing processing terms.
An AI clause checklist for the MSA and its schedules
The table sets out the clause areas worth standardizing, what to ask for in each, and where the language usually belongs. Teams that already run a disciplined data protection review will recognize the pattern from DPA enforcement in CLM, and the mechanics of finding these terms across an existing portfolio are covered in AI contract review explained.
| Clause area | What to require | Why it matters to the buyer | Where it usually sits |
|---|---|---|---|
| Role allocation | Named provider and deployer roles per service | Obligations follow the classification | AI schedule to the MSA |
| Model change notice | Advance notice, pinned version option | Silent upgrades move accuracy and cost | AI schedule or service terms |
| Logging and retention | Defined log scope, period and retrieval | Evidence of oversight sits with the vendor | AI schedule and security exhibit |
| Documentation access | Model documentation on reasonable request | Supports the buyer’s own record keeping | AI schedule and audit clause |
| Exit and portability | Return of inputs, outputs and covered logs | Compliance duties outlive the contract | Termination and transition terms |
AI vendor agreements are being signed now on paper written for a different kind of software. The regulation is phasing in, the drafting conventions are still forming, and the practical response is not to wait for either to settle. Fix the role allocation, get change notice and logging, secure documentation access and an exit that returns your own material, and hold the resulting duties as tracked obligations. That much is durable regardless of how the detail lands.
For related guidance, see SaaS renewal and vendor consolidation, at a glance, The IT leader’s guide to SaaS vendor contract sprawl and When the order form and the MSA disagree.
