What Model Cards Were Supposed to Deliver
In 2019, Margaret Mitchell, Timnit Gebru and their co-authors published a paper at FAccT that introduced the model card as a standardized artifact for machine learning transparency. The core promise was simple: every deployed model should ship with a structured document explaining its intended use, performance characteristics, evaluation conditions and, critically, the data on which it was trained.
That promise has aged poorly. In 2026, foundation models underpin hundreds of millions of user interactions per day. The model cards attached to them range from genuinely informative to deliberately vague. Some read more like marketing copy than technical documentation. The training data sections, where they exist at all, are frequently the most hollow part of the document.
This piece conducts a structured audit of training data disclosure practices across the four dominant foundation model providers: Anthropic, OpenAI, Google and Meta. The goal is not to prosecute any single lab but to map the gap between the Mitchell et al. standard and current practice, and to explain why that gap carries real technical and legal consequences.
The Mitchell et al. Specification as a Baseline
The original model card paper, Mitchell et al. (2019), published as "Model Cards for Model Reporting" at ACM FAccT, established a template with several required fields. The full citation is Margaret Mitchell et al., "Model Cards for Model Reporting," Proceedings of the Conference on Fairness, Accountability, and Transparency (2019).
For training data, the specification calls for disclosure of the datasets used, the preprocessing applied, any known demographic or representational gaps, and the conditions under which evaluation data was collected relative to training data. The authors were explicit: the purpose is not just reproducibility but accountability. A model's behavior is inseparable from its training distribution.
The paper also anticipates the consent problem. It notes that model cards should, where possible, describe whether training data was collected with informed consent and whether data subjects had any mechanism for redress or opt-out. In 2019 this read as aspirational. In 2026, with litigation and regulatory action accumulating across the EU, US and UK, it reads as prophetic.
The W3C Data on the Web Best Practices (https://www.w3.org/TR/dwbp/) and the NIST AI Risk Management Framework (AI RMF 1.0, https://airc.nist.gov/RMF) both extend this logic into formal standards territory. Neither is binding. Both have been largely ignored by the largest labs in the context of foundation model documentation.
Auditing What Major Labs Actually Document
Examining the public-facing model documentation from Anthropic, OpenAI, Google and Meta against the Mitchell et al. template reveals a consistent pattern: technical performance is well-documented, training data is not.
Anthropic
Anthropic's Claude model cards, available through their developer documentation, describe evaluation benchmarks in considerable detail. MMLU, HumanEval, GSM8K scores appear with confidence intervals. Constitutional AI methodology is described at a process level. Training data receives a paragraph that acknowledges web crawl data, licensed datasets and internally generated synthetic data without naming any specific source, corpus or data partner. No data lineage is provided. No consent mechanism is described.
OpenAI
OpenAI's system cards for GPT-4 class models are the most elaborate documents in the space and remain among the least informative on the data question. The GPT-4 system card, released alongside the model, dedicates significant pages to safety evaluations, red-teaming methodology and deployment risk. Training data appears in a single paragraph that references "publicly available data from the internet" and "proprietary data." Neither category is decomposed. The known litigation around Common Crawl and copyrighted material is not addressed in the card itself.
Google DeepMind
Google's Gemini technical report and associated model documentation follow a similar structure to OpenAI's system card approach. Benchmark performance is extensive. Training data is described as a "multimodal and multilingual dataset" drawn from web documents, books and code. Specific corpus names are absent. The report does note that data quality filtering was applied but does not describe the filter logic, the rejection rate, or whether any human review occurred.
Meta
Meta's Llama model family has the strongest data disclosure record among major labs, partly because Llama models were released with weights and faced community scrutiny that proprietary models avoid. Llama documentation names CommonCrawl, C4, Wikipedia, books corpora and GitHub as training sources and provides rough token-count ratios. This is closer to the Mitchell standard, though consent documentation for any of these sources remains absent. The Llama 3 technical report expands on data filtering pipelines in a way no competitor currently matches in public documentation.
The Training Data Gap: Omission as Strategy
The pattern across all four organizations is not random. Omission of training data specifics is a rational legal strategy given the current litigation environment. If a model card explicitly names a dataset that was later determined to contain copyrighted material used without license, that documentation becomes an exhibit.
This dynamic was anticipated in academic work on data governance long before LLMs existed. The concept of a "disclosure dilemma" in data-intensive industries is well-established: the organizations with the most to gain from transparency are also the organizations with the most to lose from it. Foundation model labs sit at the apex of this dilemma.
The practical result is that model cards for frontier models function primarily as capability marketing with a safety appendix. They communicate to enterprise buyers that the model performs well on standard benchmarks and that the lab has thought about misuse. They do not communicate what data the model learned from, who owned that data, or whether the people represented in that data had any say in the matter.
This is not a minor documentation gap. Training data determines model behavior in ways that no post-hoc evaluation fully captures. A model trained on text that systematically underrepresents certain dialects, professions, or geographic regions will exhibit those gaps in deployment. Without disclosure of the training distribution, downstream practitioners cannot diagnose these failures when they occur.
Why Training Data Disclosure Is a Technical Necessity
There is a technical argument for training data disclosure that runs independent of the legal and ethical arguments. It is rooted in the reproducibility crisis that has accumulated in machine learning over the past decade.
Researchers at major universities have repeatedly demonstrated that reported benchmark scores for large models cannot be reproduced without knowing the exact training data, because benchmark contamination is pervasive. If a model was trained on data that included examples structurally similar to evaluation benchmarks, its reported scores do not measure generalization. They measure memorization. Without training data disclosure, contamination cannot be audited.
This is not a hypothetical concern. Work on benchmark contamination in LLMs, including research from groups at Stanford and Carnegie Mellon, has shown that contamination effects are detectable through statistical probing but cannot be definitively ruled out or confirmed without access to training data manifests. The arXiv preprint landscape has accumulated substantial evidence on this problem (see, for example, work by Sainz et al. on NLP benchmark contamination, arXiv).
The NIST AI RMF explicitly flags training data documentation as a component of the "Map" function in its governance framework. The EU AI Act, which entered applicability phases through 2026, requires technical documentation for high-risk AI systems that includes description of training data and data governance practices. The Act's requirements for general-purpose AI models with systemic risk add a transparency layer that model cards in their current form do not satisfy.
Data Provenance Architecture and the PDAOS Model
At Own Your Data Inc., the technical work on the Personal Data Asset Origination System (PDAOS) approaches this problem from the data origination layer rather than the documentation layer. The distinction matters. A model card is a downstream artifact. By the time a model card is written, thousands of decisions about data collection, consent, filtering and weighting have already been made. Documenting those decisions after the fact, from memory and with legal review, produces the kind of vague institutional language that characterizes current model cards.
The PDAOS architecture encodes provenance at the point of data creation. Each data asset carries a cryptographically bound record of its origin, the consent conditions under which it was collected, any transformations applied, and the identity of the originating agent. This is not a documentation approach. It is an architectural approach. The provenance record is not written after training. It is generated at the moment data enters the system.
This connects directly to the concept of consent receipts as specified in the Kantara Initiative Consent Receipt Specification, which provides a machine-readable format for recording the terms under which personal data was collected. If training data pipelines ingested assets with attached consent receipts, the training data section of any model card could be generated programmatically from those receipts rather than assembled from organizational memory and legal constraint.
Dr. Patrick Fisher's work in "The Invisible Data" (Volume 6 of The Invisible Series, https://theinvisible.life) frames this as the core problem of the data economy: data is extracted from originating agents, transformed, and traded without preserving any connection to the conditions of its creation. Foundation model training is the most consequential instance of this pattern currently operating at scale. The assets that constitute a modern LLM's training set may represent text authored by hundreds of millions of people, none of whom were party to any agreement governing that use.
W3C's PROV ontology (https://www.w3.org/TR/prov-overview/) provides a formal vocabulary for provenance representation that could, in principle, serve as the basis for standardized training data provenance records. It has not been adopted by any major lab as part of their training pipeline or documentation practice.
Closing the Gap: What Meaningful Disclosure Requires
Closing the gap between the Mitchell et al. specification and current practice requires changes at three levels: technical, organizational and regulatory.
At the technical level, provenance must be built into data pipelines, not added at documentation time. This means adopting structured formats for dataset manifests, attaching cryptographic identifiers to data assets, and maintaining auditable logs of filtering and transformation decisions. The Croissant metadata format, developed by the ML Commons community, is a current attempt to standardize dataset documentation and is worth watching as a potential component of this infrastructure.
At the organizational level, model cards must be separated from marketing functions. The organizations currently writing model cards are the same organizations with commercial incentives to under-disclose training data. Independent third-party auditing of training data documentation, analogous to financial audit, is the structural solution. The EU AI Act's conformity assessment requirements gesture toward this but stop short of mandating independent training data audit for most model categories as of 2026.
At the regulatory level, the FTC's existing authority over deceptive trade practices, the EU AI Act's transparency requirements for GPAI models and the UK ICO's guidance on AI and data protection all create overlapping but inconsistent obligations. A coherent international standard for training data disclosure, built on the Mitchell et al. framework and extended to cover consent provenance and contamination risk, would provide a baseline that currently does not exist.
The MyDataKey system (https://mydatakey.org) applies these principles to individual data sovereignty, allowing individuals to maintain cryptographic control over their personal data assets. The same architectural logic applies at the institutional level: labs that build provenance into their training pipelines will be positioned to produce genuine model cards rather than liability-managed summaries.
The gap between what model cards promised and what they deliver is not inevitable. It reflects specific choices made by specific organizations operating under specific incentive structures. Changing those structures, technically and institutionally, is the work that the AI transparency community has in front of it in 2026 and beyond.