Every AI deployment is also a data deployment — customer messages, documents, and records flowing through models. India's Digital Personal Data Protection (DPDP) Act makes how you handle that flow a legal question, not just a technical one. Here is the practical playbook for 2026. (Practical guidance, not legal advice — involve counsel for your specifics.)
The DPDP basics that touch AI
The Act centers on consent and purpose limitation: personal data collected for a stated purpose, processed for that purpose, retained no longer than needed, with individuals holding rights to access and erasure. Penalties for breaches are serious. For AI systems, four questions become concrete:
- What personal data reaches the model? Chat messages, uploaded documents, and CRM records often contain names, phone numbers, financials, and health details.
- Where does it go? API calls to model providers are cross-border data flows — check your provider's data residency options and processing terms.
- Is it retained or trained on? Enterprise API tiers of major providers contractually exclude your data from training and offer zero-retention modes; consumer tiers may not. This distinction is the whole ballgame — read the actual terms.
- Can you honor erasure? If personal data lands in vector indexes and logs, deletion requests must reach those stores too.
Architecture that keeps you clean
- Minimize before sending. Strip or mask identifiers that the AI task does not need — a support classifier rarely needs the customer's phone number.
- Ground, don't train. RAG architectures keep your data in your stores, retrieved per-query — far cleaner for erasure and consent than baking data into fine-tuned weights.
- Permission-filter retrieval. Access controls must survive into the AI layer: the chatbot should not retrieve documents the asking user could not open (why this matters).
- Log with intent. Traces are essential for debugging; scrub personal data from them on schedule, and put retention limits in writing.
- Consent language that mentions AI. If customer messages are processed by AI systems, say so in your privacy notice — plainly.
Vendor questions that separate serious from sloppy
Which model providers and tiers, exactly? Zero-retention configured? Where do embeddings and logs live, and what is their deletion story? Who signs the data processing agreement? A builder who answers these fluently has done this before; hand-waving here predicts trouble everywhere. (It is also how we build.)
DPDP compliance is mostly good engineering hygiene applied consistently — cheaper to design in than bolt on. Ask us to review your AI data flows, or start any new build with these defaults.
Frequently asked questions
Does the DPDP Act apply to AI systems?
Yes — AI deployments process personal data through models, making consent, purpose limitation, retention, and erasure rights fully applicable. The key questions: what personal data reaches models, where it flows, whether providers retain or train on it, and whether erasure can reach vector indexes and logs.
Is sending data to AI APIs legal under DPDP?
Generally yes with the right setup: enterprise API tiers that contractually exclude training and offer zero retention, data processing agreements, minimization of identifiers before sending, and privacy notices that plainly mention AI processing.
Why is RAG better than fine-tuning for privacy?
RAG keeps your data in your own stores, retrieved per query — so erasure requests and permission filters work naturally. Fine-tuning bakes data into model weights where deletion is practically impossible and access control disappears.
What privacy questions should I ask an AI vendor?
Which model providers and tiers exactly, whether zero-retention is configured, where embeddings and logs live with what deletion story, and who signs the DPA. Fluent answers signal experience; hand-waving predicts trouble.