Is an AI data buyer a sub-processor of your customers' data?

What makes a company a sub-processor?#

A company is a sub-processor when a processor engages it to process personal data on behalf of the controller, following the controller's instructions. When your SaaS product hosts customer data, your customer is usually the controller, you are the processor, and the cloud host or email provider you rely on is a sub-processor.

Three features mark the role: the processing serves the controller's purpose, it follows documented instructions, and a contract flows the processor's obligations down to it. Data processing agreements usually require the processor to list sub-processors, notify customers of changes and give them a chance to object.

US state privacy laws use different terms, such as service provider, contractor and third party, but they draw a similar line between processing for a business and processing for oneself.

Why an AI data buyer usually isn't one#

An AI data buyer usually isn't a sub-processor because it licenses records to train or evaluate its own models, for its own purposes. It does not act on your customers' instructions or help deliver your service to them, which are the defining traits of a sub-processor.

In a typical company records license the question is narrower still. A software company licenses its own records, such as engineering history and support tickets about its product, after personal and confidential details are removed. If de-identification is strong enough that the records no longer relate to identifiable people, customer personal data is not part of the transfer and no processor chain is involved.

That conclusion depends on the strength of the de-identification. Under GDPR, pseudonymized data, where names are replaced with codes that could be reversed, generally remains personal data, so the bar is anonymization rather than substitution.

When does the analysis change?#

The analysis changes when customer personal data, rather than de-identified company records, would reach the buyer or a service provider. The table sets out common scenarios and the role each party is likely to play; counsel confirms the answer for each deal.

The second and fourth rows are where most programs stall. If records still carry customer users' personal data, adding a buyer to a list does not cure the lack of authority; and if a preparation vendor handles that data, your own customers may need notice before the work starts.

The real issue: what processor terms let you do#

The real issue for most SaaS vendors is not how to classify the buyer but whether they may use customer personal data for anything beyond the service. A processor that uses data for its own purposes, such as licensing it, steps outside its instructions and may be treated as a controller for that processing, with the duties that come with it.

Data processing agreements usually limit processing to providing the service and following customer instructions, and many add deletion at termination. Some include a right to create aggregated or de-identified data, which is where a licensing program for company records usually starts. Read those clauses closely, because their definition of de-identified often sets a specific standard and a limited set of permitted uses.

What to check in your DPA and sub-processor list#

Checking your DPA before any licensing conversation tells you which records are in reach and which are not. Work through these clauses with counsel and keep a short memo of the outcome, because it becomes part of the rights record for any package that proceeds.

Pay particular attention to terms negotiated by your largest customers. A standard DPA may allow de-identified data for product improvement while an enterprise addendum forbids any use beyond the service, and the stricter paper governs that customer's records.

• 1Definitions: what counts as customer data, personal data and confidential information.
• 2Permitted purposes: whether processing is limited to providing and supporting the service.
• 3Aggregated and de-identified data: whether you may create it, for which uses and under what standard.
• 4Sub-processor terms: the notice and objection process and what triggers it.
• 5Onward transfers: limits on disclosure to third parties and on international transfers.
• 6End of service: deletion and return duties that may reach archived records.
• 7AI-specific clauses: any customer addendum restricting use of data for model training.

Illustrative: a customer success platform reviews its DPA#

Illustrative: a fictional customer success platform considers licensing its engineering history and its own support tickets. Its general counsel is asked whether the buyer must be added to the public sub-processor list.

The review finds that the platform is a processor for customer account data and that its DPA permits de-identified data only for service improvement, so customer account data is excluded. Support tickets written by customers' users are treated as the platform's business records but contain personal data, so they go through de-identification with sampling and human review before inclusion. The platform's own team strips attachments and pasted account exports from the tickets before the preparation vendor sees them. The vendor is recorded as the platform's own processor, and because it touches no customer account data, the sub-processor list does not change.

The buyer receives only de-identified company records and is not listed as a sub-processor. The counsel's memo documents the reasoning for the file.

How SourceX handles customer data questions#

SourceX resolves these questions in the Rights step of the SourceX five-step transaction, before any data is prepared. Customer personal data held as a processor is excluded unless the customer itself decides to license its own data as a separate supplier.

The privacy record in the SourceX Evidence Packet documents the de-identification method, the review performed and any remaining risk, alongside provenance, licensing rights, permitted use and release authorization. The supplier approves each step.