In an AI system, personal data doesn't just sit in databases — it flows through prompts, gets baked into embeddings, appears in outputs, and lingers in traces. This playbook maps those four surfaces into a data-flow design with consent lineage, retention, and deletion paths that survive a DPDP or GDPR review.
Tier: Advanced · Hands-on time: ~40 minutes
The regulatory clock is running: the DPDP Rules were notified in November 2025 with phased compliance deadlines, penalties reaching ₹250 crore applying from May 2027, and — the structural difference from GDPR's six lawful bases — only consent and legitimate use as lawful bases, which changes RAG ingestion design for India-scoped personal data. Practitioner analysis of DPDP is blunt on the architectural point: every RAG system is part of the DPDP risk surface, because prompts, embeddings, and model outputs each need consent lineage, retention, and deletion by design. This is architecture work, not a legal review you wait for.
Enumerate the four AI-specific personal-data surfaces. Prompts — user questions and injected context carry personal data into every model call. Embeddings — vectors derived from personal data are personal data; deletion must reach them (pb-31's stance). Outputs — generated text can reproduce, combine, or infer personal data, including into caches (pb-47) and downstream systems. Traces — observability and eval sampling (pb-33, pb-46) persist prompts and outputs into logging systems with their own retention. Draw all four onto the data-flow diagram with trust boundaries; a DFD showing only databases is the pre-AI template failing you.
Trace consent lineage to each surface. For each personal-data element: the lawful basis at collection (under DPDP, consent or legitimate use — there is no "legitimate interests" catch-all to lean on), the stated purpose, and whether flowing into a RAG index or model call is within that purpose. Purpose drift is the classic finding: data collected for HR administration does not automatically consent its way into an HR copilot's training or retrieval corpus.
Design retention and deletion per surface, executable. Vikram, designing an HR-docs copilot for his BFSI firm:
Adversarially review this AI data-flow design for DPDP compliance
readiness (attached: DFD with the four surfaces marked, consent-lineage
table, retention schedule, deletion-path design).
Attack it as a data protection officer would:
1. Erasure: an employee exits and requests deletion. Walk the request
through source docs, chunks, embeddings, prompt logs, output caches,
eval traces, and any agent memory. Which surface has no executable
path? Which has an undefined SLA?
2. Purpose limitation: which data flows serve a purpose the consent
lineage table does not cover?
3. Retention: which surface retains longest, and does anything retain
indefinitely by default (trace stores usually do)?
4. Cross-border: which components process or store outside India, and
what would a per-destination transfer restriction under the DPDP
Rules break in this design?
Findings with severity; do not soften. Mark UNKNOWN where the attached
material is insufficient.
Architect for restrictability, not just today's rules. DPDP imposes no blanket localization today, but the framework allows government restriction of transfers per destination — so the design hedge is restrictability: region-pinned model endpoints and vector stores, portable data layouts, and a documented path to relocate processing if a destination is restricted. For GDPR scope, the parallel pattern is EU-region model deployment. Write the residency decisions as an ADR with the restrictability rationale.
Place the redaction gateway deliberately. Decide where PII is minimized: at ingestion (redact before embedding — strongest for the embeddings surface), at prompt time (gateway-level redaction before the model call), and at trace time (masking before persistence). Each placement has a cost to answer quality or debuggability; the design records what is redacted where and what deliberately is not, with the justification.
Compile the DPIA-style worksheet from the artifacts. Processing purposes, data categories, the four surfaces with their lineage/retention/deletion answers, residual risks with owners, and the review triggers (new data source, new jurisdiction, the May 2027 enforcement threshold). Legal reviews this; architecture wrote it — that ordering is the point.
Ship the package and wire the re-review. DFD, consent-lineage table, retention/deletion design with tested paths, residency ADR, worksheet — plus a standing agenda item: the Rules' phased deadlines make this a living document with dates, not a launch artifact.
This playbook's subject matter is itself the sensitive payload: DFDs and lineage tables describing a client's personal-data flows are confidential, and pasting them into external assistants may violate the very MSA and DPDP posture being designed. Work inside client-approved tenancy, or abstract structurally (surface types and flow shapes, no real data categories or system names) for external-assistant passes. All deletion and retention testing uses synthetic data principals — schema-faithful synthetic data (the UC-41 discipline) stands in for real HR or customer records everywhere in this workflow. For India-scoped BFSI work, add the client's sectoral expectations to the constraint set before designing, and verify them with the client's compliance team rather than assuming.
Prompts, embeddings, outputs, traces — four personal-data surfaces, each with consent lineage, retention, and a deletion path you have actually executed, in an architecture that could relocate if a transfer restriction lands. Design it now; May 2027 is a deadline, not a suggestion.