TL;DR: Most ML teams operating in India are already in violation of the Digital Personal Data Protection Act, often without realizing it. They assume that scraped public data and "anonymized" corpora sit outside Section 6's consent rules. This assumption is wrong. The fix is not a legal disclaimer. It is a rebuilt training pipeline with documented lineage. It also needs segmented data buckets, in-region compute for personal data, and a working unlearning path. Compliance is achievable. However, this is only true if you treat the training data as a regulated artifact, not an asset.

Key Takeaways: - Public availability is not a lawful basis under DPDP. Scraped personal data used for ML training needs explicit, purpose-specific consent. - Anonymization rarely survives model training. Membership inference and embedding inversion re-identify "anonymized" data. They also void the defense. - Data localization pushes serious ML workloads into scarce, expensive in-region GPU capacity. It also brings throughput and accuracy tradeoffs that most boards do not see. - Section 6 consent must be free, specific, informed, and unconditional. Bundling "AI training" with "service delivery" in one notice is the most common violation pattern. - A defensible training pipeline demands four artifacts. These are data lineage, consent-tagged segmentation, in-region sensitive layers, and a working unlearning response path.

If your team is training models on scraped, publicly available data, or even loosely anonymized data, then you are not on a path toward compliance. You are already in violation of India's DPDP Act. The consent you assumed existed was never actually obtained.

That sentence feels aggressive. It is meant to be. Across ML teams operating in India, the same assumption keeps showing up. If a name, photo, or email pattern is visible on a public webpage, it is fair game for training. This is true even on a social platform. That assumption collapses the moment you read DPDP Section 6 against Section 2(1)(t).

Here is the chain: - Section 2(1)(t) defines personal data as any data about an identifiable person. - Section 3 brings all digitally processed personal data into the Act's scope. - Section 6 then requires consent for any purpose not covered by a specific exception.

Public access does not enter that test in any form. The Act treats scraped names, photos, email patterns, and behavioral traces as personal data. This is true the moment they land in a training corpus. It is also true regardless of how freely they appeared on the open web. The lawful basis still has to be there.

The deeper trap is that the Act places the burden on the data processor, not the data subject. Your team cannot outsource that diligence to a scraping vendor or open-dataset aggregator. If they cannot produce the consent notice that was in force on the day a record was collected, then your ML training pipelines are running on ungrounded data.

Most teams reading the above assume that anonymization will close the gap. It is, in fact, the next trap waiting for them.

European regulators have spent the last two years pinning down a position. That position should worry every team relying on "anonymized" training data. The CNIL, EDPB, Hamburg DPA, and EDPS have all agreed on a strict rule. Anonymize training data to the maximum extent possible. Yet still honor data subject rights (DSRs) throughout the model training lifecycle. Those two obligations are in tension, not in harmony.

The CNIL itself notes that strong anonymization can make DSRs technically impossible to fulfill once a model is trained. That is the precise bind Indian regulators are likely to bring in once enforcement matures.

Why? Because modern models leak. Membership inference attacks can tell you, with high confidence, whether a specific record was in a training set. Embedding inversion and model inversion attacks can also reconstruct names, faces, and other personal attributes. They do this from a model's parameters alone. The "anonymized" label does not survive a capable adversary.

Under DPDP, the test is whether a data principal can be re-identified through reasonable means. If your embeddings, gradients, or model outputs can be reversed into a person, then your dataset was never truly de-identified. Your Section 6 consent obligation was never discharged. As a result, your model training infrastructure is producing a regulated artifact from an unlawful source. The same logic that breaks the "public data" defense also breaks anonymization the moment re-identification is on the table.

If anonymization is not a clean defense, many teams reach for the next lever. That lever is keeping the data physically inside India. That fix comes with its own invoice.

DPDP's cross-border transfer rules push serious ML workloads toward domestic compute. If your training data originated from Indian data principals, then your pipeline likely cannot ship raw corpora offshore. It cannot ship to GPU clusters without rebuilding the data flow. Model weights, training logs, intermediate checkpoints, and embeddings all carry the same classification. They are classified the same as the data they were derived from.

