Training AI on Personal Data: What India's DPDP Act Allows

Introduction

An HR-tech company in Gurugram has five years of job applications on its servers. Its product team wants to use them to build a tool that ranks CVs. The engineers ask one question: are we allowed to? The answer depends almost entirely on the Digital Personal Data Protection Act, 2023 (the DPDP Act), because India has decided against a dedicated AI statute.

MeitY's India AI Governance Guidelines, released on 5 November 2025, state that "a separate law to regulate AI is not needed given the current assessment of risks". They prefer voluntary frameworks and refer personal-data questions back to the DPDP Act. The Act's main obligations commence on 13 May 2027, so any model trained today on Indian personal data will be operating under it.

This article follows an AI system through four stages: where its data comes from, how it is trained, how it is used, and what happens when someone asks to be forgotten.

The legal position

The DPDP Act never mentions artificial intelligence. It governs AI because of how widely it defines processing: under section 2(x), any wholly or partly automated operation on digital personal data. The provisions that matter at each stage are these:

The list of legitimate uses in section 7 is closed. It covers data a person volunteers for a specified purpose, state benefits and functions, disclosures the law requires to be made to the State, court orders, medical emergencies, epidemics, disasters and employment. A business's own commercial reasons for wanting the data, however sensible, are not on it. That single feature shapes most of what follows.

Analysis

Stage 1: Sourcing the data

Scraped web data. The exclusion in section 3(c)(ii) protects data that a person chose to publish, or caused to be published, such as their own public profile or post. It does not protect material that reached the internet some other way: a breached customer list, a third party's article naming a private individual, or a directory compiled without the person's involvement. A crawler cannot reliably tell these apart. Any dataset scraped at scale should therefore be assumed to contain personal data to which the Act fully applies. The Guidelines themselves flag the scope of exemptions for training on public data as an unresolved question.

Licensed datasets. Paying a data broker does not transfer a lawful ground. The company training the model decides why the data is used, so it becomes a data fiduciary for that use. It needs written assurance about how the data was collected, the purpose stated to the people in it, and whether children's data is included.

Data you already hold. This is the HR-tech company's position. The applications were submitted to employers for recruitment. The employers are the data fiduciaries, and the platform processed the data on their behalf. Building its own ranking tool is a new purpose decided by the platform. Neither the employers' contracts nor the employment legitimate use in section 7(i) gives the platform a ground of its own.

Stage 2: Training

The realistic routes are three. The first is consent that names model training as a purpose, collected going forward. Section 6(1) limits consent to the specified purpose and the data necessary for it, so a general "to improve our services" line is weak.

The second is anonymisation. Data that cannot identify a person is not personal data. The test is practical: if records can be re-linked to individuals using information the company holds or could readily obtain, they are not anonymous.

The third is the research exemption in section 17(2)(b). It is valuable for academic and public-interest work. It fails for a product whose purpose is to make decisions about people, because the exemption requires that the data "is not to be used to take any decision specific to a Data Principal". A CV-ranking tool exists to make exactly such decisions.

Children need separate handling. Section 9(3) prohibits behavioural monitoring of under-18s, so training a model to profile minors' behaviour is off-limits even with parental consent.

Stage 3: Using the model

Once deployed, the model's outputs affect people. Section 8(3) then requires the data behind those decisions to be complete, accurate and consistent. For the CV tool, that means checking for missing fields, out-of-date information and inconsistent formats before data reaches the model, and checking outcomes for skew by gender, region or college.

Sector rules add detail. The RBI's FREE-AI committee report (August 2025) sets out principles for AI in finance. SEBI has required market intermediaries to report their AI and machine-learning systems since its circular of 4 January 2019. The ICMR's 2023 guidelines cover AI in biomedical research and healthcare. Karnataka's Platform-Based Gig Workers Act, 2025 requires platforms to tell workers how to obtain information about the automated systems that monitor them and allocate work.

Generative products face one more rule. Amendments to the IT Rules notified as G.S.R. 120(E) on 10 February 2026 require synthetically generated content to be labelled and to carry identifying metadata.

Stage 4: Withdrawal and erasure

Section 8(7) was drafted with databases in mind. Deleting a record from a training set is simple. Removing what a model has learned from that record is not, and the Act does not say whether a trained model holds personal data.

A workable approach treats the training set as the system of record. Keep each training set versioned. When consent is withdrawn, remove the person's records from the current set and the next training run. Add output checks so that the model cannot reproduce a person's details verbatim. Write the procedure down. When the Board examines a complaint, a documented, consistently applied process will matter more than a claim that the model has "forgotten".

Practical implications

For the HR-tech company, the plan looks like this:

• Historic data. Do not train on identifiable historic applications. Build an anonymised training set, removing names, contact details, photographs and free-text fields that could identify a person, and test whether records can be re-linked.
• New data. Add a separate, optional consent for model training on the application form, with its own withdrawal switch.
• Under-18s. Exclude applicants under 18 from training data.
• Quality. Before each release, run data-quality checks and outcome testing, and keep the results.
• Withdrawal. Version every training set and remove withdrawn applicants before each retraining.
• Clients. Tell employer clients what the platform does with data for its own purposes, and update the processing contract accordingly.

Key takeaways

The DPDP Act governs AI in India stage by stage, and its closed list of legitimate uses means that commercial convenience is never a ground in itself. Builders have four realistic routes: data people genuinely published themselves, consent that names training, anonymisation, or research that never feeds individual decisions. Teams that build provenance records and dataset-level erasure now will not have to rebuild their pipelines when the Act's obligations commence in May 2027.

• India has no AI statute; MeitY's November 2025 Guidelines leave personal-data questions in AI to the DPDP Act.
• Section 7's list of legitimate uses is closed, so a business's commercial interest is never a ground for training on its own.
• The public-data exclusion covers only data a person published or caused to be published, not everything a crawler can reach.
• The research exemption is unavailable for models that make decisions about individuals; such models also need s.8(3) data-quality controls.
• Treat the versioned training set as the system of record for erasure and withdrawal.