The Direct Answer: AI Contracts Need More Than Standard SaaS Terms
Buyers evaluating an artificial intelligence vendor should treat the agreement as a combined technology, data-processing, intellectual-property, security, and operational-risk contract rather than as a conventional software licence with an added confidentiality clause. The most important provisions usually address the vendor’s use of customer data, the legal status of model outputs, ownership of prompts and generated material, security controls, audit rights, service levels, prohibited uses, subcontracting, regulatory cooperation, indemnities, and exit assistance.
Also worth reading: How should enterprises draft agentic AI contract liability clauses to address autonomous decision-making risks in 2026? · How Should Organizations Control AI Procurement Risk Before Signing a Vendor Contract? · What should be on an agentic AI vendor contract negotiation checklist in 2026?
A standard SaaS agreement may allocate ordinary hosting risks, but it often does not explain what happens when a model is trained on business records, produces incorrect employment or compliance guidance, accesses connected enterprise systems, or changes its underlying model provider. The legal question is not simply whether the AI service is “good enough”; it is whether the parties can identify the failure modes they are willing to finance and control. For agentic systems that can send email, modify files, or submit claims, that allocation becomes especially important because the vendor’s software may take actions with external legal and financial consequences.
Buyers should also distinguish between a narrow AI tool, such as an internal summarization assistant, and a higher-autonomy platform that connects to customer relationship management, document management, finance, or human-resources systems. The broader the permissions and the more consequential the outputs, the stronger the contractual controls should be. No single clause can replace due diligence, security testing, data mapping, or a workable incident-response process.
Data Use, Training, Retention, and Model Change
The first negotiation point is what the vendor may do with data submitted through the service. The contract should state whether customer content is used to train or fine-tune shared models, whether it may be retained for improvement, fraud prevention, abuse detection, or service support, and how long each category is kept. “We do not sell your data” is not enough if the vendor can use de-identified or aggregated data in a way the buyer cannot inspect or reverse.
A strong clause normally separates customer data from service telemetry, prompts, feedback, support files, generated outputs, and aggregated statistics. It should also identify whether prompts and outputs become part of a vendor’s proprietary model or improvement process. Data-processing terms should specify the processing instructions, security measures, approved subprocessors, international transfers, deletion deadlines, and the buyer’s ability to request a certificate after termination.
Buyers should set measurable deletion periods rather than vague promises to delete “where legally permitted.” For example, the parties could require active customer data to be removed within 30 days of termination, backups to expire within 90 days, and access credentials to be disabled immediately. Those numbers are not universal legal requirements; they are negotiating examples. A vendor may need longer periods for legal holds, security logs, or backup rotation, but it should disclose those exceptions in advance.
The contract should also address model changes. A vendor may materially change a model, move processing to another provider, or discontinue a model version, potentially altering accuracy, data handling, or regulatory compliance. A reasonable provision can give the buyer advance notice of material changes, a defined period to test them, and a right to terminate or receive prepaid fees if the change creates a material security, privacy, or service risk.
Ownership, Licensing, Indemnity, and Output Reliability
Intellectual-property provisions must distinguish between the buyer’s pre-existing materials, vendor materials, customer-specific configurations, prompts, feedback, and generated outputs. The buyer usually needs a perpetual right to use, reproduce, and modify its own content and outputs for internal business purposes, while the vendor retains rights in its platform, model, documentation, and generic know-how.
The difficult issue is output ownership. Depending on the jurisdiction and the nature of the output, a generated result may not qualify as a copyrightable work, may contain third-party material, or may reproduce material that the vendor lacked the right to provide. A clause saying that all outputs are “owned by the customer” does not guarantee exclusivity, copyrightability, or non-infringement. The agreement should instead allocate responsibility for the vendor’s training and generation process and state what remedy applies if the service produces infringing material.
A commercially useful indemnity usually covers third-party intellectual-property claims arising from the vendor’s software, model, or documented use of the service. It should be mutual where appropriate, but it should not make the buyer responsible for indemnifying the vendor merely because the buyer supplied unlawful instructions or used generated content in a prohibited way. The parties should define notice, control of the defence, settlement consent, exclusions, and mitigation obligations.
Accuracy limitations should be explicit. An AI service can produce confident but incorrect statements, omit material facts, or apply an outdated policy. The vendor can warrant that it will use commercially reasonable efforts to meet documented accuracy criteria, but it generally cannot promise that every output is correct in every circumstance. The buyer should retain human review for employment, credit, legal, healthcare, safety, and other decisions where errors can cause harm. A service credit should not be the only remedy when the failure results in regulatory exposure, discrimination, data loss, or a material breach.
Security, Access, Subcontractors, and Regulatory Cooperation
AI vendors often combine several suppliers: cloud infrastructure, model providers, logging tools, retrieval platforms, monitoring systems, and specialist contractors. The contract should identify material subprocessors and require advance notice before a new provider receives customer data. The buyer should have the right to object on reasonable security, privacy, jurisdictional, or regulatory grounds, followed by a negotiation or termination right if the objection cannot be resolved.
Security obligations should be more concrete than a general promise to use “industry-standard” safeguards. The agreement can require encryption in transit and at rest, role-based access control, multi-factor authentication, privileged-access logging, vulnerability management, personnel screening, incident reporting, and business-continuity procedures. A 24-hour notice period for a confirmed security incident may be appropriate for a high-risk service, although the parties should account for the time needed to verify that an event actually occurred and to avoid unnecessary public disclosures.
The vendor should permit proportionate audits, inspection reports such as SOC 2 reports, penetration-test summaries, and independent certifications where available. A customer may reasonably request evidence at least annually, or more often after a material incident. Certification does not eliminate the buyer’s need to assess the service because a SOC 2 report may test controls according to a defined system boundary and period, not whether an AI model is accurate, safe, or suitable for a particular decision.
Regulatory cooperation is another neglected area. The agreement should require assistance with data-subject requests, records preservation, impact assessments, regulator inquiries, and legally binding access requests. It should also prohibit the vendor from notifying a regulator or third party about the customer’s use of the service unless required by law or necessary to address a security emergency. This matters where personal data is processed, where an AI system is used in hiring or public services, or where an agent’s actions could affect an individual’s rights.
Service Levels, Agent Permissions, Liability, and Exit
Service levels should measure things that the vendor can control. Uptime, response time, recovery time, support resolution, incident notification, and availability of documented APIs are generally more verifiable than vague promises about “AI quality.” The agreement can set an initial availability target, such as 99.9% for a business-critical service, while recognizing that monthly uptime calculations and service credits do not compensate for every failure.
For generative AI, quality metrics need a defined context. Accuracy, precision, recall, hallucination rate, or refusal rate can be useful, but only if the test set, task definition, language, user population, and scoring method are specified. A vendor may resist a fixed hallucination percentage because model performance varies by use case. Buyers should ask for task-specific acceptance tests before deployment and require periodic regression testing after material model changes.
Agentic deployments require separate controls. The contract should define which systems the agent may access, which actions it may take, spending or transaction limits, confirmation requirements, approval thresholds, session duration, and logging of tool calls. A system that can “assist” a claims handler is different from one that can approve a claim. A 100-user deployment should not automatically receive the same permissions as a 5,000-user deployment, and a pilot should not silently become production use.
Liability language should be reviewed alongside insurance, indemnities, and the parties’ bargaining power. A supplier may cap aggregate liability at fees paid in the preceding 12 months and exclude indirect or consequential damages. That may be commercially normal, but the cap could be inadequate if the incident causes mass data exposure, unlawful automated decisions, or interruption of critical operations. Buyers can negotiate a higher cap for data-protection, confidentiality, intellectual-property, and security obligations, or separate super-caps for those risks.
Exit provisions should cover data export, model-service termination, transition support, deletion confirmation, and continuity. Ask whether the customer can retrieve prompts, outputs, audit logs, configuration files, and embedded knowledge-base content in a usable format. A vendor that offers 30 days of transition assistance may be less useful if the customer needs 90 days to replace an embedded workflow. The exit plan should be tested before the contract is signed, not after a renewal dispute begins.
Comparing Contract Approaches
| Feature | Balanced enterprise position | Vendor-standard position | Buyer-protective position |
|---|---|---|---|
| Customer data | No shared training; purpose-limited processing | Broad improvement or aggregated-data rights possible | No model training, strict retention limits, deletion evidence, and change rights |
| Outputs | Licence to customer for ordinary business use | “As available,” with no assurance of rights or exclusivity | Customer rights plus vendor responsibility for vendor-controlled infringement |
| Security | Defined controls and annual evidence | General security commitment and certification only | Audit rights, incident deadlines, subprocessor objection, and remediation duties |
| Model changes | Notice and testing rights for material changes | Vendor may update models at its discretion | Advance notice, regression testing, and termination or fee-refund remedy |
| Agent autonomy | Risk-based approvals and action limits | Broad permissions based on account configuration | Explicit tool permissions, transaction limits, human confirmation, and immutable logs |
| Liability | Fees-based cap with negotiated super-caps | Broad cap and exclusions | Higher cap for security, privacy, IP, and confidentiality failures |
Buyers should also compare the contract with alternatives. A fixed-price, low-autonomy pilot can reduce exposure while the parties test accuracy and workflow fit. A private or dedicated deployment may improve control over data and infrastructure, but it can cost more and still depend on the vendor’s model or software. A build-versus-buy arrangement may provide greater control for specialised processes, while bringing recruitment, maintenance, security, and update costs. An independent legal or security review is not a substitute for negotiating the contract, but it can identify risks that a generic procurement process overlooks.
Common Mistakes, Timing, and Cost
One common mistake is negotiating only the order form and terms of service while ignoring the data-processing addendum, security schedule, and product-specific conditions. Another is assuming that a vendor’s public privacy policy is automatically incorporated into the contract. Policies can change, and a policy may not allocate responsibility for business decisions, output errors, or third-party claims.
Buyers also make the error of accepting vague phrases such as “commercially reasonable efforts” without examples, or rejecting all service levels because the model is probabilistic. Both approaches are unnecessarily rigid. Instead, define measurable operational requirements where possible, keep subjective standards for model performance, and require testing against the buyer’s actual workflows.
Timing matters. Review the contract before committing to a pilot, not after the vendor has connected to sensitive systems. For high-risk deployments, allow at least 60 to 90 days for legal, security, privacy, procurement, and business-owner review, although a straightforward low-risk tool may move faster. Renewals and material model changes deserve a second review, particularly if the original agreement is approaching its annual anniversary.
Pricing should be discussed together with risk. Vendors may charge per user, per seat, per API call, per document, per agent action, or through a minimum platform fee. A low monthly price can still produce a high total cost if the service requires premium models, additional storage, human review, or integration work. For budgeting, organisations should include implementation, data preparation, evaluation, security review, monitoring, insurance, and exit migration—not only subscription fees. Public legal articles and contract-analysis tools may be free, but they do not constitute legal advice or a substitute for a jurisdiction-specific review.
The safest practical sequence is to map the intended use, classify the data, rank the possible harms, test the service, and then negotiate the clauses in proportion to those findings. An AI vendor agreement should be treated as an operating control that assigns responsibility, not as paperwork completed after a tool has already been deployed. The strongest contract is one whose promises can be measured, whose exceptions are visible, and whose remedies remain usable when the model behaves differently from the parties expected.