Most AI vendor contracts are recycled SaaS agreements with “artificial intelligence” written into the product description. The underlying legal structure was designed for software that does what it is told, runs predictably, and does not learn from your data. AI does none of those things.
The gap is not a legal technicality. It is a business risk.
When something goes wrong — a model degrades, a vendor uses your client data to train its next product, a data breach is discovered three months after the fact — the question you will face is whether your contract gave you any protection. For most organisations that signed a standard vendor template, the answer will be no.
What standard contracts miss
The typical enterprise software contract is built around four concerns: what the software does, what it costs, what happens when it breaks, and how either party can exit. These are necessary but insufficient for AI.
AI systems have properties that generic software does not. They produce probabilistic outputs that can degrade over time without any code change. They are trained on data, and the provenance of that training data has legal implications for your organisation. The model improvements the vendor makes to their platform may be based on your data, without you knowing. And when you terminate the contract, the question of what happens to data that has already been used in training is genuinely unresolved in most agreements.
These are the gaps that need explicit contractual coverage.
The ten clauses that matter
1. Data rights and ownership
Your input data and any AI-generated outputs belong to you. The vendor is explicitly prohibited from using your data — including queries, documents, and outputs — to train or fine-tune its models without written consent. This clause needs to be explicit, not implied.
The default position of many AI vendors is that model improvements derived from client usage belong to the vendor. That is a position you need to actively contract out of.
2. Confidentiality and security
Security obligations should be aligned to ISO/IEC 27001 or equivalent. Breach notification must have a defined time window — 72 hours is the EU AI Act and GDPR standard, and a reasonable floor for any AI contract. The vendor should commit to providing SOC 2 reports or equivalent audit evidence on request.
3. SLA and performance
Uptime targets (99.9% is a reasonable minimum for production AI applications), defined maintenance windows with advance notice, and service credits for SLA breaches. This is table stakes in any enterprise software agreement, but AI contracts often omit it or set thresholds too low given AI’s operational criticality.
4. Performance and accuracy warranties
This is where AI contracts diverge most sharply from generic SaaS agreements. AI models degrade. Accuracy on the vendor’s benchmark does not equal accuracy on your real-world use case. The contract should specify minimum accuracy or output quality thresholds for your application, and create an obligation on the vendor to retrain or adjust if performance falls below that threshold.
Without this clause, you have no recourse when the model that worked in your pilot produces inconsistent results in production six months later.
5. Liability allocation
The vendor should indemnify you for three categories: third-party IP infringement arising from the AI model (a live risk given ongoing litigation over training data copyright), data breaches caused by the vendor’s systems, and regulatory violations caused by the vendor’s AI.
Liability caps are standard in software contracts. For AI, the caps should have carve-outs for confidentiality breaches and security incidents — these are the scenarios where uncapped liability is most appropriate.
6. Regulatory compliance
The vendor warrants compliance with applicable AI regulations in your operating jurisdictions. For organisations operating in Singapore, this includes the PDPA and the Model AI Governance Framework. For those with EU exposure, EU AI Act compliance is becoming a practical requirement as obligations phase in through 2026-2027. The vendor must notify you of regulatory changes that affect the service within a defined timeframe.
7. Transparency and audit rights
Disclosure of training data categories (not necessarily the full dataset, but the categories and sources), provision of model cards, and the right to commission a third-party audit of model fairness and security. This is particularly important for AI applications used in decisions that affect people — hiring, credit, access to services.
8. IP rights in custom development
Where the engagement involves custom model development, fine-tuning, or prompt engineering, ownership of those artefacts must vest explicitly in your organisation. The vendor’s boilerplate will typically claim ownership of anything built on their platform. This needs to be negotiated out for any bespoke work.
9. Termination, exit, and data return
The right to export all data and model artefacts on termination. The vendor’s obligation to delete or destroy your data after the contract ends — with evidence of destruction. A minimum 90-day transition assistance period so you can migrate without service disruption. The default vendor position often gives you very little here, particularly on model artefact portability.
10. Dispute resolution and governing law
For contracts with Singapore-based or APAC operations, Singapore law as governing jurisdiction is appropriate and provides a mature legal framework for technology disputes. Confidentiality of dispute proceedings protects both parties from reputational exposure during what are often commercially sensitive disagreements.
Why this matters now
IP and AI regulatory frameworks are still catching up with practice. That creates a window where the contract — not the law — is your primary protection.
Vendors know this. Their standard terms are written to protect them in that window. The 10 clauses above do not require extraordinary negotiation leverage. They require that you know what to ask for and that you ask before you sign, not after a problem has surfaced.
Most organisations discover these gaps at the worst possible time: during a vendor dispute, a data incident, or a regulatory inquiry. At that point, the contract says what it says.
Review your current AI vendor agreements against this list. For any new engagement above a meaningful spend threshold, treat these as the minimum negotiation requirements, not optional additions.
The technology may be new. The exposure is not.