AI Vendor Contract Requirements: A 2026 Due Diligence Checklist for In-House Counsel

Why AI Vendor Contracting Is Different in 2026

Your company's AI adoption curve has outpaced your vendor management program. You are not alone. Most in-house legal teams we talk to are building AI procurement workflows from scratch in 2025 and 2026, layering new requirements onto standard SaaS templates that were never designed for probabilistic systems that generate novel outputs, train on vast datasets of unclear provenance, and evolve over time without notice. The risk is not hypothetical: AI vendors increasingly carve out AI-generated outputs from IP indemnity, reserve the right to train on your customer prompts, and cap liability at amounts that do not begin to cover a copyright infringement suit or a regulatory enforcement action.

This article is written from the enterprise buyer's perspective — the GC evaluating, contracting with, and managing AI tool vendors. We have covered board-level AI oversight obligations and the internal AI use policy in prior pieces. Here, we focus on the operational vendor-contracting layer where most risk actually materializes: the contract you sign, the diligence you run before signing, and the ongoing obligations you build into the relationship.

IP Indemnification: The Gap Nobody Talks About

Standard technology vendor contracts include an IP indemnity: the vendor agrees to defend and hold you harmless against third-party intellectual property infringement claims arising from your use of their software. That provision worked when software was deterministic — it produced the same output for the same input, and any infringing content was something the vendor authored or selected.

Generative AI breaks that model. The vendor does not author the output; the model generates it. Major LLM providers like OpenAI and Anthropic have begun offering IP indemnity for third-party infringement claims related to their outputs, but most mid-tier and enterprise AI SaaS vendors have not followed suit — or worse, they have explicitly carved out AI-generated content from their standard IP indemnity. This means your company can be sued for copyright infringement over content the vendor's model produced, and the vendor's contract says, essentially, "not our problem."

What to demand in the contract:

• Explicit coverage of AI-generated outputs. The IP indemnity must state that it covers claims arising from outputs generated by the AI system, not just the vendor's authored code or interfaces. If the vendor will not agree to this, you need to understand the gap and either negotiate a separate AI output indemnity, require the vendor to carry specific coverage, or cap your company's exposure through use-case restrictions.
• Training data infringement coverage. If the vendor's model was trained on copyrighted material without a license, your use of the model's outputs could expose you to secondary infringement liability. The indemnity should extend to claims that the model itself — and not just its outputs — infringes third-party IP.
• No offset against liability caps for IP claims. IP indemnity should be carved out from the general liability cap (or subject to a separate, higher cap). Many AI vendor templates apply the same low cap to all claims, including IP infringement, which leaves you exposed to multimillion-dollar litigation with a $50,000 recovery.

For a deeper discussion of the IP ownership issues that arise after the contract is signed, see our earlier piece on IP ownership of AI-generated work product.

Training Data Provenance: What You Don't Know Can Hurt You

When you deploy an AI system, you are not just adopting a tool — you are inheriting the legal risk of how that tool was built. If the vendor's model was trained on copyrighted works without authorization, downstream users may face exposure even if they did not directly infringe. The active litigation against AI companies — including the multidistrict litigation consolidating copyright claims against OpenAI — illustrates that training data provenance is a live legal risk, not a theoretical one.

What to demand from the vendor:

• Training data source disclosure. At minimum, the vendor should disclose the categories of training data sources (licensed datasets, publicly available web data, synthetic data) and identify whether any third-party content was used under a license, a fair use theory, or without authorization. You do not need every URL — you need enough to assess whether your company is inheriting litigation risk.
• Representations regarding training data rights. The vendor should represent that it has obtained appropriate rights or licenses for all training data used to build the model, or that it has conducted a documented fair use analysis. If the vendor cannot or will not make this representation, that is a material risk factor you need to escalate.
• Ongoing notice of training data disputes. If the vendor becomes aware of a claim that its training data infringes third-party rights — for example, a cease-and-desist letter or a filed lawsuit — the contract should require prompt notice to you, so your company can make informed decisions about continued use.

Sub-Processor and Model-Update Notification Rights

AI vendors frequently change the models powering their products. A vendor that was using GPT-4 yesterday may switch to a different model tomorrow — or fine-tune the existing model in ways that change output quality, accuracy, or behavior. Standard SaaS sub-processor notification clauses do not cover this, because a model update is not a new sub-processor; it is a change to the core functionality of the product you purchased.

What to demand:

