What Is Training Data Provenance, and Why Buyers Now Ask for It
30 min readAIData.Broker research17 Oct 202646 records, 41 sources
Training data provenance is the documented history of a dataset: where each part of it came from, the rights and consents it was collected under, and everything that was done to it before it reached a model. Buyers ask for it now because the law and the courts have started to sort training data by its origin. In Bartz v. Anthropic a federal judge held that training on books was fair use but sent the pirated library copies to trial, and the case then settled for $1.5 billion. The EU AI Act requires every provider of a general-purpose model to publish "a sufficiently detailed summary about the content used for training", and California's AB 2013 has required developers since 1 January 2026 to post "the sources or owners of the datasets" and whether they were purchased or licensed.
A developer can only answer those questions about its models if the companies it licenses data from can answer them about their data. That is why provenance has moved from an academic idea into buyers' contracts, where holders now warrant lawful collection and, in one buyer's published terms, refund every payment if the description of the data proves materially wrong. This guide is for a company that holds data and is weighing a licence, and for anyone trying to understand what a buyer means when it asks "where did this come from?" It defines provenance, explains each reason buyers ask for it, sets out the standards that exist, lists what a provenance record for a lot contains, shows how a holder documents one, and ends with how this site keeps provenance for its own facts.
AIData.Broker acts as the holder's agent: the holder licenses its data to the buyer itself, and we do not take ownership of it. The provenance record described here is the one we ask a holder to settle before any buyer sees anything.
This guide is research from public sources, not legal advice.
Contents
- What training data provenance means
- Why buyers ask for it now
- The standards that exist
- What a provenance record for a lot contains
- How a holder documents it
- Worked example: how this site keeps provenance for its own facts
- Questions people ask
- What this means for you
What training data provenance means
The word comes from the art market, where a painting's provenance is the chain of owners back to the artist. For data the idea is the same but there are more links in the chain. A support ticket was written by a customer and an agent, stored in a help desk run by a software vendor under that vendor's terms, governed by the privacy policy in force when the customer wrote it, exported by the company, filtered, de-identified, and packaged into a lot. Each step either preserves the right to use the ticket for training or breaks it. Provenance is the record of those steps, kept well enough that someone else can check it.
It helps to split provenance into four questions, because buyers, regulators and standards ask all four.
- Origin. Which system the data came from, who created it, and over what period. A dataset of emails from a company's own mail server is different from the same emails pulled out of a customer's account.
- Rights. Under what terms it was collected: the privacy notice, the contracts with customers and vendors, the consents of the people in it, and any licence from a third party for material the company did not create.
- Processing. What was done to it: cleaning, filtering, de-identification, rewriting, sampling, and what was deliberately left out.
- Custody. Who has held it, and under what agreements, from the moment it left the source system to the moment it reached the buyer.
Two neighbouring terms cause confusion. Data lineage is the engineering view of the same history: which pipeline produced which table from which inputs. It answers "how was this file made?" but usually not "were we allowed to?" Attribution is giving credit to a creator, which matters for licences that require it but says nothing about consent or processing. Provenance in the sense buyers now use includes both and adds the legal layer. The best-known proposal for writing it down, Datasheets for Datasets by Gebru and colleagues, proposes that every dataset "be accompanied with a datasheet that documents its motivation, composition, collection process, recommended uses, and so on", on the model of the datasheets that accompany electronic components.
Provenance is not the same as quality, and it is not a guarantee. A dataset can be well documented and still contain errors, and a perfect-looking record can be false. What provenance does is make claims about the data checkable: a buyer can test a sample against the record, a regulator can follow it, and a court can see who knew what. That is exactly what the developments below reward.
Why buyers ask for it now
Until recently, much training data had no provenance worth the name. It was crawled, mirrored and reshared, and the record of where it came from was lost on the way. An audit of widely used text datasets by the Data Provenance Initiative found "frequent miscategorization of licenses on widely used dataset hosting sites", with licences often missing altogether, and called it "a crisis in misattribution and informed use." Four forces have since made that gap expensive.
The lawsuits turned on where the data came from
The most consequential ruling so far did not condemn AI training as such. In June 2025 Judge Alsup granted summary judgment for Anthropic "that the training use was a fair use", and in the same order sent to trial "the pirated copies used to create Anthropic's central library." The difference between the two was provenance: books bought and scanned on one side, copies downloaded from pirate sites on the other. The case then settled. The settlement of $1.5 billion plus interest came to about $3,000 for each work, and the court gave final approval in July 2026.
Other cases point the same way. In Kadrey v. Meta the court found for Meta on fair use on the record before it, but later let the authors add a claim over downloading books from shadow libraries by BitTorrent. The US Copyright Office's report on generative AI training said that "the copying of expressive works from pirate sources in order to generate unrestricted content that competes in the marketplace, when licensing is reasonably available, is unlikely to qualify as fair use." And where training was held not to be fair use, as in Thomson Reuters v. Ross, the source was a competitor's own material used without a licence. Several music cases ended in settlements that turned unlicensed models into licensed ones: UMG and Udio agreed a licensed platform, and Warner Music and Suno agreed that Suno would launch licensed models.
The lesson buyers drew is practical: a model trained on data of unknown origin carries a liability that cannot be removed later, so they want the origin settled before they pay. Our guide to fair use and AI training covers the rulings in depth, and every case we track is on the cases page.
The EU AI Act requires a public summary and technical records
The EU's AI Act puts provenance duties on providers of general-purpose AI models, the labs that train foundation models and place them on the EU market. Three of them matter here. Under Article 53(1)(d) a provider must "draw up and make publicly available a sufficiently detailed summary about the content used for training of the general-purpose AI model, according to a template provided by the AI Office." Under Article 53(1)(c) it must have a policy to comply with EU copyright law, "in particular to identify and comply with" opt-outs from text and data mining. And under Annex XI its technical documentation for the AI Office must include "information on the data used for training, testing and validation, where applicable, including the type and provenance of data and curation methodologies," and "how the data was obtained and selected." The obligations have applied since 2 August 2025, with models already on the market before that date given until 2 August 2027. The Digital Omnibus adopted in July 2026 did not change Article 53.
The public summary is deliberately broad. The Act's recitals say it should be "generally comprehensive in its scope instead of technically detailed", giving as an example listing "the main data collections or sets that went into training the model, such as large private or public databases or data archives." The Commission's explanatory notice to the template says it "does not require disclosure of the details for the specific data and works used to train the model", though providers may disclose more voluntarily. So a holder's name will not necessarily appear in a lab's public summary, and a licence can say whether it may. But the technical documentation behind the summary, and the copyright policy, need the lab to know the type and provenance of each source, and the lab can only know that if its suppliers documented it.
For AI systems classed as high-risk, the Act goes further. Article 10(2) requires training data to be governed by practices covering "data collection processes and the origin of data, and in the case of personal data, the original purpose of the data collection," and "relevant data-preparation processing operations, such as annotation, labelling, cleaning, updating, enrichment and aggregation." That is a provenance record by another name.
California's AB 2013 asks for sources, licences and processing
California's Generative Artificial Intelligence Training Data Transparency Act, AB 2013, is now Civil Code section 3111. On or before 1 January 2026, and each time a new or substantially modified system is released to Californians after that, the developer of a generative AI system or service released on or after 1 January 2022 must post documentation on its website about the data used to train it. The documentation includes a high-level summary of the datasets, covering twelve topics. Several of them read like the fields of a provenance record: "(1) The sources or owners of the datasets", and, as the federal court quoted the statute, whether the datasets include copyrighted material, "whether the datasets were purchased or licensed by the developer," whether they include personal information, "whether there was any cleaning, processing, or other modification to the datasets by the developer," and "the time period during which the data in the datasets were collected."
The law has survived its first challenge. xAI sued to block it; in March 2026 the court denied a preliminary injunction, finding that even if "high-level summary" is "not the picture of clarity standing alone, it is followed by a precise list of information to be included." The court did not decide how specific "sources or owners" must be. Early disclosures have stayed general, describing categories such as data from third-party partners rather than naming each licensor, as one law firm reported of the first filings by two large labs. For a holder, the point is the same as under the EU Act: a developer that must state whether each dataset was licensed, whether it holds personal information, what processing was done and when it was collected, will ask its suppliers for exactly those facts.
Buyers' own contracts now put provenance into warranties
The most direct pressure comes from the licences themselves. Buyers that pay for company records now ask holders to promise, in writing, the things a provenance record documents, and to carry the cost if the promise fails. Holders commonly give warranties of title, authority, lawful collection, non-infringement and privacy compliance, and buyers ask for representations that consents were obtained and no opt-out has been invoked. Our research has read 65 clauses from buyers' published terms, and the pattern is consistent.
| Buyer or service | What its published terms ask the holder to stand behind |
|---|---|
| micro1 | If the data manifest proves materially inaccurate, nothing is payable and the holder refunds what it was paid, even after acceptance; the holder also promises it has not licensed the same data on similar terms to anyone else |
| SimpleClosure AssetHub | The holder warrants it gave every required notice and obtained every required consent from employees, contractors, customers, investors and vendors in the data |
| Defined.ai | Data must be "ethically sourced, including proper consent, documentation, and the right to commercialize" |
| Kled | A contributor who withdraws consent refunds what it was paid for that content |
| Grepped | Tells its own buyers it offers "Clear provenance. Every source is licensed under a signed agreement with the data owner." |
| Mercor | Its intake asks the holder to confirm it owns the materials or may share them without restrictions |
Two features of these terms make provenance urgent rather than tidy. Payment often waits for it: one buyer lets the holder invoice only after it has accepted the data in writing, and acceptance is where a buyer checks the data against its description. And training cannot be undone: the same buyer's deletion clause does not require it to delete or retrain any model, and a law firm advising holders warns that once data trains a model "it cannot practically be pulled back out". If the provenance is wrong, the remedy is money, not a recall. For the clause-by-clause view, see our guide to data licensing agreements and the licence terms page.
Consent now changes the price
Provenance also shows up in what people are paid. Where book authors had to opt in to an AI licence, the publisher paid them far more per title than where inclusion was the default and authors could only opt out. A licensor that can show each contributor's consent, title by title, can sell what one without that record cannot. Our what labs buy page shows how buyers weigh records that connect and can be traced.
The standards that exist
No single standard governs training data provenance, and none is required by law in the form a holder would use. What exists is a handful of documentation formats and audits, each built for a different job. A holder does not need to adopt any of them wholesale; it helps to know what each asks, because buyers borrow their vocabulary.
Datasheets for Datasets
The idea that a dataset should come with a standard description began with a paper by Timnit Gebru, Jamie Morgenstern, Briana Vecchione, Jennifer Wortman Vaughan, Hanna Wallach, Hal Daumé III and Kate Crawford, first posted in 2018 and revised in 2021. Its premise is that "the machine learning community currently has no standardized process for documenting datasets", and its proposal is a set of questions the creator answers about the dataset's motivation, composition, collection process, preprocessing, recommended uses, distribution and maintenance. The questions are the strength: they make the creator say who is in the data, how it was gathered, whether consent was sought, and what was removed. The EU AI Act echoes the term for high-risk systems, whose technical documentation must describe data requirements "in terms of datasheets", including information about the datasets' provenance and how the data was obtained. A datasheet is also what we ask a holder to write for a lot, through our datasheet tool.
The Data Provenance Initiative
The Data Provenance Initiative is a group of researchers who audit the datasets AI is trained on. Its first large audit, by Shayne Longpre, Robert Mahari and co-authors from law and machine learning, set out to "systematically audit and trace" text datasets used to fine-tune language models, building tools "to trace the lineage of these datasets, from their source, creators, series of license conditions, properties, and subsequent use." It found licences frequently missing or wrong on popular hosting sites. A second audit, Consent in Crisis, looked at the websites behind major web corpora and found "a rapid crescendo of data restrictions from web sources" in a single year, through robots files and terms of service. The group now describes itself as public measurement infrastructure for AI data. Its work is the evidence for why buyers distrust data whose origin they cannot see, and why the open web is no longer a free substitute for licensed records ( our guide to scraping and the AI crawler census cover that side).
The Data & Trust Alliance's Data Provenance Standards
The closest thing to a business standard comes from the Data & Trust Alliance, a group of large companies that use data and AI. Its Data Provenance Standards, version 1.0.0, were co-developed by the Alliance's member organisations from use cases across many industries, and group their metadata fields under three headings: Source, Provenance and Use. The fields include the dataset's issuer and source, the data's origin geography, the range of dates for data generation, the method of collection, the location of consent documentation, whether privacy enhancing technologies were applied, processing and storage geography, the licence to use, the intended use, and whether proprietary data is present. The Alliance publishes a generator that writes the metadata as a file. For a holder, the field list is a useful checklist: it is what a corporate buyer's data team may expect to see filled in.
C2PA Content Credentials for media
For pictures, video and audio, provenance can travel inside the file. The Coalition for Content Provenance and Authenticity (C2PA) publishes an open technical standard for "publishers, creators and consumers to establish the origin and edits of digital content," called Content Credentials. In its specification, a set of signed statements about an asset (how it was captured, how it was edited, what it was made from) is bound into a C2PA Manifest, and "the set of C2PA Manifests, as stored in the asset's Content Credential, represent its provenance data". The specification also allows a manifest to cover a collection of files: "It is possible to describe each folder of the training data set of an AI/ML model by having each folder be a separate ingredient of the complete training data set's manifest." The standard is careful about its limits: it does not judge whether provenance is good or bad, only whether the statements can be validated and are free from tampering. A holder of footage or photo archives with Content Credentials can prove origin and edits file by file; one without them relies on its own records ( our pages on video and images cover those markets).
How they compare
| Standard | Who publishes it | What it documents | Where it helps a holder |
|---|---|---|---|
| Datasheets for Datasets | Gebru and co-authors (research paper) | Motivation, composition, collection, preprocessing, uses, distribution, maintenance | The narrative description of a lot that a buyer reads first |
| Data Provenance Initiative | Researchers auditing AI datasets | Sources, creators, licence conditions and later use of public datasets; web consent signals | Evidence of why buyers want licensed, documented data |
| Data Provenance Standards | Data & Trust Alliance (companies) | Metadata fields in three groups: Source, Provenance, Use | A field checklist and machine-readable metadata for a lot |
| C2PA Content Credentials | Coalition for Content Provenance and Authenticity | Signed manifests of an asset's origin and edits, also for collections | File-level proof for images, video and audio |
| EU AI Office template | European Commission | The public summary of a model's training content | What a lab will say publicly about its sources |
| California AB 2013 | California law | Twelve topics about a model's training datasets | What a lab must post, and so what it will ask suppliers |
What a provenance record for a lot contains
A lot is a defined body of records offered to buyers: one company's tickets and chats for a period, say, or a repository with its history. A provenance record for a lot answers the four questions (origin, rights, processing, custody) for that lot specifically, with evidence for each answer. It does not need to be long. It needs to be specific enough that a buyer's counsel can test it, and honest about what is unknown.
The table sets out the elements, what each records, the evidence that backs it, and who asks for it. The last column shows why the record is worth building once and well: the same facts answer a buyer's due diligence, the developer's AB 2013 posting and its EU documentation, and the holder's own warranties.
| Element | What it records | Evidence | Who asks for it |
|---|---|---|---|
| Source systems | Each system the records came from, whose account it was, and how they were exported | Export logs, admin settings, the vendor's terms at the time | AB 2013's sources or owners; the AI Act's type and provenance |
| Collection period | The first and last dates of the records, and any gaps | Export metadata, a count of records by month | AB 2013's time period during which the data were collected |
| Legal basis and consents | The privacy notice, terms and employee policies in force when the data was created; any consents; recording notices | Dated copies of the policies, consent logs | Buyers' consent representations; the AI Act's original purpose for high-risk uses; our prior promises check |
| Licences in | Material the holder did not create (bought lists, stock media, reports, other companies' documents) and the terms it came under | Contracts and licence records, or proof it was removed | AB 2013's purchased or licensed and copyright topics; our third-party data check |
| Processing and de-identification | Cleaning, filtering, de-identification method and version, and its measured result | An evidence file, an expert's or certifier's report | AB 2013's cleaning, processing, or other modification; the AI Act's data-preparation operations; our evidence file rule |
| Exclusions | What was taken out and why: privileged and HR material, other companies' confidential documents, health or children's data, people who opted out | An exclusion list with reasons | Buyers' warranties; our confidentiality and privilege checks |
| Chain of custody | Who held the data from export to delivery, where it was stored, and every transfer | Transfer records, file hashes, agreements with any processor | Buyers' acceptance testing; the manifest a buyer checks the delivery against |
| Prior licences and exclusivity | Earlier licences of the same records, and any exclusivity granted | Contracts | Buyers' prior licence warranty; exclusivity terms |
| Authority to sign | Who may license the records for the company: the board, an officeholder in a wind-down, a lender's consent where needed | Resolutions and consents | Our board, insolvency and lender checks |
Three points about this list are easy to get wrong. First, the policies that matter are the old ones: a privacy notice changed last month does not cover data collected under the version before, and the FTC has warned that quietly changing terms to permit new uses of data already collected may be unfair or deceptive. Keep dated copies of every version. Second, exclusions are part of provenance, not an admission of weakness: a list of what was removed and why tells a buyer the rest was looked at. Third, custody includes the holder's own vendors: a scrub run by a processor, or a copy kept by a broker, is a link in the chain, and some services delete the originals once they have processed them ( as one broker's terms say), which leaves the holder with no way to check the delivery afterwards unless it kept its own record.
How a holder documents it
Most companies already hold the facts a provenance record needs; they are scattered across contracts, admin consoles, old policy pages and people's memories. Documenting provenance is the work of gathering them into two files before any buyer is approached: the rights file and the datasheet.
The rights file is the holder's private record of every rights question and its answer, with the evidence. Buyers' counsel ask a predictable set of questions, and our checklist has 26 of them, 15 of which stop a sale until they are answered: who owns the records, what customer contracts and software vendors' terms allow, what the privacy notices said at the time, whether employees and call participants were told, whether third-party material or health data is inside, and who has authority to sign. The rights file holds the answers and the documents behind them. It is not shown to buyers whole; it is what lets the holder give warranties it can stand behind, and qualify the rest by what it disclosed ( the usual structure of holder warranties).
The datasheet is the description a buyer reads: what the records are, where they came from, the period, the volume and composition, what was done to them, what was left out, and what uses they suit. It draws on the rights file but says only what can be shared under an NDA, and it is written so that a buyer can test a sample against it. Our datasheet tool builds one from a holder's answers, and our readiness check shows which answers are still missing.
Most lots on offer today are not there yet
The gap between what buyers ask for and what holders can show is wide. Among the lots offered through brokers whose catalogues state who holds the rights, only 29% say the holder holds them with nothing left to confirm; 62% are held with conditions still to confirm or not confirmed at all ( the lot index shows each one). A holder that arrives with its provenance settled is, for now, unusual, and that is an advantage in a negotiation: it shortens due diligence and removes the buyer's reason to discount.
Step by step
- List the systems. Every place the lot's records live: help desk, chat, mail, code hosting, CRM, file storage. For each, note the account owner and the vendor's export and AI terms ( Slack, Microsoft 365, Google Workspace, Zendesk and GitHub each have a page).
- Fix the period. Decide the date range of the lot and record the first and last dates actually present.
- Recover the old promises. Collect every version of the privacy notice, terms of service and employee policies in force during the period. If the company's own copies are gone, a public web archive may hold them.
- Find what is not yours. Identify bought, licensed and third-party material and either document its licence or take it out.
- Settle consents. Record what notice employees, customers and call participants received, and remove people or recordings the notice does not cover ( our guide to employee emails and chats covers staff data).
- De-identify and keep the evidence. Run the de-identification on your own systems, keep the method, version, sample review and measured result, and keep any re-identification key yourself ( our standard; for health data, the HIPAA guide).
- Write the exclusion list. Everything removed, and why.
- Record custody. Hash the exported files, note where they are stored and who can reach them, and log every transfer.
- Write the datasheet from the above, and keep the rights file behind it.
- Keep it current. A provenance record describes one version of the data. If the lot is refreshed, or a buyer asks for a new slice, the record moves with it.
Example: one system's entry
Example. A 40-person business software company is closing and plans to license its support history. Its provenance entry for the help desk might read as follows. Source: the company's own help desk account, administered by its head of support, exported through the vendor's admin export in September 2026; the vendor's terms at the time allowed the customer to export its data. Period: tickets from March 2018 to August 2026, with no gaps. Basis: the privacy notice versions of 2018, 2021 and 2024 (copies kept), which told customers support conversations would be used to provide and improve the service; the company's counsel concluded the 2024 version did not cover licensing identifiable data, so the lot is de-identified. Licences in: none; attachments from customers' own vendors were removed. Processing: de-identified on the company's systems with a keyed stand-in for each person, a random sample read by a person, and an independent provider's certificate. Exclusions: tickets from customers whose contracts reserve their data, tickets tagged legal or security, all attachments. Custody: the export and the de-identified copy are held in the company's storage, hashed, and released to a buyer only under a signed licence. Each line points to a document in the rights file. A buyer's counsel can read it in five minutes and know what to test.
Worked example: how this site keeps provenance for its own facts
A research site is also a dataset, and the same discipline applies. This site maps the AI training data market as a set of facts, each with its origin recorded, so that a reader can follow any number on any page down to the page it came from. The method is a working example of provenance on a small scale, and it is the method we would ask of a holder's lot.
Everything here sits on one of five levels, and each level is built only from the one below it. At the bottom are sources: the pages, filings, dockets, articles and reports the site reads, 2,133 of them, each address counted once. Above them are records: every fact a source states, 2,854 of them that a newer reading has not replaced, each carrying the source's own words, the date it was read, the address, and how firm it is (stated by the party itself, reported by others, or self-reported). Then come the entities the records are about, then figures, every number computed from records, each with its derivation and its inputs, and finally the pages and guides like this one, where every number is a link down the chain.
Three habits keep the record honest. Permanent copies: 590 of the cited sources have a copy in the Internet Archive's Wayback Machine from near the day they were read, so a citation still shows what the page said then, even after the page changes. Re-reading: every day, the sources behind current records are read again for the words each record was read from, and a source that changed or lost a figure is re-read first. History, not overwriting: when a newer reading replaces a record, the old record is kept as history with a pointer to the one that replaced it, and stops being counted. That is the same shape as a lot's provenance record: origin (the source and its archived copy), the terms of use (what the source is and how firm its statement is), processing (the derivation of each figure), and custody (the history of each record). How we source every number explains the method in more detail.
Questions people ask
What is data provenance in AI? It is the documented history of the data a model is trained on: where it came from, the rights and consents it was collected under, and what was done to it. The EU AI Act uses the word itself, requiring general-purpose model providers to document "the type and provenance of data and curation methodologies" for the AI Office.
What is the difference between data provenance and data lineage? Lineage is the technical history of how a dataset was produced (which pipeline made which file from which inputs). Provenance includes that and adds the legal history: the terms the data was collected under, consents, licences and custody. A buyer's counsel cares about provenance; a data engineer often means lineage.
Do AI companies have to disclose their training data? In the EU, providers of general-purpose models must publish a sufficiently detailed summary of their training content, though the template does not require naming specific datasets or works. In California, developers of generative AI systems must post a high-level summary of their datasets, including sources or owners and whether data was purchased or licensed.
What does California AB 2013 require? Since 1 January 2026, a developer of a generative AI system made available to Californians must post documentation of its training data on its website, covering twelve topics including whether datasets were purchased or licensed, whether they contain personal information, the processing done, and the collection period. A federal court refused to block the law in March 2026.
What is a datasheet for a dataset? A standard description that accompanies a dataset, proposed by Gebru and co-authors, documenting its motivation, composition, collection process and recommended uses. In a sale, it is the document a buyer reads to understand a lot and test a sample against; our datasheet tool produces one.
What is C2PA? The Coalition for Content Provenance and Authenticity publishes Content Credentials, an open standard for signed records of a media file's origin and edits. It can also describe the folders of a training set as ingredients of one manifest, which makes it useful for licensing image, video and audio archives.
Why do AI buyers ask for consent records? Because they are asked to stand behind them. Buyers' terms commonly require the holder to warrant consents and opt-outs, and one buyer's terms make the holder refund everything if the description of the data proves materially inaccurate. Consent also moves price: opt-in book licences paid authors far more than opt-out ones.
Can provenance be added after a model is trained? Not in any way that helps the holder. Once data trains a model it cannot practically be pulled back out, and buyers' deletion clauses do not require retraining. Provenance has to be settled before the data leaves.
What this means for you
If you hold data a buyer might license, provenance is the part of the sale you control completely. Prices depend on the market; whether you can show where your data came from depends only on the work you do before the first conversation.
- Start the rights file now, before any buyer is involved. Work through the questions in our readiness check and gather the documents behind each answer, the old privacy notices first.
- Write the datasheet with our datasheet tool, describing origin, period, processing and exclusions in words a buyer can test.
- De-identify on your own systems and keep the evidence: our de-identification tool runs on your computer and follows our standard.
- Read buyers' terms for what they make you warrant, and qualify what you cannot prove. Our guide to data licensing agreements, the licence terms page and the buyers page set out who asks for what.
- Know what the developer will publish. Decide in the licence whether the buyer may name you in its AI Act summary or AB 2013 posting.
- Value the lot with its provenance in mind. Buyers say records that connect and can be traced are worth more ( a ticket tied to its code commit beats a loose document); see what company data is worth and the full guide to selling company data to AI labs.
For how buyers source data today and where licensed records fit, see how AI companies get training data. For every fact this guide rests on, follow the links down to the records and the sources.
This guide is research from public sources, not legal advice.