Do standard software contracts work for AI vendors?

Standard SaaS agreements were not designed for AI-specific obligations.

Can I negotiate AI vendor contracts?

Depends on the vendor and your relative bargaining power. Tier-1 AI vendors (OpenAI, Anthropic, Google, Microsoft) have enterprise agreements that are more negotiable at the enterprise tier than their standard terms suggest. Mid-tier and specialized AI vendors are often willing to negotiate DPA terms, training data use restrictions, incident notification timelines, and SLA terms when the contract is significant.

What should a good AI vendor contract include?

A well-drafted AI vendor agreement for enterprise deployment should include: (1) a data processing agreement that explicitly addresses training data use and prohibits use of your data to train models deployed to third parties without consent; (2) model change notification requirements (minimum 30 days notice for material model updates); (3) incident notification obligations (vendor notifies.

AI Vendor Contract Red Flags: 12 Clauses to Fix in 2026

TL;DR: AI vendor contracts written before 2024 do not address EU AI Act deployer obligations, state AI employment law requirements, or training data controls. Twelve specific contract clauses create compliance gaps. Most legal teams miss them because they are evaluating AI contracts using standard SaaS review criteria.

The AI vendor contract that your procurement team signed last year was probably reviewed by commercial counsel using the standard SaaS agreement checklist: liability cap, data processing agreement, uptime SLA, termination rights, IP ownership. That checklist was developed for cloud software that does what it was configured to do, consistently, in the same way each time.

AI systems are different. They can drift. They can be updated in ways that change outputs without triggering a "software update" notification. They may use your data to train models that are deployed elsewhere. When they fail, the failure may look less like a server going down and more like a pattern of outcomes that causes harm over time, without any single event that triggers a breach notice.

These twelve contract clauses create compliance and liability risk that standard SaaS review misses.

Red flag 1: No explicit training data opt-out

Many AI vendor agreements, particularly for generative AI tools, include terms that allow the vendor to use "usage data" or "interaction data" to improve services. Without a specific carve-out, this may include using your employees' queries, the documents they submit, and the outputs they generate to train models that are deployed to other customers.

The liability risk: if your employees submit confidential information to an AI tool and that information appears in another customer's AI output, you face both a contractual breach with your clients and a potential GDPR or state privacy law violation.

What to look for: The contract should explicitly state that the vendor will not use your organization's data to train models deployed to third parties. A good DPA will have this as an explicit opt-out with a default to not training. A red flag is a clause that says the vendor "may use interaction data to improve services" with no carve-out.

Red flag 2: Model change notice period under 30 days

Enterprise AI vendors regularly update their underlying models. A model update can change the outputs your users receive, including for inputs that previously produced consistent results. If you have deployed an AI system in a high-stakes context (employment decisions, loan underwriting, medical triage), a model change that changes output distributions can create compliance risk and liability before you know the change happened.

What to look for: Require at least 30 days written notice before material changes to the underlying model used in your deployment. A red flag is a clause that says the vendor may update models "to improve performance" without any notification obligation. Some vendors use 7-day or 14-day notice windows, which are insufficient for regulated use cases.

Red flag 3: Incident notification timeline that does not match regulatory requirements

EU AI Act Article 73 requires providers to notify deployers when serious incidents occur. But many AI vendor contracts specify incident notification timelines that are misaligned with regulatory requirements, either longer than the regulatory deadline or scoped differently (e.g., defined around cybersecurity incidents, not AI performance failures).

What to look for: The contract should require the vendor to notify you within 24 hours of becoming aware of any incident involving your deployment that causes or could cause serious harm to users, or that could trigger regulatory reporting obligations. The contract should also define what an "AI incident" means, not just a security incident.

Red flag 4: No data processing agreement for AI outputs

Standard DPAs address how the vendor processes your organization's data. They typically do not address what happens when the AI system generates outputs that contain personal data about third parties (customers, applicants, employees) who did not directly interact with the system.

What to look for: The DPA should explicitly address AI output data, including who is the controller and processor for outputs that contain personal data, how long output data is retained, and whether output data can be used for model improvement.

Two men working at laptops side by side in a bright office, representing the compliance risk assessment process for AI procurement agreements

Red flag 5: Bias audit language that does not meet any law's standard

Several AI vendors now include clauses in their agreements stating they conduct bias audits. The language is often vague enough to satisfy no specific law's audit requirement. NYC Local Law 144 requires an independent bias audit by a specific definition of "independent." Colorado SB 26-189 has no audit duty, but from January 1, 2027 it requires developers to give deployers documentation on intended uses, known limitations and how to monitor the tool. A clause that says the vendor "regularly tests for bias using internal processes" satisfies neither law.

What to look for: If you need bias audit compliance for a specific law, require the vendor to provide documentation of an audit that meets that law's specific requirements, including who conducted it, the methodology, and the results. A vendor that cannot provide this documentation for the laws applicable to your use case is not a compliant vendor for that use case.

Red flag 6: No human oversight support obligation

EU AI Act Article 14 requires deployers of high-risk AI systems to ensure human oversight. The practical problem: human oversight is only possible if the AI system provides the information needed to enable it, including confidence scores, flagging of low-confidence outputs, and explanations of why the system produced a given output.

What to look for: For any AI system you are deploying in a high-risk context under the EU AI Act, the vendor should contractually commit to providing the documentation and system features needed for human oversight. A red flag is a vendor that says "you are responsible for your own oversight" with no obligation to provide the technical means to do it.

Red flag 7: Liability cap that does not match AI performance risk

Standard SaaS liability caps are often set at the fees paid in the prior 12 months. For an AI system used in employment decisions affecting thousands of employees, the regulatory enforcement risk (an EEOC investigation, a NYC LL144 enforcement action, an action under Colorado's anti-discrimination law, which SB 26-189 leaves open even though it creates no new private right of action) could significantly exceed one year's SaaS fees.

What to look for: Negotiate a liability cap that reflects the actual risk profile of your use case. For AI tools used in employment, credit, or healthcare decisions, a 12-month fee cap is inadequate. Consider negotiating for a higher cap, carve-outs for claims arising from the vendor's model performance failures, or an indemnification for regulatory actions caused by the vendor's AI system.

Red flag 8: Indemnification exclusion for "AI outputs"

Some AI vendor agreements include blanket exclusions from the indemnification obligation for claims arising from AI-generated content or outputs. This means that if the AI system generates a discriminatory recommendation or a materially false statement that creates legal liability, the vendor's indemnification does not cover it.

What to look for: Review the indemnification exclusions for any language that broadly excludes AI outputs. A more reasonable allocation: the vendor indemnifies for claims arising from the AI system performing in a way inconsistent with the vendor's representations, and you indemnify for claims arising from your deployment context.

Red flag 9: "Enterprise AI features" gating that controls your regulatory compliance

Some vendors gate specific features, like audit logs, data export, or bias monitoring, behind enterprise tiers. If you need those features for regulatory compliance but signed up at a lower tier, you may find you cannot satisfy your compliance obligations without upgrading.

What to look for: Identify which features are required for compliance with applicable regulations before signing. Confirm contractually that your service tier includes all required features, or get a commitment on pricing if you need to add them.

Red flag 10: Jurisdiction clauses that create enforcement gaps

Standard SaaS agreements often specify a single governing law and jurisdiction. For AI systems subject to EU AI Act deployer obligations, the governing law for the contract may be in conflict with the regulatory obligations applicable to your deployment.

What to look for: For EU deployments, the contract's governing law clause should not create a situation where your EU regulatory obligations cannot be enforced through the contract. At minimum, ensure the contract includes explicit compliance with EU AI Act deployer obligations, independent of the contract's governing law.

Red flag 11: No SLA for AI performance, only for uptime

Traditional SaaS SLAs measure uptime and availability. AI system performance is different: a system can be fully available and producing outputs that are wrong, harmful, or degraded in quality due to model drift. Most AI vendor agreements do not include performance SLAs (e.g., accuracy thresholds, output quality standards, bias metric thresholds).

What to look for: For AI systems in high-stakes contexts, negotiate performance SLAs with defined remedies. The most practical approach: require the vendor to notify you when performance metrics fall below defined thresholds, and negotiate the right to terminate without penalty if performance remains below threshold for more than a defined period.

Red flag 12: Termination provisions that lock in your data

Some AI vendor agreements include termination provisions that make it difficult to retrieve your data or transition to another vendor. If you store historical outputs, training data, or user interaction logs with the vendor, a hard termination provision that limits export rights creates vendor lock-in.

What to look for: The contract should provide for data export in a standard format within a defined period after termination. The vendor should have no right to retain your data post-termination except as required by law.

A useful negotiating anchor: request a 30-day export window after notice of termination, with export available in CSV or JSON, and explicit deletion certification within 60 days. Vendors that refuse this are signaling that data portability is not a priority, which is itself a red flag for a long-term relationship.

Next steps

For the broader vendor due diligence process, the agentic AI vendor contract clauses guide covers what contracts should include for AI agents specifically. The AI vendor due diligence in 30 minutes guide provides a fast checklist for evaluating new vendor relationships before contract stage.

Correction (October 16, 2026): Earlier versions said Colorado SB 189 requires bias testing documentation and creates a private right of action. It does neither; it requires developer documentation for deployers and leaves existing anti-discrimination claims in place (signed act).