Under India’s DPDP framework, you must erase personal data once the user withdraws consent or the purpose is served, while also keeping certain processing logs for at least one year. For AI products, that means chat histories, prompt logs and training datasets each need a deliberate retention schedule.
This guide explains how DPDP data retention and erasure rules (mainly Rule 8 and Section 8(7)) apply to AI chat logs, and how to build a schedule you can defend. It is general information, not legal advice.
What the DPDP Act says about data erasure
Section 8(7) of the Act requires a data fiduciary to erase personal data when the data principal withdraws consent, or when it is reasonable to assume the specified purpose is no longer being served, whichever is earlier. The exception is where retention is necessary to comply with another law.
The DPDP Rules 2025 add practical detail through Rule 8, the Third Schedule and a log-retention floor. Commentary sources agree on the core mechanics, though they differ in places, so check the official text before relying on any summary.
Rule 8 and the three-year clock for large platforms
The Third Schedule applies a time limit to three classes of fiduciary: e-commerce entities with at least two crore registered users, online gaming intermediaries with at least fifty lakh registered users, and social media intermediaries with at least two crore registered users. Some purposes, such as enabling access to a user account, are carved out.
For these classes, data is to be erased three years after the user last approached the fiduciary for the specified purpose or exercised their rights (or after the Rules commenced, whichever is latest).
The 48-hour warning
At least 48 hours before the period completes, the fiduciary must tell the user that the data will be erased unless they log in or otherwise get in touch. Many teams will treat this as a re-engagement notice, because a user response restarts the clock.
The one-year minimum for logs
Rule 8(3) pushes in the opposite direction. A fiduciary must retain personal data, associated traffic data and other logs of processing for at least one year from the date of processing, including processing done by its processor. After that, the data is erased unless another law requires longer retention.
So erasure is both a ceiling and a floor: you cannot keep data forever, and you cannot always delete everything immediately.
What this means for AI chat logs and prompts
AI products create several data stores that are easy to overlook. A practical way to think about them is by purpose.
| Data store | Typical purpose | Retention question |
|---|---|---|
| Chat history shown to the user | Product feature | Delete on withdrawal or when the feature is no longer used |
| Prompt and response logs | Debugging, safety, audit | Align with the one-year log floor, then erase |
| Vector stores and embeddings | Retrieval (RAG) | Make sure deletion reaches the index, not just the source file |
| Training or fine-tuning sets | Model improvement | Needs its own lawful basis and a defined end date |
| Vendor-side logs | Processor operations | Cover in contract and verify deletion |
If you use retrieval, the privacy trade-offs are similar to those discussed in RAG vs fine-tuning in 2026. For agent-style products, see AI agents under the DPDP Act, since agents often write their own logs and memory.
Building a retention and erasure schedule
- Inventory every store. Include logs, caches, backups, vector databases and vendor systems.
- Map each store to a purpose. Retention is tied to the specified purpose, so write it down.
- Set periods. Use the one-year log floor where it applies and the three-year rule if you fall in a Third Schedule class.
- Automate deletion. Include notices, withdrawal handling and propagation to processors.
- Keep evidence. Record what was deleted and when.
Why it matters: penalties and breaches
Retained data is also exposed data. The more you keep, the larger the impact of a breach, which is covered in DPDP breach notification and Rule 7. Penalty exposure is explained in DPDP Act penalties.
Handling consent withdrawal in an AI product
When a user withdraws consent, Section 8(7) points toward erasure, and the Act also expects processors acting for you to stop processing. In practice a withdrawal request should trigger a workflow, not a manual ticket: find the user’s records, delete the chat history, remove their documents from retrieval indexes, and instruct processors to do the same.
The tricky part is the interaction with the one-year log floor. Where Rule 8(3) requires you to keep certain processing logs, keep only what the rule needs, restrict access to it, and delete it when the period ends. Do not leave full conversation text in logs if a smaller record would meet the purpose.
What about data already used to train a model?
Deleting a row from a database does not remove what a trained model may have learned from it. The DPDP text does not give a clear technical standard for this, and commentary on it varies, so treat it as an open design question. Sensible steps include avoiding personal data in training sets where you can, documenting the lawful basis and purpose, keeping training data versioned so it can be removed from future runs, and being honest in your privacy notice about what happens after withdrawal. For the wider picture, see DPDP cross-border transfers and foreign AI APIs if your vendors process data outside India.
Common mistakes to avoid
- Keeping everything “just in case”. Open-ended retention of prompts is hard to justify against a stated purpose.
- Deleting the source but not the copies. Caches, backups, embeddings and vendor logs often survive.
- Ignoring processors. Retention duties reach processing done on your behalf, so contracts need matching deletion timelines.
- No audit trail. If you cannot show what was deleted and when, you cannot demonstrate compliance.
Frequently asked questions
Does the DPDP Act force me to delete AI chat logs immediately?
No. Erasure is required once consent is withdrawn or the purpose is no longer being served, unless another law requires retention. Separately, the Rules set a one-year minimum for certain logs, so deletion has to be sequenced, not instant.
Which companies get the three-year deletion clock?
The Third Schedule names e-commerce entities and social media intermediaries with at least two crore registered users, and online gaming intermediaries with at least fifty lakh registered users, subject to listed exceptions. Smaller fiduciaries still need their own defensible retention periods.
Do I have to warn users before deleting their data?
Where the Third Schedule applies, the fiduciary must inform the data principal at least 48 hours before the erasure period completes, so the user can log in or otherwise act to keep the account.
Does a vendor or LLM API provider count for retention?
Retention duties extend to processing done on your behalf, so you should make sure your processors can honour your deletion and log-retention timelines contractually.
When do these retention rules apply?
The Rules were notified in November 2025, and the retention provisions sit in the tranche that applies roughly 18 months later, around May 2027. Sources differ by a day on the exact notification date, so confirm against the Gazette.
Conclusion
Treat DPDP data retention as a design requirement for AI systems: inventory your stores, tie each to a purpose, respect the one-year log floor, and automate erasure. Verify the exact legal text and dates with the Gazette or counsel.
Disclaimer: This article is for general information only and is not legal advice. Consult a qualified lawyer for your situation.