Implementation Kit
AI Training Data Provenance Template and Privacy Checklist
Whether you may use a dataset for this training purpose, and what you owe the people in it. A provenance record, a PII assessment method, a minimization checklist, and a data subject rights response template for training data.
Who this is for: The ML lead and privacy partner clearing a dataset before it is used to train or fine-tune a model.
1. Training data provenance record
SpreadsheetOne per dataset. Source, the basis it was collected under, and whether training is a compatible use.
Template
| Field | Entry |
|---|---|
| Dataset name and version | |
| Source (internal system, vendor, public, scraped) | |
| Original collection context and date range | |
| Legal basis for original collection | |
| Training-use compatibility assessment | compatible / incompatible / needs new basis + reasoning |
| PII assessment result | none / de-identified / contains PII (see PII assessment) |
| Licensing / terms of use for the data | |
| Approved for training by | name, date |
Worked example
| Field | Entry |
|---|---|
| Dataset | hiring-outcomes-2021-2026 v3 |
| Source | internal HRIS |
| Original context | recruitment administration; records 2021-01 to 2026-06 |
| Legal basis | legitimate interest (HR administration) |
| Training-use compatibility | Needs assessment: model training is a new purpose. Compatibility memo concludes it is compatible given the recruitment nexus and anonymization; approved by DPO. |
| PII assessment | Contains PII in raw form; training extract de-identified (see PII assessment) |
| Licensing | internal data, no third-party terms |
| Approved for training by | DPO + ML Lead, 2026-07-05 |
Acceptance criteria
- ✓Every dataset used in training or fine-tuning has a provenance record.
- ✓The training-use compatibility assessment has explicit reasoning, not just a yes.
- ✓The record is retained as part of the model documentation.
2. PII assessment methodology
SpreadsheetA consistent way to classify what identifiers a dataset contains.
Template
| Category | Definition | Examples | Handling |
|---|---|---|---|
| Direct identifiers | Identify a person on their own | name, email, phone, government ID, account number | remove or tokenize before training |
| Quasi-identifiers | Identify in combination | postcode, birth date, job title + employer, rare attributes | generalize, bucket, or assess re-identification risk |
| Special-category data | Sensitive under law | health, race, religion, sexual orientation, biometrics, trade union | remove unless a specific condition is met and documented |
| Free-text fields | May contain any of the above | CV text, notes, transcripts | run entity detection; redact or exclude |
Worked example
Applied to hiring-outcomes-2021-2026:
| Field | Category | Action taken |
|---|---|---|
| candidate_name, email | Direct | removed; replaced with a salted hash not used as a feature |
| postcode + application_date | Quasi | postcode truncated to district; date bucketed to month |
| CV free text | Free-text (mixed) | entity detection for names, contact info, and health mentions; redacted |
| self-identified ethnicity | Special-category | excluded from the training extract entirely; retained separately for bias testing only |
| Re-identification risk on the extract assessed as low (k >= 20 on quasi-identifier combinations). |
Acceptance criteria
- ✓Every field is placed in a category, and free-text fields are scanned, not assumed clean.
- ✓Special-category data is excluded from training inputs unless a documented condition applies.
- ✓Re-identification risk on the final extract is assessed, not just direct identifiers removed.
3. Data minimization checklist
SpreadsheetCut the dataset to what the training purpose actually needs.
Template
| Check | Done | Note |
|---|---|---|
| Every field has a stated reason it is needed for this model | Y / N | |
| Fields with no modeling value removed | Y / N | |
| Precision reduced where full precision is not needed (dates to month, location to region) | Y / N | |
| Records aggregated or sampled where individual rows are not required | Y / N | |
| Retention limit set for the training extract | Y / N | |
| Differential privacy or noise considered for sensitive aggregates | Y / N | decision + reason |
Worked example
| Check | Done | Note |
|---|---|---|
| Field-by-field justification | Y | 41 source fields reduced to 18 |
| No-value fields removed | Y | dropped internal workflow IDs, recruiter names |
| Precision reduced | Y | dates to month; location to district |
| Aggregated / sampled | Partial | full rows needed for the label; no down-sampling |
| Retention limit | Y | extract deleted 18 months after the model version retires |
| Differential privacy | N | decided against for a supervised model on this scale; noted |
Acceptance criteria
- ✓Each retained field has a documented modeling justification.
- ✓Precision and retention are reduced to what the purpose needs.
- ✓The minimization decisions are recorded in the provenance record.
4. Data subject rights response template (training data)
DocumentA consistent answer when someone asks what happened to their data in your training set.
Template
Use for access, erasure, and objection requests that touch training data.
- Was the requester's data in a training set? how you checked, and the result
- Access response: what categories of their data were used, for which model versions, and the source dataset
- Erasure response: removal from raw datasets and operational stores; position on the trained model (retrain cadence, filtering, or a documented feasibility limit)
- Objection response: how future processing of their data is prevented (exclusion from the next training extract, suppression at inference)
- Machine unlearning statement: your standing position and compensating measures
- Timeframe and contact
Worked example
- In a training set? Checked the hashed-identifier index for the 2021-2026 extract: yes, the requester's application record was included.
- Access: categories used were work history, education, and application date (generalized); model versions 2.0 through 2.4; source dataset hiring-outcomes-2021-2026.
- Erasure: raw record deleted from HRIS and the raw dataset; the training extract is de-identified with no recoverable link, so targeted removal from the trained model is not feasible; the next scheduled retrain (Q1) will be built from a rebuilt extract that excludes the deleted record.
- Objection: the requester is added to the training exclusion list and an inference suppression list.
- Unlearning statement: we do not perform per-record unlearning on deployed models; compensating measures are the exclusion list and the retrain cycle.
- Timeframe: completed within the statutory window; contact privacy@company.example.
Acceptance criteria
- ✓You can actually determine whether a given person was in a training set.
- ✓The response distinguishes raw datasets from the trained model and is honest about feasibility.
- ✓Objection produces a concrete exclusion, not only an acknowledgement.
Governance controls this kit produces evidence for
Completing the artifacts above gives you a head start on the evidence requirements for these controls.
The provenance record is the training data provenance and lawful-basis documentation.
The PII assessment method is the PII handling standard applied to training data.
The minimization checklist is the data minimization record for training datasets.
The provenance and PII records supply the training-data governance evidence an EU AI Act high-risk conformity assessment requires.
Provenance records retained with the model support explainability and audit documentation.
This kit backs one playbook. Read the full guidance for the reasoning behind each artifact.
Decide what to implement next
Assess your governance gaps, then create an action plan with owners and target dates. Build and export without an account; sign in when you want to save your plan.
Start the AI governance assessment →