Data clean rooms for AI training: when you can train without receiving raw records

Clean rooms exist because sensitive training data is hard to obtain: even de-identified datasets are often difficult to access, which pushes data holders toward controlled access models instead of copies [1]. For definitions, see the data clean room glossary entry and what is a data clean room?. This page covers the buyer decision for model training and evaluation, within the wider privacy and de-identification hub.

What a clean room actually changes in a data deal

A clean room changes who holds the copy, not whether a license is needed. In a delivered-copy deal the records land in your storage and the license governs what you do with them. In a clean room the supplier, or a neutral operator, keeps the records in an environment it controls, and you submit code or queries whose outputs pass through a release policy.

The mechanisms vary. Warehouse sharing such as BigQuery sharing gives the subscriber a linked dataset that can be queried but not modified, without copying the underlying tables [2], and VPC Service Controls rules govern how that shared data can be reached across project perimeters [3]. Open protocols such as Delta Sharing expose Delta Lake and Parquet tables over REST from cloud object storage [4]. Trusted execution environments go further: AWS KMS can release a decryption key only to a Nitro Enclave whose attestation measurements match the key policy, so the data is decrypted only inside approved code [5].

Federated approaches keep data with each holder and move training updates instead; domain-adaptive pretraining of language models has been studied in this setting [6]. Private set intersection lets two parties find overlapping records without exposing non-matches, a common first step for joins [8]. None of these is a clean room by itself, but commercial clean rooms often combine them with query restrictions and output review. The access models guide compares clean rooms with delivered copies, term copies and remote access.

Workloads clean rooms handle well and poorly

Clean rooms handle workloads well when compute is light and outputs are small and reviewable; they struggle when you need heavy GPU training and the full weights. Use this table before you spend weeks negotiating an environment that cannot run your job.

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

Evaluation is the cleanest fit, because nothing trained on the data needs to leave. The enclave and supplier-hosted evaluation guide covers that case in depth. For training, the friction usually comes from three places: the operator's environment lacks the accelerators your stack expects, your training code and dependencies must be audited before they run, and every iteration of hyperparameters passes through a review queue.

Why model export is the real negotiation

Model export is the central term because trained weights can carry the data out of the room. Fine-tuned language models can memorize and regurgitate training records, so a clean room that blocks raw-row export but lets unrestricted weights leave has moved the risk rather than removed it. The memorization and extraction risk guide explains how extraction attacks work and how to test for them.

Suppliers typically choose among four export postures. They can allow only metrics and aggregates out. They can allow weights out after a memorization test, such as canary insertion or extraction probes on known sensitive strings. They can require differentially private training, accepting the privacy-utility cost that DP imposes on language models [7]; the DP-SGD fine-tuning guide covers epsilon choices. Or they can keep the model hosted in the room and serve it to you by API only.

Ask which posture applies before you design the experiment. A team that plans LoRA fine-tuning and learns at the end that adapters cannot leave has wasted the compute budget.

Clean room vs data license: terms to negotiate

A clean-room arrangement still needs a written license, and its terms differ from a delivered-copy license in predictable ways. Treat the operator's platform terms and the supplier's data license as separate documents, and make sure they agree.

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

Clean-room term sheet checklist

• Permitted computations: named job types (SQL aggregates, evaluation, training of specified model classes), not "analytics."
• Output release policy: minimum aggregation threshold (for example k of at least 50 per cell), who reviews releases, and the review turnaround you can plan around.
• Model export: whether weights, adapters, embeddings or distilled models may leave; required tests before release; DP parameters if required.
• Derived artifacts: status of feature tables, synthetic data and logs created inside the room. See the synthetic data privacy guide.
• Code and dependency approval: who audits your container images and whether proprietary model code is visible to the supplier.
• Compute: GPU types and quotas available, who pays, and whether you can bring your own accelerators via an attested enclave [5].
• Logging and audit: query logs retained by whom, and whether the supplier can see your prompts, queries or evaluation sets.
• Term and teardown: what happens to your code, outputs and intermediate state when access ends.
• Jurisdiction and access location: where the environment runs and which personnel can reach it.

The last point matters for regulated data. The DOJ rule at 28 CFR Part 202 restricts and prohibits certain transactions that give countries of concern or covered persons access to bulk U.S. sensitive personal data, and access, not only transfer, is in scope [9]. A clean room reduces exposure but does not by itself settle that analysis; see the DOJ bulk sensitive data rule guide.

Privacy controls a clean room does not replace

A clean room limits where data goes, but the records inside still need de-identification appropriate to the use. Operators and suppliers' staff can see the data, your code can log it, and outputs can leak it through small cells or memorized text. Redaction tools reduce exposure but are not complete; Microsoft's Presidio project itself warns that its ML-based detection offers no guarantee of finding all sensitive information [10].

So ask for the same evidence you would for a delivered dataset: the de-identification method, the residual-risk assessment and sample checks. The de-identification evidence package checklist lists the documents. If you plan to join clean-room data with your own, review linkage and mosaic risk first, because joins are exactly what clean rooms make easy.

A decision path for procurement and platform teams

Choose a clean room when the workload is evaluation or analytics, the supplier will not release a copy, and your team can work inside someone else's environment. Choose a delivered, de-identified copy under license when you need GPU-scale training, many iterations and weights you own.

1. Write down the workload: model class, parameter count, expected epochs and GPU hours.
2. Write down what must leave: metrics, model weights, adapters, embeddings or nothing.
3. Ask the supplier which export posture it accepts and which compute the environment provides.
4. Run a pilot job in the room to measure turnaround per iteration before committing budget.
5. Compare the total cost and calendar time against a de-identified delivered copy with a license defining records, uses, term and delivery.

If step 3 rules out weights leaving, a clean room is an evaluation or analytics arrangement, not a training one. That is still valuable, for example to qualify a dataset before you license a copy. When you need the copy itself, you can also describe the data to SourceX as an alternative route.

Sourcing sensitive training data when a clean room will not fit

SourceX sources operational datasets from US companies on request, including support and sales histories, engineering records, documents, and finance and legal workflows; it does not hold stock, and a request does not guarantee a match. Every dataset is rights-reviewed and delivered under a license defining records, uses, term and delivery, with personal details removed or replaced before delivery and the method recorded. Describe the sensitive training data you need.