How to add AI training rights to your SaaS terms without a customer backlash

Why do AI training clauses set off customer backlash?#

AI training clauses set off backlash when customers read a broad license grant as permission to feed their content into models they never agreed to. The legal text may be years old; what changed is that customers now read it with AI in mind.

Zoom is the case most product teams remember. After criticism of terms changes made earlier in 2023, Zoom added a sentence in August 2023 stating that it would not use audio, video or chat customer content to train its AI models without consent. WeTransfer followed a similar path in July 2025, revising updated terms before they took effect to remove language about using uploaded content to improve machine learning models.

The regulatory angle matters too. In February 2024, FTC staff wrote that a company adopting more permissive data practices, such as using consumer data for AI training, and disclosing it only through a surreptitious, retroactive change to its terms or privacy policy may be engaging in unfair or deceptive practices. The post focuses on consumers, but vendors selling to small businesses should read it closely.

Separate customer content from telemetry before you draft#

The first drafting decision is classification: which data the clause actually covers. Customers accept product telemetry being used to improve a service far more readily than they accept their documents, tickets or code being used to train a model, so mixing the two in one clause invites the worst reading.

What should a new AI training clause say?#

A clause that survives customer scrutiny is specific about scope, consent and what happens when a customer changes its mind. Vague phrases such as improving our services or developing new features are exactly what customers object to once AI is involved.

Avoid two drafting shortcuts. Do not bury the AI permission inside a long list of permitted uses, and do not define de-identified data so loosely that pseudonymized records with stable customer IDs still qualify, because procurement and privacy reviewers check for both.

• 1Definitions that separate customer content, usage data and de-identified data.
• 2Whose models are covered: your own product features, third-party model providers, or outside AI developers who license data.
• 3The consent mechanism, who can grant it on the customer's side, and where the choice is recorded.
• 4The de-identification standard applied before any training or licensing use.
• 5Withdrawal: what stops immediately and how already-trained models are treated.
• 6Retention and deletion of training copies.
• 7An effective date that applies the clause only to data collected or consented after that date.

Click-through terms versus negotiated enterprise agreements#

Click-through terms and negotiated agreements change in different ways, and most SaaS companies have both. Posting new online terms may update the first group, depending on the update clause, but a negotiated master agreement with an entire-agreement and amendment clause usually needs a signed amendment.

This is general information, not legal advice. Whether a unilateral update binds a customer depends on the existing contract and governing law, so review your update clause with counsel before announcing anything.

Rollout checklist: notice, consent and refusals#

A rollout that respects customers looks more like a product launch than a legal update. The steps below assume a mix of self-serve and enterprise customers.

• 1Inventory every contract form and template version so you know which customers a posted update reaches.
• 2Write a plain-language summary of what changes, what does not and what the customer controls.
• 3Set an effective date far enough out that admins can read, ask questions and decide.
• 4Notify through several channels: email to account admins, an in-app banner, the changelog and direct outreach for negotiated accounts.
• 5Default training on customer content to off and make opt-in a deliberate admin action.
• 6Log each choice with account, user, terms version and timestamp.
• 7Flag refused accounts in the data warehouse so pipelines exclude them automatically.
• 8Brief support and account teams with the same answers that appear in the public FAQ.

Illustrative: a project management vendor for architecture firms#

Illustrative: a fictional project management SaaS used by architecture and engineering firms wants to train a feature that drafts meeting minutes from project notes, and later to license de-identified records to AI developers. Its click-through terms already let it use data to improve the service.

Counsel advised against relying on that phrase. The company split its clause: usage telemetry stayed under service improvement with clearer notice, training on project content became an admin opt-in, and licensing to outside developers became a separate opt-in with its own description. Enterprise customers received a short AI addendum through their account managers.

Some firms opted in to the drafting feature only, some to both and some to neither. Because refusals were flagged in the warehouse from the start, the later licensing package drew only from opted-in accounts and from the vendor's own support and engineering records.

How the update affects future data licensing#

A terms update is often the first step toward licensing records, so the consent record becomes evidence later. When a SourceX transaction reaches the Rights step, the question is not only what the terms say today but which version each customer accepted and what it covered.

SourceX records that answer in the SourceX Evidence Packet under licensing rights and permitted use, and accounts that refused are excluded during Preparation. Many software companies also find that their strongest licensing candidates are their own records, such as support outcomes and engineering histories, which depend less on customer consent than on removing customer details.