Does an aggregated data clause let a SaaS company license data to AI developers?

What does a typical aggregated data clause permit?#

A typical aggregated data clause permits the SaaS vendor to compile data from customer use into combined, de-identified form and use it to operate, improve and benchmark the service. Many clauses also say the vendor owns the resulting aggregated data and may keep using it after the agreement ends.

Clauses like this were mostly written for dashboards, industry benchmarks and product analytics. As interest in AI training data has grown, vendors increasingly look to these carve-outs as a possible route for AI use, which is exactly why they deserve a close read rather than an assumption.

The clause usually sits in a section about data rights or usage data, away from the confidentiality and DPA terms that limit it. Reading it in isolation is the most common mistake general counsel see in internal proposals.

Five words to check in an aggregated data clause#

Five words in an aggregated data clause decide most of what it permits. Read each in its defined form, because the definitions section often narrows the plain meaning considerably.

As a checklist, the clause supports an AI license only if every answer below is broad. One narrow answer is enough to take customer records out of scope.

• 1Aggregated covers the specific records, not just statistics about them.
• 2De-identified is defined at least as strictly as the privacy laws that may apply.
• 3Derived data includes the content a licensee wants, not only usage metrics.
• 4Purpose extends beyond the vendor's own service.
• 5Third-party disclosure or commercialization is expressly allowed.

Why does record-level text usually fall outside the clause?#

Record-level text usually falls outside an aggregated data clause because a de-identified support ticket, document or message is still an individual record, not an aggregate. Removing names changes who is identifiable; it does not combine the record with others.

AI developers usually want exactly these individual records: a ticket and its resolution, a document and its revisions, a request and the approval that followed. That mismatch is why aggregated data clauses, read carefully, rarely answer the licensing question for customer content.

Some proposals try to bridge the gap by pooling records from many customers and calling the pool aggregated. A pool of individual tickets is still a set of individual tickets: in most clauses the word describes the output of combining data, not the size of a collection. Test any such reading against the definition, not the label.

How do the DPA and privacy law interact with the clause?#

The data processing agreement often controls over the main agreement for personal data, and it usually limits processing to the customer's documented purposes. Check the order-of-precedence clause: if the DPA wins for personal data, a broad aggregated data clause in the main agreement may not reach any record that contains it.

Privacy laws such as GDPR and CCPA set their own standards for anonymized or de-identified data, often with conditions beyond removing names. A contract can promise de-identification, but whether the result falls outside a privacy law is assessed against that law, deal by deal, with counsel.

Confidentiality terms add a third layer. Customer business information, such as pricing, volumes or supplier lists, can stay confidential even when no person is identifiable.

What can an aggregated data clause support?#

An aggregated data clause can support genuine aggregates: benchmarks, distributions and trend data that describe many customers without exposing any one. Examples include resolution-time distributions by ticket category or feature adoption curves by industry, provided the purpose and third-party language allow sharing them.

Interest in such statistics from AI developers is narrower than interest in records, but they can inform evaluation design or market context. They also carry the lowest customer exposure, which makes them a reasonable add-on to a package built from company-owned records.

Build aggregates conservatively. Small groups can expose a single customer, so set minimum group sizes, suppress rare categories, and check whether a benchmark could reveal one large customer's figures. Record those choices in the privacy file alongside the clause reading.

Illustrative: a procurement software company reads its clause#

Illustrative: a fictional procurement software company assumes its master subscription agreement allows licensing because it grants the company ownership of aggregated data. Its general counsel reads the clause against the five words.

Aggregated is defined as data combined across customers so that no customer is identifiable. Purpose is limited to improving and marketing the service. The DPA, which controls for personal data, limits processing to providing the service. Purchase requisitions, supplier messages and approval comments are individual records, so they fall outside.

The company concludes that customer procurement records are out of scope, and notes that even its category-level spend benchmarks would need a broader purpose clause before they could be licensed. It proceeds instead with its own support escalation notes and engineering history. The general counsel files a short memo explaining the reading so the question does not resurface with each new inquiry.

How SourceX approaches aggregated data rights#

SourceX reviews aggregated data clauses in the Rights step of the SourceX five-step transaction, together with the DPA, confidentiality terms and any order-of-precedence language. Where a clause does not clearly cover both the records and the use, the default is to exclude them.

The SourceX Evidence Packet records the licensing rights relied on, including the clause text and how it was read, so a licensee can see why each record family is in scope and the supplier can see what it approved.