Rights and contracts
Access-only data licenses: letting buyers train without a copy
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
An access-only data license lets a buyer use your records for training or evaluation inside an environment you control, without ever receiving a copy. It gives the supplier stronger control over retention and audit, but buyers accept it less readily for large training runs. It suits sensitive records, evaluation work and archives too large to move.
Key takeaways
- In an access-only license the records stay in an environment the supplier controls, and only approved outputs leave.
- The contract must define what may leave: model weights, adapters, gradients, metrics or evaluation scores only.
- Weights trained inside the environment can still carry information from the records, so outputs need review.
- Buyers often prefer copies for large training runs, so access-only fits evaluation, fine-tuning and sensitive data best.
- The supplier takes on infrastructure, uptime and security duties that a transfer license avoids.
How an access-only data license works#
An access-only data license grants the right to run approved computation on the supplier's records without granting possession of them. The buyer brings code or a model to the data; the data never travels to the buyer's infrastructure.
Several architectures fit the description. The most direct is a workspace in the supplier's own cloud account where the buyer's training or evaluation jobs run under the supplier's controls. Others include a third-party clean room, query access through an API that returns only results, and federated learning, where model updates are computed locally and only those updates leave.
- Supplier-hosted compute: the buyer's containers run in a supplier-controlled account with egress blocked.
- Third-party clean room: a neutral environment where both sides' policies are enforced.
- Query or API access: the buyer submits jobs and receives approved results only.
- Federated learning: training happens where the data sits and only model updates move.
Transfer license versus access-only license#
A transfer license and an access-only license differ mainly in who holds the records after the deal starts, and most other differences follow from that. The comparison below is what a CTO and a general counsel usually work through together before offering either model.
| Dimension | Transfer license | Access-only license |
|---|---|---|
| Where the records sit | Buyer's infrastructure, as a delivered copy | Supplier-controlled environment |
| Supplier control after delivery | Contractual only | Technical and contractual |
| Verifying deletion at term end | Relies on the buyer's certificate | Supplier shuts off access |
| Audit | On request, often limited | Continuous logs of every job and query |
| Exposure if the buyer is breached | Records may be exposed | Records not held by the buyer |
| Supplier effort and cost | Preparation and one handover | Preparation plus hosting, support and uptime |
| Buyer acceptance | Broad, especially for large training runs | Narrower; strongest for evaluation and fine-tuning |
| Fit for very large archives | Encrypted drives or staged transfer | Strong, because nothing moves |
What leaves the environment is the real contract question#
What leaves the environment is the central contract question in an access-only license, because every permitted output is a channel through which information from the records can escape. Model weights trained on the records can memorize rare passages. Gradients and federated updates can leak details about individual records. Even evaluation logs and debugging samples can contain verbatim text.
The usual answer is a tiered release policy. Evaluation scores and aggregate metrics leave freely; adapter or model weights leave only after memorization testing; samples and logs leave only after human review or not at all. Privacy-enhancing techniques help at the margins: the Data Provenance Standards' list of privacy-enhancing tools includes differential privacy, federated learning, homomorphic encryption and secure multi-party computation, and a contract can name which ones apply.
Contract mechanics to write down#
Contract mechanics for an access-only license cover the environment as much as the data, and a missing term usually becomes an operational dispute rather than a legal one. Write these down before the first job runs.
| Term | What to settle |
|---|---|
| Access scope | Named users, authentication method and the environments they may reach |
| Permitted operations | Training, fine-tuning, evaluation or querying, and on which record sets |
| Prohibited actions | Bulk export, screenshots, re-identification and copying records into prompts or code |
| Release policy | Which outputs may leave, who reviews them and on what tests |
| Logging and audit | What is logged, who can see the logs and how long they are kept |
| Compute and cost | Who provides and pays for compute, storage and support |
| Availability | Maintenance windows, support hours and what happens during outages |
| Buyer code | Responsibility for malicious or faulty code the buyer brings in |
| Term end | Access shutdown, treatment of released weights and survival of restrictions |
What the supplier's IT team has to run#
The supplier's IT team has to run a small production service for the life of an access-only license, which is the main cost a transfer license avoids. Before offering the model, the CTO should confirm the team can staff it without pulling people off core systems, and that the environment can be built separately from production ERP, CRM or engineering tools.
Most of the work is front-loaded. Once the environment, release policy and logging are in place, routine operation is mainly approving outputs, watching usage and responding to buyer support requests.
- Build an isolated account or project with no network path to production systems.
- Load the prepared records, not raw exports, and fix them to a version that matches the license.
- Set up identity and access for named buyer users, with multi-factor authentication.
- Block general internet egress and route permitted outputs through a review queue.
- Turn on job, query and access logging, and decide who reviews the logs.
- Write a shutdown runbook for term end, suspension and security incidents.
When buyers accept access-only, and when they push back#
Buyers accept access-only terms most readily when the work is evaluation, benchmarking or fine-tuning a model on a focused set of records, and least readily for large training runs. Training at scale depends on the buyer's own accelerators, data pipelines and the freedom to iterate across many runs, which is hard to replicate in someone else's environment.
A hybrid often resolves the gap. The supplier delivers a de-identified copy of lower-risk records under a transfer license and keeps sensitive or very large record sets behind access-only terms. That way the buyer trains where it needs to, and the supplier keeps its most sensitive material in its own hands.
Illustrative example: a manufacturer keeps quality records at home#
Illustrative: a fictional maker of industrial pumps holds many years of nonconformance reports, CAPAs and maintenance logs in its QMS and MES, along with large volumes of inspection images. Customer-owned designs are already excluded. Its IT team is unwilling to ship the image archive, and an AI developer wants to test a quality-reasoning model against the records.
The manufacturer offers an access-only workspace in its own cloud account. The developer's evaluation harness runs there; only evaluation scores and, after memorization testing, a fine-tuned adapter leave the environment. The developer accepts the terms for evaluation but declines them for broader training, so the manufacturer separately prepares a smaller de-identified set of NCR and CAPA text under a transfer license.
How SourceX handles access-only delivery#
SourceX never hosts multi-terabyte datasets: large records stay in the supplier's own storage or ship on encrypted drives, and access-only arrangements extend that principle to training and evaluation. The handover method is recorded at the Delivery step of the SourceX five-step transaction.
The SourceX Evidence Packet records the permitted use, including which outputs may leave the environment, alongside provenance, licensing rights, the privacy record and the supplier's release authorization.
Frequently asked questions
Does access-only remove the need to de-identify records?
No. The buyer's engineers may still see records while building and debugging jobs, and released outputs can carry information from the data. Preparation that removes personal and confidential details remains necessary, though the level may be set differently than for a delivered copy.
Who pays for the compute in an access-only license?
It is negotiated. Buyers often pay for the compute they consume, either directly in their own billing account linked to the environment or through a fee that covers hosting. Write down who provides accelerators, storage and support, and what happens if jobs exceed agreed capacity.
Can the supplier cut off access during the term?
Only as the contract allows. Most licenses permit suspension for security incidents or breaches of the release policy, with notice and a cure period for lesser issues. Without a clear suspension clause, switching off access can itself become a breach.
Is a data clean room the same as an access-only license?
A clean room is one way to deliver an access-only license. Clean rooms were popularized for joining marketing data without either side seeing the other's raw records, and some now support model training. The license terms still define the permitted use and outputs.
What security controls should the environment have?
At minimum, strong authentication, blocked or tightly controlled egress, full job and access logging, encryption at rest and in transit, and separation from the supplier's production systems. Buyers may ask for evidence of these controls, so document them before offering access.
Sources
- The Data Provenance Standards' Privacy Enhancing Tools code list includes data anonymization, encryption, masking, minimization, redaction, differential privacy, federated learning, homomorphic encryption, k-anonymity, l-diversity, pseudonymization, secure multi-party computation, t-closeness and tokenization. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.