Keeping Your Data Roadmap Confidential While Sourcing

What a data request leaks about your model plans

A data request leaks more than most buyers expect, because suppliers can read strategy from specification details. The modality and domain reveal the capability you are building. Target volume and delivery date hint at the size and timing of a training run. A label schema can expose a product feature before launch, and a request for held-out records signals which benchmark you plan to report on.

Leakage also compounds across vendors. If you send the same RFP to eight suppliers, each sees one fragment, but brokers and consultants who talk to several of them can assemble the whole picture. A further failure mode is the supplier's own marketing: a sales deck that says "currently supplying a frontier lab with clinical dialogue" tells your competitors what you are doing even without your name.

Typical signals hidden in a request:

• Schema and labels: intent taxonomies, tool-call fields or rubric dimensions that mirror an unreleased feature.
• Volume and cadence: "2M conversations by March, then 200k per month" describes a training and refresh plan.
• Exclusions: asking a supplier to remove anything already public suggests you are building a contamination-free evaluation set (see how model evaluation teams protect private evaluation data).
• Language and region mix: a sudden demand for a specific locale often precedes a market launch.

Mutual NDA terms that protect the buyer side

A mutual NDA protects you only if its definition of confidential information covers your request, not just the supplier's records. Many supplier templates are one-way, written to protect sample data; a mutual structure protects both parties' information during evaluation [1]. The sample-side terms are covered in evaluation licenses and NDAs for dataset samples; this section is about the buyer's half.

Clauses to check or add:

• Definition: include specifications, schemas, volumes, timelines, evaluation criteria, the existence of discussions and your identity as the requester.
• Purpose limit: the supplier may use your information only to assess and respond to the request, not to build a competing offering or pitch other labs.
• Need-to-know list: name roles (deal lead, data engineer, counsel) rather than "employees and advisors" broadly.
• No publicity: no use of your name, logo or a recognizable description in marketing, case studies or investor materials without written consent.
• Residuals clause: strike or narrow it; a broad residuals right lets staff reuse anything "retained in unaided memory," which can include your schema.
• Return or destruction: require deletion of request documents when talks end, with written certification.
• Compelled disclosure: prompt notice before any legally required disclosure so you can seek protection.

These terms also matter legally. Under the Defend Trade Secrets Act, information qualifies as a trade secret only if the owner has taken reasonable measures to keep it secret [2]. Signed NDAs, marked documents and access logs are the record that you did.

Write requests at the capability level

A capability-level request describes the records you need and their properties, not the model or product they will serve. Suppliers need enough detail to check whether they hold the data and whether it can be licensed; they do not need your roadmap. Most of the specificity a supplier needs sits in fields, formats, volumes, date ranges and permissions.

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

Keep three items out of the first-round request: target metrics, launch dates and the names of other suppliers you are talking to. If you use a formal RFP, the AI training data RFP template can be adapted by moving the "intended use" section into a later, NDA-gated annex.

Stage what you disclose and who sees it

Staged disclosure releases each piece of information only when the supplier needs it to take the next step. That keeps the bulk of your strategy out of documents that circulate widely at the supplier during early qualification.

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

Allowed uses are the hardest item to keep vague, because the license must define them. Phrase them by category (training, fine-tuning, evaluation, retrieval) rather than by product. Ask the supplier to keep negotiation drafts in a data room with per-user access and download logging, not on forwarded email threads; the security review of a training data supplier covers how to test those controls.

Blind outreach through an intermediary

An intermediary lets a supplier answer a request on its merits before learning who is asking, which limits early leakage of your identity. A data intermediary sits between buyer and data holder, and a data licensing intermediary also manages the commercial and licensing steps.

Blind outreach has limits you should plan for:

• Suppliers screen buyers. Many data holders will not release records, or even confirm what they hold, without knowing the licensee and its intended use category.
• The license names parties. At contracting, your legal entity is a party, so identity is protected only during early stages.
• The intermediary holds your secrets too. Put it under the same mutual NDA terms, and ask how it separates requests from competing buyers.

Weigh these trade-offs against running outreach yourself; managed data sourcing vs an in-house function compares the two models.

Where confidentiality ends: transparency duties

Confidentiality during sourcing does not remove later disclosure duties, so negotiate with the eventual public record in mind. As of October 2026, California AB 2013 requires developers of generative AI systems made available to Californians to post documentation about their training data, including high-level information on dataset sources and whether data was purchased or licensed; disclosures were due 1 January 2026 [3]. In the EU, providers of general-purpose AI models must publish a summary of training content under Article 53(1)(d) of the AI Act [4], using the AI Office template published on 24 July 2025 [5].

These duties affect sourcing in two ways. First, your supplier may need to agree on how the dataset is described publicly, so add a clause on the wording of any disclosure. Second, information you hand to EU authorities is covered by Article 78, which requires them to protect confidential business information and trade secrets [6]; that protection does not extend to public summaries. For contract language that balances both pressures, see confidentiality clauses vs AI transparency duties.

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

Buyer confidentiality checklist

Use this list before any request leaves your team.

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

• Mutual NDA signed, covering specifications, the fact of discussions and your identity
• Residuals clause removed or limited; no-publicity clause added
• Request rewritten at capability level; metrics, dates and model names removed
• Project code name used in documents, file names and calendar invites
• Disclosure plan by stage, with a named recipient list at the supplier
• Data room with per-user access and download logs instead of email attachments
• Return-or-destroy certification scheduled at deal close or exit
• Public-disclosure wording (AB 2013, EU summary) agreed with counsel before signing

How SourceX handles requests

SourceX sources operational datasets from US companies on request and manages the commercial process, from licensing agreements to ongoing purchases. Buyers describe the data they need, not the businesses that might hold it, and SourceX looks for US companies that hold it. The process runs Find, Assess, Agree, Transact and Manage, and nothing is contracted until a supplier agrees.

Delivery runs through private, access-controlled workflows, never email attachments, and only after an executed agreement and supplier approval. You can start with a capability-level description on the buyer request page. For the wider process, see the AI training data procurement hub.

Source data without exposing your roadmap

Describe the records, fields and rights you need, and SourceX will look for US companies that hold that data; a request does not guarantee a match. Every dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery. Describe the data you need.