You wrote a model card. Section 6 (Training data) is one paragraph and ends with "see datasheet." Where is the datasheet? Gebru et al. (2018, journal version 2021) proposed Datasheets for Datasets as the structured documentation artifact that would do for training data what model cards do for models, and the EU AI Act Article 10 data-governance regime now requires what Gebru et al. anticipated. Article 10(2)(f) requires "examination in view of possible biases that are likely to affect the health and safety of persons" and Article 10(2)(g) requires "identification of relevant data gaps or shortcomings." Those obligations don't live in the model card; they live in the datasheet. This lesson walks the full seven-section Gebru-et-al. structure with a worked example for the 50,000 customer-service transcripts used to fine-tune Acme.ServiceAssist v1.0, and maps each section to Article 10(1)-(5) + GDPR Article 9 overlay + ISO 42001 A.7 + NIST AI RMF Map 4 / Measure 1.

Why Datasheets Exist - and Why Article 10 Made Them Mandatory

Gebru et al. Timnit Gebru, Jamie Morgenstern, Briana Vecchione, Jennifer Wortman Vaughan, Hanna Wallach, Hal Daumé III, Kate Crawford, introduced Datasheets for Datasets at FAT/ML 2018 and published the canonical 2021 journal version in Communications of the ACM. The proposal: every dataset used to train a machine learning system should ship with a structured document covering motivation, composition, collection process, preprocessing, uses, distribution, and maintenance. The analogy is to the electronics-industry datasheet that ships with every chip: a structured artifact that lets a downstream user understand the component's intended use, limitations, and operating envelope.

In 2026 the proposal is no longer optional for high-risk AI training data in the European Union. EU AI Act Article 10, "Data and data governance", imposes obligations that map almost line-by-line to the Gebru-et-al. sections:

• Article 10(1): Training, validation, and testing datasets shall be subject to data-governance and management practices appropriate for the intended purpose.
• Article 10(2). Those practices shall cover in particular: (a) relevant design choices; (b) data-collection processes and the origin of data; (c) relevant data-preparation processing operations (annotation, labelling, cleaning, updating, enrichment, aggregation); (d) the formulation of assumptions about what the data should measure and represent; (e) an assessment of availability, quantity, and suitability; (f) examination in view of possible biases that are likely to affect the health and safety of persons, have a negative impact on fundamental rights, or lead to prohibited discrimination; (g) measures to detect, prevent, and mitigate such biases; (h) identification of relevant data gaps or shortcomings and how those gaps can be addressed.
• Article 10(3): Training, validation, and testing datasets shall be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose; they shall have the appropriate statistical properties.
• Article 10(4): Datasets shall take into account, to the extent required by the intended purpose, the characteristics or elements particular to the specific geographical, contextual, behavioural, or functional setting within which the AI system is intended to be used.
• Article 10(5), To the extent strictly necessary to ensure bias detection and correction in relation to high-risk AI systems, providers may exceptionally process special categories of personal data subject to appropriate safeguards.

The datasheet is the artifact that operationalizes Article 10. Without a datasheet you can claim you did the work but you have no evidence. With a datasheet you have a single, regulator-grade document that answers every Article 10 question in the regulator's order.

Gebru-et-al. Seven Sections - Definitions and 2026 Article 10 Mapping

The seven sections in their original Gebru-et-al. order, with the 2026 Article 10 mapping for each:

