DPDP Compliance for AI Chatbots and LLM Apps Built in India

Short answer: An AI chatbot that processes user messages is processing personal data, which makes you a Data Fiduciary under India's DPDP Act. You need a notice before the conversation starts, a lawful basis for each purpose (including logging and model improvement), a processor relationship with any model provider you send data to, deletable conversation and retrieval stores, and an answer for erasure requests. Full enforceability arrives 13 May 2027.

A Text Box Is the Least Controlled Input in Your Product

Every other field in your application is typed. A name field gets a name. A chat box gets whatever the user decides to send, and Indian users routinely send:

• Aadhaar and PAN numbers, pasted to "speed things up",
• full card numbers when asking about a failed payment,
• symptoms and medical history to a healthcare assistant,
• salary figures and loan details to a fintech bot,
• other people's personal data — "my father's account number is…".

You did not ask for any of it, and you are now processing all of it. The Act does not care that collection was unintentional. That last category is particularly awkward: a third party whose data was pasted into your chatbot is a Data Principal who never interacted with you at all.

The Five Processing Purposes Inside One Chatbot

Most teams think of the chatbot as doing one thing. Under the Act it is doing five, each needing its own basis and its own line in the notice.

Purpose	Typical basis	Separately toggleable?
Answering the user's question in-session	Voluntary provision for the specified purpose	No — it is the service
Transmitting the prompt to a third-party model provider	Processor arrangement, disclosed in notice	No, but must be disclosed
Retaining conversation history for the user	Voluntary provision / service delivery	Should be, with a delete option
Retaining transcripts for quality, safety, and abuse monitoring	Safeguarding from loss — narrow, time-boxed	Disclose, minimise retention
Using conversations to train or fine-tune models	Consent	Yes — mandatory separate toggle

Key insight: the fifth row is where most Indian AI products are non-compliant today. Using customer conversations as training data is a distinct purpose requiring its own consent — it cannot ride on the consent to use the chatbot. Our guide to AI training data under the DPDP Act covers why there is no legitimate-interests fallback in India.

Your Model Provider Is a Data Processor

If you call OpenAI, Anthropic, Google, or any hosted model with content containing personal data, that provider processes personal data on your behalf. Under the Act, you remain the Data Fiduciary and remain accountable — including for what the processor does.

What that requires:

• A contract binding the processor. Accepting standard terms is a contract; whether those terms actually bind the provider to your DPDP obligations is a question worth reading the terms to answer.
• Zero-retention or short-retention configuration where available. Most major providers offer an enterprise or API tier that excludes inputs from training and limits retention. Consumer tiers frequently do not. Using a consumer tier for customer data is a common and avoidable error.
• Disclosure in your notice. The access right entitles a Data Principal to know which processors received their data. "A third-party AI provider" is not an identity.
• Deletion propagation. When a user asks for erasure, whatever the provider retained must go too.

Cross-border transfer

The DPDP Act permits transfer outside India except to countries the Central Government restricts by notification — a relatively permissive default. Three caveats:

1. Sectoral rules override. RBI's payment-data directive and similar regulator requirements apply independently of DPDP status and are stricter.
2. MeitY has signalled cross-border restrictions for Significant Data Fiduciaries. If you may be designated, assume some categories will need to stay in India.
3. Know where the inference actually runs. "The vendor is US-headquartered" and "our requests are served from Mumbai" are different facts, and only the second one helps.

The Logging Problem

LLM applications log heavily by default — prompts, completions, token counts, latency, tool calls, retrieved chunks — usually into an observability platform run by yet another vendor. Every one of those logs contains whatever the user typed.

This creates a data estate nobody planned:

• prompts in the observability tool,
• completions in the same place,
• retrieved document chunks containing other users' data,
• trace payloads in an APM vendor,
• error reports with full request bodies in the error tracker.

When an erasure request arrives, all of it is in scope. The fix is architectural and cheap if done early: redact identifiers before they reach the logging layer, keep prompt logs on a short retention clock, tag every log line with a user identifier so it can be deleted per-person, and keep full-payload logging off by default in production.

RAG and the Retrieval Layer

Retrieval-augmented generation is the compliant-friendly architecture, provided one property holds: every chunk in the index must be traceable to a source record and deletable individually.

Architecture	Erasure feasible?	Verdict
Fine-tune on customer conversations	No — requires retraining	Avoid for personal data
RAG over an index with per-chunk source IDs	Yes — delete the chunks	Preferred
RAG over an index built from a bulk dump with no IDs	No — cannot find one person's chunks	Rebuild the pipeline
In-context injection from a live query, nothing stored	Not applicable — nothing retained	Cleanest

The second-worst case is a vector store where embeddings carry no back-reference: you cannot delete one person's contribution without rebuilding the whole index. Also remember that embeddings derived from personal data are still personal data — vectors are not anonymisation.

Also: Prompt Injection Is a Data Protection Issue

