Skip to main content
Bureau of AI
Category: Data Governance & Quality

Datasheets for Datasets

Also known as: Datasheet for a Dataset, Dataset Datasheet
Simply put

A datasheet for datasets is a structured document that describes key facts about a dataset, such as why it was created, what it contains, how it was collected, how it was cleaned or processed, and what uses it is and is not suited for. The idea, proposed in a 2018 paper by Gebru and colleagues, is that every dataset should come with this kind of accompanying record, similar in spirit to a specification sheet for a physical component. The goal is to make datasets more transparent so that people building or reviewing AI systems can better understand what they are working with.

Formal definition

As introduced by Gebru et al. (2018), a datasheet for datasets is a standardized documentation artifact intended to accompany a dataset and record its motivation, composition, collection process, preprocessing and cleaning, recommended and discouraged uses, and related considerations. It addresses the historical absence of a consistent convention for documenting datasets used to train and evaluate machine learning models, supporting transparency, communication between dataset creators and consumers, and more informed decisions about a dataset's fitness for a given purpose. The datasheet approach as described in the evidence is a proposed documentation practice rather than a binding regulatory requirement; the specific fields, structure, and adoption vary across templates and implementations, and the evidence here does not establish it as a mandated standard in any particular jurisdiction or framework.

Why it matters

Datasets are a primary source of model risk, yet historically they have often circulated without any consistent record of where they came from, what they contain, or what they were intended to support. Datasheets for datasets, as proposed by Gebru and colleagues in 2018, respond to this gap by giving dataset creators and consumers a shared documentation convention. For the people who build, validate, and review AI systems, this kind of record can surface facts—such as how data was collected, how it was cleaned, and which uses are discouraged—that are otherwise easy to lose once a dataset moves from its origin to downstream teams.

From a governance perspective, this documentation supports accountability and informed decision-making about whether a dataset is fit for a particular purpose. It can help reviewers assess whether the assumptions baked into a dataset match the context in which a model will operate, which is a distinct question from how well the model performs on a given metric. It is important to be precise about status, however: the datasheet approach described in the source material is a proposed documentation practice rather than a binding regulatory requirement, and the evidence here does not establish it as a mandated standard in any particular jurisdiction or framework.

Professionals should also treat datasheets as a risk-reduction measure, not a risk-elimination one. A well-completed datasheet can improve transparency and communication between dataset creators and consumers, but it does not by itself validate a dataset, guarantee its quality, or resolve questions about fitness for use. Its value depends on the accuracy and completeness of what is recorded, and templates, fields, and adoption vary across implementations.

Who it's relevant to

Data scientists and model developers
For those building AI systems, a datasheet provides a record of a dataset's motivation, composition, collection process, and preprocessing, along with recommended and discouraged uses. This can inform judgments about whether a dataset fits a given task, though developers should recognize that the datasheet documents the data and does not by itself establish model performance or validate the dataset's quality.
Model validators and reviewers
Independent reviewers can use datasheets to understand a dataset's origins, cleaning, and stated fitness for use as part of assessing a model. The datasheet supports scrutiny of dataset assumptions, but reviewers should note that its reliability depends on the accuracy and completeness of what the authors recorded, and that its presence does not substitute for validation.
AI governance and compliance functions
Governance teams may adopt datasheets as a transparency and accountability practice that improves communication between dataset creators and consumers. It should be treated as a proposed documentation convention rather than a mandated requirement; the evidence here does not establish it as a binding standard in any particular jurisdiction or framework.
Dataset creators and curators
Those who assemble or distribute datasets are the natural authors of a datasheet, documenting why the dataset was created, what it contains, how it was collected and processed, and which uses are recommended or discouraged. Because field structures vary across templates, creators should be explicit about the format and scope of the documentation they provide.

Inside Datasheets for Datasets

Motivation
Documentation of why the dataset was created, who created it, and who funded its creation, intended to surface the original purpose and potential mismatches with later reuse.
Composition
A description of what the data instances represent, how many there are, whether the data contains sensitive or confidential attributes, and how instances relate to one another.
Collection Process
How the data was acquired, including collection mechanisms, sampling strategy, timeframe, and whether individuals were notified of or consented to collection where applicable.
Preprocessing, Cleaning, and Labeling
Documentation of any transformation, filtering, cleaning, or labeling applied to the raw data, and whether the raw data was retained.
Uses
Descriptions of tasks the dataset has been used for, tasks it could be used for, and uses for which it is not suitable or should be avoided.
Distribution
How the dataset is or will be distributed, along with any licensing terms, usage restrictions, or applicable third-party constraints.
Maintenance
Who maintains the dataset, how it will be updated or corrected over time, and how errata or version changes are communicated.

Common questions

