Data Card — datasheet for a training, validation or test dataset

Structure (8 sections)

1. 1. 1. Dataset identity, version and purpose

   Give the dataset a unique identifier and version (snapshot date or version number), state which models and model versions use it and at which stage (pre-training, continued pre-training, supervised fine-tuning, preference optimisation, evaluation), and record why the dataset was created in the first place. Describe its physical form too: storage location, format, size in samples and bytes, sharding, and who owns access. Distinguish the original collection purpose from the current use: where data was first collected for another business purpose and is now used for training, that gap triggers the GDPR Art. 6(4) compatibility analysis and the purpose-change argument under PIPL, so flag it here and point to the relevant DPIA or PIPIA section.

   Evidence to attach

   • · Dataset identifier and version register, with snapshot dates and hashes
   • · Usage matrix mapping dataset version to model version and training stage
   • · Storage locations and an access-permission matrix
   • · Comparison of the original collection purpose with the current use
   • · Index to the compatibility analysis in the DPIA or PIPIA

   Common pitfalls

   • · No version or snapshot identifier, so nobody can later reproduce which data a given model version used;
   • · A current use that differs from the original collection purpose with no compatibility analysis;
   • · Size given as "large", which cannot support the range ticked in the training-content summary;
   • · Access rights never reviewed, leaving departed staff able to reach the raw corpus.

2. 2. 2. Provenance, acquisition method and rights basis

   Record item by item: the source type (public dataset, commercial licence, purchase through a data intermediary, first-party user data, web crawling, offline digitisation, human authoring, synthetic generation); the specific source identifier (dataset name and link, vendor name and contract number, crawled domain scope, internal system name); the acquisition period; and the rights basis. Split the rights basis in two: intellectual property — licence type and version, whether commercial use is permitted, whether training is permitted, whether attribution or copyleft terms apply, and how TDM rights-reservation signals were detected and honoured; and personal information — whether personal or sensitive personal information is present, the lawful basis, how notice and consent were obtained, and how data subjects can actually exercise their rights. For purchased data, additionally record the rights chain: can the vendor show it had the right to license to you, and what warranties and indemnities does the contract carry. This is the section rightsholders and regulators probe hardest, and the only one that cannot be reconstructed later — if nothing was recorded at acquisition, nothing can be produced afterwards.

   Evidence to attach

   • · Source inventory (type, identifier, period, scale)
   • · Licence texts and a review record of the terms (commercial use, training, attribution, copyleft)
   • · Purchase contracts with extracts of the vendor’s warranties and indemnities
   • · Configuration and evidence for detecting and honouring TDM rights reservations, with effective dates
   • · Crawled-domain list and robots.txt compliance records
   • · Statement of the lawful basis for personal information, with notice and consent evidence
   • · Register of rightsholder complaints and removal requests

   Common pitfalls

   • · Reading "open source" and stopping there, without checking whether commercial use or training is prohibited;
   • · A vendor unable to show its rights chain and a contract with no indemnity, so the risk sits with you;
   • · TDM reservations honoured only from a certain date, with earlier corpora neither reprocessed nor explained;
   • · Claiming "no personal information" with no screening method and no sampling evidence;
   • · Crawl scope described as "public web pages" with no domain list, leaving nothing from which to generate the summary’s domain disclosure.

3. 3. 3. Composition and statistical characteristics

   Give a checkable description of composition: number of samples and their unit (records, images, hours, tokens); modality and format; content-type distribution by topic, genre and domain with proportions; language distribution listing the top languages with shares and noting EU official language coverage separately, which section 1.3 of the training-content summary expressly asks you to focus on; temporal distribution (the span of creation dates and recency); geographic and source distribution (site types, institution types, countries); and field structure, with a field list and value ranges for structured data. Where the dataset contains personal information, give the order of magnitude per category and tag the sensitive categories. State the counting convention: whether shares are by sample count or by bytes, whether statistics are sampled or exhaustive, and the date and dataset version they refer to. Those conventions decide whether determinations such as "this dataset exceeds 3% of all publicly available datasets for that modality" hold up.

   Evidence to attach

   • · Composition statistics report stating the convention, date and dataset version
   • · Language distribution table including EU official language coverage
   • · Content-type and domain distribution table
   • · Temporal distribution and the recency cut-off
   • · Field list and value distributions for structured data
   • · Personal information categories tagged with orders of magnitude
   • · The statistics script and a reproducible calculation record

   Common pitfalls

   • · No stated convention, so the same dataset shows different proportions in different documents;
   • · A language distribution of "multilingual", which cannot support the summary’s linguistic characteristics field;
   • · No order-of-magnitude estimate for personal information, leaving the DPIA and PIPIA nothing to cite;
   • · Statistics computed once and never recomputed after the dataset was updated;
   • · No temporal distribution, so "what is the knowledge cut-off" cannot be answered.

