AI Privacy Checklist and Data Processing Inventory

Confirming a lawful basis for personal data at every stage of an AI system and that data subject rights still work. A data processing inventory by stage, a GDPR Article 22 checklist, a data subject rights process that reaches training data, and a transfer mechanism verification log.

Who this is for: The privacy or data protection officer mapping AI processing against the law.

Download the kit (Markdown) ↓4 artifacts. Every table also copies as CSV.

1. AI data processing inventory

Spreadsheet

Personal data use per system, broken out by stage, since the lawful basis can differ between training, inference, and output.

Template

System	Personal data	Stage	Lawful basis	Purpose-limitation check	Cross-border transfer	Transfer mechanism
<system>	<categories, special category?>	training / inference / output	consent / contract / legitimate interest / legal obligation	compatible with original purpose? Y/N + note	Y / N	SCC / adequacy / DPF / n/a

Worked example

System	Personal data	Stage	Lawful basis	Purpose-limitation check	Cross-border	Mechanism
Resume Screener	CV content, contact, work history; special-category possible	inference	legitimate interest (recruitment) with notice	Y, recruitment is the original purpose	N	n/a
Resume Screener	5-yr hiring outcomes	training	legitimate interest	Contested: outcomes collected for HR admin, not model training. Assessment on file.	N	n/a
Support Copilot	ticket text, order metadata	inference	contract performance	Y	Y (vendor US processing)	SCC + DPF

Acceptance criteria

✓Every system has a row per stage where personal data is processed.
✓The purpose-limitation check is answered, and any "contested" is backed by a written compatibility assessment.
✓Special-category data is flagged explicitly per row.

2. GDPR Article 22 compliance checklist

Spreadsheet

For systems that make or heavily inform decisions about individuals with legal or similarly significant effect.

Template

Obligation	Applies?	Evidence
Decision is not solely automated, or falls under an Art. 22(2) exception	Y / N
Data subject informed that automated decision-making is used, with meaningful information about the logic	Y / N
Right to obtain human intervention is available and usable	Y / N
Right to express a point of view and contest the decision is available	Y / N
Suitable safeguards documented (regular bias testing, accuracy checks)	Y / N
Special-category data not used unless Art. 22(4) condition met	Y / N

Worked example

Obligation	Applies?	Evidence
Not solely automated or has an exception	Y	recruiter reviews every score; documented in oversight arrangement
Data subject informed + meaningful logic info	Partial	privacy notice mentions AI screening; "meaningful logic" description being added
Human intervention available	Y	reply-to-recruiter route, 14-day window
Express view / contest	Y	reconsideration process
Safeguards documented	Y	monthly adverse-impact eval; accuracy review
Special-category data condition	N/A	special-category data not used as a model input

Acceptance criteria

✓Each obligation is answered for every system that could fall under Article 22.
✓"Meaningful information about the logic" exists as a written, plain-language description, not just a mention that AI is used.
✓The human-intervention route is real and has a stated timeframe.

3. Data subject rights process for AI

Document

How access, erasure, and objection are handled when the data is in a model or its training set.

Template

Extends the standard DSAR process. Covers training data and model outputs.

Access: how you identify what personal data about the requester was used at each stage; what you disclose about inference inputs and any profiling
Erasure: removal from operational stores and logs; position on training data (retrain cadence, filtering, or documented justification for retention)
Objection / restriction: how a system is configured to stop processing a specific individual's data
Rectification: correcting input data and re-running the decision where appropriate
Machine unlearning limitations: your documented position on why full removal from a trained model may not be feasible, and the compensating measures
Timeframes and ownership: who runs each step and by when

Worked example

Access: pull the decision log records for the subject_ref; disclose the feature categories used and the score; for training, confirm whether their records were in the training extract.
Erasure: delete from application stores and the decision log after the retention period; the training extract is anonymized at build time, so individual erasure from the model is not applicable; documented.
Objection: add the individual to a suppression list that excludes them from model scoring; fall back to manual review.
Machine unlearning: our position is that the anonymized training extract contains no recoverable personal data; if a raw dataset were ever used, the policy is to retrain on the next scheduled cycle and filter in the interim.
Timeframes: privacy team triages within 5 days; system owner executes within the statutory window.

Acceptance criteria

✓The process explicitly addresses training data, not only operational stores.
✓There is a written, defensible position on machine unlearning limitations.
✓Objection results in a real configuration change (suppression, manual fallback), not just a note.

4. Transfer mechanism verification log

Spreadsheet

Proof that every cross-border flow of EU personal data through an AI vendor has a valid mechanism.

Template

Vendor	Data category	Origin	Destination	Mechanism	TIA done?	Verified on	Owner
<vendor>		EEA	<country>	SCC / adequacy / DPF	Y / N	YYYY-MM-DD	<name>

Worked example

Vendor	Data category	Origin	Destination	Mechanism	TIA done?	Verified on	Owner
Zendesk	ticket text, order metadata	EEA	US	SCC + DPF certification	Y	2026-08-20	DPO
Anthropic	contract text (may contain personal data)	EEA	EU region pinned	intra-EEA, no transfer	n/a	2026-07-02	DPO

Acceptance criteria

✓Every vendor processing EEA personal data outside the EEA has a row with a named mechanism.
✓A transfer impact assessment is recorded where required.
✓The log has a verification date and is refreshed at vendor review.

Governance controls this kit produces evidence for

Completing the artifacts above gives you a head start on the evidence requirements for these controls.

DGC-002

The processing inventory documents where personal data enters each AI system and under what basis.

DGC-005

The transfer verification log is the cross-border data transfer control record.

HOC-002

The Article 22 checklist confirms a usable human-intervention route on automated decisions.

DGC-004

The DSAR process defines retention and deletion behaviour for AI inputs, outputs, and logs.

PRC-002

The inventory drives AI-specific DPA clauses (training use, inference location, retention) into vendor contracts.

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 →