The economic consequence shows up fast. In-region GPU capacity in India is scarce, expensive, and uneven across transformer scales. Teams accustomed to spot-pricing on global hyperscalers face a multiple-fold cost increase once they localize. This is because the supply curve is steep. It is also because the buyer pool for high-end accelerators is small. Choices that looked neutral in 2024 are now budget decisions with regulatory weight. The data lakehouse patterns in regulated industries have made this clear. The GPU and inference infrastructure you pick today will quietly determine your DPDP posture for the next three years.

The hidden cost is latency and throughput. Distributed training across two regions introduces synchronization penalties. These penalties degrade effective GPU utilization during fine-tuning and embedding jobs. Gradient compression, network round-trip overhead, and storage replication all chip away at throughput. A job that ran overnight on a single region can stretch to two days across a localized data plane.

Then comes the tradeoff most boards are not seeing. Model accuracy often degrades when training is constrained to localized, consented data slices. The slices are smaller, less diverse, and biased toward users who actively opted in. That tradeoff shows up in production metrics, not legal memos. It is the kind of regression that quietly erodes model performance for months before someone notices.

So what does DPDP Section 6 actually require when your team is staring at a cluster and a deadline?

Section 6 consent is non-negotiable under the law. The consent notice must specify the purpose at the time of collection. "Training an AI model" is a separate purpose from "service delivery." Bundling them in a single notice is the most common violation pattern in mature product teams. If your existing privacy notice says "we use your data to provide our service" and nowhere names model training, then you do not have consent for training.

The notice must be free, specific, informed, and unconditional. Pre-ticked boxes, buried clauses, and dark-pattern UI all fail this test. Courts across jurisdictions have repeatedly invalidated them. The same logic will travel to DPDP enforcement.

A few operational consequences for your machine learning workflows: - Purpose limitation is binding. You cannot train on data collected for fraud detection. That same corpus cannot be used to fine-tune a customer-service LLM. Each retraining event requires a fresh lawful basis. - Withdrawal is not theoretical. If a data principal withdraws consent, then your pipeline must support model unlearning. It must also support embedding deletion from RAG indexes and retraining triggers. Anything less turns the withdrawal mechanism into a paper promise. - Sensitive categories get no special carve-out under Section 6. If your data slice includes children's data, health data, or biometric data, then the consent standard tightens, not loosens.

Understanding the law is one thing. Building a pipeline that survives an audit is something else entirely.

A defensible pipeline is a sequence of concrete artifacts, not a policy document. Here is the audit path that turns a violation into a defensible system.

Step 1: Map your data lineage. For every training corpus in your pipeline, document the source. Also document the collection date, the consent text in force at that date, and the lawful basis claimed under the Act. If you cannot answer those four questions for a row of data, then that row is a liability. Treat lineage as a first-class dataset, not a sidecar. Lineage gaps are the single most common reason compliance audits fail in regulated industries.

Step 2: Segment your data by consent type. Build a "Section 6 compliant" bucket, a "to-be-redacted" bucket, and a "do-not-train" bucket. Your transformer or fine-tuning job should pull only from the first bucket. The boundaries should be enforced in code, not in a spreadsheet. This is where your fine-tuning and RAG pipelines gain real audit posture.

Step 3: Operationalize data subject rights against the model. A deletion request against a data principal should trigger an evaluation. The data principal's records live in your training set. The question is: can embeddings be scrubbed from your RAG index? If not, what is the documented basis for refusal? The answer must be reproducible and consistent across cases. Vector index hygiene matters more than most teams realize. In practice, untagged vector corpora are quiet compliance drains that surface only during audits.

Step 4: Localize the sensitive layers. Raw personal data, labels, and embeddings should remain in-region. Model weights can be transferred, but only after a documented transformation. That transformation must remove the ability to reconstruct personal data from the weights themselves. This is harder than it sounds. The audit trail is the proof.

Step 5: Update your ROPA and DPIA. ML training is a processing activity, not a side effect. Your Record of Processing Activities should list each model. It should also list each training dataset and each retraining cadence, with the lawful basis attached. The DPIA should describe re-identification risk and the mitigations applied.