• Advance notice of material model changes. The contract should require the vendor to provide advance written notice (we recommend 30–60 days) before deploying a material model update that affects the system's outputs, accuracy, or behavior. "Material" should be defined by reference to the use case your company has licensed the tool for, not by the vendor's internal metrics.
• Right to test before forced migration. Your company should have the right to test the updated model in a staging or sandbox environment before the vendor moves your production instance to the new version. If the new model produces materially different results, you need the right to delay migration or, in some cases, terminate without penalty.
• Sub-processor flow-down. If the vendor uses third-party model providers (e.g., an AI SaaS company that calls OpenAI's API), the contract should require notice of any change to the underlying model provider and should flow down the same data protection and confidentiality obligations to that sub-processor.

Audit Access Rights

You cannot manage what you cannot inspect. AI vendors often resist audit clauses, citing the confidentiality of their models and training data. But as the deployer of the AI system, your company may bear regulatory responsibility for how the system behaves — and that means you need audit access that goes beyond a standard SOC 2 report.

What to demand:

• Logging and record-keeping access. Under the EU AI Act, deployers of high-risk AI systems must keep logs generated by the system for a minimum period (generally six months, extendable). The contract should require the vendor to provide access to system logs, input/output records, and metadata sufficient for your company to comply with its own regulatory record-keeping obligations.
• Model performance documentation. The vendor should provide documentation describing the model's intended purpose, known limitations, accuracy metrics, and bias testing results. This is not just good practice — under EU AI Act Article 26, deployers of high-risk AI systems must use the system in accordance with its instructions for use, and you cannot do that without the documentation.
• Third-party audit rights. For high-stakes use cases (hiring, credit, healthcare, legal), your company should have the right to engage a qualified third-party auditor to assess the vendor's model for bias, accuracy, and compliance with applicable law — at the vendor's facility or remotely, with reasonable notice and confidentiality protections.

Data Processing Terms When the Vendor Trains on Your Data

This is the provision that most standard DPAs get wrong. A traditional DPA governs the vendor's processing of customer data on the customer's behalf, for the customer's instructions. It assumes the vendor is a processor — it receives data, performs a service, returns results, and deletes or returns the data at termination.

AI vendors often want to do more. They want to use your prompts, your inputs, and your outputs to improve their models. This is not processing on your behalf; it is processing for the vendor's own purposes. Standard DPAs do not contemplate this, and the legal classification is ambiguous: is the vendor now a controller of your data? A joint controller? Neither?

What to demand:

• Opt-in for model training. The vendor should not use customer prompts, inputs, or outputs for model training or improvement without explicit, separate consent. This should be a standalone provision, not buried in the master agreement's data section. If your company needs the vendor to train on your data (for fine-tuning a custom model), that should be governed by a separate agreement with distinct terms.
• Data deletion and retention controls. If the vendor has used your data for any purpose, you need the right to request deletion of that data from training datasets — and you need the vendor to represent that such deletion is technically feasible. If it is not (because the data has already been incorporated into model weights), the vendor should disclose that limitation before you sign.
• Cross-border data flow restrictions. If your data is subject to GDPR, HIPAA, or other residency requirements, the DPA must explicitly prohibit the vendor from transferring data to jurisdictions that lack adequate protections — and must require the vendor to flow those restrictions down to any sub-processors, including model API providers.

Liability Allocation: When Insurance Does Not Cover AI

Here is the uncomfortable truth: most commercial general liability (CGL) and errors and omissions (E&O) policies contain AI-specific exclusions or have not been updated to cover AI-related claims. This means the contractual risk allocation between you and the vendor is your primary defense, not your insurance program.

What to demand:

• Higher liability caps for IP and data breach claims. The general liability cap in a SaaS contract is typically 12 months of fees. For AI vendor contracts, IP infringement and data breach claims should be carved out of the general cap and subject to a separate, higher cap — or uncapped entirely. A year of fees for a $2,000/month tool will not cover a copyright damages award.
• Specific insurance requirements. The vendor should carry technology errors and omissions insurance and cyber liability insurance with limits appropriate to the risk profile of the AI system. The contract should require the vendor to name your company as an additional insured and to provide certificates of insurance annually.
• No AI-specific disclaimers that eliminate recourse. Many AI vendor contracts include broad disclaimers that the output may be inaccurate, incomplete, or unsuitable for the customer's purpose — and then disclaim all liability for any damages arising from use of the output. These disclaimers should be narrowed to reflect the actual use case: if the vendor is marketing the tool for a specific purpose (contract review, code generation, hiring), the implied warranty of fitness for that purpose should survive.

Regulatory Drivers: TRAIGA, EU AI Act, and Sector-Specific Rules

TRAIGA (Texas Responsible Artificial Intelligence Governance Act)

TRAIGA took effect on January 1, 2026, and it applies to "deployers" — defined as persons who deploy an AI system for use in Texas. If your company is headquartered in Texas or operates there, you are likely a deployer under TRAIGA. The law gives the Texas Attorney General exclusive enforcement authority, with civil penalties ranging from $10,000 to $200,000 per violation and ongoing penalties of $2,000–$40,000 per day.

The key procurement implication: TRAIGA offers a safe harbor for companies that substantially comply with the NIST AI Risk Management Framework or similar recognized standards. This means your vendor selection process should include an assessment of whether the vendor's AI system aligns with the NIST AI RMF — and your contract should require the vendor to maintain that alignment over the life of the agreement. For more on TRAIGA's safe harbor and what it means for your compliance program, see our analysis of why the NIST AI RMF is now a business decision.

EU AI Act Deployer Obligations

If your company operates in the EU or deploys AI systems that affect EU residents, the EU AI Act imposes direct obligations on you as a deployer of high-risk AI systems. Article 26 requires deployers to use high-risk AI systems in accordance with the provider's instructions for use, ensure human oversight by individuals with the necessary competence and authority, monitor system operation, and keep logs for the applicable retention period. The Act also requires deployers to conduct fundamental rights impact assessments for certain high-risk AI applications (Article 27).

The procurement implication is direct: you cannot comply with Article 26 if your vendor does not provide the instructions for use, the technical documentation, and the logging capabilities the law requires. Your vendor contract must include the vendor's obligation to deliver and maintain these artifacts — and to notify you when the system changes in a way that affects your compliance obligations. The EU Model Contractual Clauses for AI Procurement, published by the EU Public Buyers Community in 2025, provide a useful template even for private-sector buyers. They are not legally mandatory, but they are rapidly becoming the de facto standard for AI vendor contracting and align with the high-risk AI system requirements under the AI Act.

Sector-Specific Rules

Beyond horizontal AI laws, sector-specific regulations impose vendor selection obligations on the deployer:

• Healthcare (HIPAA/HITECH): If the AI vendor processes protected health information, the vendor must sign a Business Associate Agreement (BAA). Standard BAAs do not contemplate the vendor training models on PHI — and if the vendor does so, both parties may be in violation. The contract must explicitly address whether and how the vendor may use PHI for model improvement, and the BAA must be updated accordingly.
• Financial services (ECOA/FCRA): AI used in credit decisions must comply with fair lending laws. The vendor must provide documentation sufficient for the deployer to conduct adverse action notices and fair lending testing.
• Employment (EEOC/Title VII): AI hiring tools must not produce discriminatory outcomes. The vendor must provide validation data and bias testing results sufficient for the employer-deployer to defend its use of the tool if challenged.

Actionable Next Steps

If you are a GC building an AI vendor contracting program, here is what we recommend you do in the next 90 days:

1. Build an AI vendor risk tier. Not every AI tool carries the same risk. A general-purpose writing assistant is different from an AI hiring tool or a clinical decision support system. Tier your vendors by risk level (we recommend a three-tier model: low, medium, high) and calibrate your diligence and contract requirements accordingly.
2. Audit your existing AI contracts. Pull every active vendor agreement that involves an AI system and check for the gaps we identified above: IP indemnity carve-outs, missing training data representations, absent model-update notice provisions, and inadequate liability caps. Flag the contracts that need renegotiation at renewal.
3. Create an AI vendor diligence questionnaire. Use the NIST AI RMF as your framework. The diligence questionnaire should cover training data sources, model governance, bias testing, security practices, sub-processor dependencies, and the vendor's own regulatory compliance posture. Require completed questionnaires before contract execution.
4. Update your contract templates. Add the provisions we outlined above to your standard AI vendor template: AI output IP indemnity, training data provenance disclosures, model-update notification, audit access, DPA updates for model training, and elevated liability caps for IP and data claims. If you need a starting point, the EU Model Contractual Clauses for AI Procurement are a useful reference — even for U.S.-based buyers.
5. Align with your compliance program. If your company operates in Texas, confirm that your vendor selection process documents alignment with the NIST AI RMF to qualify for the TRAIGA safe harbor. If you operate in the EU, confirm that your contracts require vendors to deliver the technical documentation and logging capabilities that Article 26 demands.

The vendors you select today will define your company's AI risk profile for years. The contract is where that risk is allocated — and where you, as GC, have the most leverage to demand terms that protect your company. Use it.