1. Motivation, Why was the dataset created? Who created it? Who funded it? What gap was it intended to fill? Maps to Article 10(2)(a) relevant design choices + Article 10(2)(d) assumption formulation + Article 10(4) intended-purpose context.
2. Composition, What do the instances represent? How many are there? Is the data raw or processed? Are there missing values? Are there relationships between instances? Are there recommended data splits? Are there errors, redundancies, or noise? Does the dataset rely on external resources? Does it contain confidential or sensitive content? Does it contain protected or special-category subpopulations? Maps to Article 10(2)(b) data-collection origin + Article 10(2)(e) availability/quantity/suitability + Article 10(2)(f) bias examination + Article 10(3) statistical properties.
3. Collection process, How was the data acquired? What was the time frame? Who was involved? Were they compensated? Was the data collected from the individuals directly or via third parties or inferred? Were individuals notified about collection? Did individuals consent? If consent, was a mechanism to revoke provided? Was an ethical-review process conducted? Does collection comply with applicable law (GDPR Article 6 lawful basis; Article 9 special-category processing; Article 13/14 transparency)? Maps to Article 10(2)(b) data-collection processes and origin + Article 10(5) special-category carve-out + GDPR Article 6, 9, 13, 14.
4. Preprocessing / cleaning / labeling, What preprocessing was done? Was raw data preserved alongside the processed version? Was the preprocessing software open-source or proprietary? Who did the labeling? What were the labeling instructions? What was the inter-annotator agreement? Were labelers paid fairly? Were there quality-control passes? Maps to Article 10(2)(c) relevant data-preparation processing operations + Article 10(2)(g) bias-mitigation measures.
5. Uses, What has the dataset been used for? What other tasks could it be used for? Is there a repository linking to papers/systems using it? Are there tasks for which the dataset should not be used? Maps to Article 10(2)(a) relevant design choices + Article 10(4) intended-purpose context + Mitchell-et-al. model card Section 2 (intended use).
6. Distribution, Will the dataset be distributed to third parties outside the entity that created it? How will it be distributed? When will it be distributed? Will it be distributed under copyright, IP license, or terms of use? Are there export controls or regulatory restrictions? Maps to Article 53(1)(c) copyright policy (where the dataset is used by a GPAI provider) + Article 10(2)(b) origin documentation + GDPR Chapter V international-transfer rules.
7. Maintenance, Who maintains the dataset? How can owners be contacted? Is there an erratum mechanism? Will the dataset be updated? If it relates to people, are there retention limits on the data? When will it be deprecated? Will older versions remain available? If others want to contribute, is there a mechanism? Maps to Article 10(2)(h) identification of data gaps and how those gaps can be addressed + Article 18 record-keeping + ISO 42001 A.7.4 data-quality management + Article 72 post-market monitoring (if data drift is monitored).

Each section maps to one or more Article 10 sub-paragraphs. The seven sections together cover Article 10 in its entirety. That is the cross-walk efficiency: one datasheet, one Article 10 compliance evidence base.

Worked Example, 50,000 Customer-Service Transcripts for Acme.ServiceAssist v1.0

The scenario: Acme Insurance fine-tuned Anthropic Claude 4 Opus on 50,000 anonymized customer-service transcripts. The fine-tune model card (lesson 026) cites a datasheet for the training data. This is that datasheet, walked section by section as it would appear in the technical file.

Section 1 - Motivation

• Why created: To fine-tune a foundation LLM (Anthropic Claude 4 Opus) on Acme's customer-service domain so that the fine-tuned model surfaces relevant policy provisions and drafts on-policy customer-facing responses with higher domain accuracy than the un-fine-tuned baseline. The gap: the baseline model produces generic insurance responses; the fine-tune targets Acme-specific policy vocabulary, claims-status terminology, and Acme's tone-of-voice conventions.
• Created by: Acme Insurance ML Engineering team in coordination with Customer Operations subject-matter experts and Legal/Privacy. Funded by the FY26 AI Compliance and Operations budget under the Customer Operations cost center.
• Article 10(2)(a) design choices: Decision to use real customer-service transcripts (rather than synthetic data) reflects the intent to capture authentic Acme tone-of-voice, real edge-case query patterns, and the actual claims-status vocabulary used by customers. Decision to limit to January 2023 - December 2025 transcripts reflects the policy-product version alignment (pre-2023 transcripts reference deprecated coverage terms).
• Article 10(2)(d) assumption formulation: Assumption that anonymized 2023-2025 transcripts are representative of 2026 customer query patterns; assumption tested by Q1 2026 production-distribution comparison and confirmed within tolerance.
• Article 10(4) intended-purpose context: United States customer-service deployment via Acme.ServiceAssist v1.0. Customers are U.S. residents holding Acme personal-lines policies (auto, home, umbrella). Customer-service agents are the immediate users; customers are the indirect recipients of agent-reviewed responses.

