A Data Protection Impact Assessment (DPIA) for an AI workflow is the GDPR Article 35 record that documents the data flows specific to LLM applications — prompts, completions, embeddings, tool calls, RAG retrieval — together with the legal basis, retention schedule, identified risks, and the mitigations that bring those risks down to an acceptable level. Most off-the-shelf DPIA templates were written for CRM systems and HR pipelines and do not reflect how AI agents actually move data. This guide presents a one-page DPIA section template tailored to AI workflows, walks through each field with concrete content, and shows how Vaikora capabilities (reversible PII redaction, content-free SHA-256 hash-chained audit, deterministic policy enforcement with probabilistic risk scoring) map to each mitigation row.
When a DPIA Is Required Under GDPR Article 35
GDPR Article 35(1) requires a DPIA “where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons.” Article 35(3) lists three specific cases that always trigger a DPIA, and Article 35(4) directs supervisory authorities to publish lists of operations that require one. Most LLM workflows touch at least one of the three Article 35(3) triggers.
- 35(3)(a) — systematic and extensive automated evaluation. An LLM produces decisions or recommendations about individuals based on automated analysis of their data; almost any user-facing AI feature qualifies.
- 35(3)(b) — special categories of data on a large scale (Art. 9) or criminal data (Art. 10). Healthcare assistants process Article 9 data; HR / legal assistants may process Article 10 data; both at scale.
- 35(3)(c) — systematic monitoring of a publicly accessible area on a large scale. RAG over customer-facing channels and agent-driven monitoring fits this trigger when the channel is publicly accessible.
In addition, the EDPB and most national supervisory authorities have published “black lists” of operations that automatically require a DPIA; “innovative use of new technological solutions” (the WP29 criterion that captures most generative AI deployments) and “large-scale processing of personal data using AI” appear on most national lists. The conservative answer for any production LLM workflow that touches personal data is: do the DPIA.
AI-Specific Data Flows the DPIA Has to Cover
Generic DPIA templates ask about “data” as if there is one stream. AI workflows have several, each with a different lifecycle, retention profile, and risk profile. Document each one — what flows, where it lands, and the retention concern.
- User-facing input plus system prompt; may include PII, PHI, customer data, or internal documents. Lands at the LLM provider for inference, in application logs (if the team logs raw), and in RAG indexes (if the prompt is stored). Retention concern: if logged in the clear, long retention creates GDPR / HIPAA / PCI exposure.
- Model output text returned to the user. Lands in the application and is often logged alongside the prompt. Retention concern: same as prompts, plus a re-disclosure surface if the model echoed PII.
- Vector representations of documents, user queries, or both. Land in a vector database (Pinecone / Weaviate / pgvector / FAISS) and are often indexed for years. Retention concern: embeddings of personal data are personal data; the right to erasure (Art. 17) has to operate against the index.
- Tool calls. Structured arguments passed to internal tools (database queries, API calls, file reads). Land in application logs, downstream tool logs, and at the LLM provider (the tool call is part of the conversation). Retention concern: tool arguments often contain account identifiers or queries that constitute personal data.
- RAG retrieval. Documents fetched into the prompt at query time; inserted into the prompt and sent to the provider. Retention concern: if retrieved documents contain personal data the provider sees it, and deletion in the source store does not delete from already-served prompts.
- Audit / detection events. Decision metadata, risk scores, redaction summaries, payload hashes. Land in the Vaikora audit log and the SIEM. Retention concern: acceptable when content: false — the entry is metadata + hash, not personal data.
One-Page DPIA Section Template (AI-Specific)
This is a self-contained DPIA section a privacy team can lift directly into their organization’s DPIA template. Field labels match the Article 35(7) requirements; the example content is a typical customer support assistant workflow.
Mitigations Mapped to Vaikora Capabilities (Section 11)
Section 11 of the template is where most generic DPIAs become hand-wavy. The mitigation rows below name a concrete capability, the GDPR articles it serves, and the audit evidence the privacy team can present.
| Risk | Mitigation | GDPR articles served | Evidence |
|---|---|---|---|
|
PII leakage to the LLM provider |
Reversible PII redaction at gateway egress (synthetic / mask / hash with format preservation) |
Art. 5(1)(c) data minimization; Art. 25 privacy by design and by default |
Redaction summaries in audit log |
|
Unauthorised retention in upstream provider logs |
Provider DPA + zero-retention configuration where supported; redacted prompts mean no PII reaches the provider in the first place |
Art. 28 processor obligations; Art. 5(1)(e) storage limitation |
Provider DPA; redacted-payload sample |
|
Indirect prompt injection from RAG content |
4-layer detection (pattern, semantic, ML, behavioral) on tool outputs and retrieved documents; deterministic block with audit |
Art. 32 security of processing |
Detection event stream; block decisions |
|
Right-to-erasure operability against logs and indexes |
content: false metadata-only logging; embeddings store internal docs only; no consumer content in audit |
Art. 17 right to erasure; Art. 5(1)(c) data minimization |
Audit entries showing content: false; embedding-rebuild SOP |
|
Inaccurate or harmful generated content |
Response-side detection for injection-induced output; deterministic policy; human-in-the-loop for the final reply (operational control) |
Art. 22 automated decision-making (where applicable) |
Response-side detection events; HITL workflow documentation |
Article-by-Article: How the AI Workflow Stays Compliant
Privacy teams are often asked for a compact mapping that reads like a checklist against the GDPR. The view below names the article and the matching capability.
- 5(1)(b) purpose limitation. Per-route compliance preset binds the workflow to its declared purpose; routing policy enumerates upstreams.
- 5(1)(c) data minimization. Reversible PII redaction means the provider sees the minimum needed for inference; content: false means the audit log holds metadata, not content.
- 5(1)(e) storage limitation. Workspace retention configured per preset; content-free logging keeps audit storage out of regulated scope.
- 17 right to erasure. No consumer content in the audit log; embeddings limited to internal documents; deletion SOPs documented.
- 22 automated decision-making. Where a decision has legal or similarly significant effect, human-in-the-loop is enforced operationally and recorded in the audit log.
- 25 privacy by design / by default. Inline gateway is the default path; standard, hipaa, pci-dss, and gdpr presets apply privacy-by-default policy.
- 28 processor obligations. DPAs in place with the LLM provider and the gateway provider; sub-processor list maintained.
- 30 records of processing. Audit log entries are records of processing; metadata + hash satisfy Art. 30 without storing content.
- 32 security of processing. 12+ detection vectors / 4 layers; deterministic policy + 7-factor probabilistic risk score; SHA-256 hash-chained tamper-evident audit.
- 35 DPIA. This document. Reviewed by DPO; residual risk rating recorded.
- 36 prior consultation. Required only when the DPIA finds residual high risk; the mitigation table is designed to keep residual risk below that threshold.
How to Actually Run the DPIA in Five Working Days
- Day 1 – scope. Identify the workflow boundary, the data subjects, and the controllers / processors. Pull the existing template; replace generic data-flow language with the AI-specific data flow rows above.
- Day 2 – data flows. Map prompts, completions, embeddings, tool calls, RAG retrieval, and audit events. For each, name the recipient and the retention. Use the table earlier in this guide as the inventory.
- Day 3 – risks. Run the five-risk template (R1–R5) and add any workflow-specific risks. Score each on likelihood and severity; place them on the residual-risk grid.
- Day 4 – mitigations and evidence. Map each risk to a concrete mitigation and evidence artifact (audit field, policy export, detection event). The mitigation table earlier in this guide is the starting point.
- Day 5 – sign-off. DPO review; residual-risk rating; sign-off. If residual risk is High, escalate to Art. 36 prior consultation; otherwise, file the DPIA and add a recurring review cadence.
Next Steps
Lift the one-page template into your existing DPIA structure, populate it with your workflow’s specifics, and run the five-day sequence. The companion guides — “Why Logging AI Prompts Creates Compliance Risk,” “How to Block PII in LLM Traffic Before It Leaves Your Environment,” and “Mapping AI Controls to NIST AI RMF and ISO 42001” — supply the evidence artifacts that fill in the mitigation rows.
A DPIA for an AI workflow is the GDPR Article 35 record that documents AI-specific data flows (prompts, completions, embeddings, tool calls, RAG retrieval), the lawful basis under Art. 6 / 9, retention, and the mitigations — reversible PII redaction, content-free SHA-256 hash-chained audit, deterministic policy with probabilistic risk scoring — that bring residual risk below the Article 36 threshold.
Your AI Agents Need a Control Layer
See how Vaikora intercepts, evaluates, and enforces policy on every AI agent action — in real time, before execution.
Frequently Asked Questions
Is a DPIA always required for an AI workflow?
Under GDPR Article 35(1), a DPIA is required whenever processing is likely to result in a high risk to the rights and freedoms of natural persons. Article 35(3) lists three triggers; most LLM workflows hit at least one. The practical answer: do the DPIA for any production LLM workflow that touches personal data.
What does “AI-specific” mean in a DPIA?
It means documenting the data flows that generic DPIA templates miss: prompts, completions, embeddings, tool calls, and RAG retrieval. Each has a different recipient profile and retention profile. Without those rows, the DPIA does not reflect how the workflow actually moves data.
How does Vaikora help with the DPIA itself?
Vaikora produces the evidence the DPIA’s mitigation rows reference: redaction summaries, content-free audit entries, detection event streams, hash-chain integrity reports, and policy exports. Those are the artifacts a DPO actually wants to see when signing off on residual risk.
How do we satisfy Article 17 (right to erasure) on AI logs and embeddings?
Audit logs are content: false (metadata + SHA-256 hash, no consumer content), so there is nothing to erase per request. Embeddings are limited to internal documents (not customer prompts) and rebuilt on a documented cadence; deletion in the source store triggers an embedding rebuild. The combination satisfies Article 17 operationally.
Do we need a DPIA per workflow or per organization?
Per workflow, with a master record at the organization level. Article 35 talks about the processing operation; each AI workflow with materially different data flows or recipients needs its own DPIA section. The one-page template above is designed to bolt onto an existing master DPIA without reproducing the org-level fields.
What residual-risk rating gets us out of Article 36 prior consultation?
Article 36 requires prior consultation when the DPIA indicates the processing would result in high residual risk in the absence of the controller’s mitigations. If your mitigations bring residual risk to Low or Medium, you do not need prior consultation; you file the DPIA and review it on a defined cadence.
How often should the DPIA be reviewed?
On material change (new model, new provider, new data flow) and at least annually. The annual review is good practice; the change-trigger review is the one that actually keeps the DPIA accurate.