Can You Train AI on Indian Customer Data? What the DPDP Act Says About AI Training Data

Short answer: Under India's DPDP Act you may train AI on personal data only if you have consent for that specific purpose, or the processing falls under a listed legitimate use. There is no legitimate-interests basis, no commercial research exemption, and no "we already had the data" argument. Consent obtained for delivering a service does not extend to training a model on the resulting data.

The Core Problem: Purpose Limitation

Most Indian AI projects begin with data the company already holds. Support transcripts. Chat logs. Call recordings. Loan applications. Product reviews. The data exists, the business owns the systems, and building a model on it feels like using your own asset.

The DPDP Act does not work that way. Consent under the Act must be free, specific, informed, unconditional, and unambiguous, with a clear affirmative action, and it is limited to the specified purpose in the notice. Section 6(1) is explicit that consent is limited to such personal data as is necessary for that purpose.

Key insight: "We collected this data lawfully" and "we may train on this data" are different claims. The first is about the original collection; the second requires its own lawful basis. A customer who consented to their support ticket being used to resolve their issue did not consent to it becoming training data for a model that will serve other customers.

What India Does Not Have

Teams that have worked under GDPR reach for familiar tools that simply do not exist in the Indian statute.

Available under GDPR	Available under DPDP Act
Legitimate interests (Art. 6(1)(f)) — the basis most EU AI training relies on	Does not exist. Processing runs on consent or a listed legitimate use only.
Scientific and statistical research exemption (Art. 89)	Research exemption exists but is narrow; commercial product development does not obviously sit inside it.
Pseudonymisation as a recognised risk-reduction measure with defined legal effect	No statutory definition of anonymisation or pseudonymisation, and no safe harbour attached to either.
Balancing test to justify secondary processing	No balancing test. Either you have a basis or you do not.

The absence of legitimate interests is the single biggest structural difference for AI builders. In the EU, a company can document a legitimate-interests assessment and train on customer data. In India, that route is closed. Consent for the training purpose, or a listed legitimate use, or nothing.

The Legitimate Uses That Might Apply

Section 7 lists the non-consent grounds. Read against a typical AI project, most of them do not help:

• Voluntary provision for a specified purpose — where the Data Principal has voluntarily provided data for a purpose and has not indicated objection. This covers the immediate purpose, not open-ended reuse.
• Employment purposes — safeguarding the employer from loss, providing services to employees. Relevant for internal HR analytics, not customer-facing models.
• Compliance with law, court orders, medical emergency, disaster, public order — none of which describe a product roadmap.

Note what is missing: there is no "improving our services" ground. Product improvement through model training is a consent purpose in India.

The Publicly Available Data Question

The Act does not apply to personal data that a Data Principal has themselves made publicly available, or that is required by law to be made public. That is the closest thing to a web-scraping carve-out — and it is narrower than it looks.

The exemption turns on who made it public. A person who published their own blog post made that public themselves. A person whose phone number appears in a leaked database, an aggregator listing, or a scraped directory did not. Training a model on scraped Indian data is therefore only defensible for the subset that the individuals themselves published, which is almost never how a scrape is scoped.

Does Anonymisation Solve It?

Partly, and less than teams hope. The DPDP Act applies to digital personal data — data about an identifiable individual. Data that genuinely cannot be linked back to a person falls outside the Act. But the Act contains no definition of anonymisation and no certification standard, which means the burden of proving the data is truly non-identifiable sits with you, after the fact, in front of a regulator.

Three practical failure modes:

• Stripping direct identifiers is not anonymisation. Removing name, phone, and email from a support transcript leaves an account number in the body text, a city, an order history, and a writing style. Re-identification research has repeatedly shown that a handful of quasi-identifiers is enough.
• Free text resists redaction. Customer messages contain names, addresses, and card fragments in unpredictable formats. Automated redaction over Indian-language and code-mixed text is materially harder than over English.
• Models memorise. Large models can regurgitate training examples verbatim. If a model can be prompted into emitting a real customer's phone number, the argument that the training data was anonymised collapses.

Anonymisation before training is still worth doing — it reduces breach severity and narrows exposure. It just is not a substitute for having a lawful basis.

The Erasure Problem

This is the obligation that most AI architectures have no answer for. The Act gives Data Principals the right to erasure of their personal data. When consent is withdrawn, the Data Fiduciary must cease processing and erase, unless retention is required by law.

Now apply that to a model:

• Training corpus — deletable. Straightforward if you kept a record of which records came from whom.
• RAG / vector index — deletable, if your embeddings carry a per-record identifier back to the source. Many pipelines do not, and cannot delete one person's contribution.
• Model weights — not deletable. Once a person's data has shaped the weights, removing that influence means retraining. Machine unlearning is an active research area, not a production capability.

The architectural consequence: keep personal data out of the weights. Put it in a retrieval layer you can actually delete from. A model trained on de-identified or synthetic patterns, retrieving from a per-user index with hard delete, is compliant-shaped. A model fine-tuned directly on identifiable customer records is not, and cannot be made so after the fact.

What About Models Already Trained?

The question every Indian AI team asks second: we trained on customer data in 2024, before any of this was enforceable. What now?