Section 2 - Composition

• Instance representation: Each instance is one customer-service transcript, a sequence of customer-agent turns covering a single inquiry session. Average transcript length 8 turns; median 6 turns; 95th percentile 22 turns.
• Count: 50,000 transcripts total. Stratified split: 40,000 train / 5,000 validation / 5,000 held-out test.
• Raw vs processed: Raw transcripts preserved in cold storage with restricted access (audit log on read); processed (de-identified, normalized) version used for fine-tuning. Both retained for the Article 18 record-keeping window.
• Missing values: 3.2% of transcripts have missing agent-side metadata (legacy migration); flagged as not-suitable-for fairness analysis but suitable for next-turn prediction objective.
• Relationships between instances: 8% of customers appear in multiple transcripts; deduplication at customer level performed for one validation split to test for memorization (no memorization detected).
• Recommended data splits: The 40k/5k/5k split is recommended; stratification by query type and inferred-demographic preserves class balance.
• Errors, redundancies, noise: Approximately 1.4% of transcripts contain transcription errors (auto-transcribed phone interactions); flagged and confidence-weighted in training. Approximately 0.3% are partial transcripts (call dropped); excluded from training.
• External resources: Transcripts reference Acme policy documents (versioned in the policy-document repository) and CRM records (referenced by anonymized ID). External resource references retained for traceability.
• Confidential or sensitive content: Transcripts originate from confidential customer interactions; PII removed before fine-tune use; transcripts processed under Acme's confidentiality policy and the Article 13/14 customer-service privacy notice that customers consented to at policy issuance and renewal.
• Protected or special-category subpopulations: Transcripts include interactions with all customer demographic groups represented in the Acme book. Inferred-demographic categories (age band, sex on policy, inferred language preference) used solely for fairness-analysis stratification under the Article 10(5) special-category carve-out and the Acme fairness-metric-selection memo.
• Article 10(2)(f) bias examination: Analysis across query type × inferred-demographic categories identified urban-customer over-representation (62% of training set vs. 54% of book) and slight underrepresentation of customers age 65+ (12% of training set vs. 16% of book). Both flagged for mitigation in Section 4 (Preprocessing) below.
• Article 10(3) statistical properties: Mean transcript length, query-type distribution, and outcome distribution computed and compared to Q1 2026 production distribution; statistical properties appropriate for intended use per the Acme Data Suitability Memo dated April 8, 2026.

Section 3 - Collection Process

• Acquisition method: Transcripts captured automatically by Acme's CRM at the time of customer-service interactions (web chat sessions transcribed verbatim; phone calls auto-transcribed via the speech-to-text vendor with human-review escalation on low-confidence segments).
• Timeframe: January 1, 2023 through December 31, 2025. Three-year window chosen to align with the current policy-product version and to capture seasonal variation across renewal cycles.
• Who collected: Acme employees during the course of customer-service work; no third-party data brokers; no scraped or purchased data.
• Compensation: Customer-service agents are Acme employees compensated under standard employment; customers are policyholders consenting under the policy contract and the Article 13/14 customer-service privacy notice.
• Direct vs third-party vs inferred: All data collected directly from the customer-agent interaction. Inferred-demographic categories used only for fairness analysis are derived from policy records (not separately solicited).
• Notification and consent: Customers receive the Article 13/14-compliant customer-service privacy notice at policy issuance and renewal, with explicit statement that interactions may be used to improve customer-service systems including AI model training. Revocation mechanism documented in the privacy notice; revocation honored by removal of the transcript from training pool on next quarterly refresh.
• Article 10(5) special-category processing: Health-related and other special-category content occasionally appears in customer queries (e.g., claims involving medical bills). Such content processed strictly for bias-monitoring purposes under the Article 10(5) carve-out with safeguards documented in Section 4 (Preprocessing) below: de-identification at ingestion, access controls limiting to the fine-tune pipeline service account, retention limited to the model-version lifecycle, audit log on every read.
• Ethical-review process: Acme AI Governance Committee reviewed and approved the dataset construction plan on March 18, 2026 (minutes archived). Legal and Privacy reviewed and approved on April 2, 2026. DPIA performed per GDPR Article 35 and combined with the Article 27 FRIA where applicable (this fine-tune is not high-risk per Annex III; DPIA performed for the GDPR overlay).
• Legal compliance: GDPR Article 6(1)(b) and 6(1)(f) lawful basis for processing customer-service interaction data; Article 9(2)(g) substantial-public-interest basis for the limited special-category processing for bias monitoring; Article 13/14 transparency satisfied via the customer-service privacy notice. State law (California CPRA, Illinois BIPA where biometric, Washington My Health My Data Act where relevant) reviewed; no biometric or precise-location data in scope.

