DPDP Compliance for AI Applications: What Indian Businesses Need to Check

Introduction

Most businesses building or buying an AI application already have a working handle on India's Digital Personal Data Protection Act for their existing systems: a privacy notice, a consent flow, some access controls on the customer database. Then an AI feature gets added — a chatbot that reads support tickets, a screening tool that reads CVs, an assistant that reads invoices and emails — and the same checklist stops being enough, because an AI pipeline moves personal data in ways a plain database does not.

DPDP compliance for AI means asking the standard questions again at each point personal data enters, passes through, or is produced by an AI system: who consented to what, where does the data actually go once it leaves your systems, and how long does a trace of it linger in logs, caches, or a chat transcript nobody thought to expire. This piece walks through where those points are, a checklist mapped to the Act's core obligations, the traps that are specific to AI rather than ordinary software, and how to check your vendors without needing a legal team on retainer.

This is not a substitute for legal advice on your specific processing activities. It is the working list a technical or operations lead can use to have that conversation with counsel already informed, rather than starting from a blank page.

Why AI Applications Raise the Compliance Bar

A conventional business application processes personal data in ways that are mostly visible: a record goes into a table, a report reads from that table, a backup copies the table. An AI application adds steps that are easy to lose track of. Text typed by a customer might be sent to a third-party model provider's API. A document uploaded for processing might sit in temporary storage the vendor controls, not you. A support conversation might be retained by a language model provider to improve their own service unless you have explicitly opted out. None of these steps are hidden on purpose — they are simply not present in software that does not call an external model, so the checklist most teams already have does not ask about them.

There is also a scale problem. An AI feature that reads every incoming email or every CV touches personal data continuously and automatically, at a volume a human reviewer never approached. That is precisely the situation the Act is built to have clear rules for: automated processing needs the same lawful basis and the same limits as manual processing, applied consistently rather than checked once and forgotten.

None of this means AI features are unusually risky to build. It means the compliance review has to follow the data through a few extra steps that a traditional application review would not think to ask about, which is what the rest of this piece covers.

Where Personal Data Touches Your AI Pipeline

The clearest way to find the gaps is to draw the pipeline and mark where personal data enters, is processed, and is stored or returned. Most AI features reduce to three stages, and each one carries its own question.

At intake, the question is whether the person providing the data knew an AI system, not just a person, would read it, and whether that use sits within the purpose they were told about. At processing, the question is where the data physically goes: which model provider, in which region, and whether your contract with them rules out using your customers' data to train their general-purpose model. At storage and output, the question is how long a trace survives — in a vector database, a chat log, a cached response — and who can pull it back up.

Checklist: DPDP Obligations Mapped to AI-Specific Checks

The Act's core obligations translate into concrete checks once you place them against an AI pipeline rather than a generic system. This is not exhaustive, but it covers the checks that most AI features actually need and that generic privacy reviews tend to miss.

DPDP obligation	What to verify for an AI feature specifically
Notice and consent	The notice names that an automated or AI system processes the data, not only that "we process your data"
Purpose limitation	Data collected for one purpose (e.g. support) is not silently reused to train or fine-tune a model for another purpose
Data minimisation	Prompts sent to a model include only the fields the task needs, not a full customer record by default
Storage limitation	Chat transcripts, prompt logs, and cached model outputs have a defined retention period, not "kept forever for debugging"
Security safeguards	Data sent to a third-party model provider is encrypted in transit, and the provider's own security posture has been checked, not assumed
Right to access / correction	A correction to a customer record actually reaches anywhere the AI system had cached or derived data from it
Data principal grievance handling	A complaint about an AI-driven decision has a named human reviewer, not just "the system decided"

Walk this table against one AI feature at a time rather than trying to certify your whole stack in one sitting. A recruitment screening tool and an accounts-payable OCR tool touch very different categories of personal data and carry different risk, and the checklist plays out differently for each. If you have not yet done a broader assessment, How to Run a Data Protection Impact Assessment Under DPDP covers the wider process this checklist feeds into.

