Skip to content
Data McFly.
Back to writing

writing

What to Put in an AI Vendor Contract Before You Sign

Aug 20, 2026· 3 min read· Roger Stringer

The pricing page isn't the deal. It's a screenshot of what your vendor felt like charging the day you looked.

I've written about what happens when your AI vendor triples the price. This is the other half: the clauses that decide whether that phone call is an annoyance or an emergency.

None of it needs a lawyer on retainer. It needs you to know what to ask for before you fall in love with the product.

Some context for why this matters more this year. AI vendors are rewriting how they charge. Zendesk moved to outcome-based pricing at $1.50 per automated resolution on committed volume. Hybrid models are used by 43 percent of SaaS companies, heading for 61 percent by year end. And roughly $1.8 billion went into AI agent startups across a dozen deals in July and August alone.

A lot of your vendors are pre-product-market-fit companies whose pricing is still a hypothesis. They will change their minds.

1. Cap the increase, not just the rate

Locking the rate for the term is table stakes. Everyone does that.

The clause that matters is renewal: a ceiling on how far the price can rise, written as a percentage.

If they won't cap it, you've learned something useful. A vendor confident in their unit economics will cap it. A vendor whose margin depends on repricing you later will find a reason not to.

2. Define the billable unit

This one catches everybody, and outcome-based pricing made it worse.

If you're paying per resolution, per task, or per action, get the definition in writing. Does a conversation the agent handles and then escalates to a human count as a resolution? What about a retry after a failure? What about the same customer coming back the next day with the same problem?

Each of those has a generous reading and a stingy one. Their billing system will pick the generous one by default.

Ask them to write down which is which. Vague answer now, vague invoice later.

3. Data, outputs, and training

3 separate things, and vendors like to answer all 3 with one sentence.

Who owns the inputs you send. Who owns the outputs generated for you. Whether either can be used to train their models or "improve the service," which is the phrase that usually means training.

Then the part everyone forgets: the way out. Can you export your data, your conversation history, and any tuning work in a usable format, and how long after cancellation before it's deleted?

"We'll provide an export on request" isn't a commitment. A format and a window is.

4. Notice when the model changes

Your vendor swaps the underlying model. Your prompts behave differently. Accuracy drops 4 points and nobody tells you, because on their side it was an upgrade.

Ask for notice on material model changes, plus the option to stay on the prior version for a defined window.

You won't always get it, especially from a small vendor riding somebody else's API. Asking still tells you how much control they have, which is worth knowing before you build a core workflow on top of them.

5. An exit that isn't a hostage negotiation

Month-to-month costs more than annual. Pay the premium in year 1 anyway, at least until the thing has proven itself in production. That discount is priced at exactly what locking you in is worth to them.

Get the termination terms concrete: notice period, whether unused prepaid credit refunds, what data you leave with, how long support continues after you give notice.

The clause behind the clauses

A vendor who won't put any of this in writing has told you what you needed to know. Their pricing is provisional, their data terms are flexible, and their retention strategy is friction.

The best time for this conversation is the week before you sign, when you'll never have more power in the room and they want the logo.

The worst time is 14 months later, on a call that opens with "we're making some changes to our pricing."