There is no grandfathering clause. The Act does not exempt processing that began before commencement — it regulates processing that continues after it. Three consequences worth being clear about:

• The historical training act occurred before enforceability, so it is not directly actionable under the Act's penalty provisions.
• Continuing to use the resulting model in production is ongoing processing. If the model's outputs are derived from personal data processed without a basis, you are operating on an uncertain footing.
• The training corpus itself is live data subject to every obligation — retention limits, erasure requests, security safeguards — for as long as you keep it.

The pragmatic remediation sequence: delete or de-identify the retained corpus, document what it contained and when it was used, add the AI purpose to your notice going forward, and rebuild from consented data at the next retraining cycle. What you should not do is treat an existing model as a settled asset that the Act cannot reach — a Data Principal's erasure request will test that assumption.

Synthetic Data Is Not a Loophole (But It Helps)

Generating synthetic records from real customer data is increasingly pitched as the compliance-friendly path. It is genuinely useful and it is not a free pass.

The generation step is itself processing of the source personal data, and needs a basis. What synthetic data does well is limit downstream exposure: once generated, well-constructed synthetic records relate to no identifiable individual, so they can move freely between teams, environments, and vendors without carrying DPDP obligations along.

The caveat is memorisation, again. Generative models fitted too closely to a small source dataset can reproduce real records nearly verbatim. If your synthetic customer table contains a row matching an actual customer, it is not synthetic — it is a copy with extra steps. Test for it before treating the output as out of scope.

Where the AI Governance Guidelines Land

India's AI Governance Guidelines, released at the AI Impact Summit 2026, set out seven principles — trust, human-centricity, fairness and equity, accountability, understandable by design, safety and robustness, and inclusive and sustainable innovation — supported by three new institutions: an AI Governance Group, a Technology and Policy Expert Committee, and an AI Safety Institute.

The posture is techno-legal and voluntary: self-certification and regulatory sandboxes rather than prescriptive mandates. That makes the Guidelines a statement of direction, not an enforcement instrument. The enforceable obligations on AI systems processing personal data come from the DPDP Act, and they arrive on 13 May 2027. We cover the Guidelines in detail in our breakdown of the seven sutras for data fiduciaries.

A Workable Pattern

For Indian companies that want to build with AI without betting the business on a favourable interpretation:

1. Add AI/ML as an explicit, separately toggleable purpose in your consent notice — not buried in "service improvement." Users who decline still get the product.
2. Tag every record with its consent state at ingestion. The training pipeline filters on that tag. If you cannot filter, you cannot prove which records were eligible.
3. Prefer retrieval over fine-tuning for anything involving personal data, so erasure is a delete rather than a retrain.
4. De-identify at ingestion, not at training time, so the identifiable copy never enters the ML environment.
5. Keep a training-data provenance record — which dataset, which consent purpose, which notice version, what date. This is the artefact that answers a Board query.
6. Re-consent before repurposing. Using an existing corpus for a new model purpose is a new purpose. Ask again.

Frequently Asked Questions

Can Indian companies train AI models on customer data?

Yes, with consent obtained for that specific purpose, or where a listed legitimate use under Section 7 applies. Consent obtained for delivering a service does not extend to model training — that is a separate purpose requiring its own notice and its own affirmative action from the user.

Does the DPDP Act have a legitimate interests basis for AI training?

No. Unlike the GDPR, the DPDP Act has no legitimate-interests ground. Processing must rest on consent or one of the legitimate uses enumerated in Section 7, none of which covers commercial product development or service improvement through model training.

Can we train on scraped or publicly available Indian data?

Only where the Data Principal themselves made the data publicly available, or where publication is legally mandated. Data that is merely accessible online — leaked datasets, scraped directories, aggregator listings — does not qualify, because the individual did not make it public.

Does anonymising the data remove DPDP obligations?

Genuinely anonymised data falls outside the Act, since the Act governs data about identifiable individuals. But the Act defines no anonymisation standard, so the burden of proving non-identifiability is yours. Stripping direct identifiers from records that still contain quasi-identifiers, free text, or behavioural history usually will not meet that burden.

What happens when a user withdraws consent after their data trained a model?

You must stop processing and erase their personal data. Training corpora and retrieval indexes are deletable; model weights are not, since removing one person's influence requires retraining. This is why personal data should sit in a retrieval layer rather than being baked into weights.

Do these rules apply to using third-party APIs like OpenAI or Gemini?

Yes, and they add a processor relationship. If you send customer data to an external model provider, that provider is processing personal data on your behalf and must be bound by contract. You remain the Data Fiduciary and remain accountable for the processing, including where the data is stored. See our guide to DPDP compliance for AI chatbots and LLM apps.

Where Consently Fits

The compliant pattern needs one thing above all: a per-purpose consent record you can filter a training pipeline against. Consently captures itemised consent with AI/ML as its own toggleable purpose, versions the notice each user actually saw, keeps immutable zero-PII consent records queryable per Data Principal, and propagates withdrawal so downstream systems know a record has become ineligible. If your training pipeline cannot currently answer "which of these records had consent for this purpose, on this date," that is the gap to close first. Talk to us.