SaaS contracting long followed a predictable model. Vendors supplied infrastructure, storage, processing capacity, and uptime commitments, while customers brought their data. Software behaved the same way every time, outputs were generally deterministic, and risk allocation was reasonably straightforward. You could explain, audit, and draft contracts around the workflow.
But that deterministic world is gone. In a recent Axiom CLE on negotiating generative AI agreements, I argued that many contracts signed three or four years ago are already structurally obsolete, because the foundational relationship between enterprise customers and their software vendors has changed. These systems don’t simply process data. Instead they learn from it, infer from it, and generate new outputs based on probabilistic prediction.
Having negotiated technology and security agreements from both the vendor side and the customer side, I put the central question this way: How do lawyers contract for systems that are constantly learning, constantly evolving, and producing outputs neither party can fully predict?
My answer, increasingly, is a standalone AI addendum.
What is an AI addendum?
An AI addendum is a dedicated contract schedule that governs how a vendor's artificial intelligence systems may use customer data, who owns what those systems produce, and what governance and audit obligations the vendor accepts. It sits alongside the master services agreement rather than being scattered through it.
I expect AI addendums to become as routine as data processing addendums are today. DPAs felt novel once. Now they’re standard, and AI schedules are on the same trajectory. The reason is straightforward. Traditional MSAs were never drafted for model training, prompt retention, autonomous outputs, explainability obligations, or synthetic content liability. Forcing those issues into legacy boilerplate produces bad contracts.
The precision problem starts with vocabulary. I warned against treating AI as a catch-all and distinguished three categories that carry different risk profiles. Traditional machine learning is predictive, identifying patterns in historical data sets for uses like fraud detection, cybersecurity anomaly detection, credit scoring, and predictive maintenance. Generative AI creates original content, which raises fresh questions about ownership, accuracy, and liability. Multimodal large models process text, audio, video, images, behavioral signals, and sensor data at once, and they are where the analysis gets hardest.
That distinction matters at the drafting table. Large language models do not retrieve answers the way a database does. They predict them. So a clause reading “vendor may use AI to improve services” is, in Miner's words, dangerously overbroad. Inside that single word “improve,” a vendor may find authority for model training, fine-tuning, retention, derivative model development, and product expansion built on your client's operational expertise.
When do you need an AI addendum?
The short answer is any time a vendor's product includes AI features that touch customer content, and particularly when the customer operates under sector-specific or privacy regulation.
Three triggers came up repeatedly during the CLE. The first is data sensitivity. If employees are uploading proprietary source code, litigation strategy, pricing models, customer information, or health care records, the contract needs to distinguish between a vendor processing that data and a vendor learning from it. Those are different activities, and I noted that many agreements still fail to separate them.
The second trigger is regulatory exposure. California's AI transparency requirements under AB 2013, the EU AI Act, state privacy laws, sector-specific regimes, and emerging FTC enforcement are all converging on transparency. Organizations increasingly need to answer what data was used, how it was used, whether it was retained, whether it was used for training, whether it was shared, whether it can be deleted, and whether any of that can be audited. Whatever applicable law governs the relationship, those answers should live in the contract.
The third trigger is permanence. Historically, processing was temporary, but AI ingestion may be functionally permanent. Once customer data influences model weights, that information can become embedded in a model architecture in ways that are difficult to unwind. As I put it, protection against disclosure is now only the starting point. Clients also need protection against transformation, derivative learning, and silent model ingestion.
Key AI addendum clauses to negotiate with vendors
No-Training Covenant
For many customers, a no-training covenant is the single most significant non-negotiable term, and the language should be broad rather than aspirational. I offered a version along these lines: “Vendor shall not use customer data, including prompts, inputs, outputs, derivative outputs, metadata, or behavioral interactions to train, fine-tune, optimize, improve, or otherwise modify any model made available to third parties.” Narrow drafting invites trouble. A vendor may agree not to train while quietly reserving rights to optimization, safety calibration, or quality assurance. Prohibiting use of any input or output to train closes that gap.
Clear Data Categorization
Clear data categorization is significant, too. Definitions do the heavy lifting later. The addendum should separately define customer data, output data, training data, telemetry data, derived data, model artifacts, embeddings, and vector databases. I recommend a bifurcated approach that has proven more productive than absolutist demands: strict no-training restrictions and strong deletion rights for customer content covering both input and output; broader vendor rights for usage telemetry such as latency, system performance metrics, and token consumption; and carefully bounded rights for derived intelligence.
Place Limits on De-identified Data
Place limits on de-identified data. Vendors often ask for broad rights to use de-identified customer data. That sounded like a complete answer a few years ago. Model inversion has made the assumption fragile, since modern systems can infer identity from unique operational patterns or technical architectures even after traditional identifiers are stripped. Ask what is removed, what is retained, whether embeddings persist, whether prompt histories are stored, whether outputs are logged, and whether the information can be reconstructed. Then add contractual prohibitions on re-identification attempts, technical safeguards, deletion rights, and representations about how derived data will be handled going forward.
Request Output Ownership
Request output ownership. Copyright protection generally requires meaningful human authorship, a principle the Supreme Court left undisturbed when it denied certiorari in Thaler v. Perlmutter on March 2, 2026. Work made for hire and default copyright ownership both assume identifiable human authorship, so neither travels well here. An algorithm is not an employee, or a contractor, and cannot assign rights. The workaround is to express assignment language: “To the extent any intellectual property rights arise in outputs generated through the services, vendor irrevocably assigns all right, title, and interest in such outputs to the customer, and to the extent such rights cannot presently be assigned, vendor agrees to assign any future recognized rights.” Global organizations should also consider waivers of residual moral rights, database rights, and analogous international claims.
Input Protection
Input protection is essential. Prompts increasingly contain proprietary workflows, source code, litigation strategy, pricing methodology, and institutional knowledge. The prompt itself may be the trade secret. I recommend affirmative non-waiver language stating that submission of customer data, prompts, legal strategy, privileged communications, or proprietary materials to the services does not constitute waiver of trade secret protections, attorney-client privilege, work product protections, or confidentiality rights.
AI-specific Indemnity and Liability
Address AI-specific indemnity and liability. Legacy IP indemnities were built for software products rather than probabilistic content generators, and they typically cover claims that the software infringes third-party rights while saying nothing about the generative output. Customers increasingly want output indemnity. Vendors typically condition it on responsible use, meaning approved settings, adherence to vendor documentation, no disabling of safeguards, and maintained human review protocols. I called this the seatbelt clause. I.e., the vendor will help if there is an accident, provided you were driving responsibly. Watch the caps closely, because AI-specific indemnity capped at one or two times annual contract value may not cover a serious copyright dispute, regulatory investigation, or class action.
Governance Warranties and Audit Rights
Don’t forget governance warranties and audit rights. A SOC 2 report tells you controls existed during an audit window. It says little about whether an AI model is behaving safely or consistently with contractual commitments. I pointed to ISO/IEC 42001, which establishes an AI management system covering formal governance, ongoing risk assessments, training data traceability, and continuous monitoring. Customers can require certification or demonstrated equivalent maturity. Vendors sometimes benefit from certification too, since it provides an objective standard that limits sprawling customer audit demands.
Algorithmic Disgorgement
Plan for algorithmic disgorgement before termination is on the table. Deleting raw data when a contract ends is the easy part. The harder question is what happens to embeddings, vectors, fine-tuned adaptations, and derived intelligence. I call this the brain drain problem, and the fix is explicit language requiring that customer-specific embeddings, retrieval databases, and fine-tuned adaptations be deleted, returned, or permanently isolated when the relationship ends.
Prompt Injection Security
Finally, build in mutual obligations around prompt injection security. Vendors commit to adversarial testing, red teaming, and prompt injection testing. Customers commit not to intentionally jailbreak the system. The result is a comparative fault framework, which courts and insurers tend to prefer over blanket liability shifts.
Legal teams can build AI agreements that protect the business as technology evolves.
How an AI addendum works with an MSA, DPA, and security addendum
An AI addendum layers on top of the agreements already in place and closes gaps the others were never designed to address.
The MSA remains the commercial backbone, carrying the term, fees, service levels, warranty disclaimers and limitations, and limitations of liability. The AI addendum forms part of that agreement by reference, which means capitalized terms should carry their MSA meanings unless the addendum defines them differently, and the parties should agree on an order of precedence so AI-specific terms control where the documents conflict.
The DPA governs personal data and the data processing relationship between controller and processor, including transfer mechanisms and data protection obligations under applicable law. It answers questions about lawful basis and processor duties. It does not answer whether a vendor may use prompts to fine-tune a foundation model, nor does it address ownership of generative output.
The security addendum governs controls, encryption, access management, and breach notification. I noted that customers increasingly want notification obligations tied specifically to model inversion attacks, prompt injection attacks, and training data exposure events, often on faster timelines than a traditional breach clause provides.
Without a dedicated schedule, organizations end up relying on fragmented language spread across MSAs, privacy schedules, security exhibits, product terms, and vendor documentation. I was blunt about how fragmentation creates litigation nightmares later. Bringing the terms into one place creates operational clarity.
AI addendum checklist for in-house legal teams
I walked through ten elements an effective AI addendum should include:
- Clear data categorization defining customer data, output data, training data, telemetry data, derived data, model artifacts, embeddings, and vector databases
- A no-training covenant, stated explicitly
- A governance warranty confirming appropriate controls, including ISO 42001 certification where applicable
- Output assignment language for generated content
- Similarity documentation, including prompt logs, output logs, timestamps, and audit trails
- Human-in-the-loop requirements, particularly for health care, employment decisions, financial services, security operations, and legal workflows
- Explainability rights, which matter for regulators and in litigation
- Algorithmic disgorgement covering embeddings, fine-tuned layers, retrieval databases, and derivative artifacts
- AI-specific indemnity for AI-generated harms
- Prompt injection security, with vendor testing obligations and customer responsible-use obligations
I also pressed the point that operational specificity beats comforting generalities. “Industry standard security” and “commercially reasonable efforts” become painfully vague in litigation. Concrete commitments hold up better, like prompt filtering designed to reduce sensitive data leakage, accuracy credits when defective outputs require extensive human correction, documented adversarial testing, and an incident response plan that names who investigates, who preserves logs, and who communicates with regulators.
One closing point from the CLE deserves emphasis. Under ABA Model Rule 1.1 and Comment 8, lawyers must maintain competence in technologies affecting client representation. Approving a platform without understanding how it trains models, stores prompts, retains outputs, handles privilege, and manages deletion means making legal decisions in the dark. Judges have shown little patience for lawyers who relied on AI-generated authorities that didn’t exist, and they don’t distinguish between a hallucination from an associate and one from an algorithm. Your signature is still on the filing.
Frequently asked questions
What is an AI addendum?
An AI addendum is a contract schedule that governs a vendor's use of AI in connection with customer data. It covers training restrictions, ownership of outputs, governance and audit obligations, deletion at termination, and AI-specific indemnity. It supplements the MSA, DPA, and security addendum rather than replacing them.
What clauses should an AI addendum include?
At minimum, an AI addendum should include data categorization definitions, a no-training covenant, a governance warranty, output assignment, logging and audit trail requirements, human-in-the-loop obligations, explainability rights, algorithmic disgorgement, AI-specific indemnity, and prompt injection security commitments.
Do I need an AI addendum for every AI vendor?
No. The analysis is risk-based. A vendor using narrow machine learning on non-sensitive telemetry presents a different profile than a generative platform ingesting privileged material. Prioritize vendors whose systems touch sensitive content, operate in regulated sectors, or reserve broad rights to improve their products.
What is the difference between an AI addendum and a data processing addendum?
A DPA governs personal data and allocates controller and processor responsibilities under privacy law. An AI addendum governs model behavior, including whether customer content may train or fine-tune a model, who owns generated outputs, and what happens to embeddings and derived data at termination. Most AI risk sits outside the DPA's scope.
Can an AI vendor train its model on customer data?
Only if the contract permits it. Broad language authorizing a vendor to use customer data to improve services may be read to allow training, fine-tuning, and derivative model development. Customers who want to prevent this need an express covenant barring use of any input or output to train, optimize, or otherwise modify models made available to third parties.
Are prompts considered confidential information?
Not automatically. Prompts often contain trade secrets, source code, litigation strategy, or pricing methodology, so the agreement should define them as confidential customer content and include language confirming that submitting them does not waive privilege, work product protection, or trade secret status.
Who owns AI-generated outputs under an AI vendor agreement?
Ownership depends on the contract, because copyright law generally requires meaningful human authorship and fully autonomous outputs may not qualify for protection. The practical approach is an express assignment from vendor to customer of any rights that do arise, plus an agreement to assign rights recognized in the future. Owning an output also does not guarantee exclusivity, since probabilistic systems can produce similar results for other customers.