An AI contract looks at first glance like any other software contract: a licence, a term, an SLA with uptime percentages. That is exactly where it goes wrong. With AI you aren't buying predictable functionality but a system that works statistically, learns from input, and whose quality can shift with every update.
Buying AI software is a matter of writing down four things ordinary software contracts never address: who owns your data and the models trained on it, what happens when quality drops, how the price behaves as usage grows, and which role you and your vendor hold under the AI Act. Without those four terms, you're buying a performance promise that exists nowhere on paper.
This guide covers the clauses that make the difference, the pricing models and their risks, and the questions to ask before you sign. This is general information, not legal advice.
What makes an AI contract different?
With classic software, "does it work" has a binary answer. An invoicing module calculates the amount correctly or it doesn't. With AI the answer is a percentage: the model classifies 94 percent of documents correctly, and that 94 can be 89 next month because the vendor swapped the underlying model.
Three differences follow, and your contract has to absorb them. First, variable quality: performance isn't constant and sometimes degrades without anything changing on your side. Second, your data as raw material: your input makes the product better, which raises the question of who benefits. Third, costs that move with usage: success makes AI more expensive, whereas success under a licence usually costs nothing extra.
Skip these three and you've effectively bought a trial setup with an annual contract underneath it. The prior question of whether to buy at all is covered in our guide on build vs buy for software.
Which terms do you set on your data?
This is where standard contracts are most often written in the vendor's favour. Four questions deserve explicit answers, with "no, unless" as the starting position.
May the vendor train on your data? Standard terms frequently allow this for "product improvement". Write in that training on your data is excluded, or permitted only with explicit consent given case by case.
Who owns the output? What the system produces (generated text, classifications, summaries) has to be unambiguously yours, including the right to use it commercially.
Who owns a tuned model? If fine-tuning happens on your data, the result is a model carrying your domain knowledge. Settle whether you take that model with you on exit, and in which format.
Where does the data sit and who can reach it? Ask about processing locations, sub-processors, and the measures against access by governments outside the EU. Our guide on AI data security covers what to check on the technical side.
[ TIME SAVED ]
Save 9 hours per week on reconstructing after the fact which data an AI vendor processes and where
Which pricing model fits your usage?
AI pricing models differ sharply in how they behave as usage grows. That isn't a detail: it decides whether a successful rollout strengthens your business case or undermines it.
| Pricing model | What you pay for | Risk as you grow |
|---|---|---|
| Per user per month | fixed amount per employee | predictable, but you pay for light users too |
| Per consumption (tokens, calls) | variable, per unit processed | costs rise in direct proportion to success |
| Per item processed | fixed rate per document or conversation | easy to model, check the minimum commitment |
| Fixed annual price with a cap | amount plus a usage limit | overage often priced far higher |
| Own infrastructure | hardware and operations, no usage price | invest up front, flat costs after |
Two clauses matter whatever the model. Agree a maximum annual price increase, for instance indexed with a ceiling, because AI vendors are currently raising rates faster than inflation. And ask for a cost simulation at three usage levels: expected volume, twice that, and five times that. If the vendor can't or won't produce it, you've learned something.
How do you put quality into an SLA?
An SLA covering only availability measures the wrong thing. An AI service can be online 99.9 percent of the time and still be unusable because the answers have become unreliable.
So alongside uptime, fix three substantive commitments:
- An acceptance threshold on your own test set. Before go-live, assemble 100 to 300 representative cases from your own operation with agreed correct answers. The system goes live only above an agreed score, and that set stays the yardstick.
- Notification on model changes. The vendor tells you in advance when it changes the underlying model or version, with reasonable time to retest.
- A fallback scenario. What happens during an outage or a quality drop: does the process fall back to human handling, and who decides?
That test set is the strongest instrument you have, and it costs you a day of work. Without one, every discussion about quality is impressions against impressions.
Who is provider and who is deployer under the AI Act?
The AI Act splits obligations by role. The provider develops the system and places it on the market; the deployer puts it to use inside its own organization. Both roles carry duties, and your contract should say who carries which.
Watch one trap: if you substantially modify a purchased system, or put it out under your own name, you can be treated as the provider yourself, with the documentation and assessment duties that come with it. So record who supplies technical documentation, who retains logs and for how long, and who answers questions from a supervisory authority.
For systems classed as high risk, the heavy obligations have now moved to December 2027. That's a delay, not a cancellation, and a three-year contract runs straight through it. Signing today means signing into the period when those rules take effect.
What do you arrange for the end, at the start?
You negotiate exit terms when your position is strongest: before you sign. Four points cover most situations.
Write in that you can obtain a full export at any time of your source data, your configuration and, where applicable, your tuned model, in an open format and within an agreed period. Agree a transition obligation under which the vendor assists with handover at a rate fixed now. Limit term and automatic renewal to a year at most until the service has proven itself in production. And arrange deletion of your data afterwards, with written confirmation.
For cloud services the law now strengthens that position: our explainer on the EU Data Act and cloud switching sets out the deadlines your vendor has to respect regardless. The broader set of dependencies to avoid is in our guide on avoiding vendor lock-in.
Conclusion: the contract is the first implementation decision
Buying AI software isn't about the lowest price per user. It's about who keeps control once the system matters. Settle ownership of data, output and tuned models, measure quality against your own test set, model costs at five times your current volume, and fix the exit before you start.
Do that, and your choice of vendor becomes a decision you can revisit later. If you want help assessing proposals and terms, our guide on choosing an AI implementation partner covers the selection criteria, and our AI consulting work weighs buying against building.