AI Contract Clauses Guide: Data, Liability, Model Change

Standard software and SaaS contracts were not written for products whose behaviour changes when the supplier swaps a model, and whose inputs may become someone else's training data. The gaps show up after signature: a supplier changes its terms to allow training on customer prompts, a model upgrade shifts accuracy in a regulated process, or an AI integration's tokens are stolen and nobody agreed who notifies whom. This guide sets out the contract areas that matter for buying AI, with example points to negotiate in each, drawn from the European model contractual clauses for AI procurement (MCC-AI), the EU AI Act, US OMB memo M-25-22, UK government AI procurement guidance, GDPR Article 28 and the NIST AI RMF. It is written for security, privacy, procurement and legal teams who review AI supplier contracts. The examples are points to raise with your lawyers and suppliers, not finished legal drafting.

Key takeaways

Write the data terms first. A contractual commitment that customer inputs and outputs are not used to train or improve models, with retention limits, matters more than any other AI-specific clause.
Model change is a contract event. Require advance notice of material model changes, the right to test before they apply, and a rollback or exit route if performance drops.
Use the model clauses as a checklist, not a contract. The MCC-AI (updated 5 March 2025) cover AI Act style requirements but leave intellectual property, liability, warranties and data protection to be negotiated separately.
Allocate EU AI Act roles explicitly. Article 25 can turn a deployer into a provider, and Article 25(4) requires written agreements between high-risk providers and their suppliers on information, technical access and assistance.
Plan the exit at signature. Portability of data, prompts, fine-tuned models and logs, plus deletion certificates, is far easier to agree before go-live than at termination.

Reference clause sets and what each covers

Several public sources give buyers a starting point. None is a complete contract, and the public-sector ones are written for public bodies, but each is useful for private buyers as a list of issues.

Source	Status	What it helps with	What it leaves out
EU MCC-AI High-Risk	Updated version published 5 March 2025 by the Procurement of AI Community of Practice; first version 29 September 2023; non-binding	Obligations for high-risk AI aligned to the AI Act Chapter III requirements (risk management, data governance, transparency, human oversight, accuracy, robustness, cybersecurity)	IP, liability, warranties and data protection, which must be negotiated separately
EU MCC-AI Light	Same publication; for non-high-risk AI and some algorithmic systems	A customisable subset for lower-risk systems	Omits some provisions of the high-risk version, such as conformity assessment and audit provisions
OMB M-25-22 (US federal)	Issued 3 April 2025; rescinded M-24-18; applies to solicitations issued 180 days after issuance	No training on non-public agency data, portability, independent testing, change notification, rights at contract end	Binding on federal agencies only; national security systems excluded
OMB M-26-04 (US federal)	Issued 11 December 2025, implementing Executive Order 14319	LLM-specific terms; agency clauses implementing it include acceptable use policies, documentation of limitations and advance notice of material model changes	Applies to federal LLM procurement; focused on its two principles
UK Guidelines for AI procurement	Published 8 June 2020, not withdrawn; complemented by the AI Playbook for the UK Government (10 February 2025)	IP in new or retrained algorithms, explainability, avoiding lock-in, knowledge transfer, end-of-life for system and data	Guidance, not clauses
GDPR Article 28	In force	Mandatory processor terms (Article 28(3)(a) to (h)) and sub-processor authorisation (Article 28(2))	Nothing AI-specific; training use and model retention must be added

The MCC-AI are not officially endorsed by the European Commission; the Commission supported the Community of Practice that produced them. Recital 90 of the AI Act separately allows the Commission to develop and recommend voluntary model contractual terms between high-risk providers and their suppliers. Check whether any official terms have been published before relying only on the community clauses.

Roles and the EU AI Act value chain

Many AI obligations depend on who is the provider and who is the deployer, and the contract should record the parties' shared understanding.

