Contract Clauses That Matter When You Buy AI

Most AI procurement disputes come down to five questions: who owns the output, who pays when a third party claims it infringes, what the vendor may do with your data, what happens when the model changes under you, and who holds which regulatory role. The sample language below is a drafting starting point, not a substitute for a lawyer.

The five clauses that decide the deal

Everything else in an AI contract is either standard software contracting or noise. These five are where AI-specific risk actually sits, and where vendor standard terms are most likely to be unacceptable and most likely to be negotiable if you are large enough to ask.

Ownership of inputs and outputs

The vendor’s standard position is normally acceptable: you retain rights in your inputs, the vendor assigns or disclaims any interest in the outputs, and you are responsible for your use of both. What to check is the licence you grant back — its scope, its purpose and its duration — because that is where a clause about ownership becomes a clause about training.

OWNERSHIP OF CUSTOMER CONTENT AND OUTPUT

1. Customer retains all right, title and interest in Customer Content.
   Customer grants Supplier a non-exclusive, worldwide, royalty-free
   licence to process Customer Content solely to the extent necessary to
   provide the Services to Customer, and for no other purpose. This
   licence terminates on the earlier of deletion of the relevant Customer
   Content or termination of this Agreement.

2. As between the parties, Customer owns all Output generated from
   Customer Content. Supplier assigns to Customer all right, title and
   interest it may have in such Output.

3. Customer acknowledges that Output may not be unique, that similar or
   identical Output may be generated for other customers, and that
   Supplier makes no representation that Output is protectable by
   copyright or any other intellectual property right in any
   jurisdiction.

4. Supplier shall not use Customer Content or Output to train, fine-tune,
   or otherwise improve any model, except where Customer has opted in in
   writing to a specific programme identified by name.

Paragraph 3 is unusual and you should want it. It stops the contract being read as a warranty that the output is yours to enforce against the world, which it is not: whether copyright subsists in machine output is a question of law that no vendor can settle. Paragraph 4 is the one vendors will push back on if their default is opt-out training; make it opt-in and name the programme.

IP indemnity, and the conditions on it

The major model providers offer indemnities covering third-party intellectual property claims arising from output. They are real, they have been used, and they are conditional. Typical conditions, stated at the level of pattern rather than by vendor because vendor terms change:

• You must be on a paid tier, and often on specific services.
• You must not have disabled or circumvented safety filters or output controls.
• You must not have supplied infringing material as input, or provided input designed to elicit reproduction of a particular work.
• You must not have continued to use output after being notified of a claim.
• You must give prompt notice, tender control of the defence, and cooperate.
• The indemnity often does not cover output you modified, or output used outside the documented use.

The conditions are the clause. An indemnity that fails because your application turned off a filter for latency reasons is worth nothing, and that is a configuration decision an engineer makes without reading the contract. Circulate the conditions to the team that operates the system.

INTELLECTUAL PROPERTY INDEMNITY

1. Supplier shall defend Customer against any third-party claim alleging
   that Output infringes that third party's copyright, and shall pay
   damages and costs finally awarded or agreed in settlement, provided
   that Customer:
   (a) used the Services in accordance with the Documentation and the
       Acceptable Use Policy;
   (b) did not disable, circumvent or materially modify any output
       filter, safety system or citation mechanism made available by
       Supplier;
   (c) did not provide as input any material Customer knew or ought
       reasonably to have known was infringing, and did not prompt with
       the intent of reproducing a specific third-party work;
   (d) gives Supplier prompt written notice, sole control of the defence
       and reasonable cooperation at Supplier's expense; and
   (e) ceases use of the specific Output on written notice from Supplier
       following a claim.

2. This indemnity is not subject to the limitation of liability in
   clause [X] up to a cap of [amount], and Supplier shall not settle any
   claim in a way that imposes a non-indemnified obligation on Customer
   or admits fault on Customer's part without Customer's written consent.

3. Supplier shall on request confirm in writing whether a given
   configuration of the Services falls within the scope of this
   indemnity.

Paragraph 2 is the negotiation. An indemnity capped inside a general liability cap of twelve months’ fees is not much of an indemnity for a claim about a brand asset. Paragraph 3 costs the vendor nothing and gives you something to point at when your configuration is questioned later.

Data use, retention and training

This clause has to be consistent with what you tell your own customers, and the inconsistency between a vendor’s actual terms and a company’s public privacy notice is one of the more common unforced errors in this area.

DATA HANDLING

1. Supplier shall not use Customer Content or Output for training,
   fine-tuning, evaluation, or model improvement of any kind.

2. Retention. Supplier shall retain Customer Content and Output only for
   the period necessary to provide the Services and in any event no
   longer than [30] days, save where a longer period is required by law,
   in which case Supplier shall notify Customer of the requirement and
   its duration to the extent legally permitted. Customer may elect zero
   retention for any endpoint by written notice.

3. Access. Supplier personnel shall access Customer Content only where
   necessary to investigate a security incident, to comply with law, or
   at Customer's request, and Supplier shall log every such access and
   make the log available to Customer on request.

4. Location. Processing shall take place only in [region]. Supplier shall
   give Customer at least [60] days' written notice before adding or
   changing a processing location or a sub-processor, and Customer may
   terminate the affected Services without penalty if it objects.

5. Deletion. On termination, or on Customer's written request, Supplier
   shall delete Customer Content and Output within [30] days and certify
   deletion in writing, including from backups within the ordinary backup
   rotation cycle.

6. Abuse monitoring. Where Supplier retains Customer Content for abuse
   monitoring, it shall identify that retention, its duration and who may
   access it, and shall offer Customer an exemption process.

