Lab 14 · DPDP-Compliant RAG Data-Flow Design

Vikram's ARB has a new standing question. The BFSI firm's HR function wants a copilot over employee handbooks, HR policies, and — this is where the review gets serious — individual employee records: leave histories, grievance files, performance notes. The Digital Personal Data Protection regime makes this a design problem, not a legal afterthought: the DPDP Rules were notified in November 2025 with phased compliance deadlines, penalties scale to ₹250 crore from May 2027, and the lawful-basis menu is consent-centric — consent plus a narrow legitimate-use category, far narrower than GDPR's six bases. A RAG system multiplies personal-data copies into places most architectures forget: chunks, embeddings, caches, model outputs, and observability traces. This lab makes you find every copy, draw it, and design its deletion path — before an auditor asks.

Time & tier

~90 minutes hands-on · Advanced tier (maps to module M8). Runs at ~₹0 — this is a design-artifact lab; you need only a chat assistant and a Mermaid renderer (any free online editor or your IDE preview).

Setup

Create lab-14/ with four empty files: surfaces.md, dfd.md, compliance-design.md, adr-residency.md.

The engagement brief (all details synthetic):

SYSTEM: "Saarthi" - internal HR copilot for a BFSI firm, ~18,000 employees,
all data principals located in India.
CORPUS: (a) HR policy handbook (no personal data), (b) per-employee records:
leave history, grievance tickets, appraisal summaries. Employees consented to
HR processing at onboarding; the copilot is a NEW purpose.
USERS: HR ops team (full corpus) and employees (self-service: policies + own
records only).
STACK (proposed by the vendor): managed embedding model + LLM endpoint,
vector store, app tier, LLM-observability tracing "for quality improvement",
nightly ingestion from the HRMS.
OPEN QUESTIONS FROM THE ARB: residency, consent lineage, deletion,
redaction placement, and whether tracing is even lawful as proposed.

You also received an AI-drafted "compliance summary" from the vendor's presales engineer. It is part of your input — and it contains seeded errors you must catch in Step 2:

VENDOR AI COMPLIANCE SUMMARY (as received):
1. DPDP requires all personal data of Indian citizens to be stored only on
   servers physically located in India, so the vector store must be in-country.
2. Embeddings are anonymized mathematical representations, not personal data,
   so consent and deletion obligations do not apply to the vector store.
3. Penalties under the DPDP regime reach Rs 500 crore per incident from
   May 2027, so we recommend our premium compliance tier.
4. Because employees consented to HR processing at onboarding, no further
   consent action is needed for the copilot.

Guided steps

Step 1 — Inventory the personal-data surfaces (15 min)

In surfaces.md, list every place personal data exists in the proposed system — at rest and in motion. Work through the request path (employee question → retrieval → prompt assembly → model → answer → trace) and the ingestion path (HRMS → chunker → embedder → vector store). Your list must include at minimum: source records, chunks, embeddings, assembled prompts, model outputs, application logs, observability traces, semantic/response caches if any, and eval samples if answer quality is being reviewed. For each surface: what personal data reaches it, where it physically lives, and its retention today (usually: "indefinite, by accident").

✅ Checkpoint: surfaces.md lists at least eight surfaces; embeddings, traces, and caches all appear with a stated retention answer (even if that answer is "undefined — flagged").

Step 2 — Fact-check the vendor's AI compliance summary (10 min)

Before designing anything, audit the four vendor claims against what you know from the module and the primary texts. Mark each claim correct, wrong, or dangerously oversimplified, with one line of reasoning. Do this yourself first; then ask your assistant to critique your audit — and verify anything it adds before accepting it, because correcting one AI with another AI unverified is compounding the failure mode, not fixing it. Record the audit at the top of compliance-design.md.

✅ Checkpoint: all four claims dispositioned in writing; at least three marked wrong or oversimplified (see answer key after finishing).

Step 3 — Draw the data-flow diagram (20 min)

In dfd.md, produce the Mermaid DFD. Every personal-data surface from Step 1 must appear as a node; annotate edges with what crosses them. Skeleton to extend:

flowchart LR
  subgraph IN["India region - pinned deployment"]
    U[Employee / HR user] --> RG[Redaction gateway]
    RG --> APP[Copilot app tier]
    APP --> VDB[(Vector store: chunks + embeddings + doc/principal metadata)]
    APP --> LLM[LLM endpoint - private connectivity]
    APP --> TR[(Trace store - sampled, redacted, TTL)]
    HRMS[HRMS source] --> ING[Ingestion + chunker + embedder]
    ING --> VDB
    ING --> CR[(Consent register)]
    CR -. lineage check .-> ING
    CR -. deletion trigger .-> VDB
  end

Design decisions the diagram must make visible: where the redaction gateway sits (before the model and before the trace store — outbound prompts and stored traces are separate exposures), the consent register as a first-class component wired to both ingestion (no consent, no ingest) and deletion (withdrawal triggers purge), and access-path separation for the two user classes (HR ops vs employee self-service — retrieval must enforce the requester's entitlement via metadata filters, not the prompt).

✅ Checkpoint: rendered diagram shows all Step-1 surfaces, the consent register with both its edges, and the redaction gateway covering both the model path and the trace path.

Step 4 — Consent lineage and the deletion path (20 min)

This is the section auditors will read first. In compliance-design.md, design two mechanisms:

1. 1Consent lineage. Every vector carries metadata: principal_id, source_doc_id, purpose_tag, consent_ref, ingested_at. Ingestion checks the consent register per principal per purpose before embedding — and because the copilot is a new purpose beyond onboarding-era HR processing, the design must include a fresh consent capture for it. Lineage means you can answer, for any single vector, "whose data, from which document, under which consent, for which purpose."
2. 2The deletion path — the hard question. When principal P withdraws consent: enumerate every surface from Step 1 and specify the mechanism, owner, and deadline for each. The spine: metadata-filtered delete of all vectors where principal_id = P (this is why the metadata schema exists — deletion by similarity search is not deletion); purge of chunk store and any caches holding P's content; trace-store handling (redacted-at-write plus TTL makes this tractable — raw traces make it a crisis); eval samples scrubbed; and downstream copies (backups) covered by a documented backup-expiry window. Close with the two structural commitments that keep deletion possible: no fine-tuning on employee personal data (a model weight has no delete API), and no unredacted personal data in any store without TTL. Add a verification step: a periodic job re-queries all stores for principal_id = P and files the empty result as evidence.

✅ Checkpoint: the deletion-path table covers every surface from Step 1 with mechanism + owner + deadline, and states the no-fine-tuning commitment explicitly.

Step 5 — The residency ADR (15 min)

Write adr-residency.md in standard ADR form (context, options, decision, consequences). The honest legal posture per the module: the DPDP regime today does not impose blanket localization, but the government may restrict transfers to specified destinations — so the architecture question is not "must everything be in India?" but "how expensive is it to comply the day a restriction lands?" Options to weigh: (A) India-pinned everything (model endpoint, vector store, traces); (B) India-pinned data stores with cross-border model inference; (C) unpinned managed defaults. Decide for this BFSI context (sectoral conservatism is a legitimate input — mark any RBI-adjacent expectation as "verify with compliance before relying on it"), and record the architect-for-restrictability consequences: region-pinned deployment, a portable vector store (export path tested, no proprietary-only index format), and provider terms verified in writing for no-training-on-inputs.

✅ Checkpoint: ADR names its decision, and the consequences section includes portability and the no-training contractual verification as first-class items.

Step 6 — Red-team the package (10 min)

Paste your DFD and compliance design into your assistant with: "You are a DPDP auditor. Find data flows where personal data escapes the controls described." Typical genuine catches: personal data in error logs (a stack trace containing the assembled prompt), the embedding model provider retaining inputs, cached answers served across entitlement boundaries, and deletion not covering the consent register's own records. Accept or rebut each finding in the margin — and verify any legal claim the assistant makes before adopting it.

✅ Checkpoint: at least two red-team findings accepted into the design, each with its mitigation added to the DFD or the deletion table.

Verification

• Surface completenessembeddings, traces, and caches all appear in both the inventory and the deletion table; none is hand-waved.
• Vendor audit donethe four seeded claims dispositioned with reasoning before design began.
• Consent is a componentthe register appears in the DFD with ingestion-gate and deletion-trigger edges, and new-purpose consent is addressed.
• Deletion is provableevery surface has mechanism + owner + deadline, plus the re-query verification job.
• Residency is an ADRa decision with consequences, not a vague "keep it in India."

Completion artifact

The lab-14/ design package: surfaces.md, dfd.md (rendered), compliance-design.md (vendor audit + consent lineage + deletion paths), adr-residency.md, with red-team findings incorporated. Self-grading rubric (pass = 8/10):

• Vendor-claim audit (0–2): the three wrong/oversimplified claims caught with correct reasoning = 2.
• Surface inventory (0–2): ≥8 surfaces including embeddings, traces, caches, eval samples = 2.
• Deletion path (0–3): full table, metadata-filtered vector deletion, no-fine-tuning commitment, verification job = 3.
• Residency ADR (0–2): restrictability framing, portability and no-training verification in consequences = 2.
• DFD quality (0–1): an auditor could walk the diagram and find every store personal data touches = 1.

Client-safe variant

This lab is already synthetic, but its real-world twin is maximally sensitive: an actual client's HR data flows are themselves confidential. Run the design work inside the client's approved tenancy or a local model; never paste a real client's system inventory, employee-data descriptions, or MSA excerpts into public AI tools. The deliverable formats — surface inventory, DFD, deletion table, residency ADR — contain structure rather than data and are safe to reuse across engagements; the populated contents are the client's. And every legal interpretation in the package ships to the client marked "architecture input — confirm with counsel," because the architect owns the data flows, not the legal opinion.

Stuck?

• •
  Surface list stalls at four or five: walk one single question through the system word by word — every hop that stores, logs, or transmits the text is a surface; then do the same for one ingested grievance ticket.
• •
  Mermaid won't render: check subgraph/end pairing and that node labels with special characters are quoted; render early, not after 40 lines.
• •
  The deletion table feels impossible for backups: that is normal — the accepted pattern is a documented backup-retention window after which deletion completes, stated honestly rather than hidden.
• •
  Your assistant "confirms" a legal claim you suspect is wrong: ask it for the primary-source basis, then check that source — this lab's Step 2 exists precisely because confident compliance prose is cheap to generate.
• •
  Employee self-service vs HR ops access is muddling the DFD: draw it as one retrieval component with a mandatory entitlement filter (requester's principal_id/role in the query), not two parallel systems.

Answer key (don't read before attempting)

The four vendor claims, dispositioned:

1. 1"DPDP requires all data stored only in India" — WRONG. The regime as covered in this track imposes no blanket localization; the real obligation is readiness for per-destination transfer restrictions the government may impose. The architecture answer is restrictability — region-pinning as a chosen posture (Option A/B in your ADR) plus portability, not a false legal mandate. An architect who repeats this claim in an ARB pack has shipped a hallucinated constraint.
2. 2"Embeddings are anonymized, so obligations don't apply" — WRONG, and it is the most dangerous claim of the four. Embeddings are derived from personal data, are linked back to principals through your own metadata and retrieval behavior, and in this track's treatment are explicitly a personal-data surface alongside prompts and outputs. Treating the vector store as out of scope silently deletes the deletion path — the exact hole Step 4 exists to close.
3. 3"Penalties reach ₹500 crore" — WRONG NUMBER. The figure taught from the research base is penalties scaling to ₹250 crore with full enforcement from May 2027. A doubled penalty figure in a vendor pitch is a tell: the summary was generated, not checked — and it is the easiest of the four to falsify against the primary text, which is why it is seeded here.
4. 4"Onboarding consent covers the copilot" — OVERSIMPLIFIED TO THE POINT OF WRONG. The consent-centric basis structure makes purpose the unit of consent; a copilot that processes grievance and appraisal records for a new purpose needs its own consent capture, which is why the consent register carries purpose_tag and why ingestion gates on it. "We already have consent" without a purpose match is the compliance equivalent of reusing credentials across systems.

The structural answer to the lab's hard question, compressed: consent withdrawal becomes tractable exactly when every derived copy carries principal_id metadata and no copy lives in a store without either a delete-by-filter API or a TTL — and it becomes intractable the moment personal data enters model weights, which is why "no fine-tuning on employee personal data" is an architecture commitment, not a policy preference.