Role triggers: under Article 25(1), a deployer or other third party is treated as the provider of a high-risk AI system if it puts its name or trademark on it, makes a substantial modification, or modifies the intended purpose so that the system becomes high-risk. Example point to negotiate: a schedule stating the intended purpose, the permitted configuration and fine-tuning, and which changes the supplier agrees do not amount to a substantial modification.
Supplier cooperation: Article 25(4) requires the provider of a high-risk system and the third party supplying AI systems, tools, services, components or processes used in it to specify, by written agreement, the information, capabilities, technical access and other assistance the provider needs. If [Organisation] is the provider, this agreement is a legal requirement, not a negotiating nicety.
Deployer support: deployers of high-risk systems must use them in line with the instructions for use, assign human oversight, monitor operation, inform the provider of serious incidents and keep logs under their control for at least six months (Article 26). Example point: the supplier provides instructions for use meeting Article 13(3), and log access or export that lets [Organisation] meet the six-month retention.
General-purpose models: where the product is built on a general-purpose AI model, Article 53(1)(b) requires the model provider to give downstream providers information on capabilities and limitations (Annex XII). Example point: the supplier passes this information on, or confirms it has it.
Timing: the AI Omnibus, published in the Official Journal on 24 July 2026, moved the Annex III high-risk obligations to 2 December 2027 and Annex I obligations to 2 August 2028. Multi-year contracts signed now should include a change-in-law clause that covers these dates and any further amendments.

See the EU AI Act Compliance Guide and the EU AI Act High-Risk AI Systems Guide.

Data use, training and confidentiality terms

OWASP's 2025 Top 10 for LLM Applications (LLM03 Supply Chain) names unclear terms and privacy policies as a risk, with a scenario in which an operator changes its terms to require an explicit opt-out from training on application data. A contract term is the control.

Clause area	Example points to negotiate	Anchor
No training or improvement	Supplier and its model providers do not use [Organisation] inputs, outputs, files or embeddings to train, fine-tune or improve any model offered to others, unless [Organisation] gives prior written consent	M-25-22 requires agencies to bar training of publicly or commercially available AI on non-public agency inputs and outputs without consent
Retention	Maximum retention period for prompts, outputs and logs per data class; option for zero retention; abuse-monitoring copies included in the limit	GDPR Article 5(1)(e) storage limitation; Article 28(3)(g) deletion or return
Human access	Conditions under which supplier staff may view customer content, logged and notified	GDPR Article 28(3)(b) confidentiality
Purpose limitation	Supplier collects and retains data only as reasonably necessary to deliver the contract	M-25-22 section 3(e)
Sub-processors and model providers	List of sub-processors including foundation model providers and hosting regions; prior notice and objection right for changes	GDPR Article 28(2)
Derived artefacts	Fine-tuned models, adapters, retrieval indexes and vector stores built from [Organisation] data are [Organisation] confidential information and are deleted or returned at exit	UK AI procurement guidance on end-of-life for system and data
No change by policy	Data commitments cannot be reduced by updates to online terms, privacy policies or product settings	OWASP LLM03 scenario on changed terms

Where personal data is processed, the AI terms sit alongside the Article 28 processor agreement, not instead of it. See the AI and GDPR Guide and the GDPR Compliance Guide for Security Teams.

Model change and performance terms

An AI product can change materially without a new release number. The contract should treat model changes the way it treats changes to a critical sub-processor.

Change notification: advance notice of [notice period, for example 30 days] before replacing, retraining or materially changing the underlying model, or adding new AI features. M-25-22 says vendors should notify agency stakeholders before integrating new AI enhancements, features or components, and DOE clauses implementing M-26-04 require advance notice of material model changes.
Define "material": examples include a change of model provider or model family, a change in hosting region, a drop in agreed metrics, new data uses or new autonomous actions.
Testing rights: [Organisation] may evaluate the changed model on its own data in a staging environment before it applies to production, and testing results may be shared internally. M-25-22 asks agencies to allow periodic independent evaluation using agency-defined data the vendor cannot access, and says contracts must not bar internal disclosure of testing results.
Version pinning and rollback: the right to stay on the current model for [period], or to roll back if agreed performance standards are not met. M-25-22 refers to vendors meeting performance standards before deploying new versions, with a rollback option.
Performance levels: stated metrics for the use case (for example extraction accuracy on an agreed test set), how they are measured and what remedies apply. For high-risk systems, the instructions for use must state accuracy levels and metrics (Article 13(3)(b)).
Default-off features: new AI features in an existing product are off until an administrator enables them.

Security, identity and incident terms

AI products usually connect to business systems with OAuth grants, API keys or service accounts. Those non-human identities, and the data behind them, are what attackers target.

