Contractual Language That Binds Vendors to Zero Training on Enterprise Prompt Data
Vendor commitments must cover subprocessors, survive termination, and resist policy changes.
AI without data collection or monetization requires more than a zero-training promise. Contractual language that binds vendors to zero training on enterprise prompt data must cover downstream providers, survive termination, and resist unilateral policy changes. Even then, separate retention, deletion, and tenant-isolation controls are needed to make the promise checkable.
Why standard SaaS contract language has become a training-data liability
Standard SaaS contracts inherited language from a different era. Rights to “improve the Services,” “develop new features,” or “use aggregated and de-identified data for any business purpose” once addressed product analytics and bug fixes. In an AI engagement, those grants can reach model improvement benefiting other customers. An internal pricing snippet could, in principle, appear paraphrased in a competitor’s response. The problem begins with scope and can arise even in good faith.
The same vendor logo can also conceal opposite defaults. Free or individual paid tiers often allow training unless users opt out, while enterprise terms can ban it. Personal-account use bypasses those negotiated protections entirely. Khan v. Figma Inc., filed in November 2025, alleged that enterprise customers were excluded from default AI training while individual designers and small teams were not.
What "zero training" actually covers — and the four layers it does not touch
A no-training commitment governs whether inputs are used to update model weights. During inference, weights stay frozen, so the request itself does not change how the model behaves for other users through weight updates. Training changes those weights. The distinction is foundational, but it leaves four exposure layers outside the promise.
The first layer is inference logging. Providers commonly log API requests for abuse detection, rate limiting, and reliability monitoring, with retention documented in the data processing addendum, or DPA. Compiled prompts, including proprietary retrieval-augmented generation context, can be stored on the provider’s infrastructure for weeks or longer. The second layer is prompt caching. A latency optimization may retain proprietary context externally for the cache’s time to live, or TTL, regardless of whether training is prohibited.
The third layer is subprocessor infrastructure, governed by cloud agreements the customer may never see. The fourth is jurisdictional exposure. A US-based provider’s data may be subject to US legal process regardless of server location, creating potential conflicts with GDPR data residency obligations. These are separate questions about custody and access. Storage, subprocessor, and deletion clauses must therefore address what happens during and after inference as well as whether content improves a model.
The subprocessor gap: where most zero-training policies silently fail
A vendor-only restriction stops before the full processing chain ends. Foundation model providers, embedding services, and retrieval infrastructure need to be bound by the same no-training and retention commitments. A named, auditable, kept-current subprocessor register makes that chain visible. Without it, legal teams cannot tell where the contract’s protection ends.
Customer-specific fine-tunes can also lead to disputes over what the restriction covers. A vendor may argue that a persistent model variant is not “general” training and falls outside the restriction. The clause must cover that variant explicitly. De-identification offers a less obvious way around the restriction, because there is no reliable way to remove all identifying information from free-form text. Permission to improve models using “aggregated and anonymized data” can therefore reopen the training right under a different label.
The five contractual commitments that must be in the order form, not the FAQ
The lesson for procurement is to secure five commitments in the order form, with precedence over conflicting referenced terms. Placement is part of the protection. A marketing page or FAQ can describe intent, but it is not a durable substitute for negotiated language. A sales representative’s promise also cannot override written rights to use the data.
First, the agreement must prohibit using prompts, uploaded files, or outputs to train, fine-tune, or reinforce first-party or third-party models. Second, it must expressly prohibit customer-data fine-tuning, including customer-specific variants that persist beyond the session. Third, those duties must bind named subprocessors through an auditable register. Fourth, tenant isolation must prohibit cross-customer retrieval, shared embedding pools, and index commingling as a deployment property that persists across runtime resets. Fifth, the customer must be able to get the data flow diagram and subprocessor register before signing.
The governing restriction should say, “Vendor's modification of its privacy policy, terms of service, or data processing addendum shall not alter this restriction without Customer's written consent”. That sentence closes a structural loophole. Without it, changes to the documents a carefully negotiated promise refers to may weaken that promise.
The training data carve-out clause: what the model language must say and why each phrase carries weight
“Vendor shall not use Customer Data, including any inputs, outputs, prompts, fine-tuning data, or derived data, to train, fine-tune, retrain, or otherwise modify any model, algorithm, or system, whether owned by Vendor, its affiliates, or any third party. This restriction applies in perpetuity and survives termination of this Agreement. Vendor's modification of its privacy policy, terms of service, or data processing addendum shall not alter this restriction without Customer's written consent.”
“Inputs, outputs, prompts, fine-tuning data, or derived data” prevents an argument that outputs or embeddings fall outside Customer Data. Definitions determine the reach of the prohibition. “Train, fine-tune, retrain, or otherwise modify” broadens the restricted activity beyond initial training. Stronger drafting also names reinforcement learning, retrieval augmentation, evaluation, and other training-adjacent purposes, including activities that leave weights unchanged. “Vendor, its affiliates, or any third party” extends the restriction beyond the contracting entity.
“In perpetuity and survives termination” prevents the restriction from expiring with the service relationship. Otherwise, retained data could become available for training afterward. In negotiation, reject “Vendor may use de-identified or aggregated data for service improvement” where it reopens content use. Any product-improvement telemetry permission should be separately opt-in, exclude content, and cover only non-content metadata.
Holon Law Partners identifies ambiguous data rights as a way vendors can derive lasting value from customer inputs. Its recommended limitations include “no training,” “no commingling,” and “no retention,” especially for confidential, regulated, or high-risk data sets. Those are distinct restrictions. A training carve-out should not be treated as shorthand for all three.
Four additional clauses that make the training ban enforceable in practice
Model change notification should require substantial written notice before material changes, including version upgrades, training-data changes, fine-tuning changes, and deprecations. The customer should retain the right to continue on the prior version for an extended period or terminate without penalty. In negotiation, the continuation right is more important than merely extending the notice window.
Audit rights should require, upon reasonable written notice, the latest SOC 2 Type II report or ISO 27001 certification, executive attestation of compliance with training and data-use terms, and reasonable cooperation with customer or third-party algorithmic audits. Those audit rights must also cover the named subprocessor register. A generic assurance is not equivalent to evidence. SOC 2 concerns vendor controls and does not replace the customer’s access controls, data classification, or vendor management.
IP indemnification should cover third-party claims that authorized output use infringes copyright, trademark, trade secret, or other IP, including claims arising from underlying training data. The general liability cap should not apply to this duty. Otherwise, the cap can sharply limit the remedy. OpenAI, Anthropic, Microsoft, and Google offer forms of enterprise IP indemnification, but their breadth, conditions, and exclusions vary.
The DPA should set maximum retention for inference logs, prompt caches, and abuse-monitoring windows, with deletion rather than merely stopped collection upon termination. Those duties must flow to subprocessors. For data adjacent to protected health information routed through an AI API, a signed BAA specific to the AI use case is required, rather than reliance on a generic cloud infrastructure BAA.
How regulators and courts are now pricing the cost of getting this wrong
The FTC warned in February 2024 that unilateral privacy revisions enabling AI training could be unfair or deceptive under the FTC Act. The Irish DPC’s €91M fine against Meta in 2024 concerned plaintext password storage and GDPR security and breach-notification failures. Enforcement already attaches substantial consequences to deficient data handling, while the FTC warning addresses the policy-change mechanism directly.
Connecticut’s privacy law requires covered notices, effective July 1, 2026, to disclose whether businesses collect, use, or sell personal data to train large language models. Disclosure is an affirmative duty. EU AI Act Article 53(1)(d) requires general-purpose AI model providers to publish a summary of their training content with enough detail, using the Commission template published July 24, 2025. The obligation applied from August 2, 2025, with Commission enforcement from August 2, 2026. It binds model providers exclusively, although their API customers need to understand vendor compliance.
The Figma complaint, Case No. 3:25-cv-10054 in the Northern District of California, includes breach-of-contract and trade-secret theories. It alleges that proprietary designs supplied for collaboration were used to extract competitive value through AI improvement. These remain allegations. Their significance is that copyright is not the only route to a claim. Proposed remedies involving deletion of customer-derived training data could, if granted, require costly model rollback or retraining.
Enterprise customers also need to consider purpose-limitation. Putting operational inputs into a training corpus is a secondary use, so GDPR requires a compatible-purpose assessment that is based on the facts of the case and put in writing. California privacy law sets similar duties through a different set of rules. Several supervisory authorities have indicated that AI training is not automatically compatible with the original collection purpose.
Why contractual language alone cannot close the gap — and what architecture-level assurances must accompany it
A contractual prohibition does not physically prevent commingling. A misconfigured retrieval index or shared embedding pool can expose data across tenants without updating any model weights. The training clause and the infrastructure would then be answering different questions. The same distinction applies to logging, caching, and incident-response access. These behaviors need their own controls.
Architecture-level assurance begins with evidence tied to the actual service. The SOC 2 Type II report should cover relevant training and inference data-handling controls as well as generic cloud infrastructure. A pre-signature data flow diagram should trace inference, caching, logging, and subprocessor handoffs. Written confirmation of tenant-isolation should name the technical mechanism and state that it is a property of the deployment. Each named subprocessor should be contractually bound to the no-training and retention duties.
AI addendums and standardized audit provisions are starting to close the distance between what vendors promise and what they put in place. They do not eliminate that distance by themselves. Privacy built into the architecture makes the contractual restriction structurally verifiable because the controls exist independently of a policy statement.
A negotiation checklist for legal and procurement teams going into an AI vendor review
Before signing. Read the DPA word-for-word, including its training defaults. Confirm that the order form contains the restriction and takes precedence over conflicting terms. Request the data flow diagram and named subprocessor register before signature. If the vendor cannot identify the processing chain, treat its downstream training commitment as unverifiable.
Clause language. Require definitions that cover all the data, terms that cover first-party and third-party use and stay in force after termination, and protection against unilateral amendment. Spell out how the terms cover training-adjacent uses and reject exceptions for de-identified content. Get rights to model-change notice and continuation, access for audits, output IP indemnification outside the general liability cap, and limits on how long data is kept before deletion. Do not let “zero training” substitute for those separate duties.
Establish whether caching is opt-in or opt-out, its TTL, and inference-log retention and access. Ask for evidence that covers the controls for training and inference. Confirm that the contractual restrictions reach every named subprocessor.
Ongoing governance. Plan to review the DPA each year as duties change, including the Connecticut disclosure requirement and EU AI Act enforcement dates. Require notification of material subprocessor changes. A register is useful only when changes reach the customer.
