Client Data Held by Service Providers: The Authorization Buyers Need Before Licensing

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Why the processor role decides the answer

The supplier's legal role in each client relationship, not its possession of the files, decides whether it can license them. Under GDPR Article 28(3)(a), a processor handles personal data only on the controller's documented instructions, and under Article 28(10) a processor that decides the purposes and means of processing is treated as a controller for that processing, with the liability that follows [1]. Selling client call transcripts to a model developer is a new purpose. A BPO that does it without client instructions is no longer acting as a processor for that activity.

US rules follow the same logic with different words. The CCPA defines a "service provider" and a "contractor" as parties that process personal information for a business purpose under a written contract restricting other uses [2]. The CCPA regulations at 11 CCR § 7050 let a service provider use personal information to build or improve the quality of its own services, but not to build or modify household or consumer profiles for use in serving another business, or to perform services on behalf of another business [3]. Licensing transcripts to a third-party AI lab is hard to fit inside that carve-out, so treat it as needing the client's authorization.

Health data adds a third layer. A business associate's rights to protected health information come from its business associate agreement, and HIPAA de-identification must meet Safe Harbor or Expert Determination [6]. If the agreement does not permit the associate to de-identify and reuse PHI, a clean de-identification method does not fix the gap.

Regulators also treat broken data-use promises as a consumer protection issue. In a January 2024 staff post, the FTC warned that companies may face liability if they break promises not to use customer data for undisclosed purposes such as model training [5]. A service provider whose client contracts promise "data used only to deliver the services" creates that exposure for itself, and potentially a dispute that reaches the buyer.

The client authorization: fields it must state

A usable client authorization is a signed document from the client (the controller or business) that names the data and the use specifically enough to survive a later dispute. A generic "we may use aggregated data to improve services" clause in the supplier's standard terms is not that document. For the wider document set, see the chain of title for AI training data and the data rights attestation template.

Check that each authorization states:

1. Parties and signatory. The client legal entity, the service provider, and a signatory with authority to grant data rights (often the client's legal or privacy lead, not the account manager).
2. Datasets covered. Systems, record types and date range, for example Genesys or NICE call recordings and transcripts, Zendesk or ServiceNow tickets, or campaign assets, with the queue, line of business or program codes.
3. Purposes. AI training, fine-tuning, evaluation or agent training, named explicitly. "Analytics" or "service improvement" does not cover third-party model training.
4. Recipients. A named licensee or a defined recipient class, and whether onward transfer to a model developer's affiliates or contractors is permitted.
5. Preparation. Required de-identification or redaction method, who performs it, and whether the client reviews a sample first.
6. Term, revocation and deletion. How long the grant lasts, how revocation works, and what happens to data already delivered or models already trained.
7. Consideration and confidentiality. Whether the client is paid, and how client trade secrets, product names and pricing inside the records are handled.
8. Precedence. A statement that the authorization amends or overrides the MSA and DPA on data use, or the specific clauses it supersedes.

Contract clauses that override a general authorization

The client's master service agreement, statement of work and DPA can silently cancel an authorization that looks clean. Ask for the executed versions and read the clauses that restrict data use, because a later, narrower clause in an amendment often controls.

For the parallel analysis when the supplier's own customers are the data subjects, see customer contracts and DPAs for AI training use. Our owner page on licensing data your vendor holds covers the question from the client's side.

De-identification is not a substitute for client permission

Removing personal data reduces privacy exposure, but it does not create a right to license data that belongs to a client under contract. The CCPA treats deidentified information differently from personal information, and commentators have debated whether a service provider can deidentify client data and then use it for its own purposes [2][4]. Even where privacy law allows it, the client's confidentiality clause and ownership of work product still apply.

Agency and MSP records show why. A creative agency's briefs, decks and revision threads contain client strategy. An MSP's tickets contain client hostnames, network diagrams and vendor contracts. Redacting names and phone numbers does not remove the commercial confidentiality those clients bargained for. For spoken PII specifically, see redacting PII from call recordings.

Multi-client queues and co-created records

Data that mixes several clients needs authorization from every client represented in the delivered sample, or those clients' records must be removed. Shared contact-center queues, pooled ITSM instances and agency asset libraries often hold records from many clients in one table. A single client's authorization covers only its own records.

Co-created work product is harder. When an agency and client jointly produced a document, or a ticket thread includes the client's engineers, both parties may hold rights; see who owns data in a client project and licensing data you co-own with a client. Call recordings carry their own consent layer on top of client authorization, covered in call-recording consent for AI training. Offshore and multi-client BPO specifics are in sourcing AI training data through BPOs.

Client-level exclusion flags: the control that makes it auditable

The practical control is a client identifier on every record, joined to an authorization register, so unauthorized clients' records are filtered before delivery. Without it, the supplier cannot prove which records a given authorization covers. Ask for this at record level, not just in a dataset-level statement.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "record_id": "tkt-000184233",
  "source_system": "ServiceNow incident",
  "client_id": "CL-0412",
  "client_authorization_id": "AUTH-2026-031",
  "authorization_status": "active",
  "authorized_purposes": ["sft", "eval"],
  "authorized_recipient_class": "named_licensee_only",
  "authorization_expires": "2028-06-30",
  "deidentification_method": "named-entity replacement + regex for account numbers",
  "client_sample_review": "approved 2026-09-12",
  "exclude_from_delivery": false
}

Run three checks on a supplier's export. Count distinct client_id values and confirm each has a matching authorization record. Confirm no record carries a null or "unknown" client_id. Re-run the filter after any revocation and get a delivery manifest that lists excluded record counts per client.

Buyer verification workflow

Verify the authorization chain before pricing, because a missing client signature can remove most of a dataset. A workable order is:

1. Map roles. Ask the supplier to state, per client, whether it acts as processor, service provider, business associate or independent controller, with the governing contract.
2. Collect documents. Executed MSAs, DPAs or BAAs, any amendments, and the signed client authorizations.
3. Reconcile coverage. Match authorizations against the distinct client_id list in a sample export.
4. Read the overrides. Apply the clause table above to each client contract.
5. Get warranties. Request supplier warranties that the data was lawfully obtained and that client authorizations are valid and unrevoked; chain-of-title practice relies on these [7].
6. Record it. Log permitted purposes and expiries in your training data use register.

Our AI training data due diligence checklist covers the remaining privacy, security and quality checks. The provenance hub links related title tests, including contractor-created data.

How SourceX handles client-held operational data

SourceX sources operational datasets from US companies on request, including support and sales histories, engineering records and documents, and manages the licensing process. Every dataset is rights-reviewed for ownership and consents and delivered under a license that defines the records, uses, term and delivery, and every release is approved by the supplying company. Personal details are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Relevant categories include contact-center call recordings and IT service management tickets; you can describe your data requirements to SourceX.

Licensing service-provider data with SourceX

SourceX looks for US businesses that hold the data you describe, assesses licensing permissions before anything is agreed, and nothing is contracted until a supplier agrees. Data is sourced on request, so a request does not guarantee a match. Start a buyer request.