No-AI-training clauses in customer contracts: what B2B companies are seeing

Where are no-AI-training clauses showing up?#

No-AI-training clauses are showing up wherever enterprise customers negotiate paper with their software vendors: MSA redlines, data processing agreements, standalone AI riders and security addenda. Customers add them because many vendors now seek contract room to improve models with customer data, and procurement teams want that room closed or tightly controlled.

The clause rarely arrives alone. A typical enterprise renewal now carries an AI section in the security questionnaire, a sub-processor list that names model providers, and a rider limiting what the vendor and its sub-processors may do with customer content. When the questionnaire is attached as an exhibit, its answers can become contract terms too.

Vendor-side commitments show the same pressure from the other direction. Zoom's online Terms of Service (Section 10.2) state that it does not use audio, video, chat, screen sharing, attachments or other communications-like customer content to train Zoom or third-party AI models. Slack drew public backlash in May 2024 when its privacy principles were read to allow training on customer data unless an organization opted out by email. Procurement teams point to episodes like these when they ask for a clause of their own.

• 1Master service agreement: confidentiality, customer data use and license-back sections, often rewritten in redlines.
• 2Data processing agreement: processing instructions, sub-processor terms and any carve-out for aggregated or de-identified data.
• 3AI rider or addendum: a separate exhibit covering AI features, model providers, training and outputs.
• 4Order forms and statements of work: one-off restrictions negotiated for a single deal.
• 5Security questionnaire answers and trust center statements incorporated by reference.

What do the common clause patterns say?#

The common clause patterns sit on a short spectrum, from a flat prohibition to use allowed with documented consent. The table paraphrases each pattern and reads it from the supplier's side: what it typically leaves open if the company later wants to license records to an AI developer.

Treat the table as a sorting aid, not a legal conclusion. The same label can hide very different drafting, and a clause that looks permissive can be narrowed by a definition three pages earlier.

Which definitions decide how far the clause reaches?#

The definitions decide how far a no-AI-training clause reaches, often more than the operative sentence does. A ban on training with customer data means little until you know whether customer data includes support conversations, usage logs or bug reports that customers emailed to your engineers.

Read these terms in the version of the agreement that actually governs each customer, and note where the MSA and DPA define the same word differently. An order-of-precedence clause usually settles conflicts, and it often favors the DPA.

• 1Customer data or customer content: only what users upload, or also tickets, chats and files sent to support?
• 2Usage data, service data or telemetry: carved out of customer data and assigned to the vendor, or not?
• 3Derived data: are aggregates, embeddings and analytics treated as customer data?
• 4Training: does it cover fine-tuning, evaluation, benchmarking and retrieval indexes, or only building a model?
• 5AI model or machine learning: is the term broad enough to sweep in rules engines and simple classifiers?
• 6Third party: could a licensee, an affiliate or a future acquirer count as a permitted recipient?
• 7Survival: does the restriction continue after the agreement ends?

How do these clauses interact with the rest of your paper?#

A no-AI-training clause interacts with confidentiality terms, privacy statements and sub-processor commitments, so the clause alone rarely tells the whole story. Customer data is commonly defined as the customer's confidential information, which means a license to a third party can breach confidentiality even where the AI clause is silent.

Public statements matter as well. A trust center page or privacy notice saying the company never shares customer data for AI training is a commitment customers rely on, and a questionnaire answer saying the same can be pulled into a contract. Align these documents before any licensing conversation, and record which version each customer accepted.

What records usually remain licensable?#

Records a company creates about its own work usually remain licensable even when every customer contract carries a no-training clause. For a B2B software company, that typically means Jira issues and engineering discussion, pull requests and code review threads, internal Confluence or Notion documentation, product decision records and release notes.

The hard part is embedded customer content. Engineering tickets quote customer bug reports, paste log lines with account identifiers and attach screenshots from customer environments. Under most definitions those fragments are customer data, so they are removed, or the record is excluded, before anything moves.

Support conversations sit in the middle. A Zendesk or Intercom thread is often customer data in full, so many companies consider only the internal side: macros, internal notes, escalation decisions and the linked engineering fix, with customer text removed.

Illustrative: an HR software company sorts accounts by clause#

Illustrative: a fictional HR software company sells to mid-market and enterprise employers. Its older click-through terms are silent on AI, its enterprise customers signed redlined MSAs, and many recent renewals added an AI rider with a flat training prohibition.

Counsel tags every Salesforce account with its clause pattern: silent, flat prohibition, carve-out or consent. Support mirrors the tag onto Zendesk organizations so any export can filter by it. Engineering history in Jira and GitHub is reviewed separately, and a script flags ticket text pasted from customer emails for removal.

The company scopes a first package to internal engineering records with customer fragments stripped, and defers support threads entirely. It then asks a handful of silent-contract customers whether they would sign a narrow consent addendum, rather than assuming that silence permits use.

How SourceX reviews AI clauses#

SourceX reviews customer contract patterns in the Rights step of the SourceX five-step transaction, after Supply and before Preparation, Approval and Delivery. The initial fit check uses metadata only, so counsel can describe contract categories and known restrictions without sharing agreements or records.

When a package proceeds, the conclusions go into the SourceX Evidence Packet under licensing rights and permitted use, next to provenance, the privacy record and release authorization. That mirrors provenance standards such as the Data and Trust Alliance Data Provenance Standards, whose Use metadata includes elements for license to use, intended data use and consent documentation location.