Section 4 - Preprocessing, Cleaning, Labeling

• Preprocessing steps: (1) De-identification via Acme-approved DLP toolchain: direct identifiers (name, account number, SSN, phone, email, address) replaced with role tokens; (2) Confidence-weighted transcription-error flagging for auto-transcribed phone segments; (3) Removal of low-quality transcripts (call dropped, technical issues); (4) Stratified sampling to mitigate the urban-customer over-representation identified in Section 2 (rural-customer transcripts upsampled by factor 1.15); (5) Stratified sampling to mitigate the age 65+ underrepresentation (upsampled by factor 1.33); (6) Tokenization compatible with the Anthropic Claude 4 tokenizer.
• Raw data preservation: Raw transcripts (pre-DLP) preserved in cold storage with restricted access (audit log on read); processed version used for fine-tune. Retention per Article 18 (10 years for high-risk records; this fine-tune is limited-risk but retained on the conservative posture).
• Software: De-identification via Acme-approved DLP tool (proprietary, vendor-supplied, version 4.2.1). Stratified sampling and tokenization via in-house Python pipeline (version-controlled, code-reviewed). Reproducibility manifest captured in the ML-BoM.
• Labeling: For the supervised-fine-tune objective, the customer-service agent's actual response is the label (the gold-standard target response). For the held-out test set, additional expert-curated labels for 1,000 edge cases were created by senior customer-service supervisors; inter-annotator agreement (Cohen's kappa) of 0.81 on the edge-case subset; labelers compensated at standard supervisor rates with no piecework incentives.
• Quality control: Two-pass review of the held-out test set by independent senior reviewers; disagreement adjudicated by the customer-operations director.
• Article 10(2)(c) data-preparation operations: Annotation (label = agent gold response) + labelling (edge-case expert curation) + cleaning (DLP, error flagging, partial-transcript removal) + updating (quarterly refresh planned) + enrichment (inferred-demographic stratification for fairness analysis) + aggregation (no per-customer aggregation; deduplication validated). All documented in the data-preparation runbook archived in the Article 11 technical file.
• Article 10(2)(g) bias mitigation: Stratified upsampling of underrepresented demographic groups (rural, age 65+); validation that mitigation reduces accuracy gap from 6 percentage points to within 3 percentage points across analyzed groups; ongoing quarterly fairness recomputation.
• Article 10(5) special-category safeguards: De-identification at ingestion (DLP); access controls (service account only; no human direct access to the special-category-flagged subset); retention limited to model-version lifecycle plus the audit window; audit log on every read; periodic review by Privacy team.

Section 5 - Uses

