# 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. Source playbook: https://aigovernance.com/playbook/data-privacy-compliance-and-ai --- ## AI data processing inventory _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 | |---|---|---|---|---|---|---| | | | 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. --- ## GDPR Article 22 compliance checklist _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. --- ## Data subject rights process for AI _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. --- ## Transfer mechanism verification log _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 | |---|---|---|---|---|---|---|---| | | | EEA | | SCC / adequacy / DPF | Y / N | YYYY-MM-DD | | ### 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 - **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.