The Traps Specific to AI: Consent, Training Data and Retention

Three failure modes come up repeatedly in AI features that would not occur in a plain database application, and they are worth naming directly.

The first is consent that covers the general product but not the AI feature bolted onto it. If your CRM's existing privacy notice was written before you added an AI-generated call summary, a lead-scoring model, or an automated reply drafter, it may not actually cover those uses. Revisit consent language whenever an AI capability is added to an existing product, rather than assuming the original notice already stretches to cover it.

The second is model training. Some AI providers, by default, may use API traffic to improve their models unless a business account or specific setting opts out. Sending customer support conversations or CV content to a provider without checking this setting means that data could end up shaping a model used by other customers entirely — a use nobody consented to and one that is very difficult to undo once it has happened. Confirm this setting explicitly with every provider you use, in writing, and keep the confirmation on file.

The third is retention that nobody set deliberately. Logs kept "just in case" for debugging an AI feature often have no expiry, unlike the records in your core database which usually do. A chat transcript containing a customer's personal details, sitting in a log file indefinitely because nobody added a cleanup job, is exactly the kind of gap an audit finds first. Set an explicit retention period for every log, transcript, and cache an AI feature produces, and automate its deletion rather than relying on someone remembering to clear it.

Vendor Due Diligence and a Review You Can Repeat

Every AI feature depends on at least one vendor — a model provider, a hosting platform, sometimes a specialised tool built on top of a model you do not control directly. Your compliance obligations do not transfer to them; you remain responsible for how a vendor handles the personal data you send them, which makes vendor due diligence a genuine compliance step rather than a procurement formality.

Ask each vendor four things before you connect them: where the data is processed and stored, whether they use your data to train models beyond your own use, what their data retention and deletion process looks like, and what security certifications or audits they can show you. Get the answers in writing, ideally in the contract itself rather than a sales conversation, and keep them alongside your internal records. For your own infrastructure and access controls, the practices covered in Security & Compliance apply directly to whatever you build around a vendor's model.

Businesses that get comfortable with this rhythm find it takes a fraction of the time on the second and third AI feature that it took on the first, because the vendor answers and the retention patterns tend to repeat.

Conclusion

DPDP compliance for an AI application is the same law applied to a pipeline that moves personal data through a few extra steps a plain system does not have: an external model call, a cached response, a log that outlives the conversation it recorded. The checklist does not change in spirit — consent, purpose limitation, minimisation, retention, security, and a named person to handle complaints — but it needs to be walked against intake, processing, and storage separately for every AI feature you run.

Start with one feature, walk the checklist against it, fix what the walk finds, and repeat for the next one. That produces a working compliance posture you can actually defend, rather than a policy document that was accurate on the day it was written and has drifted ever since.

If you want help mapping this checklist against a specific AI feature you are building or buying, start the conversation and we will work through it with you.

Frequently Asked Questions

Does DPDP apply differently to AI than to normal software?

The obligations are the same law, but an AI pipeline adds steps — sending data to a model provider, caching a chat transcript, deriving new information from existing records — that a plain database application does not have, so the checklist needs extra questions at each of those steps.

Do we need consent specifically for an AI feature?

You need consent and a notice that actually cover the use. If an AI capability was added after your original privacy notice was written, check whether that notice still describes what the AI feature does, and update it if it does not.

What is the biggest AI-specific compliance risk?

Sending customer data to a model provider without confirming, in writing, that it will not be used to train their general-purpose model, and logs or transcripts with no retention period set. Both are easy to miss because they do not exist in non-AI software.

Can we rely on our vendor's compliance instead of doing our own review?

No. Your obligations under the Act do not transfer to a vendor. You remain responsible for how the personal data you send them is handled, which is why vendor due diligence — asking where data is processed, whether it trains their models, and how it is retained — is a compliance step, not just a procurement one.

Further Reading

• How to Run a Data Protection Impact Assessment Under DPDP
• DPDP Compliance for Indian Startups: A Practical Action Plan
• Security & Compliance