Make the Support Bot DPDP-Compliant

Tier: Core · Workflow area: Governance & measurement · ~40 minutes

This playbook operationalizes India's DPDP Act 2023 (and translates cleanly to GDPR shops) for the AI service desk in UC-46. It is written for the administrator who has to configure the systems, not the lawyer — but its outputs are exactly what legal and the Data Protection Officer will ask you for.

When to use

• Before the bot or any LLM workflow touches user conversationsthe data map and DPIA are launch prerequisites, and retrofitting them after an incident is done under subpoena-grade scrutiny.
• Your organization serves or employs Indian data principalsDPDP applies, penalties are serious, and "the vendor is compliant" is not the same as "our configuration is."
• A DSR just arrivedsomeone asked what data you hold on them across tickets and chats. If answering takes more than a day of ad-hoc grepping, run this playbook now.

When NOT to use

• As legal advicethis playbook builds the technical and operational layer; your DPO or counsel signs the interpretation. Bring them the artifacts, not the liability.
• When a corporate AI data policy already covers the deskextend it, don't fork it. Two overlapping data-classification schemes guarantee both are ignored.
• To block AI adoption theatrically"compliance" invoked to kill every use case teaches staff to hide usage, which is the least compliant outcome available.

The recipe

1. 1.

   Map the data flows — every one of them. One table: source → tool → destination → personal data present. Cover the bot conversations, RAG retrieval (KB articles can embed user examples), copilot ticket summaries, staff pasting into external chat assistants, and prompt/completion logs the platform keeps. The paste-into-ChatGPT flow is the one everyone omits and the one most likely to leak.

2. 2.

   Write the data-entry matrix. Rows are data classes, columns are your tools, cells are allowed / redacted-only / never:

   Data class	Tenant bot	Tenant LLM (copilot)	External chat LLM
   Name, employee ID	Allowed	Allowed	Never
   Ticket symptom text	Allowed	Allowed	Redacted only
   Credentials, tokens	Never	Never	Never
   Health / leave reasons	Redacted	Redacted	Never
   Aadhaar / PAN / bank	Never	Never	Never

   Adjust cells to your tenancy and legal advice, then fold the matrix into pb-49's desk policy so it reaches the people doing the pasting.

3. 3.

   Deploy Presidio-class redaction where "redacted-only" applies. Automate it — humans will not manually scrub at 4:55 pm:

   Copy

   from presidio_analyzer import AnalyzerEngine
   from presidio_anonymizer import AnonymizerEngine
   
   analyzer, anonymizer = AnalyzerEngine(), AnonymizerEngine()
   results = analyzer.analyze(text=ticket_text, language="en",
       entities=["PERSON","EMAIL_ADDRESS","PHONE_NUMBER","IN_AADHAAR","IN_PAN"])
   clean = anonymizer.anonymize(text=ticket_text, analyzer_results=results).text
   

   Test it on 50 real (already-resolved) tickets and count misses — Indian names, project codenames and ten-digit numbers that are asset tags all trip generic recognizers. Add custom recognizers for your employee-ID and asset-tag formats before trusting it.

4. 4.

   Pin data residency and set prompt-log retention deliberately. In each platform's admin console, verify where conversation data and LLM logs physically live and whether prompts are used for provider training (turn it off where the toggle exists; get it in the contract where it doesn't). Then set retention numbers on purpose: raw chat transcripts 90–180 days is a common working answer, action audit logs 12 months (pb-41 needs them), review samples deleted after grading. Whatever you choose, write it down with a reason — DPDP's storage-limitation principle punishes "forever by default."

5. 5.

   Disclose the AI, plainly. Users must know when they are talking to a bot and where the conversation goes. First bot message: "You're chatting with an automated assistant. This conversation is recorded and retained for N days to improve support. Type 'agent' anytime to reach a person." No dark-pattern hedging like "smart assistant" — disclosure is also the escape-hatch advertisement pb-40 requires.

6. 6.

   Build the DSR runbook for support history. When a data principal asks what do you hold on me or erase it: enumerate the systems from the step-1 map (tickets, chat transcripts, prompt logs, audit logs, workbook samples); script the search per system by user identifier; define what erasure means where legal holds or audit obligations block deletion (redact-in-place versus delete); and set the response clock per your act's timelines. Do one full dry run on a volunteer colleague and time it — that timing goes in the DPIA.

7. 7.

   Complete the DPIA and file it where it can be found. Use your organization's template (or a standard DPIA structure): processing purpose, data classes, flows (step 1), risks — hallucinated personal data in summaries, prompt-log breach, over-retention, vendor training on your data — and the mitigations, which are steps 2–6 with owners and dates. The DPIA is a living document; re-touch it when a new tool or a new action class (pb-41) lands.

Make it yours

• Microsoft-tenant shopPurview sensitivity labels and DLP policies can enforce the "never" column at paste time for managed browsers; Copilot's tenant boundary handles the external-LLM row for licensed staff, which shrinks your redaction surface.
• ServiceNow/Freshservice shopcheck each platform's data-residency and AI data-usage settings explicitly (region pinning, "improve the model" toggles); export your retention configuration and attach it to the DPIA as evidence.
• Custom-bot shopyou are the vendor now: run redaction before storage, encrypt transcripts at rest, put retention in a scheduled deletion job (not a policy doc), and log every DSR search you execute.

Quality check

• The data map matches reality. Quarterly, trace one real conversation end-to-end and confirm it touched only mapped systems. Unmapped flow found = map updated same day.
• Redaction is measured, not assumed. Keep a running miss-rate from your 50-ticket tests; re-test after every recognizer or model change.
• Retention jobs actually delete. Sample the transcript store for records older than the policy age. A retention policy without a deletion job is a breach with a start date.
• The DSR dry run is repeated yearly. Systems accrete; the runbook that worked last year silently misses this year's new log store.