Paragraph 6 is the one people miss. Several providers retain inputs for a period for abuse monitoring even under zero-retention arrangements, with an exemption process for customers who cannot accept it. If your privacy notice says data is not retained, and it is retained for thirty days for abuse monitoring, your notice is wrong. See what zero data retention actually means, because the phrase is used for several different arrangements.

Model change and version pinning

The clause almost nobody negotiates and the one that breaks systems. A model you evaluated, tuned prompts for and validated can be replaced by the provider, or its default alias repointed, or your version deprecated with short notice. Every downstream artefact — your evaluation results, your validation report, your regulatory filing — refers to something that no longer exists.

MODEL VERSIONS AND CHANGES

1. Supplier shall make available, and Customer may specify, a pinned
   model version identifier for each endpoint. Requests specifying a
   pinned version shall be served by that version.

2. Supplier shall give Customer not less than [90] days' written notice
   before deprecating or withdrawing a pinned version in use by Customer,
   and shall make a successor version available for testing for not less
   than [60] days before the withdrawal takes effect.

3. Material Change means any change to a model, its serving
   configuration, its safety systems or its default parameters that could
   reasonably be expected to alter the content, format or distribution of
   Output for Customer's use case. Supplier shall give Customer not less
   than [30] days' notice of a Material Change affecting a version in use
   by Customer.

4. Supplier shall maintain and make available a public change log
   recording each version, its release date, its deprecation date and a
   description of material changes.

5. Where Customer demonstrates, within [30] days of a Material Change,
   that the change causes a material degradation against Customer's
   documented acceptance criteria, Customer may terminate the affected
   Services without penalty and receive a pro rata refund.

Paragraph 3 is the drafting problem. “Material change” defined by reference to your use case is what you want and is what a vendor will resist, because it makes their notice obligation depend on facts about you. A workable compromise is a definition tied to the vendor’s own published evaluation results plus a notice duty for any change to safety systems or default parameters, which are the changes that most often move output shape without moving a benchmark.

Paragraph 5 needs your acceptance criteria to exist and to have been shared. That is a reason to build the evaluation set before you sign, not after.

Regulatory roles and cooperation

New, absent from most standard forms, and increasingly the clause your compliance team cares about most. It cannot change who actually holds which role — that is decided by conduct — but it can allocate the work and the cost.

REGULATORY COOPERATION

1. Intended purpose. Supplier's statement of the intended purpose of the
   Services is set out in Schedule [X]. Supplier shall notify Customer
   before changing it.

2. Roles. The parties record their understanding that, in respect of the
   Services as supplied, Supplier is the provider and Customer is the
   deployer for the purposes of Regulation (EU) 2024/1689. The parties
   acknowledge that this allocation does not determine either party's
   status as a matter of law.

3. Documentation. Where the Services comprise or include a high-risk AI
   system, Supplier shall supply instructions for use and the information
   required to be given to deployers, and shall keep them current.

4. General-purpose models. Where Supplier provides a general-purpose AI
   model, Supplier shall make available the information required to be
   provided to downstream providers, its policy on compliance with Union
   copyright law, and the published summary of training content.

5. Cooperation. Where Customer becomes a provider by operation of law in
   respect of a system incorporating the Services, Supplier shall provide
   the technical documentation, information and reasonable technical
   access necessary for Customer to comply with its obligations, on
   [commercially reasonable terms / at no additional charge].

6. Authorities and incidents. Each party shall notify the other without
   undue delay of any regulatory enquiry, serious incident or malfunction
   relating to the Services, and shall cooperate in any required
   reporting. Supplier shall report to Customer any serious incident
   affecting the Services within [72] hours of becoming aware of it.

7. Data protection. The Data Processing Agreement at Schedule [Y] applies
   and prevails over this clause in the event of conflict.

Paragraph 5 is the important one and it exists because the AI Act already requires that cooperation from a provider whose system is repurposed. Putting it in the contract converts a regulatory obligation into a commercial one you can enforce, and fixes the price of it before you need it.

Performance, and why an accuracy SLA fails

Buyers routinely ask for an accuracy service level and vendors routinely refuse, and the vendors are usually right. Accuracy depends on inputs the vendor does not control, on prompts you wrote, and on a ground truth only you can define. An SLA promising 95% accuracy is either unmeasurable or a dispute waiting to happen.

What works instead:

• Availability and latency service levels, which are measurable and conventional. Specify percentiles rather than means: a p95 latency commitment says something a mean does not.
• A documented evaluation and an acceptance test run before signature on your own data, with the result recorded in a schedule as the baseline for the material change clause.
• A right to re-test after any material change, and a termination right if the baseline is not met.
• Transparency commitments — the vendor publishes evaluation results and a change log — which are achievable where a performance guarantee is not.

Liability, audit and exit

• Liability cap. An AI service embedded in a decision process can cause loss out of all proportion to its fee. Push for carve-outs from the cap for the IP indemnity, data protection breach and confidentiality, or a supercap for those heads.
• Audit. Full audit rights are rarely granted by hyperscale providers and rarely necessary. Ask instead for current certifications and reports, a completed security questionnaire, the sub-processor list with a notification mechanism, and the right to audit if a certification lapses. In EU financial services, DORA makes audit and access rights a regulatory requirement rather than a preference.
• Exit. Export of your prompts, configurations, evaluation data and any fine-tuned artefacts in a usable format; transition assistance for a defined period; and deletion certified in writing. Fine-tuned model weights are the contentious item — establish before signing whether you can take them.
• Change of control and model sourcing. If the vendor is a layer over somebody else’s model, you want notice if the underlying model provider changes, because that is a material change to what you validated even though the vendor’s product name did not move.