Security baseline: a schedule of controls aligned to ISO/IEC 27001 or the supplier's SOC 2 scope, plus AI-specific testing for prompt injection, sensitive information disclosure and excessive agency (OWASP LLM01, LLM02, LLM06), with a right to receive summaries.
Least privilege for integrations: the supplier requests only the OAuth scopes and API permissions listed in the schedule, supports customer-controlled rotation and revocation, and stores [Organisation] credentials in a secrets manager. See the Third-Party Access Guide.
Agent actions: where the product includes AI agents, each agent acts under a distinct identity, actions are logged, and [list of high-impact actions] require human approval.
Incident notification: notice within [hours] of a security incident affecting [Organisation] data or credentials, including incidents at model providers and sub-processors, with the information needed to revoke tokens and keys. NIST SP 800-53 SR-8 (Notification Agreements) is the control to map this to.
Serious incidents under the AI Act: for high-risk systems, agree how the deployer's duty to inform the provider immediately of a serious incident (Article 26(5)) works in practice: contact points, channel and timelines.
Logs: access to sign-in, admin, prompt and tool-call logs in a stated format and retention, exportable to [SIEM].

The Salesloft Drift breach shows why: OAuth tokens held by one chatbot integration gave attackers access to many customers' Salesforce tenants, and each customer's ability to respond depended on fast notification and on being able to revoke the integration's tokens.

Transparency, documentation and audit terms

Documentation: capabilities, limitations, intended and precluded uses, known failure modes and data handling, kept current. For high-risk systems, instructions for use with the contents of Article 13(3), including human oversight measures and logging mechanisms.
Supply chain disclosure: the foundation models, key datasets, libraries and hosting the product depends on, ideally as an AI-BOM, updated on change. See the AI Supply Chain and AI-BOM Guide.
Audit and information rights: the right to receive information needed to demonstrate compliance and to audit, or to rely on independent reports (GDPR Article 28(3)(h) for processing; extend it to AI controls). The MCC-AI high-risk version is the fuller source here.
Supplier use of AI: disclosure of where the supplier uses AI in delivering the service, as M-25-22 suggests agencies consider.
Explainability: UK guidance advises avoiding reliance on black-box algorithms; agree what explanation of outputs the supplier provides for the use case.

Liability, indemnities and intellectual property

The MCC-AI leave these points to the parties, and they are where most negotiation time goes.

Liability caps: standard SaaS caps (often a multiple of annual fees) may be low compared with the exposure from a data breach or a regulatory fine. Example point: a higher or separate cap for breaches of data use, confidentiality and security obligations.
IP in outputs: who owns outputs, whether the supplier claims any licence to them, and whether [Organisation] can use them commercially.
IP infringement indemnity: whether the supplier indemnifies against third-party claims that the model or its outputs infringe copyright or other rights, and the conditions (use of filters, no modification, no deliberate prompting for infringing content). NIST AI RMF GOVERN 6.1 calls out the risk of infringing third-party intellectual property.
Ownership of developed work: UK guidance asks buyers to decide who owns new or retrained algorithms. M-25-22 asks agencies to secure rights to code and models produced under the contract and to scope licences to avoid lock-in.
Warranties: that the product is used and supported in line with its documentation, that the supplier complies with laws applicable to it as provider, and that data commitments are met by its sub-processors.
Regulatory cost allocation: who bears the cost of changes needed for new AI laws during the term.

Exit, portability and termination terms

Termination triggers: a right to terminate without penalty on a material model change, a material change in terms, a breach of data use commitments, or a regulatory finding that the system cannot lawfully be used.
Portability: export of data, prompts, configurations, evaluation sets, fine-tuned models or adapters (where licences allow) and logs in an agreed format. M-25-22 asks agencies to agree on data format and usability and to secure rights to data and derived products at non-renewal.
Deletion: deletion of all [Organisation] data and derived artefacts within [days], including backups on a stated schedule, with a written certificate.
Transition assistance: knowledge transfer and support for a stated period, which UK guidance emphasises.
Credential clean-up: confirmation that all tokens, keys and service accounts the supplier held for [Organisation] are revoked. NIST CSF 2.0 GV.SC-10 calls for supply chain plans to cover activities after a relationship ends.

Negotiating by risk and organisation size

Situation	Realistic approach	Minimum terms to hold out for
Low-risk tool, standard click-through terms, small organisation	Choose the plan tier and settings that give contractual data commitments; configure rather than negotiate	No training on your data in the terms, SSO, admin controls, documented retention
Medium risk, internal data and integrations	Order form or addendum on the supplier's paper	Data terms table above, change notification, incident notice, scoped integrations, exit export
High risk, regulated or customer-facing, large organisation	Negotiated agreement, using MCC-AI High-Risk as a checklist	All sections of this guide, testing rights, audit rights, higher liability caps for data breaches, AI Act role schedule
Public body	Use your procurement route and MCC-AI or the applicable national guidance	As high risk, plus transparency and publication duties under your procurement rules

