AI training addendum template for SaaS customer contracts

What does an AI training addendum do, and when do you need one?#

An AI training addendum gives a SaaS vendor written permission from a customer to use specific records derived from that customer's account for training, evaluating or licensing AI models. Vendors usually need one when the master subscription agreement, the data processing addendum and the online terms are silent on AI, or only allow use for service improvement or aggregated statistics.

The addendum should say which of two uses it covers, because they carry different risk. Training your own product features keeps records inside the company. Licensing de-identified records to an outside model developer moves them to a third party, which is the use most customer contracts never contemplated.

Where the vendor processes personal data on the customer's behalf, the addendum records the customer's instruction, but it may not settle every question. Using records for the vendor's own training or for licensing to others can make the vendor responsible for that use in its own right under laws such as GDPR or US state privacy laws, and those laws may still apply to the individuals in the records. Counsel should assess the addendum against the DPA and the privacy notice before it goes out.

Template structure at a glance#

The template structure below keeps each decision in its own clause, so a customer's lawyer can accept scope while negotiating recipients, or strike the revenue share without reopening the rest. Short, separate clauses also make it easier to record which version each customer signed.

Scope and exclusions: sample language and notes#

The scope clause is where most of the protection sits, because a narrow list of record categories limits everything downstream. Sample wording: "Customer authorizes [Vendor] to use De-identified Service Records within the categories listed in Schedule A for the purposes of training, evaluating and improving machine learning models, and to license De-identified Service Records to Permitted Recipients for those purposes only."

Schedule A should name record families the way your systems store them, so the data team can filter by field rather than by judgment. The exclusions belong in the body of the addendum, not the schedule, so they cannot be widened by a later schedule update.

• 1Typical Schedule A categories: support ticket text with resolution codes, product workflow event logs, configuration settings and error messages.
• 2Typical exclusions: files and attachments the customer uploads, credentials and API keys, payment card and bank details, health information and source code the customer provides.
• 3Also exclude content the customer has marked confidential and any records of the customer's own end customers, unless counsel approves a specific category.
• 4Add a sentence that anything not listed in Schedule A is out of scope by default.

De-identification standard: what the clause should promise#

A de-identification standard clause should describe a process the vendor can actually run and evidence, not a result it cannot guarantee. Sample wording: "Before any use under this Addendum, [Vendor] will remove or replace direct identifiers, customer and end-user names, contact details, account identifiers and free-text fields that cannot be reviewed, using automated detection followed by human review of samples, and will not attempt to re-identify any person or customer."

Avoid the word anonymized unless counsel is comfortable with it, because legal definitions of anonymous data differ across laws. Commit instead to the steps, the reviewers and the records you keep of each preparation run.

Automated scanning alone is not enough to support the promise. The documentation for Presidio, a widely used open-source PII detection tool, warns that its automated detection cannot guarantee it finds all sensitive information and that additional protections should be used. The clause should therefore name human review as part of the standard.

Permitted recipients and flow-down terms#

The permitted recipients clause tells the customer exactly who may hold its de-identified records, and the flow-down clause tells it what those holders must promise. Customers react far better to defined categories with conditions than to an open-ended right to share with third parties.

Each recipient should sign terms at least as protective as the addendum: no re-identification, no onward sale or sublicensing, reasonable security, use only for the stated purpose and deletion when the license ends.

Opt-out, withdrawal and an optional revenue share#

The opt-out clause should let a customer stop future use on written notice, with a stated effective date and a confirmation from the vendor. Be explicit that withdrawal stops new preparation and new licenses, and state whether recipients must delete records already delivered. Trained models generally cannot remove what they learned, so say that plainly rather than promising deletion you cannot perform.

A revenue share is optional and works best as a separate commercial schedule. If you offer one, define the base (for example, net license fees attributable to the customer's records), the reporting cadence and an audit right, and leave amounts to negotiation. Some vendors offer product credits or nothing beyond product improvements; either approach is acceptable if it is stated clearly.

Revenue sharing can affect how the vendor recognizes license revenue and how the customer reports the income, so bring in your accountants as well as counsel before offering it.

• 1Sample opt-out wording: "Customer may withdraw this authorization by written notice; withdrawal takes effect for records created or prepared after [Vendor] confirms receipt."
• 2Sample change wording: "[Vendor] will give Customer notice before adding a new Permitted Recipient category, and Customer may object within the notice period stated in Schedule B."
• 3Sample consideration wording: "Any revenue share is set out in Schedule C; if Schedule C is blank, no payment is due."

Illustrative: an equipment rental software company rolls out the addendum#

Illustrative: a fictional software company sells reservation and fleet tracking software to equipment rental yards. Its Zendesk tickets link to Jira issues, and its product logs record each reservation, return, damage inspection and billing exception. The CEO wants to explore licensing support-to-fix histories and workflow logs, but the master agreement only allows use for operating and improving the service.

The general counsel adopts an addendum with ticket text, resolution codes and workflow event logs in Schedule A, excludes damage photos and payment fields, and offers it at renewal rather than by email blast. Customers that already negotiated no-AI clauses are flagged in Salesforce and never receive it. Signed versions are stored with the contract record, and the data team filters exports by a signed-addendum field. The resulting package is smaller than the full archive, but every included customer has a signed, dated authorization.

How SourceX treats customer authorizations#

SourceX reviews customer authorizations during the Rights step of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Records from customers without a clear authorization are excluded from the proposed package rather than argued into it.

For each package that proceeds, the SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization, including which addendum version covers which customers. The supplier approves every step, and nothing is shared during the initial fit check.