Rights and contracts
Aggregated data clauses: what your SaaS customer contracts let you do
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
An aggregated data clause in a SaaS customer contract usually lets the vendor use combined, de-identified statistics to run and improve its service. It rarely lets the vendor hand record-level customer content to an AI developer. Before licensing anything, sort records into customer data, usage data and your own company records, then read each clause's definitions and limits.
Key takeaways
- Aggregated usually means combined across customers into statistics, which is different from a single record with names removed.
- Many clauses limit use to operating, improving or benchmarking the service, which may not cover licensing to a third party.
- Customer data, usage data and your own operational records carry different rights and should be inventoried separately.
- Negotiated enterprise paper often narrows or strikes the clause, so read the signed version, not your website template.
- A DPA or confidentiality clause can restrict data even where an aggregated data clause seems to allow use.
What does an aggregated data clause usually say?#
An aggregated data clause is a provision in a SaaS agreement that lets the vendor create and use data derived from customer data once that data no longer identifies the customer or any individual. Typical wording grants the vendor ownership of, or a license to, aggregated and anonymized data, often tied to a purpose such as improving the service, developing new features or publishing industry benchmarks.
The clause works together with three definitions that decide what it actually covers: customer data (what the customer and its users submit), usage data or service data (telemetry and metadata the platform generates), and aggregated data (the output of combining and de-identifying either one). A general counsel weighing an AI licensing request should read all three together, because the clause reaches only what the definitions put in scope.
Most of these clauses were drafted with dashboards, benchmarks and product analytics in mind. Few were written for record-level training data, which is why the wording often fits awkwardly when a licensing question arrives.
Clause spectrum: what common wordings permit for AI licensing#
The reach of an aggregated data clause depends on its exact wording, and common versions fall along a spectrum from silent to explicit. The table reads each pattern from the supplier's side: what it usually permits, and how it likely applies when the question is licensing records to an outside AI developer.
Two words do most of the work. Aggregated generally means combined across customers or records so the result describes a group; a single support ticket with names stripped out is de-identified, not aggregated. And a purpose limit such as to improve the services describes the vendor's own use, not disclosure to someone else.
| Clause wording pattern | What it usually permits | Likely position on licensing to an AI developer |
|---|---|---|
| No aggregated data clause; customer data used only to provide the service | Processing needed to deliver the contracted service | Customer data likely out of scope without new written consent |
| Vendor may use aggregated, anonymized data to improve the service | Internal analytics and product improvement | Third-party licensing usually falls outside the stated purpose |
| Vendor may use aggregated data for benchmarks and industry reports | Publishing combined statistics that identify no customer | Statistics only; record-level text and files are not aggregated |
| Vendor owns aggregated and de-identified data and may use it for any lawful purpose | Broad commercial use of properly derived data | Possible for combined, de-identified outputs; counsel still checks confidentiality and privacy overlays |
| Express permission to use de-identified customer data to develop AI or machine learning models | Training the vendor's own models, sometimes more | Check whether disclosure to third parties is allowed or only internal training |
| Express prohibition on AI training or on sharing derived data | Nothing beyond service delivery | Out of scope unless the customer agrees in writing |
Customer data, usage data and your own records are separate questions#
Customer data, usage data and your company's own operational records sit under different sets of rights, so sorting them is the first step. Much of what AI developers want from a software company falls in the third group: your own Jira issues, GitHub pull requests and code reviews, internal Slack and Confluence threads, and the support tickets your team handled in Zendesk or Intercom.
Your own records are not automatically free to license. Support conversations contain customer names, screenshots and pasted configuration, and engineering tickets often quote customer bug reports. But the starting point is your ownership, limited by confidentiality duties and personal data, rather than a license grant from each customer.
| Data category | Typical examples | Main rights question |
|---|---|---|
| Customer data | Records users create in your product, uploaded files, messages between your customers and their own clients | What the customer contract and DPA allow beyond running the service |
| Usage data | Feature events, API call logs, performance metrics, error traces | How the contract defines usage data and whether it captures content |
| Your own operational records | Support tickets, CRM history, Jira issues, code reviews, release notes, internal docs | Confidentiality owed to customers and personal data inside the text |
| Aggregated outputs | Benchmarks, counts and trend tables across customers | Whether the combining and de-identification meet the contract definition |
Where aggregated data clauses stop short#
Aggregated data clauses usually stop short of AI licensing in three places: the purpose, the recipient and the form of the data. A clause allowing use to improve and develop the service rarely speaks to giving a dataset to an unaffiliated company for its own model development.
The form problem is the one most often missed. An AI developer typically wants record-level material such as ticket threads, issue histories or document text, while aggregated data in the contract sense is a summary. Removing names from a record does not make it aggregated, and many clauses require both aggregation and de-identification before any right applies.
Where a clause ties de-identification to a legal standard, the bar can be specific. Under the CCPA as amended by the CPRA, information counts as deidentified only if the business takes reasonable measures so it cannot be associated with a consumer or household, publicly commits to keep it in deidentified form and not to re-identify it, and contractually obligates any recipient to do the same. A vendor that cannot show those steps may find its de-identified data does not meet the definition the clause relies on.
Other provisions can override the clause entirely. Customer data is often defined as the customer's confidential information, a data processing agreement may limit processing to the customer's documented instructions, and laws such as the CCPA or GDPR may treat the vendor as a service provider or processor with tight purpose limits. Which of those laws reach a given record family is a deal-by-deal question for counsel.
How to review your contract stack before a licensing conversation#
A contract review for AI licensing works best when it starts from the records rather than the template. Identify which record families a buyer might want, then trace which agreements govern each one.
Click-through customers may have accepted several versions of your terms over the years. Which version governs a given record can depend on when it was created and how updates were accepted, which is a separate question from what the current clause says. A useful decision rule: if a record family is licensable only because of the aggregated data clause, treat it as out of scope until counsel confirms the clause covers record-level disclosure to a third party.
- Pull signed versions of master agreements, order forms, DPAs and amendments, not just the current template on your website.
- Group customers by paper: click-through terms by version date, your standard negotiated MSA, and enterprise contracts on customer paper.
- Read the definitions of customer data, usage data, aggregated data and confidential information side by side.
- Note purpose limits, recipient limits, deletion-at-termination duties and any express AI or machine learning language.
- Check the order of precedence clause to see whether an order form or DPA overrides the MSA.
- Record which customers struck or narrowed the aggregated data clause in negotiation.
- Map each record family to in scope, out of scope, or needs customer consent.
Illustrative: a property management software company sorts its records#
Illustrative: a fictional property management software company with many years of history wants to know what it could license. Its standard terms include an aggregated data clause allowing use of anonymized, aggregated data to improve the service and publish market reports. Its largest customers signed on their own paper and struck the clause.
Counsel concludes that tenant messages and maintenance requests inside customer accounts are customer data and stay out of scope. Aggregated vacancy and response-time statistics fit the benchmark language, but they are not what the developer wants. The strongest package turns out to be the company's own records: Zendesk tickets about software problems linked to Jira bugs, GitHub code reviews and release notes, with customer names and pasted tenant details removed. The company proceeds with that package and leaves customer data aside.
How SourceX handles contract scope#
SourceX treats contract scope as part of the Rights step in the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The fit check uses metadata only, so a general counsel can describe record families and contract types before any file leaves the company.
When a package proceeds, the conclusions of the contract review are recorded in the SourceX Evidence Packet under licensing rights and permitted use, next to provenance, the privacy record and release authorization. The buyer sees which record families were included and which were carved out, and the supplier approves each step.
Frequently asked questions
Can we rely on an aggregated data clause to license de-identified support tickets?
Usually not on its own. Support tickets about your own product are generally your company's records rather than customer data, so the more relevant questions are confidentiality obligations and personal data in the text. If the tickets were customer data, a clause permitting aggregated statistics would rarely cover record-level text.
Does de-identified data fall outside a customer's confidentiality protection?
Not always. Confidential information definitions often cover everything the customer provides, and de-identification removes identities rather than the business content. A pricing setup or internal process description can remain confidential after names are gone. Check whether the confidentiality clause expressly carves out aggregated or de-identified data.
Should we add an AI training clause to our template now?
Many software companies are revising templates, but a new clause affects only contracts signed or properly amended after it. It does not reach data collected under older terms without consent. Draft it with clear definitions, a stated purpose and an explicit position on third-party disclosure, and expect enterprise customers to negotiate it.
Is usage data the same as aggregated data?
No. Usage data is raw material, such as event logs and API metrics, while aggregated data is a processed output. Customer data definitions are often broad enough to absorb logs: Intercom's terms, effective April 9, 2025, define Customer Data to include data about people such as chat and message logs. Check whether your own definition does the same before treating logs as usage data.
Who should sign off on the contract analysis?
General counsel or outside counsel should own the conclusion, with input from whoever manages customer contracts and the product or engineering lead who knows what each system stores. Write the analysis down per record family so the supplier's authorized signer approves a defined scope rather than a general impression.
Sources
- Post-CPRA, Cal. Civ. Code 1798.140(m) treats information as deidentified only if the business takes reasonable measures to ensure it cannot be associated with a consumer or household, publicly commits to maintain and use it in deidentified form and not attempt to reidentify it, and contractually obligates any recipients to comply with these requirements. Source
- Intercom's Terms of Service (effective April 9, 2025) define 'Customer Data' as any data, content or other information submitted to the Services by or on behalf of the Customer. The definition includes data about People, such as chat and message logs, collected from the Customer Properties through the Services. Source
Related resources
- IndustryLegal data
- QuestionDo AI labs buy legal documents?
- InsightDo you need a DPA when licensing de-identified data?
- InsightIs an AI data buyer a controller, a processor or a third party?
- InsightData licensing partner vs law firm vs doing it yourself
- SolutionData partnerships between businesses and AI developers
See if your company qualifies
A short company assessment. No data uploads are needed.