• Has been used for: Fine-tuning Anthropic Claude 4 Opus to produce Acme.ServiceAssist v1.0 (April 15, 2026 fine-tune; May 1, 2026 deployment). Bias and fairness analysis as part of the model-card Section 7 quantitative analyses. OWASP/ATLAS robustness testing leveraged a derived adversarial-prompt subset.
• Other potential uses: Possible future use as evaluation corpus for subsequent fine-tune iterations (held-out test set); possible use as input to a retrieval index for in-context learning with the un-fine-tuned baseline (under review). Any new use requires AI Governance Committee approval and a Use-Approval addendum to this datasheet.
• Repository linking to systems using it: Internal model registry entry MR-2026-014 references this datasheet; cross-references in the Acme AI inventory.
• Tasks the dataset should NOT be used for: Underwriting decisions (Annex III §5(c) territory; dataset is not representative for underwriting and does not include underwriting-decision outcomes); claims-adjudication decisions (separate governance review required); employee performance evaluation (Article 5(1)(f) workplace emotion-recognition prohibition concern; dataset captures customer-side interactions only); training of models intended to predict customer attributes (potential GDPR Article 22 automated-decision concern); sale, license, or transfer to third parties (customer privacy commitment).
• Article 10(2)(a) design-choice link: Out-of-scope uses explicitly stated to prevent dataset-drift into prohibited or unintended use.

Section 6 - Distribution

• Distribution scope: Internal only. Dataset will not be distributed to third parties outside Acme Insurance.
• Distribution mechanism: Access via the Acme data-lakehouse with role-based access control. Service account access for the fine-tune pipeline; read-only audit access for the AI Officer team; no end-user access.
• License or terms of use: Internal-use license under Acme's enterprise data-use policy. No external distribution permitted without written approval from the Chief Privacy Officer and the AI Governance Committee.
• Export controls or regulatory restrictions: Dataset includes U.S. customer data only; no cross-border transfer at this time. GDPR Chapter V international-transfer mechanism not applicable. EU AI Act Article 53(1)(c) copyright policy not applicable (no third-party copyrighted content in the dataset; transcripts are Acme-customer interactions).
• Article 10(2)(b) origin documentation: Acme internal CRM; provenance chain documented (CRM → de-identification pipeline → fine-tune pipeline → model registry) with hash at each stage captured in the ML-BoM.
• Future external distribution: If considered in the future (e.g., for a published research benchmark with re-consented and re-anonymized subset), this datasheet would be updated and a new Article 13/14 customer notification cycle would be required.

Section 7 - Maintenance

• Maintainer: Acme ML Engineering Lead (technical custody); AI Officer (compliance custody); Customer Operations VP (business owner).
• Contact: [email protected]
• Erratum mechanism: Issues with the dataset reported to the data-governance address; logged in the dataset-issue tracker; triaged within 5 business days; remediated in the next quarterly refresh or sooner if material.
• Update plan: Quarterly refresh adding the most recent quarter's transcripts and removing the oldest quarter to maintain a rolling three-year window. Refresh triggers re-running the Article 10(2)(f) bias examination and Article 10(2)(h) gap identification; results documented as a datasheet amendment.
• Retention limits on personal data: Raw transcripts retained per the Acme records-retention schedule (seven years for customer-service interactions); de-identified fine-tune dataset retained per Article 18 (10 years on the conservative posture); customer revocation honored at next quarterly refresh.
• Deprecation plan: When the dataset is superseded by the next major version (e.g., when the policy-product version changes and transcript vocabulary diverges), the prior version is retained in cold storage for the Article 18 record-keeping window with read access restricted to the AI Officer team for audit purposes.
• Older versions: Versioned per the ML-BoM identifier; each version associated with a specific fine-tune model version and retained for the model-version lifecycle plus audit window.
• Contribution mechanism: Not applicable (internal dataset). For internal contributions (e.g., supervisors adding edge-case labels), the labeling-pipeline workflow applies with two-pass review and inter-annotator agreement tracking.
• Article 10(2)(h) gap identification: Current gaps identified: limited coverage of niche policy types (farm policies, watercraft endorsement, mobile-home policies; combined 2.1% of training set); limited coverage of Spanish-language interactions (3.4% of training set vs. 7.2% of book in service-language preference); seasonal-event-spike coverage (named-storm CAT events) underrepresented (data limited to the relatively quiet 2023-2025 weather window). Each gap mapped to a remediation plan: niche-policy upsampling in Q3 2026 refresh; Spanish-language transcript-acquisition plan with the bilingual customer-service team; CAT-event corpus expansion as event data accumulates.

