Procurement teams buying AI capability are working through a familiar sequence: a new regulatory framework arrives, compliance guidance proliferates, and the contract template grows by several pages of provisions that are difficult to negotiate and harder to operate. The AI Act is producing that pattern now, and the clause sets circulating are considerably longer than they need to be.
The useful starting point is narrower. The framework allocates duties by role, principally provider and deployer, with additional rules for general-purpose models. Most buyers of AI capability are deployers of systems supplied by others, and a deployer has a defined and limited set of obligations. The contract exists mainly to secure the inputs a deployer needs to meet them.
This article sets out that clause set: what to establish about roles, what documentation to require, which operational provisions matter, and where the genuinely contested negotiations sit. Data processing terms interact with this and are covered in dpa-gdpr-ccpa-clm-enforcement-checklist.html.
Establish the roles before drafting anything
Role allocation determines the whole clause set, and it is system-specific rather than vendor-specific. The same supplier may be a provider for one product and something else for another.
- Provider, the party that develops a system or has one developed and places it on the market or puts it into service under its own name or trademark
- Deployer, the party using a system under its own authority in a professional capacity, which describes most enterprise buyers most of the time
- Role shifts, a deployer that puts its own name on a system, substantially modifies it or changes its intended purpose can assume provider obligations
- General-purpose model layer, where a system is built on a general-purpose model, upstream documentation duties flow downstream and the contract should preserve that flow
- Distributor and importer roles, relevant where systems are resold or brought into the market, and worth checking in reseller and marketplace arrangements
The role shift is the provision buyers most often miss. Deploying a supplied system under an internal product name, or adapting it to a purpose the supplier did not intend, can move a buyer into a category with materially heavier duties. The contract should record the intended purpose as the supplier defines it, and internal governance should require a check before that purpose is varied. Reseller and marketplace arrangements deserve a separate check for the same reason, since a party that resells a system under its own branding may have taken on duties its agreement with the upstream supplier does not address.
Vendors frequently offer a general warranty of compliance with applicable law in place of the specific documentation and information duties a buyer needs. The warranty is worth having and does not help operationally. A deployer meeting its own obligations needs the instructions for use, the information supporting classification, and transparency material it can actually give to affected people. Ask for the artifacts, and treat the warranty as additional rather than as an alternative.
The clauses that do operational work
These five provisions produce something the buyer can use, as distinct from provisions that allocate risk on paper.
- Documentation and instructions for use. Delivery of technical documentation and instructions sufficient for the buyer to operate the system within its intended purpose and to meet its own obligations.
- Classification support. Information sufficient to determine whether a system falls into a regulated category, and a duty to inform the buyer if the supplier assessment changes.
- Transparency artifacts. Material the buyer can pass to people interacting with the system or affected by its outputs, in a form suitable for that use rather than as internal documentation.
- Change and model update notice. Advance notice of material changes to the model, training data or intended purpose, with a right to assess before the change takes effect in production.
- Training data and customer data use. Whether buyer data, inputs or outputs are used for training or improvement, with an opt-out that is contractual rather than a configuration setting.
A five-step roadmap for AI vendor contracting
Step 1, Inventory AI systems, not AI vendors
Build the register at system level with intended purpose, business owner and the role the organization takes. A single vendor may supply several systems with different classifications, and a vendor-level register cannot express that.
Step 2, Classify before negotiating
Determine the likely category for each system before opening contract discussions. Negotiating a heavy clause set onto a low-risk internal productivity tool wastes leverage that is better spent on the systems where the duties are substantive.
Step 3, Build a tiered clause set
Maintain a baseline set for all AI procurement and an extended set for systems in regulated categories. Tiering is what keeps the process workable at the volume of AI purchases most organizations are now making.
Step 4, Fix the change notice provision
This is the provision most worth negotiating hard. Models change in ways conventional software does not, and a system assessed as acceptable can behave differently after an update the buyer was never told about.
Step 5, Connect the register to the contract record
Link each system entry to the agreement, the documentation received and the obligations tracked. A separate AI inventory maintained by a governance team will diverge from the contract population within two cycles.
See AI supplier obligations tracked against contracts
Walk through system-level registers, documentation duties and change notice tracking on vendor agreements.
Where the negotiations actually get difficult
Three provisions reliably produce resistance, and it is worth knowing which to press. The first is training on customer data. Vendors whose commercial model depends on improving models from usage will resist a contractual prohibition, and the common compromise, an administrative setting the buyer can toggle, is weaker than it appears because settings change during platform migrations and product transitions. A contractual commitment survives those events. The second is change notice. Suppliers operating continuous delivery genuinely cannot give advance notice of every model update, and an unrealistic demand will be refused or ignored. A workable position defines materiality, seeks notice for changes affecting intended purpose, accuracy characteristics or data handling, and accepts post-hoc notification for routine updates. The third is audit and information rights. Vendors resist access to models and training processes for reasons that are not purely defensive, and pressing for direct audit rights usually fails. What succeeds is specifying the artifacts to be delivered, including evaluation results, documentation and incident information, together with a duty to cooperate with regulatory requests. That is less satisfying than an audit right and considerably more useful, because artifacts arrive on a schedule while audit rights are exercised rarely and at cost.
Clause priorities by system role
The table indicates where to concentrate contractual effort depending on the role the organization takes for a given system.
| Clause | Deployer priority | Provider priority |
|---|---|---|
| Documentation and instructions | High, needed to operate compliantly | High, must be produced and maintained |
| Classification support | High, drives own obligations | High, own assessment duty |
| Transparency artifacts | High, passed to affected people | Medium, supplied downstream |
| Change and update notice | High, affects deployed behavior | Medium, upstream dependency |
| Training data use terms | High, commercial and privacy effect | High, upstream data provenance |
The clause set that matters for AI procurement is shorter than the guidance volume suggests, but it depends on a determination most organizations have not made systematically: which role they take for each system. Make that determination first, build a tiered clause set around it, and spend negotiating effort on change notice and training data use rather than on general compliance warranties. Keep the system register connected to the contract record, because an inventory that drifts from the agreements is worse than useful. The register is also what makes the next framework cheaper to absorb, since the same system-level facts answer most of the questions any successor regime will ask.
For related guidance, see SaaS renewal and vendor consolidation, at a glance, The IT leader’s guide to SaaS vendor contract sprawl and OCC and FFIEC expectations for vendor contract files.
