Licensing training data for client AI projects: a guide for AI consultancies and systems integrators

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

Three ways to structure the license

There are three workable structures, and the right one depends on who will run the model after the engagement ends. The licensing basics (scope, term, deletion) are covered in the AI training data licensing guide and the explainer on data license terms. This section covers only the intermediary's choice.

1. Client as licensee, consultancy as contractor. The client signs the data license. The license defines "Authorized Users" or "Contractors" to include the consultancy's named staff, bound by confidentiality no weaker than the license's own. The client keeps the rights when the engagement ends, and nothing needs to be assigned.
2. Consultancy as licensee, then assign or sublicense. The consultancy signs, often because it wants to start before the client's procurement finishes. This only works if the license expressly permits assignment to, or a sublicense for, a named end client; many data licenses prohibit both without the licensor's consent.
3. Project-scoped tri-party license. The license names the data supplier, the client and the consultancy, with a defined project, model and permitted uses. It takes longer to negotiate but removes ambiguity about who may do what, and it suits regulated clients whose risk teams want the supplier in privity with them.

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

Rights that must survive hand-over

The client must be able to keep, run and retrain the model after the consultancy leaves, so check four survival rights before delivery. A license that ends at "project completion" can leave a production model built on data nobody is licensed to use.

• Model retention. Can the trained weights, adapters (LoRA or other parameter-efficient deltas) and fine-tuned checkpoints be kept and used after the license term or the engagement ends? Check whether deletion obligations reach model artifacts or only the raw records.
• Successor models. Can the client retrain or distill a new version using the same data, or only use the delivered model as is? Retraining on a hosted service such as Azure OpenAI keeps fine-tuning data within the customer's resource [2], but the service's privacy terms say nothing about whether the license allows that retraining.
• Derived assets. Embeddings, vector indexes for RAG, evaluation sets, annotations and synthetic data generated from licensed records are derivatives in most licenses. Ownership and provenance of synthetic data derived from licensed material is a live diligence question in AI transactions [3].
• Change of operator. If the client later moves the model to another integrator or in-house team, the contractor clause must allow a new contractor without a fresh negotiation.

For retrieval systems, the corpus stays live after hand-over, so the license must cover continued indexing and display; see RAG content licensing.

Reuse across clients

Reusing the same licensed data for a second client is usually not permitted unless the consultancy holds the license and it expressly allows multi-client use. Even then, the first client may have negotiated exclusivity or field-of-use limits in the statement of work that block reuse.

Separate three asset types when you answer the reuse question:

• The licensed records themselves. Governed by the data license. If the client is the licensee, the consultancy has no reuse right.
• Work product created on the records. Annotation guidelines, labeled subsets, prompt templates and eval rubrics. Ownership is set by the consulting master services agreement (MSA), and the data license may still restrict any part that embeds records.
• Model components. A fine-tuned adapter trained on client-licensed data is not a neutral "accelerator." Treat it as client deliverable unless every input license and the MSA say otherwise.

Write the reuse position into both the MSA and the data license so they cannot contradict each other. A common failure mode: the MSA lets the consultancy keep "general know-how and tools," and a team reads that as permission to keep a domain adapter trained on licensed support tickets.

Keeping client data and licensed data apart

Client confidential data and third-party licensed data should live in separate, labeled stores with separate deletion schedules, even when they are joined for training. Mixing them without lineage makes it impossible to honor a deletion request or license termination for one source without retraining from scratch.

Practical controls for the delivery team:

• Tag every record with a source_id, license_id and permitted_uses field at ingestion, and keep the tag through feature stores and training manifests. The ML data engineering guide shows how to turn license terms into pipeline controls.
• Keep training run manifests listing which license_id values fed each checkpoint, so you can prove what a model saw.
• Run fine-tuning in the client's tenant where possible. Hosted providers make commitments about not using customer data for undisclosed purposes, and the FTC has warned that breaking such commitments can create liability [1]; your own commitments to the client deserve the same discipline.
• At project end, issue a deletion certificate per source covering raw data, intermediate files, caches and consultant laptops.

De-identification and regulated records

Personal data rules follow the records, not the contract structure, so whichever party is licensee must confirm the de-identification standard before anything enters a client pipeline. Health data under HIPAA must meet 45 CFR 164.514, either through Safe Harbor removal of the listed identifiers or Expert Determination [6]. Under the CCPA, "deidentified" information also requires a public commitment not to reidentify and contracts binding recipients to the same [7], which matters when the consultancy is one of those recipients.

If the client's model will make consequential decisions about people, documentation duties may attach. As of October 2026, Colorado's SB26-189 replaced the 2024 Colorado AI Act, and from January 1, 2027 developers of automated decision-making technology must give deployers technical documentation [8]. A consultancy that builds the system may be treated as the developer, so keep dataset provenance records ready to hand over.

EU obligations that reach the client's model

For EU-facing clients, data provenance documentation is part of the deliverable, not an afterthought. High-risk AI systems must be trained on data sets subject to data governance and management practices under Article 10 [4]; as of October 2026 the high-risk application dates were reportedly moved by Regulation (EU) 2026/1744, which also amends Article 10 [9]. See applying EU AI Act data quality criteria.

A narrow fine-tune for one client does not usually make the consultancy a general-purpose AI model provider, but if the engagement does produce a general-purpose model, the provider must keep a copyright policy and publish a training-content summary under Article 53 [5]. Agree in the SOW who is the "provider" and who compiles that summary.

Warranties, indemnities and the client's risk review

The consultancy should not promise the client more than the data supplier promised the consultancy. If the supplier gives a limited title or non-infringement warranty, the consultancy's warranty to the client should be capped to match, or the client should hold the license directly and take the supplier's warranty itself. Do not assume supplier warranties pass through a sublicense; check the wording.

Expect the client's third-party risk management (TPRM) process to review the data source as well as the consultancy. Prepare a source pack per dataset: origin system, rights basis (ownership and consents), preparation method, de-identification method and allowed uses. Counsel on the client side will use the checklist in reviewing an AI data license as in-house counsel.

Pre-SOW checklist for the delivery lead

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

• Licensee chosen (client, consultancy or tri-party) and recorded in the SOW
• Contractor clause covers subcontractors, offshore delivery centers and named tools
• Model retention, retraining and successor-model rights confirmed in writing
• Derived assets (embeddings, adapters, eval sets, synthetic data) allocated
• Reuse position identical in MSA and data license
• De-identification standard and method documented per source
• Deletion certificate format agreed for project end
• Warranty and indemnity chain mapped from supplier to client

How SourceX fits a client engagement

SourceX sources operational datasets from US companies on request, such as support and sales histories, engineering records, documents and finance or legal workflows, and manages the licensing and ongoing purchases. Data is not held in stock, so a request describes the data, not the businesses, and does not guarantee a match. Every dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery, with diligence materials (source, rights, preparation, allowed use) prepared per dataset. You can describe a client project's data needs on the SourceX buyers page.

If you are an advisory firm considering selling your own data instead, see the consulting industry page and whether consulting firms can sell data to AI companies. For other buyer teams, start from the buyer teams hub or the AI data hub.

Sourcing data for a client AI project

SourceX finds US businesses that hold the operational data you describe, assesses data and licensing permissions, and agrees pricing and allowed uses in a license before anything is transacted. Personal details are removed or replaced before delivery, delivery runs through private, access-controlled workflows, and nothing is contracted until a supplier agrees. Start a buyer request.