Cross-Walks, GDPR Overlay, and Integration with Model Card + ML-BoM

The Acme customer-service-transcript datasheet serves multiple frameworks and integrates with the other documentation artifacts:

• EU AI Act Article 10, Full coverage of Article 10(1) through Article 10(5) as documented above. Datasheet is the single artifact that closes Article 10 in the Annex IV technical file.
• GDPR Article 9 + Article 35 overlay, Article 9 special-category processing addressed via Article 9(2)(g) substantial-public-interest basis and the Article 10(5) AI-specific carve-out with safeguards; Article 35 DPIA performed and combined with the Article 27 FRIA where applicable.
• ISO/IEC 42001:2023 A.7 (data governance), A.7.2 data acquisition (Section 3); A.7.3 data preparation (Section 4); A.7.4 data quality (Sections 2, 3, 4); A.7.5 data provenance (Section 6); A.7.6 data privacy (Sections 3, 4 safeguards).
• NIST AI RMF, Map 4 (third-party data inputs and risks) and Measure 1 (appropriate methods identified), datasheet is the artifact that demonstrates Map 4 + Measure 1 evidence.
• NIST AI 600-1 GenAI Profile, Risk 4 (data privacy): de-identification + safeguards. Risk 12 (harmful bias and homogenization): bias examination + mitigation in Section 4. Risk 6 (information integrity): transcription-quality flagging + adjudication. Risk 11 (value chain and component integration): provenance chain in Section 6.
• Integration with the model card, The fine-tune model card (lesson 026, Acme.ServiceAssist v1.0) Section 6 (Training data) cites this datasheet by versioned identifier; the datasheet provides the depth that the model card section summarizes.
• Integration with the ML-BoM (CycloneDX 1.7, lesson 029): The dataset appears as a CycloneDX component with version identifier, lineage hash, supplier (internal), and reference to this datasheet. ML-BoM provides the SBOM-style supply-chain view; datasheet provides the data-governance depth.
• Integration with the AI inventory: Dataset row links to the datasheet, the model card, the ML-BoM, the Article 11 technical file, and the Annex IV §2(d) data-requirements evidence.

Publication, Retention, and Refresh

The datasheet is an internal document with regulator-facing readiness. Publication scope, retention, and refresh cadence:

• Publication scope: Internal, Engineering, AI Officer team, Legal, Privacy, AI Governance Committee, full access. Regulator-facing, full datasheet furnished on request as part of Annex IV §2(d) data-requirements evidence. Customer-facing, high-level summary in the Acme AI transparency report.
• Retention: Article 18 record-keeping window (10 years on the conservative posture even though the deployed model is limited-risk); ISO 42001 A.7.5 data-provenance retention; aligned with the model-version lifecycle plus audit buffer.
• Refresh cadence: Quarterly amendment cycle aligned with the model-card quarterly refresh and the fine-tune dataset quarterly refresh. Triggered amendment on substantial-modification events (next fine-tune; new training-data sources; threshold changes), Commission interpretive notes on Article 10 expectations, and significant findings (new bias signal, new gap identification, customer revocations triggering removal).

Six Common Datasheet Mistakes - and the Defensible Posture

Mistake 1 - Skipping the Datasheet Entirely

The model card says "see datasheet"; no datasheet exists. Article 10 obligations are unsupported by evidence; Annex IV §2(d) data-requirements section is bare; the bias-examination claim in the model card has no underlying methodology document. Defensible posture: every high-risk training dataset has a datasheet; the datasheet is created as part of the data-acquisition workflow and updated quarterly.

Mistake 2 - Using a Generic Template Without Gebru-et-al. Depth

