Ed. Note: This is the third article in our series, Smarter AI Vendor Contracts: Legal Strategies for Protecting Your Business. Read Part 1, Part 2, Part 3, and Part 4.
The final article in this series addresses two topics that are often underestimated in AI vendor contracting: the traditional “boilerplate” provisions that require meaningful revision for AI engagements, and the post-signature governance framework that gives the contract operational force.
Boilerplate Provisions that Need AI-Specific Updates
Due to the unique nature of how AI functions and the risks associated with the use of AI tools, several categories of provisions that are standard in technology agreements require recalibration for AI vendor contracts.
Representations and Warranties. As we discussed in previous articles in this series, AI model behavior is often opaque due to the autonomous processing that is a feature of AI tools and the unpredictability of outputs. That opacity also makes it difficult to address specific concerns through contractual provisions. For instance, in a traditional SaaS application where the application produces an output based explicitly on the coding and data provided by the developer it is simpler to ensure the output does not violate third-party intellectual property (“IP”), as the output is based purely on the developer’s programming. However, with an AI tool, where the output may be based on a broad range of data, on which it was trained, including third-party data, ensuring the output does not infringe any third-party intellectual property rights, or ownership rights in the output may not be as clear cut. As such, representations and warranties play a crucial role in AI vendor agreements to provide customers with the assurances needed to use a tool that embodies uncertainties.
Depending on the AI tool engagement, and contemplated uses of it, the vendor should represent and warrant:
- to non-infringement of third-party intellectual property: specifically, that the AI tool itself does not violate any third-party intellectual property rights, and that the outputs will not infringe any third-party intellectual property rights (this point is related to the next representation and warranty).
- to provenance of data used to train its models: that (a) the training data does not infringe any third-party intellectual property rights and/or that the vendor has necessary rights in the training data, (b) the training data is free of any biases and/or that the vendor actively tests for and remediates biases, and (c) the training data is accurate and complete and/or that the vendor actively tests for accuracy and remediates inaccuracies.
- that the outputs of the AI tool will be accurate and free of any known biases.
- to compliance with applicable laws and policies, including data residency requirements and laws related to data privacy, data security and AI development.
- the vendor will not commingle the customer’s data, prompts, or inputs with other customers’ data.
- that vendor will not provide the customer’s data, prompts, or inputs as outputs for other clients, which is a concern with both confidentiality and antitrust dimensions.
- that the AI tool does not contain any known vulnerabilities (e.g., gaps in security measures, viruses, malicious code, etc.) and that the use of the AI tool is secure.
AI tools are also unique in the sense that as they continually ingest data, they evolve over time. The contract should include a mechanism for updating the agreement upon major model changes, new regulatory requirements, or expanded use cases. The representations and warranties should align vendor commitments with the customer’s corporate AI principles and internal guidelines.
Indemnities. Due to the opacity of AI models, customers may have to trust and rely on representations and information provided by the vendor. In the event of any harm resulting from the use of the AI tools, especially to any third-parties, the vendor’s Indemnification provisions should include a tailored IP indemnity covering claims that the services, models, or outputs infringe or misuse third-party rights. This indemnity must extend to claims arising from training data sources and from the acts of the vendor’s subcontractors. A separate data breach indemnity should cover costs associated with security incidents. The vendor should also commit to supporting the customer in regulatory proceedings related to the AI services. If possible, the customer should consider including indemnification obligations of the vendor for biased or inaccurate outputs. A vendor may reject such indemnification obligations for biases or inaccuracies, however, such a refusal may open the door for an opportunity to discuss and negotiate favorable terms for bias and inaccuracy detection or human-in-the-loop obligations.
Limitations of Liability. Liability caps should be meaningful. Typically, a liability cap should be tied to amounts paid or payable under the agreement with multipliers depending on the sensitivity of the data to be processed by the AI system and the foreseeability of harm. Liability caps should also include carve-outs for IP infringement, data breach, confidentiality breaches, willful misconduct, and regulatory fines where legally permissible.
Additionally, indemnification obligations should be exempt from the liability cap. In the context of an agreement for an AI system, indemnification obligations require the vendor to cover the customer for any third-party damages arising from the AI system or the vendor’s obligations under the agreement. If a third-party is harmed due to the AI system designed by the vendor or the vendor’s actions or omissions in performing its contractual obligations, the vendor should not be able to cap its liability to the injured third-party and leave the customer to cover the remainder of the damages.
In some cases, supercaps (i.e., the general liability cap multiplied by some factor) for specific categories of harm, such as data breach, IP infringement or third-party harm, provide a middle ground between uncapped liability and a cap that may be insufficient to cover the customer’s exposure.
Audit, Transparency, and Reporting. The contract should grant the customer audit rights for security and data processing practices, and impose transparency obligations regarding training data categories, model updates, safety incidents, and material changes. The vendor should commit to cooperating with audits, impact assessments, and regulatory inquiries, and to maintaining logs and documentation necessary for compliance. While not all aspects of an AI system may be inspectable, the transparency obligations should provide for the vendor to, at least, explain and describe the functionality of its AI system and how it arrives at outputs. If a vendor is unable to provide such explanations, it may be a red flag that the customer needs to consider further or address through other contractual levers (e.g., more robust indemnification obligations or a larger liability cap).
Subprocessors and Third-Party Models. The customer should have approval rights over subprocessors, with flow-down obligations, and notification of changes. The contract should clarify responsibility when the vendor relies on upstream model providers whose terms may conflict with the customer’s requirements. Additionally, the vendor should accept responsibility for the actions and omissions of its subprocessors as it is in the best position to validate, audit and ensure the performance of its subprocessors.
Use Restrictions and Acceptable Use. The contract should prohibit high-risk or prohibited uses absent enhanced controls, require compliance with customer policies and sectoral requirements, and ban attempts to extract model weights or circumvent safeguards. Additionally, as discussed throughout this article series, customer data, prompts, inputs and outputs should be prohibited from being included in output for other customers.
Transparency Requirements. If deliverables are generated using AI, the contract should require that those deliverables be labeled as AI-enhanced or AI-created, ensuring downstream transparency.
Testing, Validation, and Sandboxing. The contract should provide for pre-production pilots with safe datasets that are applicable to relevant proofs of concept as well as development environments of the customer. The customer should have the right to run red-team tests, and the agreement should establish acceptance criteria and go/no-go gates. Importantly, the contract should guard against the vendor using pilot data for training without the customer’s consent. If a vendor is unable or unwilling to provide pilots, it may be a red flag that requires further consideration by the customer.
Open-Source and Third-Party Components. Open-source components and copyleft contamination may impact the customer’s rights in the output. The vendor should disclose all open-source and third-party components in its models and ensure licensing compliance. Security diligence of model artifacts and datasets should be required, and the contract should prohibit copyleft contamination in deliverables.
Additionally, vendors will often disclaim liability for third-party components. However, such disclaimers should be removed from the vendor agreement as the vendor has the ability and made the decision to select specific third-party components. As such, the vendor should be required to conduct sufficient due diligence to verify the trustworthiness of third-party components and be liable for their usage.
Term, Termination, and Transition. Exit rights should be triggered by safety or compliance failures, with obligations for content and model deletion, data portability, transition assistance, and an ongoing license to outputs that survive termination if the vendor agreement does not provide for the customer owning all rights, title and interest to the outputs. The vendor agreement should also provide for termination rights in the event of model drift (i.e., changes in the landscape and quality of training or tuning data impacting the functions of the AI system) so that the customer is not left saddled with an AI system whose function is no longer useful to the customer. The customer may also consider including termination rights in the event outputs of the AI system are consistently biased or inaccurate.
In addition to termination rights, the vendor agreement should include terms specifying the effects of termination requiring the vendor to return or permanently delete any customer data, prompts, inputs or outputs upon the termination or expiration of the agreement.
Insurance. The agreement should require the vendor to maintain technology errors and omissions, cyber, and media liability coverage with appropriate limits, and should designate the customer as an additional insured with evidence of coverage provided upon request.
Remedies. The remedies toolkit for AI vendor agreements should include injunctive relief, service credits, re-performance, model rollback, enhanced monitoring, termination rights, and escalation processes through governance forums.
SOW or Order Terms. Statements of work or order forms should specify how human-in-the-loop controls will operate, or confirm that human review will always remain an option. Where the customer retains final decision-making authority through a human-in-the-loop requirement, the SOW should address how that allocation of responsibility affects the vendor’s liability.
Post-Signature Implementation, Monitoring, and Governance
A well-drafted contract is necessary but not sufficient. The post-signature phase is where the contract’s protections are either operationalized or allowed to atrophy.
Vendor Management. The customer should establish a defined vendor management framework for AI vendors that includes designated relationship owners, regular business reviews, and escalation paths. AI vendors warrant closer ongoing attention than traditional SaaS providers because the technology evolves more rapidly and the risk profile can shift between reviews.
Periodic Risk Reviews. The risk assessment conducted during pre-contract diligence should be refreshed at least annually, and more frequently if the vendor introduces material model changes (whether intentionally or through model drift), the customer expands its use of the tool, or the regulatory landscape shifts.
Model Performance Monitoring. The customer should monitor model performance against the benchmarks and service level agreements established in the contract. Degradation in output quality, increases in error rates, or changes in model behavior may indicate model drift or an undisclosed model update. Monitoring should be proactive, and not reactive.
Documentation of Human Oversight. Where the contract requires human-in-the-loop controls, the customer should maintain documentation demonstrating that those controls are being followed, or confirm the vendor is implementing human-in-the-loop controls if it is required to do so under the contract. This documentation serves both as evidence of compliance and as a defense in the event of a claim arising from an AI output.
Incident Playbooks. AI-specific incident response playbooks should be developed and tested. These playbooks should address scenarios such as the discovery that the vendor trained on customer data without authorization, the generation of infringing or harmful outputs, a data breach involving the AI system, and the vendor’s failure to comply with a regulatory inquiry.
Continuous Compliance. The regulatory landscape for AI is evolving rapidly, and the customer’s compliance obligations may change during the term of the agreement. The governance framework should include mechanisms for identifying and responding to new regulatory requirements, updating the contract where necessary, and ensuring that the vendor’s practices remain aligned with the customer’s policies and applicable law.
Conclusion
Contracting with AI vendors is not a matter of appending a few AI-specific clauses to a standard SaaS agreement. It requires a comprehensive approach that begins with understanding the technology, proceeds through structured risk assessment and due diligence, and culminates in a contract that addresses the unique risks of AI engagements with precision and foresight. The post-signature governance framework ensures that the contract remains a living instrument, adapted to evolving technology, regulation, and business needs.
The organizations that approach AI vendor contracting with this level of discipline will be best positioned to capture the benefits of artificial intelligence while managing the risks that come with it.
