India's data protection law isn't a checkbox for AI companies — it's a real constraint on how you can collect, train on, and retain personal data at scale.
February 2026 · 5 min read
India's data protection law isn't just another item on a compliance checklist for AI companies — it's a genuine shift in what you're allowed to do with personal data at scale. If you're training models or processing user data in any volume, the rules changed under you. Here's what actually moved.
The DPDPA, backed by rules notified in November 2025, runs on one principle: no consent, no processing. Most ML pipelines were built on the opposite assumption — scrape forums, repurpose old user logs, fine-tune on customer interaction data, build recommendation systems from behavioural traces collected for something else entirely. Under Section 4, essentially all of that now needs explicit, informed, specific consent. Not a vague "we may use your data to improve our services" line buried in a 2019 terms-of-service document.
The consent has to be purpose-bound — "training large language models" clears the bar, "improving user experience" does not. It has to be free, specific, informed, unconditional, and unambiguous, meaning users genuinely understand what's being taken and why, given through a clear affirmative action rather than legalese that hides the AI-training use or a pre-ticked box bundling it with something else. And it has to stay withdrawable — a user can revoke it at any point, and your pipeline needs an actual mechanism to handle deletion or anonymisation once that happens.
If a model was trained on user data collected before 2023, there's a real chance it's non-compliant today. The Act doesn't grandfather legacy datasets — fresh consent is needed regardless of when the original collection happened.
Section 9 together with Rule 10 requires verifiable parental consent for anyone under 18. This isn't a "click here if you're 18+" checkbox — it means actual age verification paired with guardian approval. For consumer-facing AI products — chatbots, ed-tech tools, social platforms — that means either building a genuine dual-consent system or excluding minors from the product entirely.
The Rules define personal data broadly, and in an ML context that reach is wider than most teams assume. It covers the obvious fields — names, emails, phone numbers, IP addresses — and it covers behavioural data too: clickstreams, search queries, purchase history, session logs. It also reaches derived data your own models produce, like credit scores, health risk predictions, or personality profiles inferred from other inputs. Embeddings and pseudonymised data count as well, if re-identification is realistically possible.
Anonymisation is a genuine exit from these obligations, but the bar sits high. K-anonymity or simple hashing alone may not clear it if the Data Protection Board decides a real re-identification risk still exists.
You need to track what data was collected, when, and under which specific consent — storing the consent artefact itself, logging the purpose it was tied to, and handling withdrawal requests with the corresponding data deletion that follows. For fine-tuning or transfer learning on upstream datasets sourced elsewhere, you need assurance those datasets came with valid consent or were genuinely anonymised — liability for non-compliant upstream data doesn't stay with whoever collected it originally, it follows the data.
Section 4 requires collecting only what's necessary for the stated purpose. Pulling an entire user profile when the actual need is a transaction timestamp is a violation on its face. Watch particularly for feature engineering that creates new categories of personal data without anyone noticing — inferring religion or health status from inputs that weren't sensitive on their own. Model outputs that predict individual behaviour count as personal data too, and they inherit the consent scope of whatever input data produced them.
The Rules haven't imposed a blanket data-localisation requirement yet, but Section 16 gives the government power to restrict transfers to countries it doesn't consider adequately protective. If your infrastructure or GPU capacity sits on US or EU cloud providers, it's worth mirroring critical data within India and making sure your data processing agreements and transfer clauses are actually aligned to DPDPA — not just repurposed GDPR paperwork with the labels changed.
Sections 11, 12, and 13 give users rights to access, correction, erasure, and grievance redressal. Your systems need to support machine-readable data exports and a real right to erasure — including erasure from training checkpoints already in production, which is where this gets genuinely hard. Deleting a user's contribution from a frozen training checkpoint or an RLHF dataset usually means either a retraining protocol or documented proof the data was anonymised before it ever went into training.
The Data Protection Board is already operational, and penalties under Section 33 can be imposed today, not at some future enforcement date. Penalties can reach ₹250 crore for breaches involving children's data or cross-border violations, and even the lower end of the range — roughly ₹50 to ₹200 crore — is existential for a startup.
Worth starting now: audit training data sources for consent gaps, build consent infrastructure that's genuinely purpose-specific and logged rather than bolted on, invest in privacy-preserving ML techniques like federated learning and differential privacy, and appoint a Data Protection Officer.
Compliance work here is expensive, but it also functions as a moat. Companies that build privacy-first AI infrastructure now will be genuinely harder to displace later — enterprise buyers and increasingly users themselves will prefer vendors that can produce an audit trail on demand. The companies that treat DPDPA as an engineering problem, not a legal afterthought, are the ones likely to still be building in India's AI market by 2028. The rest will be responding to Data Protection Board notices instead.
If personal data from Indian users is going into model training without a real consent strategy behind it, the runway to a compliance problem is shorter than it looks.
This constraint hits SaaS and AI-native companies particularly directly — our DPDP gap assessment is a practical place to find out exactly where your training data practices stand.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation