Every software vendor now ships model-assisted features, and every one of them needs data. Some train on public corpora only. Some use customer data with consent. Some use it by default and describe it as service improvement in a policy incorporated by reference into the agreement nobody reads to the end.
The commercial and legal consequences are not abstract. Customer content fed into a training pipeline may include confidential information belonging to your own customers, personal data subject to processing restrictions, or trade secrets whose protection depends on their not being disclosed. Once a model has been trained, unwinding that is not practically possible, which makes this one of the few contract terms where a remedy after the fact is close to worthless.
This guide covers what an AI training data rights clause should address, the four data categories that need separate treatment, the drafting patterns that quietly reopen a negotiated restriction, and how to find the exposure across a vendor portfolio that was mostly signed before anyone was asking the question. The question is not whether to use vendor AI features, which is largely settled, but on what terms your data participates in them.
The four data categories to address separately
Treating customer data as a single undifferentiated category is what lets broad rights slip through. A clause that prohibits training on customer content may still permit everything that matters to the vendor.
- Inputs, the content you submit, including documents, prompts, records and files, which is the category buyers usually think of and the one most often protected.
- Outputs, what the system generates in response, which vendors frequently treat differently from inputs and may claim broader rights over.
- Derived and aggregated data, statistics, embeddings, patterns and de-identified extracts drawn from your data, where the vendor position is usually that these are no longer your data at all.
- Usage telemetry and feedback, interaction logs, corrections, thumbs-up signals and error reports, which are extremely valuable for model improvement and almost never restricted.
- Personnel and third-party content, data you submit that belongs to your own customers or employees, where your right to grant a training licence may be limited by your own agreements.
A clause covering only the first category leaves three open. Vendors are not usually being devious about this; the categories genuinely behave differently and standard templates evolved before the distinctions mattered. The buyer’s job is to make the clause address each one explicitly rather than assuming that a general prohibition sweeps them all in. Vendors generally negotiate these categories individually, so a buyer who raises all four gets a more useful answer than one who asks whether customer data is used for training.
The most common way a negotiated data protection is undone is not a clause in the agreement, it is a sentence incorporating the vendor’s current acceptable use or data processing policy as amended from time to time. That gives the vendor a unilateral right to change what it may do with your data by updating a web page. Requiring notice, or fixing the policy as at the effective date, costs nothing and preserves the protection you negotiated.
Drafting patterns worth pushing back on
These appear regularly in vendor paper and are usually negotiable, particularly at renewal or at any point where the buyer is expanding its commitment.
- Service improvement as an undefined purpose. A permission to use data to improve the services covers model training without saying so, and is broad enough to cover almost anything.
- De-identification without a standard. Rights over de-identified data are reasonable if de-identification is defined and tested. Without a standard, the term is an unbounded carve-out.
- Opt-out by configuration. A contractual right that depends on a product setting can be reset by a migration or a default change. Contractual restrictions should not rely on a toggle.
- Silence on subprocessors. A prohibition that binds the vendor but not the model providers it uses leaves the substantive exposure unchanged.
- No deletion commitment. Termination clauses routinely require deletion of customer data and say nothing about data already absorbed into training sets or derived artifacts.
Five steps to get control of the exposure
Step 1, Identify which vendors process meaningful data
Filter the vendor estate to those handling confidential content, personal data or material belonging to your own customers. This is a far smaller set than the full application inventory, and concentrating effort there is what makes the exercise finishable rather than perpetual.
Step 2, Extract the data use terms into fields
Pull training permissions, derived data rights, policy incorporation language, subprocessor terms and deletion commitments into structured fields on each agreement. Record whether each category is addressed, permitted or prohibited, so the population can be reported rather than described.
Step 3, Set a clause standard and grade against it
Define what acceptable looks like for your organization: prohibited by default, aggregated data permitted under a named de-identification standard, no unilateral policy change, deletion on termination. Grade each agreement against it and rank the gaps by the sensitivity of the data involved.
Step 4, Fix the incorporation and change mechanics first
Before negotiating the substantive permission, close the route that makes any permission unstable. Fixing the incorporated policy as at the effective date, or requiring notice and a termination right on material change, protects everything else you negotiate.
Step 5, Track the commitments after signature
Deletion on termination, notification of model provider changes and any agreed audit or attestation rights are post-signature obligations with dates and owners. A negotiated protection that nobody enforces at the point of exit produces the same outcome as not having negotiated it.
See where your data can be used for training
Watch how data use, retention and deletion terms become reportable fields across the vendor estate.
Why this is a portfolio question, not a deal question
Most organizations negotiate hard on the two or three AI vendors they bought deliberately, and inherit far broader rights across dozens of existing tools that added model features by product update. That asymmetry is only visible at portfolio level, which is the same problem described in The IT leader’s guide to SaaS vendor contract sprawl. Where the vendor is also subject to regulatory obligations of its own, the contractual terms interact with the classification and documentation duties covered in EU AI Act vendor contract clauses for technology buyers, and both are best extracted in one pass across the same agreements. The inherited agreements are usually where the real exposure sits, and they are the ones nobody has a reason to reopen.
Data category, default position and what to negotiate
A practical clause standard states a position for each category rather than a single global prohibition.
| Data category | Common vendor default | Buyer position to seek | Field to track |
|---|---|---|---|
| Inputs | Permitted for improvement | Prohibited without written consent | Training on inputs, permitted or not |
| Outputs | Vendor rights asserted | Customer owns, no training use | Output ownership and use |
| Derived and aggregated | Freely usable | Permitted under defined standard | De-identification standard named |
| Usage telemetry | Unrestricted | Permitted, no customer content | Telemetry scope defined |
| Post-termination | Not addressed | Deletion and no further training | Deletion commitment present |
AI training terms are unusual among contract provisions in that the harm is effectively irreversible and the remedy is therefore worthless. That argues for spending the negotiating capital up front rather than relying on indemnities. The practical work is to treat data use as four categories rather than one, close the policy incorporation route that makes any protection unstable, and run the extraction across the whole vendor portfolio rather than the handful of agreements where AI was the point of the purchase. Treated as a portfolio exercise rather than a deal-by-deal one, it is a few weeks of extraction and grading rather than an open-ended review.
For related guidance, see When the order form and the MSA disagree, Auto-renewal clause risk in enterprise SaaS contracts and How to build a contract metadata model for AI search.
