Buying AI is not like buying software, and most organisations discover that on their first contract. The price is quoted per token, per seat or per GPU hour; the product can change underneath you within months; and the clauses that carry the real risk are ones standard IT templates never had to cover. These are the commercial and contract terms we see buyers get wrong most often, and what to negotiate instead.
What are you actually buying when you buy AI?
Usually several different things at once, each with its own commercial model:
- Access to models through an API, priced by consumption. Input and output are often priced differently, and the bill grows with adoption rather than with headcount.
- Assistants and AI features sold per seat, frequently inside software you already own, added one department at a time.
- Cloud and GPU capacity to run models yourself, rented on demand or reserved against a commitment.
- Partners: the integrators, resellers and specialists who implement, fine-tune and support all of the above.
Each of these can arrive through a different budget and a different requester. That is the first reason AI spend is so hard to see, and the first thing to fix.
Mistake 1: committing to today's price
Prices for model access have fallen repeatedly, and new models often arrive cheaper and better than the ones they replace. A multi-year commitment at today's rate can look generous in its first year and expensive in its second.
What to negotiate instead: shorter terms, or commitments that can move between models from the same provider; price protection that follows the provider's own published price reductions; benchmarking rights; and a ramp schedule that matches real adoption rather than the vendor's forecast. The aim is not to avoid commitment, which usually earns the best rates, but to avoid fixing what the market is about to move.
Mistake 2: buying the same capability three times
The same model can often be bought directly from its developer, through a cloud provider's marketplace, or through a partner, at different prices and on different terms. Meanwhile, departments buy overlapping assistants on separate subscriptions, and usage charges appear on cloud invoices nobody owns.
Before any negotiation, map what is already in use: every pilot, subscription and cloud line item, with its owner and its cost. Then choose the buying channel deliberately. Spend through an existing cloud agreement can count towards commitments you have already made, and keeps billing and security in one place; buying direct can bring earlier access to new models and different terms. Either can be right. Drifting into all three is not.
Mistake 3: accepting the vendor's data terms
Whether your prompts and documents can be used to train a model, how long they are retained, where they are processed and which sub-processors touch them are commercial terms, not technical footnotes. They also vary between a provider's consumer, business and enterprise offers.
Get these commitments into the contract itself, not left to a policy page the provider can update. Agree retention, processing location, sub-processor notice and audit rights in writing, and make sure they match your own data classification and security requirements.
Mistake 4: ignoring model change
The model you evaluate is not necessarily the model you will be running next year. Providers retire versions, change default models and alter behaviour between releases, sometimes at short notice.
Negotiate notice periods for retirement, the right to stay on a tested version for a defined period, the right to re-test before a change reaches production, and a remedy, including exit, if the replacement performs worse on your use cases. Otherwise the evaluation you ran in the tender quietly stops being true.
Mistake 5: nobody owns consumption
Usage-based pricing means cost follows behaviour. Without budgets, quotas and reporting by department, AI spend is discovered on the invoice rather than managed. A more capable model is not always the right one either: for many routine tasks a smaller, cheaper model does the job just as well.
Treat AI like any other category with a variable cost: set budgets, allocate cost to the departments that use it, review usage monthly, and make choosing the right model for each task part of the governance rather than an afterthought.
Who owns the outputs, and who carries the risk?
Ownership of what a model produces, and protection if those outputs infringe someone else's rights, are where vendor paper is most one-sided. Some providers offer indemnities for intellectual property claims, but usually with conditions attached: particular products, particular settings, and exclusions that can be broad.
Read the conditions as closely as the indemnity itself, check that the liability caps are proportionate to how you will use the outputs, and work through both with your legal team before signature, not after the first claim.
How should procurement evaluate AI providers?
On your own use cases and your own data, not on the vendor's benchmarks. Define what good looks like before the market sees your requirements, then test each shortlisted option against it: accuracy on real tasks, including Arabic where your users need it; speed and rate limits at your expected volume; security and certifications; and the total cost at the volumes you actually expect, not at the pilot's.
Then write what you learned into the contract. A capability that was demonstrated in the evaluation should be a capability the provider commits to.
Where should you start?
- Map AI use and spend across the organisation, including pilots and cloud usage.
- Decide what to standardise, through which channel, and on what level of commitment.
- Rewrite your templates: AI-specific requirements in your RFPs and AI-specific clauses in your contracts.
- Negotiate with the market's direction in mind, so that falling prices and new models work for you rather than against you.
This is the work our Buying AI service covers, from the buying strategy to the signed contract, alongside your procurement, IT and legal teams.