Negotiating AI Contracts: What Is Actually on the Table

The first thing most teams ask an AI vendor for is a discount on the per-token rate, and it is usually the item with the least give in it. Published rates are competitive and move on their own; the terms that will actually cost you money over two years are elsewhere in the document and are rarely raised.

What follows is an inventory of what is genuinely negotiable, roughly in order of how much a small or mid-sized team can expect to move it, plus an honest account of the leverage required for each.

Committed spend discounts: real, but priced in lock-in

Most vendors will trade a discount for a commitment — an annual minimum, sometimes with a ramp. The discount is real and can be material at volume.

What is easy to miss is that you are paying for it in optionality. The price of a given capability has fallen repeatedly, and a model released six months into your term may do your job at a fraction of the rate you locked. A twenty percent discount on a rate that halves is not a saving.

The version worth signing is a commitment on spend rather than on a specific model or a specific rate card, so that new and cheaper models inside the vendor's catalogue count toward your minimum. Ask explicitly whether the commitment survives a model deprecation, because deprecation during a term is common enough to plan for.

If your volume is small, this is not your lever. Below a certain threshold vendors will not staff a negotiation, and the honest answer is to stay on list pricing and keep your options open.

Rate limits and tier placement

This is where a small team has more leverage than it expects, because it costs the vendor almost nothing.

Rate limits are usually assigned by an automated tier system based on spend history. A request to be placed a tier higher, backed by a concrete description of your traffic shape — burst pattern, concurrency, whether you can shift work to off-peak — is often granted by a support ticket without any contract at all.

It is worth asking for the limit that matches your peak rather than your average. Being throttled during a burst forces retries, and retries cost tokens and latency for work you already paid for once. Rate limits and retries covers the mechanics of what throttling actually costs you.

Ask also how limits are enforced across keys. Some providers scope them per organisation, some per key, and if you are splitting traffic across environments the difference determines whether staging can starve production.

Data retention and training terms

These are frequently negotiable and frequently left at default because nobody reads that section.

The three things to pin down: whether your inputs and outputs may be used to train or improve models, how long request data is retained, and whether abuse-monitoring retention is separate from general retention. Vendors often default to no-training for API traffic already, but "usually" is not the same as "contractually".

Zero-retention or short-retention modes exist with several providers and are typically available on request rather than by default. There is sometimes a functional cost — certain debugging or evaluation features depend on stored requests — so ask what you lose before you ask for it.

If you handle regulated data, get the subprocessor list and the data residency options in writing. This is the section where a vendor's answer either exists or does not, and finding out during a security review is worse than finding out now.

Support and SLAs

Uptime SLAs on inference APIs are usually thinner than teams expect, and the remedy is typically service credits, which are worth a fraction of what an outage costs you. Read the credit schedule before treating an SLA as protection.

More useful than an uptime number is a support response commitment with a named channel and a defined severity ladder. When a model's behaviour changes and your evaluation suite starts failing, the question is who you can reach and how fast, not what percentage of minutes were nominally available.

Ask specifically about notice periods for model deprecations and for changes to a model behind a stable alias. A vendor that will commit to a written notice window is giving you something worth more than a small rate concession, because it converts an emergency migration into a planned one. Pinning versions where the vendor allows it, as covered in pinning model versions, is the technical half of the same protection.

Exit and portability clauses

The clause that matters most is the one nobody negotiates, because it only matters on the way out.

Establish what happens to stored data on termination, in what format you can extract it, and over what window. If you are using vendor-side features — stored files, fine-tuned artefacts, cached prefixes, evaluation datasets — ask which of them come with you and which simply cease to exist. Fine-tuned model weights, in particular, are usually not portable at all.

Ask whether a commitment can be terminated for convenience with notice, and whether unused committed spend is forfeited or credited. This single answer determines how much a bad commitment can actually hurt.

The technical side of exit is worth measuring separately from the legal side, since most of the real cost is engineering rather than contractual. Measuring vendor lock-in costs and the real cost of migrating between providers cover that half.

What leverage a small team actually has

Not volume. If you are spending four figures a month, no amount of framing turns that into pricing power, and pretending otherwise wastes the goodwill you do have.

What you do have: the ability to leave cheaply, which is a real threat when the API surface is OpenAI-compatible and switching is a base URL change plus an evaluation run; reference value, if you are visible in a segment the vendor wants; and the fact that most of the non-price asks cost the vendor nothing to grant.

Use that leverage on terms rather than rate. A tier bump, a retention setting, a deprecation notice window and a clean exit clause are all obtainable at low volume. A discount usually is not, and chasing it tends to be the ask that gets you a polite no and ends the conversation.

A practical order of operations

Before you talk to anyone, know three numbers: your monthly spend, your peak requests per minute, and what a week of downtime would cost you. Every ask below is easier to make concretely than in the abstract.

Then work down the list in this order: retention and training terms first, because they are free to grant and expensive to discover late; rate limits and tier placement second; deprecation notice and support ladder third; exit and portability fourth; and price last, if your volume justifies raising it at all.

Keep whatever you agree in a document your engineers can read, not only your legal team. A retention guarantee nobody in the team knows about will not change a single architectural decision, which means you paid negotiating capital for nothing.