DPDP Act and AI Chatbots: Consent, Notice and Transcript Retention Done Properly

Every enterprise chatbot is a personal data collection point. It just does not look like one. There is no form, no submit button, no obvious moment where the user consents to anything — and that is exactly why chatbot deployments are one of the weakest links in Indian DPDP compliance programmes right now.

India’s Digital Personal Data Protection Act does not care that the interface is conversational. If your bot captures a name, an email address, a phone number, an order ID tied to a person, or a customer’s description of their problem, you are processing personal data as a data fiduciary. The Rules were notified on 13 November 2025 and the substantive obligations take effect in May 2027, with consent manager registration provisions live from 12 November 2026.

This is what that means in practice for teams running AI assistants on their website, in WhatsApp, or inside their own workplace.

Where chatbot deployments break DPDP

Notice arrives after collection, or not at all

The Act requires an itemised notice — what data, for what purposes, how to withdraw, how to complain — presented at or before the point of collection. Most chat widgets open with “Hi! How can I help?” and collect an email three turns later. By then, collection has already happened without notice.

The fix is not a link to the privacy policy in eight-point grey. It is a pre-chat notice that states plainly what the assistant records, in language a customer can read, available in English and in the official Indian languages your users actually use.

Consent is bundled into the cookie banner

Consent under DPDP must be free, specific, informed, unconditional and unambiguous, and given by clear affirmative action for a specified purpose. “Accept all” on a cookie banner does not carry consent for a chatbot to retain a transcript, enrich a CRM record, or use the conversation for quality review. Those are separate purposes and need separate capture.

Transcripts are retained forever

Chat logs are the easiest thing in the stack to keep and the hardest to justify keeping. DPDP requires erasure once the purpose is served. A transcript retained indefinitely “for analytics” with no defined retention period is a straightforward breach of the purpose limitation and storage limitation obligations — and it is sitting in a system that, in most deployments, nobody has mapped.

The model vendor is a processor and nobody has papered it

If your assistant sends user messages to a third-party LLM API, that provider is processing personal data on your behalf. You need a contract with processing terms, security commitments, breach notification obligations and deletion on termination — and you need to know where the inference happens, because cross-border transfer conditions apply.

This is the question to ask your platform vendor before anything else: where does my data go, who processes it, and can you contractually commit to that?

There is no erasure path into the transcript store

When a data principal asks for erasure, the request has to reach every system holding their data. Chat transcripts are almost never in the inventory. They live in a vendor console, a vector database, an analytics warehouse and a support ticket — four copies, none of them wired to the DSR workflow.

If you have built retrieval on top of user conversations, there is a fifth copy inside the embeddings, and deleting the source row does not remove it from the index.

Withdrawal is harder than consent

The Act is explicit that withdrawing consent must be as easy as giving it. One click to start chatting and an email to support to have the transcript deleted does not meet that bar.

Conversations are used to train models

Using customer conversations to fine-tune a model is a distinct purpose. It needs its own consent, and it is close to irreversible — once a model has trained on the data, honouring an erasure request in any meaningful sense becomes extremely difficult. For most enterprise deployments the right answer is simply not to train on production conversations at all.

What a DPDP-ready assistant actually needs

• Pre-chat notice shown before the first message is captured, in the user’s language, itemising data categories and purposes.
• Per-purpose consent capture with a consent record — timestamp, purpose, notice version, method — stored against the conversation, not inferred from a cookie banner.
• PII redaction before inference, so that Aadhaar numbers, PAN, card fragments and phone numbers are masked before a message leaves your boundary.
• Defined transcript retention with automatic deletion, applied to the vector index as well as the primary store.
• DSR reach: access, correction and erasure requests that resolve across transcripts, embeddings, analytics and tickets from a single workflow.
• One-click withdrawal inside the chat surface itself, not through a support queue.
• Processor agreements and data residency for every model and infrastructure vendor in the path.
• An audit trail that can show, months later, which notice version was shown and which consent was held on the day of a given conversation.

Where IntelloWork sits

IntelloWork is built for enterprise deployments where these questions get asked during procurement rather than after an incident. That means retrieval that respects source-level access controls, so the assistant cannot answer from a document the user was never entitled to see; SSO and ACL-aware retrieval rather than a flat index; configurable retention on conversation history; and answering across languages without shipping content to a separate translation service. Our enterprise AI chatbot security and compliance checklist covers the wider control set, and the monitoring guide covers what to log once it is running.

What a chatbot platform should not try to be is your consent system of record. Consent belongs in one place across every surface you own — website, app, chatbot, WhatsApp, in-store — because a data principal who withdraws consent has withdrawn it everywhere, and a regulator asking what consent you held on a given date will not accept four different answers from four different systems.

That is the case for a dedicated consent management platform sitting underneath the whole estate. ProtectComply’s notice and consent module handles granular per-purpose capture, OTP-gated withdrawal, notices in twenty-two Indian languages and a hosted preference centre, and exposes it as a consent layer other systems — chatbots included — call rather than reimplement. If you are running an assistant in India, wire it to a consent layer rather than building consent inside the bot.

Frequently asked questions

Does the DPDP Act apply to chatbots?

Yes. The Act applies to the processing of digital personal data regardless of interface. If a chatbot collects data that identifies a person, the operator is a data fiduciary and owes notice, consent, rights and security obligations.

Do we need consent before the user types the first message?

You need to present the notice at or before the point of collection, and hold consent for each purpose you rely on consent for. In practice that means a pre-chat notice, with consent captured before data is stored or sent onward.

How long can we keep chat transcripts?

Only as long as the purpose requires, unless a law requires longer. There is no fixed number in the Act — you must set, document and enforce a retention period per purpose, and erase after it.

Is sending chat data to an overseas LLM provider allowed?

Cross-border transfer is permitted except to countries restricted by the Central Government, but the provider is your processor: you need contractual terms with them and you remain liable for what they do with the data. Know where inference happens before you deploy.

Can we train our model on customer conversations?

Only with consent for that specific purpose, and it should be treated as a high-risk choice — erasure obligations are very hard to honour once data is baked into model weights.

When do these obligations take effect?

The Rules were notified on 13 November 2025. Consent manager registration provisions become operative on 12 November 2026, and the substantive obligations — notice, consent, rights, breach reporting, transfer conditions — take effect in May 2027.