Answers to the questions practitioners most commonly ask about Datasheets for Datasets.

Are datasheets for datasets a legally required document under any current regulation?
Not as a standalone mandate. Datasheets for datasets originated as a proposed documentation practice in the machine learning research community rather than as a regulatory instrument. Some governance frameworks and standards encourage dataset documentation of a similar nature, and certain regulatory or supervisory expectations may call for documentation of data used in models, but a datasheet in its specific published form is not itself binding law. Whether any documentation obligation applies depends on the jurisdiction, sector, and framework in question, so professionals should map datasheet content to the specific requirements that govern their systems rather than assume the artifact satisfies a legal duty.
Does completing a datasheet mean a dataset is unbiased or fair?
No. A datasheet is a documentation and transparency artifact; it records information about how a dataset was collected, composed, processed, and intended to be used. It can surface characteristics that help practitioners reason about potential bias, but documenting a dataset does not remove bias from it, nor does it establish fairness. Bias and fairness are distinct concerns—bias generally refers to systematic skew in data or outcomes, while fairness concerns normative judgments about acceptable treatment across groups. A datasheet supports the analysis of these issues but does not resolve them, and it should not be treated as evidence that a dataset is free of problems.
Who in an organization should be responsible for completing a datasheet?
Responsibility typically rests with those closest to the data's creation and curation—often data engineers, data scientists, or dataset owners who can accurately describe collection, labeling, and preprocessing. In organizations that use a lines-of-defense structure, this authoring generally sits in the first line, with review or challenge from a second-line function such as model risk or data governance. Assigning clear ownership matters because a datasheet is only useful if the people completing it have direct knowledge of the dataset; roles and review expectations should be defined in internal policy rather than assumed.
At what point in a data or model lifecycle should a datasheet be created?
In many implementations, the most reliable time to begin a datasheet is during or immediately after dataset creation, when details about collection, consent, and processing are still known and verifiable; reconstructing this information later is often difficult or incomplete. The datasheet is commonly treated as a living document that is updated as the dataset is modified, extended, or repurposed. Aligning datasheet creation with existing data intake or model development checkpoints can help ensure the documentation is produced rather than deferred.
How should datasheets relate to other model documentation such as model cards or validation reports?
A datasheet documents the dataset, while artifacts such as model cards typically document a trained model's intended use and performance, and validation reports address whether a model is fit for purpose. These serve complementary but distinct purposes and should not be substituted for one another. In practice, organizations often cross-reference them so that a model's documentation points to the datasheets for the data it was trained and tested on, supporting traceability without conflating dataset-level and model-level information.
How can an organization keep datasheets current when datasets change over time?
Because datasets are frequently updated, extended, or resampled, a datasheet completed once can quickly become inaccurate. Common approaches include versioning datasheets alongside dataset versions, defining triggers that require review when a dataset is materially changed, and assigning ongoing ownership so updates are someone's explicit responsibility. Treating the datasheet as a static file rather than a maintained record is a frequent pitfall; embedding update expectations into data governance processes helps the documentation remain a reliable reflection of the dataset it describes.

Common misconceptions

A datasheet is a regulatory or legally mandated document that satisfies compliance obligations on its own.
Datasheets for Datasets is a documentation practice proposed in the research literature, not a binding legal instrument. It may support governance and audit processes, but as commonly understood it does not by itself constitute or replace any specific regulatory requirement.
Completing a datasheet demonstrates that a dataset is unbiased, fair, or fit for a given model.
A datasheet is a transparency and disclosure artifact; it documents characteristics and limitations rather than certifying them as absent. Documenting composition and collection can help surface potential bias, but it does not eliminate bias or establish fairness, which are separate assessments requiring their own analysis.
There is a single authoritative, standardized datasheet template that all organizations must use.
The concept is typically implemented as a flexible set of prompting questions rather than a fixed standard. Organizations commonly adapt the structure to their context, and formats vary across teams, sectors, and use cases.

Best practices

Author the datasheet as close as possible to data collection and labeling, while the rationale, sampling decisions, and processing steps are still known to the people who performed them.
Explicitly document intended uses and, just as importantly, uses for which the dataset is not suitable, so downstream teams can identify purpose mismatches before deployment.
Record sensitive or confidential attributes and any consent or notification practices during collection, and flag limitations rather than implying the data is free of concerns.
Treat the datasheet as a living document by assigning maintenance ownership, versioning changes, and communicating errata as the dataset evolves.
Preserve information about raw versus preprocessed data, including what cleaning, filtering, and labeling were applied, so later reviewers can assess how transformations may affect model behavior.
Integrate datasheets into broader governance and validation workflows as a supporting input, without treating their completion as evidence that dataset risk has been resolved.