A contract for an AI implementation differs from a typical implementation contract in a few places that are easy to miss in the excitement after a good demo. Here’s a checklist of what to check before you sign — from the buyer’s side, not the vendor’s.
Why an AI contract needs a different approach
A standard implementation contract mostly answers questions about scope, timeline, and price. A contract for an AI implementation has to answer a few more questions that rarely come up with regular software: who owns what got configured for your company, what happens to the data that flows into the model, and who’s liable when the model gets something wrong in a way that costs money. Skipping these questions at signing doesn’t make them go away — they come back later, usually at a worse moment than during negotiation.
Ownership of prompts, models, and data
The first set of questions covers what actually gets built during the implementation, and who it belongs to.
Prompts and instructions. The vendor builds specific prompts, instruction templates, and logic for your company that control how the model responds to your data. Make sure the contract states clearly that you own this configuration — not the vendor, who could otherwise reuse it with a competitor or hold onto it once the relationship ends.
Data going into the model. Check explicitly whether your company’s data — documents, customer queries, financial records — can be used to train or fine-tune the AI vendor’s model. In most cases the answer should be “no, not without separate, explicit consent” — and the contract should state that directly rather than staying silent on it.
Input and output data. Who owns the data that goes into the system, and the outputs it generates? This question sounds obvious until you notice the contract doesn’t address it at all — and the default answer, when nothing is written down, tends to favor the vendor rather than the buyer.
Exit terms
A contract that describes the start of the relationship well but says nothing about how it ends is incomplete, no matter how good the rest of it looks.
Check whether, if the relationship ends, you can actually get your data, prompts, and configuration back in a format you can use — not just in theory, but in practice, without having to rebuild everything from scratch with a new vendor. A good contract also spells out a transition period and what handover documentation looks like: exactly what you receive, by when, and in what form, if you decide to switch vendors or bring the work in-house.
The lack of clear exit terms is one of the most common reasons companies stay with a vendor longer than they’d like — not because they’re happy, but because switching looks more costly and risky than it actually is.
Maintenance costs, not just the implementation price
We’ve written before about how an AI implementation is really three budgets, not one — pilot, production, and maintenance. The contract should state clearly what the price actually covers: just the build phase, or ongoing maintenance after launch too.
Check directly who bears the cost when the underlying language model provider releases a new version and someone needs to verify the system still works correctly; who pays when a data source (a bank, a counterparty) changes the format of the documents the system is supposed to read; and whether ongoing monitoring is part of the contract at all, or a separate line item you only find out about later.
Acceptance criteria
“The AI works well” isn’t an acceptance criterion — it’s an opinion. A good contract defines specific, measurable conditions that mark the implementation as complete: a defined accuracy threshold on classification against your company’s real data, a maximum response time, or the percentage of cases the system handles without escalating to a human.
We’ve written about how to choose the right moment to move from a pilot to a full rollout in AI pilot vs full rollout — acceptance criteria in the contract should reference the results of that stage directly, rather than general sales promises made before any testing on your own data.
Liability for AI errors
This is the question many companies skip at signing, and the one that matters most when something actually goes wrong: who’s liable when the model makes a mistake that costs money or causes harm?
The answer depends heavily on how the implementation itself is designed. If AI only proposes, classifies, or prepares material, while a human or deterministic code makes any decision with a real financial consequence — a principle we covered in more depth in AI proposes, code decides — liability is far easier to assign than in a setup where the model itself “decides” everything with no control layer in place. The contract should state clearly where that line sits in the system’s architecture, rather than assuming the liability question will sort itself out once a problem actually appears.
The checklist, in short
Before signing a contract for an AI implementation, make sure you have a clear answer to each of these:
- Who owns the prompts, configuration, and logic built for your company?
- Can your data be used to train the vendor’s model — and under what conditions?
- What happens to your data and configuration if you decide to end the relationship?
- Does the price cover only implementation, or ongoing maintenance after launch too?
- Who pays to adapt the system when data formats change or the underlying model is updated?
- What are the specific, measurable criteria that mark the implementation as complete?
- Who is liable when AI makes a mistake that costs money?
FAQ
Is a standard implementation contract enough for an AI project? Usually not on its own — it needs added clauses on prompt and data ownership, exit terms, and liability for model errors that a typical IT implementation contract doesn’t cover.
Can a vendor use our company’s data to train their own model? They shouldn’t, without separate, explicit consent written into the contract — worth checking directly rather than assuming.
How do we define acceptance criteria if we don’t yet know how the system will perform? A pilot on your company’s real data is a good starting point — acceptance criteria for the full rollout should be based on that stage’s results, not on assumptions made before any testing.
Is it worth negotiating exit terms when we’re just starting the relationship? Yes — that’s the best time to negotiate, because both sides can look at it rationally. Once the relationship is underway, the buyer’s negotiating position usually weakens.
Who should be liable for AI errors in the contract? It depends on the implementation’s architecture, but the principle should be a clear assignment of liability to a specific layer — a human or deterministic code — rather than leaving the question open until an error actually happens.
If you’re preparing for a conversation about an AI implementation contract and want to talk through what to watch for in your specific case, get in touch — we look at this from the vendor’s side too, since we have to answer these same questions ourselves.