Customer phone numbers, email addresses, and Aadhaar-shaped ids turn up where they were never meant to live: in plain-text application logs, in a debugging dump shared over chat, or — worst — in a third-party dashboard, because the logging pipeline forwarded raw events to an external analytics API. Often nobody notices until an audit, a client security review, or a teammate asks why a log line contains a full phone number.
Any LLM application that logs prompts and answers for debugging — which is every LLM application, because module 3.5 taught you to log retrieval and module 3.9 taught you to log every step. Support bots are the classic case: users volunteer phone numbers, account ids, and addresses inside their questions, so the most useful log is also the most dangerous one. The production version: transcripts logged in full "temporarily, for debugging", then wired into a hosted analytics service, with customer consent covering support only. Under India's DPDP Act 2023 that is stored and transmitted personal data without a matching purpose. Linked module: 3.11 (Safety, guardrails, DPDP).
The root cause is architectural: logging was designed for debugging value, with nobody at the boundary asking what leaves the system. Confirm the blast radius before fixing anything. Grep the logs with the same patterns a redaction layer would use — phone, email, 12-digit id shapes — and count hits per log file. Then map every sink: local files, log aggregators, analytics APIs, error trackers, backups. For each sink holding personal data, ask two DPDP questions: did the person consent to this use (consent), and is this the purpose the data was collected for (purpose limitation)? A support transcript sent to an overseas analytics API fails both, and the third-party provider holding it is now part of your problem.
Put a redaction layer at the logging boundary: every string passes through a
scrubber that replaces phones, emails, and id-shaped numbers with neutral tags
like <PHONE> before any write or send. Redacted logs keep their debugging
value — "customer asked about an EMI date and shared contact details" survives;
the number itself does not. Then clean up the past: purge or redact existing
logs, request deletion from third-party services that received raw data, and
record what was done. Escalate honestly — a personal-data leak can be a
reportable breach under the DPDP Act, and that call belongs to your data
protection officer, not to the engineer who found it. Finally, cut what you
log: if a field is never used in debugging, stop recording it — data
minimisation is the cheapest control you will ever ship.
Redact before storing, always — the scrubber sits inside the logging function, so no future code path can forget it. Review every outbound data flow against the stated consent before wiring it: new analytics tool, new error tracker, new "quick export" all get the same two DPDP questions. Keep synthetic test data for development so real customer text never leaves production. And add a log audit to your release checklist: grep the newest logs with your PII patterns; the count must be zero.
Q: "You inherit a support bot whose logs hold raw customer transcripts, and those logs feed an external analytics API. Walk me through your response." Strong answer: assess first (pattern-grep the logs, map every sink), name the legal frame (DPDP: consent and purpose limitation both fail for the analytics flow), then fix in order — redaction layer at the boundary, purge and third-party deletion, escalation to whoever owns breach decisions. Finish with prevention: data minimisation and redact-before-store as defaults. Bonus for saying the redacted log is still useful for debugging — it shows you have actually operated one, not only read about the rule.