If your chatbot has tools — reading a user record, issuing a refund, sending a message — then a successful prompt injection is unauthorised processing of personal data, and potentially a reportable breach. Treat retrieved content and user input as data, never as instructions. Put allowlists and confirmation gates on any tool that mutates state or reveals records. The security-safeguards obligation carries the ₹250 crore maximum, and "the model was tricked" is not a defence.

WhatsApp Bots and Voice Agents Are Harder

Most Indian conversational AI does not run in a web widget. It runs on WhatsApp, or on a phone line. Both add obligations that a website chatbot does not have.

WhatsApp

There is no page to render a notice on before the conversation starts, and the first message is often initiated by the user. Workable pattern: serve the notice as the bot's first response, before processing anything substantive, with a link to the full notice and a clear statement of what the AI does with messages. Two further points: template message rules and the 24-hour window shape when you can contact someone at all, which interacts with consent withdrawal in ways teams rarely think through; and the phone number itself is personal data, so an opt-out must actually stop messages rather than just muting a campaign.

Voice

Voice agents process audio, which is personal data and frequently biometric-adjacent. Three additions to the checklist: disclose recording and AI handling at call start rather than burying it in a privacy policy nobody will hear; treat transcripts as conversation data subject to the same retention and erasure clocks; and decide deliberately whether to retain the audio at all — in most cases the transcript is sufficient and the raw recording is pure liability. Automatic speech recognition over Indian languages and code-mixed speech also produces transcription errors that end up in a person's record, which makes the correction right operationally relevant in a way it rarely is for text.

Consent for a conversation that already started

The awkward case both channels share: the user has already sent a message containing personal data before seeing any notice. You cannot un-receive it. The defensible handling is to process that first message only to deliver the service the user clearly sought, serve the notice immediately, and obtain consent before any secondary purpose — logging for quality, retention beyond the session, or training — attaches to it.

The Compliant Architecture

1. Notice before the first message — what is collected, what the AI does with it, which provider processes it, how long transcripts are kept, and how to delete them. In the languages your users use.
2. Separate toggle for training, defaulted off, with the product fully functional when declined.
3. Input minimisation — tell users not to paste identity documents or card numbers, and detect-and-redact common Indian identifier patterns server-side before storage.
4. Enterprise-tier model access with training excluded and retention minimised, contract in place, region known.
5. Per-user-tagged storage for conversations, retrieval chunks, and logs, so erasure is a query rather than an archaeology project.
6. Short retention clocks on transcripts and logs, enforced automatically — see our retention automation guide.
7. Erasure that reaches everything — conversation store, vector index, observability platform, error tracker, and the model provider.
8. Tool-call guardrails and treating all retrieved content as untrusted data.

Frequently Asked Questions

Does the DPDP Act apply to AI chatbots?

Yes. A chatbot that processes user messages containing personal data makes its operator a Data Fiduciary, with the full set of obligations: notice, lawful basis, security safeguards, retention limits, breach notification, and Data Principal rights. The fact that data arrives through a free-text box rather than a form field changes nothing.

Is OpenAI or Anthropic a data processor under India's DPDP Act?

If you send them personal data to process on your behalf, yes — they act as Data Processors while you remain the accountable Data Fiduciary. You need a contract binding them, should use an enterprise or API tier that excludes your data from training, must disclose them in your notice, and must be able to propagate erasure requests to them.

Can we use customer chat conversations to improve our AI model?

Only with consent obtained specifically for that purpose. Model training is a distinct purpose from answering the user's question, and India's DPDP Act provides no legitimate-interests basis to fall back on. It needs its own toggle in your notice, defaulted off, with the product still working if the user declines.

Can Indian companies send prompts to AI models hosted outside India?

Generally yes — the DPDP Act permits cross-border transfer except to countries restricted by government notification. But sectoral rules from RBI, IRDAI, and SEBI apply independently and are often stricter, and MeitY has signalled cross-border restrictions specifically for Significant Data Fiduciaries. Confirm which region actually serves your inference requests.

How do we handle an erasure request for chatbot data?

Delete across every store the conversation touched: the conversation database, the vector or retrieval index, observability and tracing logs, the error tracker, and anything retained by the model provider. This is only feasible if every record carries a user identifier from the start, which is an architecture decision rather than a later cleanup.

Are vector embeddings of personal data still personal data?

Yes, if they can be linked back to an identifiable individual — which they can, when the index stores source IDs, and often even when it does not, since embeddings can be partially inverted. Treat the vector store as a personal data store subject to the same access, deletion, and security obligations as your primary database.

Where Consently Fits

An AI product needs the same consent spine as any other product, with one extra purpose in it. Consently provides itemised per-purpose consent with AI processing and model training as separate toggles, notices in all 22 Scheduled languages served before the first interaction, immutable zero-PII consent records tied to notice versions, withdrawal that propagates as an erasure trigger, and Data Principal rights workflows that cover conversational data alongside everything else. If your chatbot cannot currently answer "did this user consent to training, on which notice version, on what date," that is the gap. Talk to us.