This pattern is not theoretical. It is the same lineage, consent, and localization discipline. Regulated enterprise deployments across financial services and clinical AI now operate under this discipline. Often, untracked AI agent stacks expose the gaps only after procurement review. Teams that have run the full sequence report that the controls stop being a tax. They start being a forcing function for cleaner data and tighter model governance.

None of this matters unless it changes something tangible for your organization.

Enterprise procurement is shifting. Indian banks, insurers, and hospital chains now require DPDP-aligned AI vendors in their RFPs. A defensible training pipeline is increasingly a gating criterion rather than a differentiator. If your LLM deployment and inference stack cannot answer lineage questions in a procurement review, then you are losing deals you never see.

Data quality improves when you segment by consent. Teams that audit their training corpora almost always discover label noise. They also find duplicate records and stale samples that were hidden under the cover of "we have lots of data." Consent-driven segmentation forces a data audit. That audit pays for itself in model performance within a quarter.

Audit readiness compounds. The same lineage, consent, and localization controls that satisfy DPDP also satisfy contractual obligations. They satisfy contracts with global customers operating under GDPR, HIPAA, and the EU AI Act. The investment is rarely DPDP-only. That is the part CFOs miss when they frame compliance as a one-jurisdiction cost.

The honest summary: DPDP does not punish ML teams for using data. It punishes ML teams for pretending consent exists when it does not. A training pipeline that knows its lineage, segments by consent, localizes sensitive layers, and supports unlearning is not just compliant. It is also operationally better than the one most teams are running today. It is the kind of pipeline that turns a regulatory burden into a procurement advantage.

Q: Does the DPDP Act apply to ML training data scraped from the public internet?

A: Yes. Section 2(1)(t) read with Section 3 covers all digitally processed data relating to an identifiable person. Public availability does not create a separate lawful basis. Scraped personal data used for ML training requires DPDP Section 6 consent or another valid ground.

Q: Can I use publicly available data for AI training under DPDP?

A: Public availability is not a blanket exemption. The Act requires that the data was "lawfully made available" for the specific purpose of AI training. Most publicly available data was published for browsing, not for model ingestion. So the lawful-basis test typically fails without explicit consent.

Q: What does DPDP Section 6 require for consent in machine learning?

A: Section 6 requires free, specific, informed, and unconditional consent for a stated purpose. AI training must be named as a distinct purpose at the time of collection. The data principal must also be able to withdraw consent. This, in turn, obliges you to support deletion or unlearning in your trained model.

Q: Does DPDP require data localization for ML training pipelines?

A: DPDP restricts cross-border transfer of personal data to countries not on the notified whitelist. If your training data contains personal data of Indian data principals, then the raw data must remain in-region or in an approved jurisdiction. Intermediate embeddings must also remain in-region. Model weights can typically be exported only after documented transformation.

Q: How do I operationalize data subject deletion requests against a trained model?

A: You need a documented response path. First, identify which training records and embeddings reference the data principal. Then, scrub embeddings from retrieval indexes. Next, evaluate whether model unlearning is technically feasible. Where it is not, document the lawful basis for partial non-fulfillment along with the mitigation applied.

Research and references cited in this article:

• IAMAI raises concerns over DPDP Act clause impacting AI model training in India; flags threat to AI innovation - Storyboard18
• The Efficacy Of The DPDP Act, 2023, In Addressing Algorithmic Bias In AI-Driven Recruitment Platforms In India » Lawful Legal
• IAMAI raises concerns over DPDP Act clause impacting AI model training in India; flags threat to AI innovation - Storyboard18
• Provisions Of DPDP Act And Its Impact » Lawful Legal
• Impact of the DPDP Act 2023 on Healthcare Technologies in India - Responsibilities, Risks & Roadmap
• AI and Machine Learning Under DPDPA: Compliance Guide for Organizations | DPDPA.com
• What DPDP Act Rule 6 Requires When Your Organisation ...
• Navigating Data Minimization Requirements under India's ...
• 🚨 DPDP Awareness Workshop for Retailers 🚨 The Digital ...
• India DPDP Phase 2: What Businesses Must Do to Prepare | Secure Privacy Blog
• Better than the Real Thing? The Promises and Perils of ...
• 18 AI Privacy Violations: Real Examples (2026)