Part 1 of this series explained why AI vendor relationships break the assumptions built into most standard software procurement templates, and where those legacy templates leave organizations exposed: silent or vague data training rights, indemnification that doesn’t reach AI-specific harms, no meaningful audit rights, and liability caps that quietly undercut whatever protections do exist. Part 2 gets specific about what to actually put in the contract.

Data Training and Model Improvement Restrictions

The single most important clause to add to any AI vendor contract is an explicit, affirmative prohibition on using your organization’s inputs, outputs, and any data submitted through the tool to train, retrain, fine-tune, or otherwise improve any commercial or publicly available model, without your organization’s prior express written consent. This needs to be specific and unambiguous language, not a general confidentiality clause that leaves the question implicit. It should cover not just the vendor’s own models but any underlying foundation models the vendor’s product is built on top of, since a restriction that only binds the vendor and says nothing about the model provider underneath them leaves an obvious gap.

Given that AI vendors regularly swap or update the underlying models powering their products, the contract should also require advance notice before any material model change that could affect output quality, behavior, or data handling practices. Your organization needs the ability to evaluate a new underlying model before it starts processing your data, not learn about the change after the fact when something behaves unexpectedly.

Indemnification That Actually Covers AI-Specific Risk

Indemnification language needs to be extended explicitly to model outputs and predictions, not just to the underlying software or platform itself. A standard IP indemnification clause protecting against claims that the software infringes a third party’s rights typically doesn’t reach a claim that a specific AI-generated output, a piece of text, an image, a code suggestion, infringes someone’s rights or defames someone. That gap needs to be closed directly in the contract language.

Training data provenance indemnity deserves its own explicit attention, and it’s often the hardest provision to actually get a vendor to agree to, precisely because it’s the provision vendors are most exposed on. If the underlying model was trained on improperly sourced or infringing data, your organization can face real exposure simply for having used or commercialized outputs from that model, even without any independent wrongdoing. Push for indemnification that specifically addresses this scenario, and treat vendor resistance on this particular point as a meaningful data point about how confident the vendor actually is in its own training data practices.

Critically, indemnification provisions need to be negotiated in coordination with liability limitation clauses, not as a separate, disconnected section of the contract. An indemnification promise that sounds robust on its own can be effectively meaningless if the same contract caps the vendor’s total liability at a figure like the fees paid over the prior twelve months. For a relatively low-cost AI tool handling high-sensitivity data, that cap can represent a small fraction of your organization’s actual exposure. Push for liability caps calibrated to the actual risk and sensitivity of the data involved, not a flat, boilerplate figure carried over from a generic services agreement.

Audit Rights and Verification Mechanisms

A contractual promise that a vendor won’t train on your data, or will handle it according to specific security and retention standards, is only as good as your organization’s ability to actually verify that promise is being honored. Push for audit rights, or at minimum a contractual right to request compliance documentation and evidence of the technical controls a vendor claims to have in place, such as training-disabled configurations, retention settings, and access controls. Without some verification mechanism, your organization’s assurance rests entirely on the vendor’s self-reporting, which is not a meaningful control in any vendor relationship handling data your organization would classify as confidential, privileged, or regulated.

Data Residency, Subprocessors, and Retention

The contract should require the vendor to disclose where data is stored and processed, and to identify any subprocessors or underlying model providers involved in delivering the service, including any that process data on the vendor’s behalf. This disclosure obligation should be ongoing, not a one-time representation made at signing, given how frequently AI vendors add or change subprocessors and underlying model relationships. The contract should also specify data retention terms, ideally the shortest retention period consistent with the actual business need, along with a defined, enforceable process for data deletion upon request or at contract termination.

Regulatory Compliance Provisions

Given the pace of AI-specific regulation, including the EU AI Act’s now-active enforcement regime, contracts with AI vendors should include an affirmative representation that the vendor’s product and practices comply with applicable AI regulation in the jurisdictions where your organization operates, along with an obligation to notify your organization promptly of any regulatory investigation, enforcement action, or material compliance finding affecting the vendor’s AI systems. This gives your organization visibility into regulatory risk building up on the vendor side before it becomes your problem too.

Termination and Exit Rights

Finally, build in a genuine data portability and exit plan as a contractual right, not an assumption. If the vendor relationship ends, whether due to a business decision, a vendor’s financial instability, or a discovered compliance failure, your organization needs a defined, contractually guaranteed process for retrieving its data and confirming deletion from the vendor’s systems, including from any subprocessors. Vendors facing financial distress or facing their own regulatory troubles are exactly the vendors from which a clean, guaranteed exit matters most, and that’s precisely when informal, good-faith cooperation is least likely to be available.

Negotiating Leverage: What to Expect From Different Vendor Types

It’s worth being realistic about negotiating leverage here. A small, high-growth AI startup with a handful of enterprise clients may be genuinely willing to negotiate most of these provisions in exchange for a meaningful contract. A dominant platform vendor with standardized terms and enormous market power may resist several of these clauses, particularly training data provenance indemnity and audit rights, treating them as non-negotiable boilerplate. In those cases, the practical path forward often runs through your organization’s own AI vendor due diligence and approval process: if a vendor won’t agree to baseline protections around a specific data classification, the answer may be restricting that vendor’s approved use case to lower-sensitivity data rather than accepting the gap for confidential or regulated information. That’s exactly the kind of decision an Approved AI Tool List, tying specific vendors to specific approved use cases and maximum data classifications, is designed to capture and enforce consistently across your organization.

The Bottom Line

AI vendor contracts deserve their own dedicated review process, not a pass through the same template used for conventional software procurement. The specific gaps, silent training rights, indemnification that doesn’t reach model outputs or training data provenance, missing audit rights, and liability caps that undercut whatever protections exist, are predictable and addressable, but only if legal and procurement teams treat AI vendor contracting as a distinct discipline requiring its own playbook. Build that playbook now, and apply it to every new AI vendor relationship going forward, rather than discovering these gaps retroactively when something goes wrong.