Rights and contracts
Will your company be named in an AI training data disclosure?
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
Your company could be named in an AI training data disclosure, but it may instead be described only by industry or category. Laws such as California AB 2013 and the EU AI Act ask developers to summarize training sources. The decisive lever is your license: agree in advance how your records are described and who may name you.
Key takeaways
- Transparency laws put disclosure duties on AI developers, but their summaries can describe or name suppliers.
- Legal summaries are one route among several; press releases, model documentation, litigation and audits are others.
- A license can control descriptions, require notice and ban publicity, but it cannot override a legal duty.
- Some suppliers want to be named, so decide your preference before the term sheet, not after.
Will your company be named?#
Your company is most likely to be named publicly if a developer concludes that a law requires it to identify sources at that level, or if your contract lets the developer name you for its own reasons. Disclosure laws generally ask for summaries, so a description by industry or category, such as enterprise support records, is also a possible outcome. Neither result is automatic.
For a CEO, the question is more reputational than legal. Customers, employees and competitors can read a developer's documentation, and a description that points to your company can prompt questions you would rather answer on your own terms. Planning the wording costs far less than reacting to it.
Which rules ask developers to describe training sources?#
California AB 2013 and the EU AI Act are the rules that most often ask developers to describe training sources, and both place the duty on the developer rather than on you. Their details differ, and counsel should check the current text and guidance for any specific system.
Voluntary statements often say more than any statute requires. A developer promoting the quality of its training data has a commercial reason to mention well-known sources, which is why publicity terms matter as much as legal ones.
| Source of disclosure | Who discloses | What it could say about you | Where your lever sits |
|---|---|---|---|
| California AB 2013 | Developers of generative AI systems made available to Californians | Dataset sources or owners, whether data was licensed, whether it includes personal information | Agreed description and advance notice |
| EU AI Act | Providers of general-purpose AI models offered in the EU | A public summary of training content, with detail set by EU guidance | Agreed description and cooperation terms |
| Developer's own documentation | Any developer that publishes model or dataset documentation | Whatever the developer chooses to say | Publicity and confidentiality clauses |
Where else your name could appear#
Beyond statutory summaries, your name could appear in model documentation, announcements, litigation, regulator inquiries and the buyer's own diligence records, and those routes can be more specific. A supplier's name can surface wherever a developer has to explain where its data came from.
Structured provenance records are a growing route. The Data & Trust Alliance's Data Provenance Standards organize dataset metadata into Source, Provenance and Use groups, which the specification describes as needed to enable proper dataset selection for AI model training. Buyers that adopt such standards will hold detailed records about each supplier, even when their public summaries stay general.
- Model and dataset documentation: data cards and technical reports that describe training sources.
- Announcements: a developer promoting a new data relationship in a press release or blog post.
- Litigation: lawsuits over training data can require production of license agreements.
- Regulator inquiries: authorities can ask developers for supplier lists and contracts.
- Investor and acquirer diligence: the developer's own financings and deals put its data contracts under review.
- Provenance metadata: machine-readable records of dataset sources kept by the buyer.
How specific could a description of your records get?#
A description of your records can sit anywhere on a ladder from your full company name to a broad category shared with many other sources. Where it lands decides how easily outsiders can connect a disclosure to you, and each step down the ladder lowers that risk.
Pick the lowest rung that still lets the developer meet its obligations, and test it with a simple question: could a competitor or a customer who knows your market guess that the description means you? If the answer is yes, broaden the industry, region or record wording until it no longer does.
| Level | Example wording | Identification risk |
|---|---|---|
| Named | Records licensed from a named company | Certain |
| Identifying description | Dispatch records from a family-owned HVAC contractor in one metro area | High in a small market |
| Industry description | Field service records from a US home services company | Moderate |
| Category only | Licensed enterprise operational records | Low |
| Aggregated | Licensed records from multiple business sources | Lowest |
The contract levers you control#
The contract levers you control are an approved description, identity confidentiality, advance notice, a publicity ban, aggregation and protective-order duties, and they work best when agreed at the term sheet stage. None of them can stop a disclosure the law requires, but together they decide how you are described and whether you hear about it first.
Make sure the levers survive termination. Disclosure duties and litigation can arise long after delivery, and a publicity ban that expires with the license protects you only for the easy years.
| Lever | What it does | Limit |
|---|---|---|
| Approved description | Fixes the words used for your dataset in any required summary | Must still satisfy the law |
| Identity confidentiality | Treats your name and the deal as confidential information | Usually yields to legal compulsion |
| Advance notice | Gives you time to review and comment before publication | Cannot delay a mandatory deadline |
| Publicity ban | Prohibits press releases, case studies and logo use without consent | Covers voluntary statements only |
| Aggregation | Lets the developer describe you only alongside other sources | Depends on how many sources the developer uses |
| Protective orders | Requires the developer to seek confidential treatment in litigation | The court decides |
Should you want to be named?#
Whether you should want to be named depends on your customers and your market, and some suppliers do choose it. Being publicly identified as a source of high-quality records can signal expertise, help recruiting or attract later buyers. Others prefer anonymity because their customers are wary of AI, or because competitors could infer business details from the description.
Decide the preference before negotiating, write it into the license and brief internal teams. If customers may recognize their own interactions in a description, plan whether to tell them. Sales and support leaders should know the agreed answer if someone asks.
Illustrative: a freight brokerage chooses a generic description#
Illustrative: a fictional freight brokerage licenses years of load tenders, carrier exception notes and claims resolutions from McLeod and its email archive to a developer building logistics agents. The developer's draft lets it list the brokerage by name in model documentation.
The CEO worries that shippers will assume their own load data was shared, even though shipper identities were removed in preparation. The parties agree that any statutory summary will describe the source as freight brokerage operations records from a US company, that the developer will give advance notice of any disclosure naming the brokerage, and that no announcement will mention it. The CEO briefs the largest shippers anyway, using the agreed description.
How SourceX handles disclosure terms#
SourceX treats a supplier's disclosure preference as part of the Approval step of the SourceX five-step transaction, decided alongside permitted use and release authorization rather than left for the buyer's lawyers to propose.
The SourceX Evidence Packet gives the developer documented provenance, licensing rights and a privacy record to describe the dataset from, which lowers the temptation to fill gaps with identifying detail. Any wording that would name the supplier is put to the supplier before the license is signed.
Frequently asked questions
Does a confidentiality clause keep our name out of every disclosure?
Not every one. Most confidentiality clauses allow disclosure required by law, court order or a regulator. A clause still helps: it makes voluntary naming a breach and usually requires the developer to limit what it discloses to what is legally required.
Will customers find out if we are described generically?
A generic description makes identification less likely but not impossible, especially in a niche industry. If the description combined with your region and record type could point only to you, consider broader wording or aggregation with other sources.
Can we be named years after the license ends?
Possibly. Disclosure duties can attach to systems trained on your data long after delivery, and litigation can bring old contracts back into view. Confidentiality and publicity clauses should survive termination for that reason.
Does using a transaction platform hide our identity from the buyer?
Not as a rule. Buyers generally need to know who the supplier is to check rights and provenance before signing. Public disclosure is a separate question, controlled by the license terms rather than by who arranged the transaction.
Should our privacy notice mention data licensing?
It may need to, depending on what the records contain, how they were prepared and the laws that apply. That is a question for privacy counsel, assessed deal by deal, and it is separate from whether your company name appears in a developer's disclosure.
Sources
- The Data & Trust Alliance's Data Provenance Standards (version 1.0.0 specification) define dataset metadata in three groups: Source, Provenance and Use. The specification says this metadata is needed "to enable proper dataset selection for AI Model Training." Source
Related resources
- QuestionDo AI labs buy legal documents?
- InsightCan a 3PL license warehouse video to robotics and AI developers?
- InsightMCP and your business data: is connecting AI tools the same as licensing?
- InsightCan a buyer release open-weight models trained on your data?
- SolutionHow AI developers source data
- IndustryBPO & contact centers data
See if your company qualifies
A short company assessment. No data uploads are needed.