# 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. Source playbook: https://aigovernance.com/playbook/training-data-privacy-compliance --- ## Training data provenance record _One 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. --- ## PII assessment methodology _A 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. --- ## Data minimization checklist _Cut 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. --- ## Data subject rights response template (training data) _A 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 - **DGC-001**: The provenance record is the training data provenance and lawful-basis documentation. - **DGC-002**: The PII assessment method is the PII handling standard applied to training data. - **DGC-003**: The minimization checklist is the data minimization record for training datasets. - **CMP-007**: The provenance and PII records supply the training-data governance evidence an EU AI Act high-risk conformity assessment requires. - **ALC-004**: Provenance records retained with the model support explainability and audit documentation.