Smaller buyers rarely change a large supplier's paper. Their leverage is choosing the product tier whose standard terms already include the commitments, and recording the gap as a risk acceptance when they do not. Larger buyers should maintain an AI addendum as a reusable schedule. Use the AI Procurement Checklist to collect the findings that feed the negotiation, and tier the use case first with the AI Use Case Risk Tiering Guide.

How to put the clauses in place

Inventory existing contracts. List suppliers whose products include AI features, from the AI register and from software spend. See the AI Register and AI Inventory Template.
Build an AI addendum. Draft a schedule covering data use, model change, security and incidents, documentation, and exit, reviewed by legal. Keep fallback positions for each point.
Pilot it. Use the addendum on the next few AI purchases and renewals, and record which points suppliers accept, reject or counter.
Apply at renewal. Prioritise high-risk suppliers and those holding broad OAuth scopes or sensitive data.
Operationalise the terms. Turn each commitment into a check: who receives model change notices, who tests them, who reviews sub-processor changes, who confirms deletion at exit.
Keep a rollback route. For every AI integration, document how to revoke its credentials and disable the feature if a supplier breaches its terms or a change fails testing.

Monitoring contract compliance

Watch terms: monitor supplier terms of service, privacy policies and sub-processor lists for changes, and compare them with the contract.
Watch behaviour: review integration logs for new OAuth scopes, new endpoints or regions, and unexpected data volumes.
Metrics: share of AI contracts with a no-training clause; share with model change notification; number of model change notices received and tested before rollout; median days to revoke credentials at supplier exit; open contract gaps accepted as risks, by age; suppliers reviewed in the last 12 months.

Framework mapping

Contract area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	NIST AI RMF	Threat reference
Requirements in contracts	GV.SC-05	SA-4 Acquisition Process, SR-3	GOVERN 6.1	OWASP LLM03 Supply Chain
Due diligence before signing	GV.SC-06	SR-5, SR-6	MAP 4.1	MITRE ATLAS AML.T0010 AI Supply Chain Compromise
Data use and confidentiality	GV.SC-05	SA-9 External System Services	MAP 4.2	MITRE ATLAS AML.T0024 Exfiltration via AI Inference API
Model change and monitoring	GV.SC-07	SR-6 Supplier Assessments and Reviews	MANAGE 3.1, MANAGE 3.2	MITRE ATLAS AML.T0020 Poison Training Data
Incidents	GV.SC-07	SR-8 Notification Agreements	GOVERN 6.2	OWASP LLM02 Sensitive Information Disclosure
Exit	GV.SC-10	SA-4	MANAGE 3.1

ISO/IEC 42001:2023 provides the AI management system in which supplier terms are governed. See the ISO/IEC 42001 Guide and the NIST AI RMF Guide.

Common failure patterns

Relying on a settings page: training opt-outs configured in a console but absent from the contract can be reversed by a policy update.
Treating model clauses as complete: adopting MCC-AI text without separately negotiating liability, IP and data protection, which they leave out.
No definition of material change: a change notification clause without a definition gives the supplier discretion over what to notify.
Ignoring the integration's credentials: contracts cover data at rest but not the OAuth tokens and API keys the supplier holds, so there is no duty to report their theft quickly or help revoke them, as the Salesloft Drift breach illustrates.
Missing derived artefacts at exit: deleting source data but not embeddings, indexes or fine-tuned adapters.
AI arriving in old contracts: suppliers add AI to products under existing agreements that predate any AI terms. Review at the next renewal or on feature launch.

Practitioner checklist

Maintain an AI addendum covering data use, model change, security, documentation, liability and exit, reviewed by legal.
Require a contractual no-training commitment that cannot be changed by online terms updates.
Set retention limits for prompts, outputs, logs and derived artefacts, with deletion certificates at exit.
Define material model change and require advance notice, testing rights and rollback or termination.
Record EU AI Act roles, intended purpose and permitted modifications in a schedule; check Article 25(4) where you are a provider.
Scope integration permissions, require incident notice covering credentials, and confirm revocation at exit.
Negotiate liability caps and IP indemnity separately from any model clauses.
Assign owners for monitoring terms changes, model change notices and sub-processor updates.

Standards and references

This guide summarises contract considerations for buying AI and is not legal advice. Related NHI Mgmt Group resources: Third-Party AI Risk Guide · AI Governance Guide · AI Governance Platform Buyer's Guide · Third-Party Risk Management Guide · AI Security Architecture Reference Guide

AI Contract Clauses Guide: Data, Liability and Model Change Terms