Every meaningful AI vendor contract has a data-rights section that determines whether your prompts, your fine-tuning data, your retrieval corpora and the model outputs they produce can be used to improve the vendor's product, distributed to other customers, or sold. Most buyers sign these clauses without reading them. We have audited more than 200 AI agreements in the past 18 months and the patterns are consistent: vendors keep more rights than enterprise customers realise, the carve-outs are narrow, and the consequences compound at renewal.
When we sit down with a draft AI agreement, the first exercise is sorting every data clause into one of four buckets: customer inputs (prompts, queries, uploaded documents), customer training data (fine-tuning sets, retrieval indexes, embeddings), model outputs (completions, embeddings, generated artifacts), and telemetry (usage logs, latency metrics, prompt patterns, feature flags). Vendors routinely write contracts that treat these as a single undifferentiated bucket of "Customer Data" or "Service Data" - which lets them quietly assign different rights to different categories in the operative clauses. The redline starts with definitions.
In our experience across 340+ engagements, the single highest-leverage edit in an AI contract is forcing the vendor to define each of the four categories separately and grant rights against each one explicitly. Once the categories are separated, the asymmetries become visible. From there the redline is a software contract negotiation problem rather than a legal-review one.
The vendor's default position is almost always "we do not train on your inputs by default for enterprise tier, but we may retain inputs for X days for abuse monitoring and service improvement." Three things to push on. First, the abuse-monitoring window: 30 days is industry standard; some vendors quote 90 or even unlimited; push to 30 with deletion confirmation. Second, "service improvement" is a wide door - we have seen it interpreted to include human review for safety tuning, which is functionally training. Demand a definition that excludes any process that updates model weights, embeddings, retrieval indexes or fine-tunes. Third, get the opt-out for training applied at the tenant level by default - not by API parameter, not by user setting, not via a separately signed addendum.
When you fine-tune a model on your data or build a retrieval index over your corpus, the question is not just "who owns the data?" - it is "who owns the derived weights, the embeddings, and the indices, and what happens to them when the contract ends?" Standard vendor language preserves the customer's ownership of the raw data but is silent or vendor-favourable on the derivatives. Three redlines: explicit customer ownership of fine-tuned model weights and embeddings derived from customer data; explicit deletion of those derivatives on termination, with a certificate of destruction; and a prohibition on using the derivatives to inform any other customer's model, including in aggregated or anonymised form.
Our redline turnaround on AI agreements is typically 48-72 hours for a master and a single SOW.
Output ownership is the clause buyers most often think they understand and most often get wrong. The standard language - "Customer owns outputs subject to OpenAI's/Anthropic's/vendor's rights" - is structurally a shared-rights regime, not a customer-ownership regime. The vendor reserves the right to use outputs for service operation, abuse monitoring and (variably) service improvement. More importantly, output ownership in AI is non-exclusive by default because the same prompt may produce the same output for another customer - so "ownership" cannot mean exclusive ownership. Three redlines: explicit customer ownership of outputs subject only to the vendor's right to operate the service (not "improve" it); an indemnity for third-party IP claims arising from outputs (more on this below); and a representation that outputs will not be used to train future versions of the model unless the customer opts in.
Telemetry is the category buyers most often ignore. It is also the category where the vendor's economic interest is largest. Telemetry data - which prompts get sent, which features are used, which outputs get accepted or rejected, latency, token counts, error patterns - is what the vendor uses to improve its product, benchmark against competitors, build new features and sell renewal expansions. Standard contracts give the vendor unrestricted rights to "aggregated and de-identified" telemetry. The redline is to define telemetry narrowly (exclude prompt contents, exclude output contents), require aggregation thresholds (no telemetry on cohorts smaller than 100 customers), and prohibit external sale or licensing of any telemetry-derived dataset.
In 2023 and 2024, the major foundation-model vendors introduced output IP indemnities - protection for customers if a generated output is found to infringe a third party's copyright. By 2026, indemnities are standard for the top three vendors but the conditions remain narrow. The two most common carve-outs that gut the protection in practice: indemnity applies only when the customer uses content filters that are on by default (so a customer who turns off filters for legitimate reasons loses cover); and indemnity excludes outputs that are substantially similar to inputs the customer provided (which means RAG-based applications often fall outside protection). Redline both carve-outs aggressively. Where the vendor will not move, document the residual risk and price it.
Indemnity caps in AI contracts are typically 12 months of fees - in line with general SaaS norms. For high-volume enterprise deployments, push for an uncapped indemnity on IP claims, or at minimum a multiple of fees (2-3x is achievable). The vendor's actual exposure on output IP is low because most enterprise outputs are short-lived and never published; the cap negotiation is often easier than buyers expect.
Twenty-three clauses we redline on every AI deal, with the exact replacement language.
AI contract data residency is more complex than traditional SaaS. The "data" can sit in three places at once: the input data sits in the inference region, the model weights sit wherever the vendor hosts them (often US even for EU customers), and the telemetry sits in the vendor's central analytics infrastructure. EU customers operating under GDPR cannot rely on a generic "EU residency" clause - they need explicit commitments on inference region, model-hosting region, and telemetry-processing region, plus a Standard Contractual Clauses package that covers transfers to the US for telemetry. Microsoft and Google have made the most progress on EU-only inference for their primary models; OpenAI added EU residency in 2024 but it is not the default; Anthropic's enterprise tier offers EU residency under specific commercial terms.
Where regulatory or sensitivity constraints require it, the answer is a private deployment - the model weights running in the customer's cloud account, or in a sovereign cloud, with no data leaving the perimeter. Microsoft offers this via Azure OpenAI dedicated capacity; AWS via Bedrock with PrivateLink; Google via Vertex AI; Anthropic via dedicated capacity on AWS and GCP. The economics shift significantly - dedicated capacity is typically 2-4x the cost of shared inference for equivalent throughput - but for regulated industries the trade is usually defensible.
The contract is the operational backbone. The redline is the lever.
AI vendor contracts are renewed annually. The data-rights terms that were carefully redlined at initial signature are quietly amended at renewal through three mechanisms: updated DPAs, updated terms of service incorporated by reference, and new features that ship under default-permissive terms. Buyers who do not re-baseline the data-rights position at every renewal typically find that their hard-won protections have been narrowed over 24-36 months. Two operational habits: maintain a redline summary as a living document and diff it against the vendor's standard at every renewal; and require any change to data-rights terms to be a separate signed amendment, not an incorporated-by-reference update.
For the broader contract-level redlines, see our contract red flags guide and the AI vendor contracts pillar.
For any AI deal above $250k annual contract value, an independent review of the data-rights section pays for itself in the first round of redlines.
Enterprise tier is a meaningful improvement over consumer or developer tiers, but it is not a complete answer. Most enterprise tiers default to no training on inputs, 30-day retention windows and an output indemnity - but the carve-outs and telemetry rights still require redlines. Enterprise tier is the floor, not the ceiling.
As long as you would retain the equivalent human-generated artifact, governed by your existing retention schedule. The fact that an output came from an AI does not change its underlying retention obligation. Many enterprises have over-retained outputs by treating them as a new data class.
No. Output review is a function of the risk profile of the use case, not of the technology. The contract should govern the data flow; the policy should govern the use case.
A clean, narrow definition of "Service Improvement" that excludes any process that updates model weights, embeddings or retrieval indexes from the rights the vendor reserves. That one definition decides whether your business becomes training data.
Our AI & SaaS procurement team redlines AI agreements against the patterns we have seen across 200+ deals.
Weekly compliance intelligence for IT leaders.