AI Privacy Impact Assessment Checklist

Traditional privacy assessments map personal data through databases and applications. AI systems add flows those maps miss: personal data in prompts and conversation history, in retrieved documents, in agent memory, in traces and evaluation sets, and in processing by model providers, plus risks of memorization and inference. This checklist structures an assessment that covers them. It complements ai data privacy compliance, ai and gdpr, and ai and ccpa compliance. This is general guidance, not legal advice.

Who should use this checklist?

Privacy officers and counsel, engineering owners of AI systems, security teams, and governance functions approving deployments that process personal data.

Is the assessment scoped?

1. The system, purpose, and users are described.
2. Personal data categories identified, including sensitive categories.
3. Data subjects identified: customers, employees, third parties.
4. Assessment trigger and requirement confirmed for the jurisdictions involved.
5. Assessment owner and sign-off authority named.

Are all AI data flows mapped?

Flow	Mapped?
Inputs: prompts, uploads, conversation history
Retrieval: indexed documents, chunks, embeddings, permissions
Memory: stored preferences, facts, episodes
Model processing: providers, regions, subprocessors
Outputs: responses, actions, downstream systems
Traces and logs: prompts, outputs, tool calls
Evaluation datasets: golden sets and production samples
Human review: reviewers' access to content

Reference: the AI observability whitepaper and how to build long-term memory for ai agents.

Is there a legal basis and purpose per flow?

1. Purpose defined per flow, including secondary uses such as evaluation and improvement.
2. Legal basis identified per flow and jurisdiction.
3. Consent obtained where required, with records.
4. Compatibility of secondary uses assessed.
5. Automated decision-making provisions assessed where decisions affect people.

Reference: ai transparency notices.

Is minimization designed in?

1. Prompts include only necessary personal data; identifiers redacted or tokenized where not needed.
2. Retrieval returns only authorized and necessary content.
3. Logs and traces redacted; raw content access-controlled.
4. Memory writes governed by policy; no storage of inferred sensitive attributes.
5. Evaluation datasets anonymized or pseudonymized where feasible.

Reference: ai data leakage prevention.

Are provider transfers assessed?

1. Provider role (processor or recipient) determined.
2. Terms: no training on your data, retention, deletion, subprocessors, breach notification.
3. Locations and transfer mechanisms for cross-border processing.
4. Security assessment of the provider.
5. Alternatives where terms are insufficient: redaction, private deployment.

Reference: ai data residency and private llm vs public api.

Can data-subject rights be honored?

1. Access: personal data locatable across primary stores, embeddings, memory, caches, logs, and datasets.
2. Correction and deletion: propagation across all stores, including derived data.
3. Objection and restriction: processing can be stopped per subject where required.
4. Explanation: meaningful information about automated decisions where required.
5. Timelines achievable operationally.

Reference: ai explainability requirements.

Is retention defined?

1. Retention per flow: inputs, outputs, traces, memory, datasets.
2. Automated enforcement with cascade to derived data.
3. Legal holds supported.
4. Conflict between record-keeping obligations and minimization resolved and documented.

Reference: ai record keeping requirements.

Are AI-specific risks assessed?

1. Memorization and regurgitation of personal data by models trained or fine-tuned on it.
2. Inference of sensitive attributes from non-sensitive data.
3. Leakage through outputs, tool calls, and prompt injection.
4. Cross-user or cross-tenant exposure through retrieval, memory, or caching.
5. Profiling and automated decision effects on individuals.
6. Re-identification of pseudonymized data.
7. Provider incidents and subprocessor exposure.

Reference: what is differential privacy and the prompt injection defense checklist.

Are mitigations and residual risk recorded?

1. Mitigation per risk: technical and organizational measures.
2. Residual risk rated and accepted by the sign-off authority, or the design changed.
3. Consultation with regulators where required for high residual risk.
4. Monitoring for the mitigations' effectiveness.
5. Review triggers: scope, provider, model, or regulatory changes.

Is the assessment documented and signed?

1. Assessment record with all sections.
2. Sign-off by the accountable authority.
3. Linkage to the system's register entry and documentation.
4. Review schedule.

Reference: the ai documentation checklist.

How should findings be handled?

Unlawful flows, insufficient provider terms, and inability to honor rights block processing of personal data. Minimization and retention gaps block launch beyond a controlled pilot. Monitoring and documentation gaps are closed before sign-off.

How FISTA Solutions supports privacy assessments

FISTA Solutions designs AI systems so privacy assessments can pass: data flows mapped as part of the specification, minimization in prompts, retrieval, and logs, provider terms confirmed or private deployment used, rights propagation across embeddings, memory, and logs, retention automated, and AI-specific risks mitigated with evidence. The AI enablement practice provides the platform controls, AI agents are built with memory and logging policies, and forward deployed engineers work with your privacy officer through the assessment. The record behind the approach is 150+ projects across 12+ countries.

This checklist is general guidance, not legal advice. To prepare a privacy assessment for an AI system, message FISTA on WhatsApp, or read ai data governance for the governance foundation.