An organization adopts a one-page "dataset summary" template missing most of the Gebru-et-al. questions. Composition is two sentences; collection process is one sentence; preprocessing is unlabeled. Defensible posture: walk every Gebru-et-al. question; if a question is not applicable, say so explicitly and explain why; depth is the audit-defensibility signal.

Mistake 3 - No Bias Examination in the Composition Section

Article 10(2)(f) requires bias examination; the datasheet's Composition section lists counts and split sizes but no demographic stratification, no representation analysis, no identification of over-represented or under-represented subpopulations. Defensible posture: include the bias examination in Composition; cite the methodology (the fairness-metric-selection memo); name the over-/under-representation findings; link to the Preprocessing section mitigation steps.

Mistake 4 - No Gap Identification in the Maintenance Section

Article 10(2)(h) requires identification of relevant data gaps and how those gaps will be addressed. A datasheet that lists update cadence but never names a single gap leaves the Article 10(2)(h) obligation unmet. Defensible posture: name the gaps (niche policy types, language coverage, seasonal variation), the remediation plan for each, and the timeline.

Mistake 5 - Treating the Datasheet as a Static Document

The datasheet was written once at dataset creation and never updated. The dataset has refreshed twice; new customer revocations have been honored; new bias-examination findings have not been incorporated. Defensible posture: quarterly amendment cycle aligned with dataset refresh; triggered amendments on material events; version history archived for regulator inspection.

Mistake 6 - No GDPR Article 9 Documentation for Special-Category Processing

The dataset includes occasional health-related content (medical-bill claims). The Article 10(5) carve-out is cited but no GDPR Article 9 lawful basis is documented, no safeguards detailed, no DPIA referenced. Defensible posture: explicitly cite the Article 9(2)(g) substantial-public-interest basis (or the applicable Article 9 lawful basis), the Article 10(5) AI-specific carve-out, the safeguards (de-identification, access controls, retention limits, audit log), and the DPIA reference.

Key Takeaways

• Gebru et al. (2018 / 2021) Datasheets for Datasets proposed the seven-section structured documentation artifact for ML training data. Motivation, composition, collection process, preprocessing, uses, distribution, maintenance.
• EU AI Act Article 10 made the datasheet effectively mandatory for high-risk training data in the Union. Article 10(1) data-governance practices; Article 10(2)(a)-(h) covering design choices, origin, preparation operations, assumption formulation, suitability assessment, bias examination, bias mitigation, gap identification; Article 10(3) statistical-properties expectation; Article 10(4) intended-purpose context; Article 10(5) special-category carve-out with safeguards.
• The seven Gebru-et-al. sections map line-by-line to Article 10 sub-paragraphs. One datasheet, one Article 10 compliance evidence base.
• The Composition section is where the Article 10(2)(f) bias examination lives. Demographic stratification, representation analysis, identification of over- and under-represented subpopulations.
• The Preprocessing section is where the Article 10(2)(g) bias mitigation lives. Stratified sampling, upsampling, re-weighting; validation that mitigation reduces measured gap.
• The Maintenance section is where the Article 10(2)(h) gap identification lives. Named gaps, remediation plans, timelines, not just an update-cadence statement.
• GDPR Article 9 + Article 35 overlay applies whenever the dataset includes personal data. Article 9 lawful basis, safeguards documentation, DPIA reference; combined with the Article 10(5) AI-specific carve-out for bias monitoring.
• The datasheet integrates with the model card (Section 6) and the ML-BoM (CycloneDX 1.7 dataset component). Model card cites the datasheet; ML-BoM references the datasheet by versioned identifier; the three artifacts form one coherent evidence base.
• The datasheet is a living document. Quarterly amendment aligned with dataset refresh; triggered amendments on substantial-modification events, Commission interpretive notes, new findings.
• Six mistakes to avoid. Skipping the datasheet entirely; using a generic template without Gebru-et-al. depth; no bias examination in Composition; no gap identification in Maintenance; treating the datasheet as static; no GDPR Article 9 documentation for special-category data.