What to Demand in an AI Contract

Most AI contracts are written for a world where the software can't be wrong. The software can be wrong. Very wrong. Confidently wrong.

That's the gap between the contract you're signing and the risk you're actually taking on. The standard enterprise software contract protects you from the vendor's software failing to do what it promised. The AI contract has to protect you from something worse: the vendor's software doing what it promised, confidently, incorrectly, in a way that hurts your customer.

The vendors know this. The contract templates are written to keep the risk on your side of the table. Your job is to push it back.

The three clauses that matter most

Most AI contracts have twenty pages of noise — liability caps, indemnification, data processing, boilerplate that reads the same in every industry. Three clauses actually matter, and they're the three the vendor will push back on hardest.

First: an accuracy clause that means something. The vendor's SLA will promise uptime. Uptime is not accuracy. A system that's up 99.9% of the time and wrong 15% of the time is not a system you want. You need a clause that defines what "working" means for your use case, names a measurement, and ties something to it — a credit, a remedy, an exit. The vendor will say accuracy can't be guaranteed because it depends on your data and your prompts. That's partially true, which is exactly why the clause needs to define the baseline: what data, what prompts, what test set, what acceptable rate. Make it measurable or it isn't a clause.

Second: a data-rights clause that covers the real exposure. The obvious part is your data — the vendor can't use it to train their model, can't share it, can't hold it hostage. That's table stakes now. The part most people miss is the output side: what happens when your customers' data goes through the model and the model's answer gets used against you? You need clarity on who owns the outputs, who's liable when an output is wrong, and what the vendor's obligation is when their model produces something harmful. The data clause isn't just about your data going in. It's about the outputs coming out.

Third: an exit clause that's actually exercisable. The scariest sentence in AI procurement is "you can cancel anytime." Canceling isn't exiting. Exiting means you can leave with your data, your evaluation history, your prompts, your usage logs, and your learned knowledge — in a usable format, within a reasonable time, without a data-export ransom. The vendor's model will change. Your needs will change. The exit clause is the insurance that you're never stuck with a system you can't leave.

The contract that protects you names a measurement, owns the outputs, and lets you leave with everything. Anything less is a receipt, not a contract.

The three clauses they fight hardest

The accuracy clause gets fought because it's a new ask in software procurement — vendors aren't used to being measured on correctness, and they know the measurement will expose them. The data-output clause gets fought because it allocates liability in a direction vendors don't like: toward them. And the exit clause gets fought because every vendor knows that switching costs are their strongest lock-in, and an easy exit destroys their pricing power.

When the vendor pushes back, the pushback tells you something. If they resist naming a measurement, ask why — a vendor confident in their product should welcome a defined baseline. If they resist output liability, ask what they're afraid of. If they resist the exit, ask what they're protecting. The resistance is information. Use it.

The realistic negotiation

You won't get everything. The accuracy clause will have carve-outs for model updates and third-party models. The output liability will be capped somewhere. The exit will have a timeline. That's fine — the goal isn't a perfect contract. It's a contract where the risk is on the table, named, and allocated, instead of silently sitting on your side.

The way to get the clauses you need: make them boring. The vendor's legal team has seen aggressive AI riders before and has counters for the aggressive ones. What they don't have a counter for is specificity. Come in with your measurement defined, your baseline named, your data categories listed, your exit timeline specified. The vendor who can't meet a specific, reasonable, measurable set of terms is telling you something.

And price it. The accuracy clause you can't get in the base contract is often available for a premium — the vendor's willingness to stand behind the product at a price is real information about how good the product is. The premium tier with the real SLA is sometimes the honest price of the product you actually need.

The question that frames the whole review

Before you send the contract to legal, ask the question that should frame the entire negotiation: what does this system do when it's wrong?

If the answer involves your customer, your compliance, or your money, the contract has to cover it. If the answer is "it doesn't matter much," the contract can be lighter. The cost of being wrong is the only number that tells you how hard to negotiate, and it's the number the standard template ignores.

The AI contract is different from every software contract you've signed because the product can fail without breaking. It can be up, responsive, and entirely wrong. The contract that protects you is the one that names a measurement, owns the outputs, and lets you leave with everything. Get those three, and the twenty pages of boilerplate can say whatever they like.

Think this argument fits your event? Tell me about the room — the calendar is selective.