4. 4. 4. Cleaning, filtering and deduplication

   Annex IV item 2(d) expressly asks for data-cleaning methodologies such as outlier detection, and Annex XI item 2(c) for curation methodologies such as cleaning and filtering together with all other measures to detect the unsuitability of data sources. Walk the pipeline stage by stage: deduplication (exact and near-duplicate methods with thresholds, and cross-dataset deduplication); quality filtering (rules, classifiers, language identification, perplexity filtering and their thresholds); harmful-content filtering (the category taxonomy, detection method, and an assessment of recall and false positives); personal information handling (detection method and the decision rules for masking, deleting or retaining); removals relating to copyright and rights reservations; and isolation from evaluation sets, with the contamination-detection method and results. Give the volume before and after each stage: those numbers both demonstrate the processing happened and supply the "after pre-processing" figures the training-content summary asks for. Version the pipeline, since different dataset versions correspond to different processing configurations — otherwise there is no way to explain why the same source yielded different volumes twice.

   Evidence to attach

   • · Pipeline description and versioned configuration files
   • · Before/after volume table for each stage
   • · Deduplication method and thresholds, and the scope of cross-dataset deduplication
   • · Harmful-content taxonomy and effectiveness evaluation (recall, false positives, sampled human review)
   • · Decision rules for detecting and handling personal information, with sampled verification
   • · Contamination-detection method and results against the evaluation sets
   • · Job logs and reproducible scripts for the processing runs

   Common pitfalls

   • · A pipeline listing step names with no parameters or thresholds, so nothing can be reproduced;
   • · Harmful-content filtering reporting recall but not false positives, while quietly removing large volumes of ordinary text;
   • · No cross-dataset deduplication, so the same content is counted several times toward the total;
   • · No contamination check against evaluation sets, which undermines the credibility of every evaluation result;
   • · An unversioned processing configuration, leaving volume differences between batches unexplained.

5. 5. 5. Labelling rules, quality control and labellers

   Annex IV item 2(d) asks for labelling procedures, for example in supervised learning. Art. 8 of China’s Interim Measures is more specific: labelling requires clear, specific and workable rules consistent with the Measures; quality assessment of the labelling with sampled verification of accuracy; and necessary training for labellers with supervision and guidance so they work to standard. Record: the task definition and label taxonomy; the version and change history of the labelling rules; the workflow (single or multiple annotation, adjudication, dispute handling); quality control (inter-annotator agreement metrics and their values, sampling rate and accuracy of review, rework mechanism); the labelling workforce (in-house or outsourced, size, training content and assessment, language and domain competence, whether they see personal information and the confidentiality and access arrangements that follow); and the processing of personal information during labelling, including whether labellers see raw personal data and how that is minimised. For outsourced labelling, also record the vendor’s labour-compliance and data-security requirements, which EU enterprise customers ask about in supply-chain diligence.

   Evidence to attach

   • · Labelling rules with version and change history
   • · Label taxonomy definitions and boundary-case guidance
   • · Inter-annotator agreement metrics and values, by task type
   • · Sampled review records, accuracy statistics and the rework register
   • · Labeller training materials, assessments and qualification records
   • · Outsourced labelling contracts covering data security, confidentiality and labour compliance
   • · Access controls in the labelling environment and personal-information minimisation measures

   Common pitfalls

   • · Labelling rules existing only as verbal convention or chat messages, with no formal text or version;
   • · No agreement metrics, so quality rests entirely on the vendor’s own account;
   • · A sampling rate so low (one in a thousand) that the claimed accuracy is unsupported;
   • · Labellers with direct access to raw personal data and no access records;
   • · An outsourcing contract with no data-security or confidentiality clauses, which loses points immediately in supply-chain diligence.

