Skip to main content
Orion Five Engineering

10 Jalan Kilang #04-05, Singapore 159410
+65 6100 5505

Book a scoping call
← All insights

Assurance

What your AI vendor contract is probably missing

Most AI agreements reuse SaaS contract templates. Those templates assume software that does what it is told, performs consistently and does not learn from your data. An AI system meets none of these assumptions.

Terence Kok · 2026-06-21 · 5 min read

A stack of matte white machined plates with one thin red shim inserted between two of them, standing slightly proud of the stack.

Executive summary

4

assumptions in a standard SaaS contract that do not hold for AI

5

clauses to insist on before you sign

Key conclusions

  • A standard software contract assumes software that is deterministic and stable and does not learn. An AI system has none of those properties.
  • Performance floors, drift and re-baselining obligations, training-data rights and audit access all need explicit clauses that a SaaS template does not contain.
  • Regulation has not caught up with practice, so for now the contract has to cover issues that the law does not yet address.

Gaps in an AI vendor contract usually appear only after something has gone wrong. That is the worst time to find out that the agreement did not cover the problem.

Standard software contracts were drafted for deterministic products. AI systems produce probabilistic outputs, and their performance degrades over time even when the code does not change. They learn from the data you give them. They also raise provenance questions about the data they were trained on, long before you started using them.

A SaaS template rests on four assumptions that AI systems break

Assumption in a SaaS templateWhat an AI system actually does
Output is deterministic and reproducibleOutput is probabilistic and may differ across identical inputs
Performance is stable until the code changesPerformance drifts in production with no code change at all
Your data is processed, not absorbedYour data may improve the model, and the contract may be silent on who owns that
Provenance is the vendor's own IP questionTraining-data provenance becomes your exposure once you deploy the output

Insist on five clauses before you sign

  • A performance floor that states what the system must still be able to do, and how that is measured. An uptime percentage says nothing about the quality of the output.
  • A drift and re-baselining obligation, with a defined trigger and a clear statement of who bears the cost.
  • Explicit terms on the vendor's right to train on your data, including whether you can opt out and what opting out costs.
  • An exit path that returns your data in a usable form, with its schema.
  • Audit access sufficient to answer a regulator, agreed before you need it.
A closed white document folder with a steel clip and a red ribbon bookmark.

Regulation is still catching up with practice, so for now the contract has to cover issues that the law does not yet address. Draft it carefully now.

Related insights


All insights

Related service


Book a scoping call