Training Data Governance Under DPDPA: What AI Teams Must Check Before a Model Ships

Most data science teams in India did not build their training pipelines with the DPDP Act in mind, because most of those pipelines existed before the Act's rules were notified. That is not unusual, and it is not a reason for alarm. It is a reason to look at what training data governance actually requires now, before the next model gets built the same way the last one did.

This is the first piece in a four-part series for data science, AI, and ML teams inside Indian enterprises. Each part covers one stage where DPDPA meets the AI lifecycle. This one starts where every model starts: the data it learns from.

Why Training Data Is A DPDPA Problem, Not Just An Engineering One

A model's training set is, in legal terms, processed personal data the moment it includes anything that can identify a person, directly or indirectly. That includes obvious fields like names and phone numbers, but it also includes things engineering teams do not always think of as personal data: a customer ID joined against a behavioural log, a free text support ticket, an image with a face in it, or a voice recording.

The DPDP Act does not carve out an exception for data used to train a model instead of running a transaction. If the data identifies a person, it is personal data, and every obligation that applies to personal data elsewhere in the business applies to it here too.

The Consent Gap Most Pipelines Already Have

Here is the pattern that shows up most often. A product team collects customer data under a notice that describes operational uses: processing a transaction, sending a confirmation, resolving a support ticket. Eighteen months later, a data science team pulls that same data to train a fraud detection model or a recommendation engine. Nobody updated the notice. Nobody asked whether the original consent covers this new purpose.

This is not a hypothetical. It is close to the default state of most enterprise data pipelines, because training data and operational data usually live in the same warehouse, and the data science team rarely owns the consent that data was collected under. Consent governance, in the DPDP sense, is not a one-time form. It is a live mapping between what was promised and what is actually being done with the data, and a training pipeline is one of the easiest places for that mapping to break silently.

Data Provenance Is The Foundation, Not An Afterthought

Data provenance, meaning a clear, traceable record of where a dataset came from, how it was collected, and what it was originally collected for, is the single most useful thing a data science team can build before training anything. Without it, every question that matters later, can we use this data, do we need fresh consent, what happens if a Data Principal asks for erasure, becomes a research project instead of a lookup. A practical provenance record for a training dataset should capture: the original collection point and notice it was collected under, whether the data has been pseudonymised or anonymised and to what standard, whether it includes any sensitive personal data categories, and who approved its use for model training. This does not need to be elaborate. It needs to exist and be current.

What Counts As Anonymisation, And What Does Not

Teams often assume that removing a name or an ID column makes a dataset safe to use freely. Under DPDP, that assumption needs scrutiny. If the remaining fields, combined with other available data, could still identify a person, the dataset is not anonymised in any meaningful legal sense. A date of birth, a PIN code, and a job title together can narrow down to one person in a small enough population, even with the name stripped out.

True anonymisation needs to be irreversible. Pseudonymisation, where identifying fields are replaced with tokens that could theoretically be reversed, is a useful security control, but it does not exit the data from DPDP's scope the way genuine anonymisation does. Knowing which one a dataset has actually undergone, not which one a team assumes it has undergone, is part of training data governance.

Vendor And Open Source Training Data Carries The Same Obligations

A growing share of training data does not originate inside the enterprise at all. It comes from data vendors, scraped public sources, or open datasets bundled into a foundation model's fine-tuning set. None of this is automatically exempt from DPDPA. If that external dataset contains personal data of individuals in India, the enterprise using it to train a model is still processing personal data, and still needs a lawful basis for doing so.

This is where data science teams often assume the vendor or dataset provider has already handled compliance. That assumption is rarely safe to make without verification, and it is one of the reasons third-party risk management needs to extend to data vendors, not just software vendors. Part three of this series goes deeper into vendor risk specifically.

A Practical Checklist Before The Next Training Run

1. Confirm the lawful basis and the scope of original notice for every dataset entering the training pipeline.
2. Document provenance for the dataset: source, collection date, original purpose, and any processing already applied.
3. Verify whether sensitive personal data categories are present and flag them explicitly.
4. Confirm whether the dataset is genuinely anonymised or only pseudonymised, and treat it accordingly.
5. Extend due diligence to vendor and open source datasets the same way it applies to internally collected data.
6. Record who approved the dataset for training use, with a timestamp, so the approval is auditable later.

How Privy By IDfy Supports Training Data Governance

Privy by IDfy gives data science teams the visibility layer this checklist depends on. Data Compass discovers and classifies personal data across structured and unstructured systems, including the datasets that eventually feed a training pipeline, so a team is not relying on memory or tribal knowledge to know what a dataset contains.

InspectAI connects that visibility to consent governance, flagging when data flowing into a new use case, including a training pipeline, drifts from the purpose it was originally collected under. The goal is not to slow down model development. It is to make sure the question "is this dataset clean to use" has an answer before the model ships, not after a regulator asks it.

Conclusion

Training data governance is not a separate compliance exercise bolted onto machine learning work. It is the same DPDPA obligations, consent, purpose limitation, and lawful basis, applied to the dataset a model learns from instead of the system a customer interacts with directly. The data science teams that build provenance and consent checks into their pipeline now will spend far less time reconstructing answers later, whether that question comes from a regulator, an auditor, or a customer exercising their rights.

If your team wants to talk through how to build this visibility into your training pipeline, or you would like a demo of how Privy connects data discovery to consent governance, write to shivani@idfy.com.

FAQ's

Is training data considered personal data under DPDPA? 

Yes, if it includes information that can identify a person, directly or through combination with other data, it is personal data and subject to the same DPDPA obligations as any other processing.

Can we use existing customer data to train a new model without updating consent? 

Not automatically. If the original notice and consent did not cover model training as a purpose, using that data for training may exceed the lawful basis it was collected under.

Does anonymising training data remove it from DPDPA's scope? 

Only if the anonymisation is genuine and irreversible. Pseudonymised data, where identifying fields are tokenised but theoretically reversible, generally remains within DPDPA's scope.

Are vendor or open source training datasets exempt from DPDPA? 

No. If a dataset contains personal data of individuals in India, the enterprise using it to train a model is processing that data and needs a lawful basis, regardless of where the dataset originated.

What is the first practical step toward training data governance? 

Build a provenance record for every dataset entering a training pipeline: its source, original collection purpose, anonymisation status, and approval history.