6. 6. 6. Bias, representativeness and known defects

   Art. 10 requires training, validation and testing datasets for high-risk systems to be relevant and sufficiently representative for the intended purpose, to the best extent possible free of errors and complete, and to be examined for possible biases. Answer four questions. Representativeness: how well the dataset covers the intended population and settings, and where the gaps are, along relevant dimensions such as language, region, age, sex, ethnicity, industry and device type. Bias: the types identified (selection, measurement, historical, annotator, aggregation bias), the detection method and quantified results. Known defects: error and noise rates, label quality issues, residual duplicates and near-duplicates, temporal drift, and uses the dataset is unsuited to. Mitigation and residual: measures taken (resampling, weighting, augmentation, targeted collection, post-processing constraints) with evidence they worked, and the bias that remains afterwards. Marking a dimension "not assessed" is more credible than claiming "no bias" — Art. 10 asks for examination of possible biases, not a declaration that none exist.

   Evidence to attach

   • · Representativeness analysis comparing the target distribution with the actual one across the relevant dimensions
   • · Bias detection methods and quantified results per dimension
   • · Known-defects list (error rate, noise, residual duplicates, temporal drift)
   • · Mitigations and evidence of their effect
   • · Statement of residual bias and of uses the dataset is unsuited to
   • · Explicit marking of dimensions not assessed, with reasons

   Common pitfalls

   • · Skipping bias analysis entirely because "we do not collect ethnicity or sex data", with no proxy indicator or qualitative method;
   • · Declaring the dataset "unbiased", when Art. 10 asks for examination of possible biases;
   • · Measuring representativeness against the dataset’s own distribution rather than the intended population;
   • · Mitigations listed but never validated, leaving residual bias unknown;
   • · No discussion of temporal drift, leaving post-launch performance decay unexplained.

7. 7. 7. Personal information handling and data subject rights

   Where the dataset contains personal information, this section feeds the DPIA and PIPIA directly. Record: the categories present and whether any are special-category or sensitive personal information; the detection method (regular expressions, named-entity recognition, classifiers) with its recall and false-positive rates; the handling strategy (delete, mask, pseudonymise, retain) with the decision rules and coverage of each; the lawful basis and the position on notice and consent; how data subject rights are actually executable at dataset level — how an access, rectification or erasure request is traced to specific samples, and what the fallback is when tracing fails; and the dataset’s retention period and deletion mechanism. Spell out the technical boundary of erasure in particular: the feasibility and cost of removing data from the corpus, from the index, and from an already-trained model, and which approach the company actually takes. Customers, regulators and data subjects ask this repeatedly, so write it once in the data card and keep the wording consistent rather than improvising each time.

   Evidence to attach

   • · Personal information detection method and its evaluation (recall, false positives, sampled review)
   • · Handling strategy and coverage statistics
   • · Lawful-basis statement and an index to the notice and consent evidence
   • · How data subject requests are traced within the dataset, with test records
   • · How erasure is handled at corpus, index and model level, with a cost assessment
   • · Dataset retention period and deletion execution records
   • · Cross-references to the corresponding DPIA and PIPIA sections

   Common pitfalls

   • · Claiming de-identification where only direct identifiers were removed and re-identification risk was never assessed;
   • · Detecting personal information with regular expressions alone, giving low and unmeasured recall on unstructured text;
   • · No way to trace a data subject request to specific samples, and no fallback described;
   • · The data card, DPIA and PIPIA describing the same dataset’s personal information differently;
   • · A retention period of "long term" that contradicts the commitment in the privacy policy.

8. 8. 8. Maintenance, distribution and version changes

   Describe the dataset lifecycle: the maintainer and team; update frequency and method (incremental append, full rebuild, rolling window); a version changelog recording what changed, why, and which model versions are affected; quality monitoring (periodic recomputation of statistics, drift detection, anomaly alerts); and the retirement and deletion policy. For distribution, record whether the dataset goes outside the company, to whom and under what licence, what processing precedes distribution (masking, sampling, licence restrictions), and the recipient’s use restrictions and audit arrangements. If it is not distributed externally, still record the internal distribution boundary — which teams may access it, whether export is permitted, and any restriction on cross-border access — which maps directly onto the remote-access flows in the transfer impact assessment. Finally, record the maintenance of the data card itself: document version, last update, owner, and the mechanism keeping it in step with the model card and the public training-content summary, so the three do not drift apart.

   Evidence to attach

   • · Maintainer and update plan
   • · Version changelog (change, reason, affected model versions)
   • · Quality-monitoring configuration and the most recent results
   • · Distribution list (recipients, licence, processing applied, audit arrangements)
   • · Internal access boundary and any cross-border access restriction
   • · Data card version history and the reconciliation record across the three documents
   • · Retirement and deletion execution records

   Common pitfalls

   • · A dataset updated continuously while the data card stays at its first version, so the statistics no longer describe reality;
   • · An undefined internal access boundary, with overseas teams reaching raw personal data directly while the TIA records no such flow;
   • · External distribution without a licence or use restrictions, and the recipient redistributing it;
   • · No synchronisation between data card, model card and public summary, so their figures contradict each other;
   • · Retired datasets still sitting in object storage because the deletion policy was never executed.