Insights · 6 min read
Data Cards and Provenance for AI Training Data: What to Include
A data card is the document a buyer’s legal, security and research teams read before anyone looks at a single file.
Selling data without documentation asks every reviewer on the buyer’s side to take your word for it. A data card replaces trust with a record. It states what is in the data, where it came from, what was done to it and what it should not be used for. This article explains the idea, what to put in a card, and how to keep a provenance trail you can stand behind.
Where data cards come from
The idea is borrowed from engineering. In “Datasheets for Datasets,” Timnit Gebru and colleagues proposed that every dataset ship with a datasheet documenting its motivation, composition, collection process and recommended uses, much as electronic components ship with datasheets. Bender and Friedman proposed data statements for language data, and Holland and colleagues proposed a dataset nutrition label that summarizes a dataset’s “ingredients.” Google researchers later described Data Cards as structured summaries of the essential facts about a dataset that stakeholders need across its lifecycle, and the PAIR group published a Data Cards Playbook to help teams fill them in.
Why buyers ask for one
- Licensing facts are often wrong. An audit of more than 1,800 text datasets found license information omitted on more than 70 percent of entries on popular dataset hosting sites, and wrong on more than 50 percent. Buyers know they cannot assume the paperwork is right.
- Disclosure duties. Providers of general-purpose AI models on the EU market must publish a sufficiently detailed summary of the content they used for training under Article 53 of the AI Act. The Commission’s template, published in July 2025, covers categories such as commercially licensed content, so a buyer may need to describe your data in public.
- Contracts. Published legal commentary on training data licenses expects the licensor to deliver a provenance file recording where the data came from, how it was processed and known limitations, with a summary at signing and a fuller record available on request under confidentiality.
What goes in a card
The Data Cards Playbook lists themes that include summary, authorship, dataset overview, provenance, transformations, annotations and labeling, human and other sensitive attributes, sampling methods, extended use, and access, retention and wipeout. You do not need all of them. For company data sold to an AI lab, these sections do the most work:
| Section | The question it answers | Illustrative entry (synthetic) |
|---|---|---|
| Owner and rights | Who may license this, and on what basis? | Owned by the fictional Harbor Example Ltd; rights memo dated and reviewed by counsel |
| Sources | Which systems did it come from? | Git repositories, team chat export, ticket export, design file export |
| Period and size | What dates and volume? | Dates and counts, stated per source |
| Transformations | What was done to it? | Secrets rotated; people replaced by stable stand-ins; generated files removed; duplicates removed |
| Removed subsets | What was left out, and why? | HR channels, customer-confidential projects, third-party licensed code |
| People and sensitive data | Who appears, and how are they protected? | Stand-ins used; mapping table held separately and not delivered; sample review found a stated number of misses, all fixed |
| Grading and labeling | How were tasks or labels made and checked? | Reference tests run repeatedly; human review of tests; difficulty recorded |
| Known gaps | Where is it weak? | Mostly one programming language; little data from the first year |
| Use and limits | What is it for, and what is not allowed? | Training and evaluation as per the license; no re-identification |
| Version and access | Which release is this, and how is it delivered? | Version number, file hashes, delivery method |
The entries are invented. They are a synthetic illustration (ID SYN-CARD-01) crafted by the Bearish AI team, for a fictional company, to show the level of detail. Replace each with facts you can prove.
Keeping a provenance trail
A card is a summary. Behind it you want a trail:
- Source manifest. For each export, the system, who exported it, when, and a hash of each file so any change is detectable.
- Transformation log. Each processing step, the tool or script and version, and counts of what it changed or removed.
- Removal counts. How many identifiers and secrets were found and replaced. In the reported sale of an airline’s business data to Google, the privacy ombudsman asked that the certification filed before each transfer state how many passengers’ details were found and removed. Counts are what make a claim checkable.
- Review notes. Who reviewed a sample of the output, what they found, and what was fixed.
- Version history. What changed between releases, so a buyer can tell which version they hold.
What a card must not contain
A card is a document you may share widely, so it must not leak what you removed. Leave out personal data, credentials, customer names that are confidential and any detail that would identify a person. If the mapping table that links stand-ins to real people exists, say that it exists and is held separately. Regulators treat such tables as personal data, so do not attach them.
Format: human readable first
Write the card in plain language that a lawyer and a researcher can both follow, and attach any machine-readable manifest as an annex. Keep it versioned with the data: a card that describes release 1 while the buyer holds release 3 is worse than no card. Review it with whoever signs the rights memo, so the claims in the card and the claims in the contract match.
A card does not replace a legal review
A well-written card makes rights and privacy work visible. It does not do that work. Pseudonymization and secret removal are described alongside a separate review of rights, confidentiality and licensing, and a lawyer should review both. For where the card fits in the whole process, see /insights/prepare-company-data-for-ai-labs and /insights/ai-lab-data-due-diligence. To see how documented, prepared data might change what your archive is worth, the free estimate is at /estimate.
Questions we get
- What is a data card for AI training data?
- A structured summary of the essential facts about a dataset: where it came from, how it was collected and processed, who is in it, how it was labeled, and what it should and should not be used for. Google researchers described them in 2022 as documents stakeholders need across a dataset’s lifecycle.
- What is the difference between a data card and a datasheet?
- Both document datasets. “Datasheets for Datasets” (2018) proposed a standard set of questions on motivation, composition, collection and uses, modeled on electronics datasheets. Data Cards are a later, related format from Google researchers, with a playbook for filling them in.
- Do AI labs require provenance documentation?
- Labs do not publish a universal requirement, but published legal commentary expects a provenance file in training data licenses, and EU rules require providers of general-purpose models to publish summaries of training content. Documentation helps buyers meet their own obligations.
- What should a dataset provenance record include?
- Sources and dates, who exported what, file hashes, each processing step with counts of what was changed or removed, review notes, license basis, and version history. Keep personal data and secrets out of the record itself.
What is your data worth?
Sources
- Gebru et al., “Datasheets for Datasets” (2018, revised 2021)
- Bender and Friedman, “Data Statements for Natural Language Processing,” TACL 6 (2018)
- Holland et al., “The Dataset Nutrition Label: A Framework To Drive Higher Data Quality Standards” (2018)
- Pushkarna, Zaldivar and Kjartansson, “Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI” (2022)
- PAIR (Google), “The Data Cards Playbook”
- Longpre et al., “The Data Provenance Initiative: A Large Scale Audit of Dataset Licensing & Attribution in AI” (2023)
- EU AI Act, Article 53 (obligations for providers of general-purpose AI models), as published on artificialintelligenceact.eu
- WilmerHale, “European Commission releases mandatory template for public disclosure of AI training data” (2025)
- Sergei Tokmakov, Esq., “AI Training Data Licensing: A Usable Agreement” (attorney commentary, undated)
- The Next Web, “Spirit’s privacy ombudsman backs Google’s $10m data deal” (October 2026)
- European Data Protection Board, “Guidelines 01/2025 on Pseudonymisation” (adopted 16 January 2025, version for public consultation)