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, and Part 3.
With the risk landscape mapped and due diligence complete, the customer can turn to the contract itself.
AI engagements introduce concepts that standard technology contracts were not built to address. This article presents a structured approach to drafting agreements with AI vendors, focusing on the core clauses that distinguish AI vendor contracts from traditional SaaS agreements. Similarly to how a few years ago data processing terms became commonly associated with vendor agreements for software tools that process personal information, there is a rising trend of including AI-related terms with vendor agreements for AI tools. These provisions supplement, but do not replace, the standard vendor terms that customers already know well.
Scope and Definitions
Precision in definitions is the foundation of an effective AI vendor agreement as it ensures the parties are clear on what the engagement entails. Ambiguity in defined terms cascades through every operative provision and can impact the meaning of provisions in ways not intended by either party.
The contract should clearly define:
- “AI Services” or “AI Technologies” to delineate the scope of the AI-specific terms.
- “Model” to capture the specific machine learning or language model being provided, including any versioning or update mechanisms, and whether the model is limited to the customer’s enterprise or shared among multiple customers.
- “Inputs” to encompass the data, prompts, and instructions that the customer provides to the AI system.
- “Outputs” to cover everything the system generates in response.
- “Customer Data” to broadly capture all data the customer provides or that is derived from the customer’s use of the services.
- “Tuning Data” or “Training Data” to distinguish between data used to train the underlying model and data used to fine-tune or customize the model for the customer’s specific needs.
“Fine-Tuned Models” require particular attention. If the customer’s data is used to customize a model, the contract must address who owns the resulting model, who can use it, and what happens to it at termination.
“Usage Data” (i.e., metadata about how the customer interacts with the AI system) is a category that vendors often claim the right to use freely, and the contract should constrain that right.
From a scope perspective, the contract should delineate production use versus pilot use, with different terms and risk allocations for each phase. Additionally, a provision prohibiting shadow data ingestion (defined as the use of data sources not authorized in the agreement) protects the customer against scope creep and unintended data exposure.
Data Use and Training Rights
Data use and training rights are the single most consequential category of terms in an AI vendor agreement.
The contract should restrict the vendor’s use of customer data, prompts, inputs, and outputs for training or improving models unless the customer has expressly permitted such use. The default should be no training on customer data, prompts, inputs, and outputs. Where training or fine-tuning is authorized, the contract should require opt-in consent, mandate robust segregation of the customer’s data, prompts, inputs, and outputs from other customers’ data, specify de-identification standards, and ban re-identification.
Additionally, the contract should require the vendor to disclose whether its AI system constitutes a “high-risk” system under applicable law, and to update the customer if that classification changes, whether because of changes to the AI system itself or changes in the regulatory landscape. The customer should also retain the right to terminate if a system that was not previously classified as high-risk becomes so.
Ownership and Licenses
There is no set requirement that automatically determines whether the customer or the vendor owns inputs and outputs, and often ownership rights will depend on the nature of the AI tool and the needs of the parties. The ownership and licensing terms of the vendor agreement can clarify the ownership rights as between the parties.
Typically, ownership provisions should confirm the customer’s ownership of inputs (as inputs often contain customer data) and, where appropriate, outputs. The contract, at the least, should grant the customer a broad license to use outputs for any lawful business purpose without restriction.
Derivative works, fine-tuned model IP, and pre-existing IP require careful treatment. If the customer’s data is used to create a fine-tuned model, the contract should address whether the customer owns the fine-tuned model, has a license to it, or simply has the right to use it during the term. Pre-existing IP belonging to either party should be carved out and preserved.
Confidentiality and Trade Secrets
Standard confidentiality provisions should be enhanced for AI engagements. The general guidance in the AI space is that customers should avoid inputting confidential information if the AI model trains from customer data as that confidential information may be disclosed to other users as part of output generated for such third-party users.
Even if customer data is not used for training the AI model, or the AI model is limited to the Client’s systems only, customer data and model interaction metadata should be elevated to confidential information with heightened protections. It is generally understood that customer data may contain sensitive, confidential, or proprietary information and needs to be protected, whether such customer data is included in prompts, inputs, or generated outputs. Model interaction metadata should also be treated as confidential because it may reveal behavioral patterns, strategic intent, and sensitive context. Even without exposing the actual prompt content, details like interaction times, query frequency, session lengths, and user locations map out operational workflows, proprietary research timelines, and vulnerabilities. Accordingly, the contract should prohibit the vendor from disclosing customer data, and model interaction metadata as confidential information through model outputs or to third-parties who do not need to know such confidential information.
Where the customer’s data includes trade secrets, the contract should require the vendor to implement appropriate secrecy measures sufficient to preserve trade secret status under applicable law. That being said, it is generally recommended that trade secrets not be input into AI models, as it may impact trade secret protection.
Privacy Compliance
Where the AI engagement involves personal data, the contract should allocate roles and responsibilities between the parties. Controller and processor designations, where applicable under the relevant privacy framework, should be clearly established.
The agreement should incorporate data processing terms, cross-border transfer mechanisms, sensitive data restrictions, and provisions for maintaining records of processing activities. These provisions should be tailored to the specific privacy regimes that apply, rather than relying on generic templates.
Additionally, many data privacy laws provide data subjects with rights such as: right to data portability, right to restrict processing for certain purposes or right to deletion. The vendor agreement should clearly set out how data subject rights may be exercised. Specifically, as discussed in previous articles in this series, with AI tools, there is a risk that customer data may be combined or stored in ways where identification or deletion may not be possible, resulting in unauthorized retention. The vendor agreement should address how exercising a data subject’s right to deletion will ensure that all such personal data pertaining to a data subject will be deleted.
Security and AI-Specific Safeguards
Security provisions should require adherence to the safeguards reviewed and approved during the due diligence process or substantially similar safeguards, and recognized security frameworks, including specific commitments regarding encryption, least-privilege access, and secure model operations. These are the cybersecurity provisions organizations should be accustomed to including in vendor agreements, extended to cover AI-specific infrastructure.
AI-specific safeguards should include commitments against training on customer data and protections against model inversion, data extraction, and adversarial attacks. Access to customer inputs and outputs should be restricted on a need-to-know basis, with logging and monitoring sufficient to detect unauthorized access.
Even still, AI-specific safeguards may fail and result in a data breach. Accordingly, vendor agreements for AI tools should expressly set out obligations of the parties (e.g., provision of notice and identity and credit monitoring services to impacted individuals) and the party responsible for the associated costs. The customer may also consider including termination rights in the event of a data breach, allowing the customer to exit an agreement for a tool that has proved itself to be untrustworthy.
Safety, Quality, and Performance
The contract should include vendor commitments regarding accuracy bounds, documented limitations, content safety filters, bias testing, explainability artifacts, and change management practices. Often, due to the autonomous nature and opacity of data processing by an AI model, it may not be possible to verify explainability, bias, or accuracy of outputs. The customer may have to rely on certain representations and warranties (discussed in our next article) to secure the assurance needed to comfortably use the AI tool. These commitments should be measurable and tied to specific standards or benchmarks wherever possible.
Whenever possible, the contract should include human-in-the-loop requirements that mandate human review of AI outputs, and training or tuning data before they are used to make consequential decisions.
Service Levels and Support
Service level agreements (“SLAs”) should address uptime, latency, error rates, rate limits, incident response times, and model version support lifecycles. These metrics may differ from traditional SaaS SLAs because AI systems have different failure modes. As discussed in previous articles, with AI systems model drift (i.e., changes in the landscape and quality of training or tuning data impacting the functions of the AI system) is a significant concern. Accordingly, a model that is “available” but producing degraded or materially different outputs is functionally impaired even if it meets a conventional uptime SLA.
Credit regimes should provide meaningful financial remedies for SLA breaches, and step-in rights should be available for chronic failure, allowing the customer to take specified actions to mitigate the impact of sustained vendor underperformance.
From Core Clauses to the Full Agreement
These core AI clauses form the skeleton of the vendor agreement, but they do not stand alone. The next article in this series addresses the traditional boilerplate provisions that require updating for AI engagements, and the post-signature governance framework that ensures the contract is operationalized effectively.
