How to Review an AI Contract: The Clauses That Matter

AI contracts carry risks that conventional software agreements do not address: training use of your data, models changing without notice, and liability when the system is confidently wrong. This playbook covers the clauses worth attention, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

When is this worth doing?

Before signing any AI service agreement, at renewal, and when a vendor issues updated terms — which they do more often than in conventional software.

It is also worth reviewing existing agreements for systems already in production, because many were signed before the organisation understood what to ask for.

What does the sequence look like?

Step	Purpose
1. Data use and retention	Where, how long, and for what
2. Training use of inputs	Default is frequently yes
3. Sub-processors	Your supply chain extends
4. Model change and deprecation	Notice periods
5. Outputs, IP, and indemnity	Read the conditions
6. Liability, service levels, exit	Where the real exposure sits

Step 1 — Read the data clauses first

Where processing occurs, what is retained and for how long, who can access it, and what happens on deletion.

Get these in the contract rather than relying on a documentation page. Vendor documentation changes without notice and is not an enforceable commitment, which matters at exactly the moment you need it to be one.

Where residency or specific processing locations are required by your own obligations, they need to be contractual terms rather than configuration settings.

Step 2 — Check whether inputs are used for training

The default varies by vendor and by plan, and consumer or basic tiers frequently permit it.

For anything involving confidential or personal data, a no-training commitment is worth having explicitly. It is generally available and is generally not the default, which means someone has to ask.

The same applies to outputs and to any feedback you provide. Vendors sometimes treat those separately, and the distinction is easy to miss. See AI and trade secrets.

Step 3 — Map the sub-processors and change notice

Which providers the vendor relies on, and what notice you get when that list changes.

Your data travels through them and your obligations follow it. A sub-processor change that moves processing to a different jurisdiction can break your compliance position without any action on your side.

Require the list and notification. Objection rights are worth asking for and less commonly granted.

Step 4 — Ask for model change and deprecation notice

What happens when the vendor changes the model behind the service, how much notice you get, and whether you can remain on a version.

This is the clause most specific to AI and least commonly offered. Without it, your system's behaviour can change without any deployment, and a deprecation announced with short notice forces a migration on someone else's schedule.

For validated or regulated systems, a notice period is close to a requirement rather than a preference. See how to handle ai model deprecation.

Step 5 — Read the output and indemnity conditions

Output ownership is usually granted, and the interesting part is what conditions attach to any indemnity.

Indemnities for third-party intellectual property claims commonly require using specified features, not deliberately seeking infringing output, and following the vendor's guidance. Those conditions frequently exclude the behaviour most likely to cause a problem.

Read them rather than noting that an indemnity exists. An indemnity with conditions you cannot meet is not protection. See AI and copyright.

Step 6 — Examine liability, service levels, and exit

Liability for wrong outputs is generally excluded or capped low, service levels usually cover availability rather than quality, and exit provisions are frequently thin.

The liability position is not necessarily unreasonable, and it tells you where the risk sits — with you, which should inform how much human review your design includes.

Exit provisions matter more than they appear at signing: data export in a usable format, confirmed deletion, and a transition period during which service continues. Those are cheap to negotiate before signing and impossible afterwards.

What about vendors who change terms unilaterally?

Many AI vendors reserve the right to update terms with notice, which makes the terms you signed a snapshot.

Ask for notice periods and, where possible, the right to terminate without penalty if terms change materially. That is a modest request and it converts an open-ended exposure into a decision point.

Set a reminder to re-read the terms periodically. Changes arrive by email and get filed.

How much negotiating power do you have?

More than most buyers assume, particularly on non-price terms.

Vendors concede more readily on data handling, notice periods, and exit than on pricing, because those cost them little. Buyers who spend all their leverage on the rate frequently accept terms that cost more than the discount was worth.

A tested alternative provider is what makes any of it credible. See how to negotiate llm provider pricing.

Who needs to be involved?

Legal counsel familiar with technology agreements, the technical owner who knows what the service will touch, and someone with commercial authority.

Reviews conducted by legal alone miss the technical implications of a model change clause; reviews by technology alone miss the enforceability questions.

How long does it take?

One to three weeks for a review and negotiation on a significant agreement, longer where the vendor's standard terms need material change.

What are the common failure modes?

Relying on documentation pages rather than contract terms. Accepting default training-use terms. Ignoring sub-processors. No model change notice. Assuming an indemnity has no conditions. And thin exit provisions.

How do you know it worked?

Data handling and notice periods in the contract, indemnity conditions you can actually meet, exit terms you have tested, and no surprises from a unilateral terms update.

What does it cost?

Mostly people's time rather than tooling. The expensive version is the one that stalls halfway and leaves the organisation with neither the old state nor the new one, which is why a narrow first pass beats a comprehensive plan nobody finishes.

Budget the work as an operated change rather than a project with an end date, because most of these need a maintenance tail. See AI total cost of ownership.

What should you do first?

Read the training-use clause in your largest AI agreement. Many organisations discover their default terms permit something they assumed they had excluded.

How FISTA Solutions helps

FISTA Solutions runs this work alongside client teams rather than around them: contract review focused on data use, model change notice, and exit rather than on capability commitments, with indemnity conditions read rather than assumed, evidence produced as the work proceeds, and handover that leaves your people able to continue without us. Delivery runs through AI agents, AI enablement, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries, with 47% average efficiency gains where measured.

To run this with support, message FISTA on WhatsApp, or read how to audit an AI vendor.