Buying AI-enabled software has become a contracting problem rather than only a procurement one. The EU AI Act allocates obligations by role and by risk classification, and the roles are functional rather than nominal. A company that buys a system and deploys it in its own operations is generally a deployer. A company that puts its name on a system, substantially modifies it, or changes its intended purpose can become a provider, with a materially heavier obligation set.
That structure means the first question in an AI vendor negotiation is not about liability or price. It is about which party holds which role for this system in this use case, and what happens to that allocation if either side changes something. Buyers who skip the question end up with a clause set drafted for a role they do not occupy, and obligations they cannot meet because they lack the information rights to do so.
This guide covers how to establish role and risk classification during vendor selection, the clause terms that follow from each position, the information rights buyers need in order to satisfy their own obligations, and the change notification mechanics that keep the classification current through the life of the agreement.
Establish role and classification first
Everything downstream depends on two determinations made early. Neither is a legal formality, because both change what the contract has to require.
- The role each party holds, provider, deployer, importer or distributor for this system in this deployment, recorded with the reasoning rather than assumed from the commercial relationship
- The risk classification, whether the system is prohibited, high risk, subject to transparency obligations, or minimal risk, assessed against the specific intended purpose rather than the product category
- The intended purpose as deployed, the actual use in the buyer’s operations, since the same system can fall into different classifications depending on what it is used for
- Any modification the buyer will make, fine-tuning, rebranding, or repurposing, each of which can shift the buyer toward provider obligations
- General purpose model dependencies, whether the system builds on a general purpose model, which carries its own obligations upstream and affects documentation availability
These determinations should be made during evaluation and recorded on the contract record, not settled in a legal review two days before signature. They drive the clause set, the due diligence depth and the ongoing monitoring obligations, and revisiting them after the commercial terms are agreed rarely improves the buyer’s position.
A buyer that fine-tunes a model on its own data, rebrands the system, or deploys it for a purpose the provider did not intend can assume provider obligations for that system. Where the buyer intends to do any of these, the contract should say so explicitly and allocate the resulting documentation and conformity responsibilities rather than leaving them to be argued later.
Clause terms that follow from the classification
Once role and classification are settled, a defined set of clause terms follows. These are the provisions that make the buyer’s own compliance achievable rather than aspirational.
- Technical documentation access. The buyer needs access to documentation sufficient to understand capabilities, limitations and intended purpose, and to support its own record keeping obligations
- Logging and record availability. Where logs are generated by the provider’s infrastructure, the buyer needs contractual access and a retention commitment, since the obligation to keep records does not move with the infrastructure
- Human oversight enablement. The provider should commit to providing the interfaces and information that make effective human oversight possible, rather than leaving oversight as a buyer responsibility with no supporting capability
- Accuracy, robustness and testing evidence. Commitments on performance characteristics, testing methodology and known limitations, with evidence available on request rather than asserted in marketing material
- Incident and serious malfunction reporting. Defined notification timelines to the buyer, aligned to the buyer’s own reporting duties, since a generic notice period is usually longer than the buyer can accept
A five-step contracting sequence
Step 1, Classify during evaluation, not at signature
Run role and risk determination as part of vendor evaluation, with the intended purpose stated as it will actually be deployed. The determination changes which vendors are viable, so making it late wastes the evaluation.
Step 2, Set a required clause set per classification
Maintain distinct clause requirements for high risk deployments, transparency-obligation systems and minimal risk tools. A single AI addendum applied uniformly either over-negotiates low risk purchases or under-protects high risk ones.
Step 3, Secure information rights, not just warranties
A warranty that a system is compliant is worth little if the buyer cannot obtain documentation, logs and testing evidence. Prioritize access rights in negotiation, because they are what make the buyer’s own obligations satisfiable.
Step 4, Define notifiable change narrowly
Require notice of changes to the model, training data sources, intended purpose, or performance characteristics that could affect classification. A broad definition of notifiable change produces noise, and a vague one produces silence.
Step 5, Track obligations after signature
Documentation refresh, testing evidence, incident notification and change notices are ongoing obligations with owners and clocks. Filing the addendum and moving on returns the buyer to the position it was in before negotiating it.
Standardize AI clause sets by risk tier
See classification-driven clause requirements and post-signature obligation tracking on technology agreements.
Why the AI addendum is not the whole answer
Most enterprises responded to AI regulation by drafting an addendum and attaching it to technology agreements. It is a reasonable first move and it is not sufficient, for three reasons. First, an addendum applied uniformly ignores classification, so the same terms are imposed on a minimal risk productivity tool and a system supporting a high risk use case, which produces friction on the first and inadequate protection on the second. Second, addenda are written as warranties and representations, which allocate liability but do not deliver the documentation, logs and evidence a deployer needs to meet its own obligations. Third, an addendum is a point-in-time instrument, and AI systems change continuously, so without a change notification mechanic the classification recorded at signature becomes stale. The durable answer resembles the approach taken to data protection terms, where a tiered clause set, information rights and ongoing obligations replaced the single addendum, as covered in the data processing enforcement checklist.
Role, obligation focus and contract emphasis
The table summarizes how contract emphasis shifts with the role a party holds for a given system and deployment.
| Role | Primary obligation focus | Contract emphasis | Key risk if unaddressed |
|---|---|---|---|
| Deployer, minimal risk | Use consistent with instructions | Basic transparency and change notice | Silent reclassification |
| Deployer, transparency tier | Disclosure to affected people | Notice content and update duties | Inadequate user-facing disclosure |
| Deployer, high risk use | Oversight, logging, monitoring | Documentation and log access rights | Cannot evidence own compliance |
| Buyer who fine-tunes | Provider-style duties may apply | Explicit allocation of responsibility | Unintended provider obligations |
| Buyer who rebrands | Provider duties likely apply | Full documentation and conformity support | Obligations without capability |
AI procurement becomes tractable once role and classification are settled early and the clause set follows from them. The terms that matter most are not the warranties, which are easy to obtain and hard to rely on, but the information rights and change notification mechanics that let a buyer meet obligations it cannot delegate. Buyers that build a tiered clause set and track the resulting obligations after signature will find the work scales across a portfolio, which matters because the number of AI-enabled systems in a typical enterprise is growing faster than the legal capacity to review them individually.
For related guidance, see SaaS renewal and vendor consolidation, at a glance, The IT leader’s guide to SaaS vendor contract sprawl and Auto-renewal clause risk in enterprise SaaS contracts.
