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.

Why an AI contract needs a different approach

Skipping these questions at signing doesn’t make them go away — they come back later, usually at a worse moment than during negotiation. The checklist below isn’t a list of formalities to tick off. These are questions worth asking out loud in conversation with a potential vendor, before any specific contract clauses get proposed — how a vendor answers often says more than the draft contract itself.

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 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.
  • Data going into the model. Check explicitly whether your company’s data can be used to train or fine-tune the vendor’s model. In most cases the answer should be “no, not without separate, explicit consent” — and the contract should state that directly.
  • Input and output data. Who owns the data that goes into the system, and the outputs it generates? This sounds obvious until you notice the contract doesn’t address it at all.

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 usable format, 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.

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 and acceptance criteria

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 too. Check directly who bears the cost when the model provider ships a new version, who pays when the format of input documents changes, and whether ongoing monitoring is part of the contract at all.

“The AI works well” isn’t an acceptance criterion — it’s an opinion. A good contract defines specific, measurable conditions: an accuracy threshold on your company’s real data, a maximum response time, or the share of cases handled without escalating to a human. We’ve written about the right moment to move from a pilot to a full rollout in AI pilot vs full rollout — acceptance criteria should reference that stage’s results, not sales promises made before any testing.

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 is designed.

If AI only proposes or prepares material, while a human or deterministic code makes any decision with real financial consequence — a principle we covered 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.

The contract should state clearly where the liability line sits in the system’s architecture, not assume the question will sort itself out.

In short

An AI implementation contract is complete once it answers five questions: who owns the configuration, what happens to the data after the relationship ends, what the price covers, how acceptance works, and who’s liable for a mistake. If you’re preparing for that conversation, read more about our approach on the AI page.

Frequently asked questions

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.