DPDP Act in AI: Data, Training, Deployment

The AI Lifecycle Under the DPDP Act

An AI system is not a single product but the result of a multi-stage process, or lifecycle. Each stage involves distinct "processing" activities under the DPDP Act, and each must have a lawful basis. We will examine three key stages:

1. Data Collection: Acquiring the raw data to train the model.
2. Model Training: Processing the collected data to "teach" the model.
3. Deployment & Inference: Using the trained model to make predictions or decisions based on new data.

Let's begin at the source.

Stage 1: Data Collection for AI Training

The adage "data is the new oil" is especially true for AI. The performance of most models depends on the volume and quality of their training data. Under the DPDP Act, how this data is acquired is the first and most critical compliance checkpoint.

There are two primary categories of data used for training: non-public data and publicly available data.

Processing Non-Public Personal Data

When an AI developer uses personal data that is not publicly available (e.g., user account information, private messages, customer support logs), the DPDP Act applies in full.

• Lawful Basis: The primary ground for this processing will almost always be consent. As we learned, this consent must be free, specific, informed, and unambiguous.
• Practical Challenge: This presents a significant challenge for developers of general-purpose AI. The "specific" purpose requirement means a developer cannot simply ask for consent to "improve our AI services." They must specify what data will be used and for what kind of AI development. If a model trained for one purpose (e.g., spell-checking) is later repurposed for a completely different task (e.g., sentiment analysis for advertising), this new purpose would require fresh, specific consent.

Processing Publicly Available Personal Data

This is one of the most debated and consequential areas of the DPDP Act for AI development. Many powerful AI models, particularly Large Language Models (LLMs), are trained by scraping vast quantities of data from the public internet.

Section 3(c)(ii) of the DPDP Act states that the Act does not apply to "personal data that is made or caused to be made publicly available by the Data Principal." On its face, this appears to create a massive exemption, effectively permitting the unrestricted scraping of public websites, social media, and forums for AI training.

However, the reality is far more complex. To understand this nuance, let's turn to an academic analysis.

As the article highlights, relying on the public data exclusion is risky. Key issues to consider are:

• Hybrid Workflows: If a dataset mixes publicly scraped data with any non-public personal data, the entire processing activity for the non-public portion falls back under the Act's full scope.
• The Research Exemption (Sec 17(2)(b)): Some may argue AI training is "research." However, this exemption is conditional. It does not apply if the data is used to make a decision about an individual. A commercially deployed AI model that profiles users or recommends content is almost certainly making such "decisions," rendering the research exemption inapplicable.
• Context Collapse: An individual posting on a public forum does not reasonably expect their data to be ingested into a global AI model and used for entirely unrelated purposes. While the Act is textually clear, this disconnect between user expectation and downstream use creates significant ethical and potentially legal risks, which regulators may address in the future.

Stage 2: Data Processing During Model Training

Once data is collected, the training process itself constitutes "processing." This stage invokes several other core principles of the DPDP Act.

Purpose Limitation & Data Minimization

The principles of purpose limitation (processing only for the specified purpose) and data minimization (processing only necessary personal data) are often in direct tension with AI development paradigms that favor using vast datasets for versatile, multi-purpose models.

Let's explore this tension in more detail.

This means an AI developer cannot hoard data for unspecified future uses. The training process must align with the specific purpose for which the data was originally collected and justified. Using a customer's support chat history (collected for the purpose of 'providing customer service') to train a new generative AI for public release would be a clear violation of purpose limitation.

Stage 3: AI Model Deployment & Inference

When the trained model is put into use, two further processing events occur:

1. Input Processing: The model processes new personal data provided by the end-user (e.g., a user's question to a chatbot, a photo uploaded for analysis). This requires its own lawful basis, typically consent from the end-user or the 'Legitimate Use' of voluntary provision.
2. The Right to Erasure: A Data Principal whose data was used in the training set has the right to withdraw their consent and request the erasure of their data.

This second point presents a profound technical challenge for AI. How do you remove a single person's data from a model that has learned complex patterns from petabytes of information?

Let's watch an expert discuss this exact problem.

The issue Dr. Chakrabarti raises is at the heart of a cutting-edge field of computer science known as "Machine Unlearning." As noted in the primer from NLSIU (Resource LINK, Section K), rather than retraining a multi-million dollar model from scratch, MU techniques aim to create an "unlearned" model that behaves as if it had never seen the data that needs to be forgotten. This is a crucial intersection of law and technology that you will increasingly encounter in AI governance.

Tying It All Together: A Visual Framework

To consolidate our understanding of how the DPDP Act applies across the AI lifecycle, let's examine a helpful flowchart.

Study this flowchart carefully. It neatly summarizes our discussion:

• It confirms the Act applies when processing personal data to offer goods/services in India.
• It lists common collection methods that fall squarely under the Act (user prompts, developer data, third-party brokers).
• Crucially, it highlights the two major "off-ramps" we've discussed: using only publicly available data and processing solely for research/statistical purposes, along with the necessary due diligence for each.

Conclusion

Today we have moved from the abstract principles of the DPDP Act to its concrete application across the AI lifecycle. We have seen that at every stage—from the initial data collection to the final deployment and beyond—AI developers must navigate a complex web of legal obligations.

Key Takeaways:

• Lifecycle Compliance: The DPDP Act applies to every stage of AI development, including data collection, model training, and inference. Each stage is a "processing" activity requiring a lawful basis.
• The Public Data Dilemma: While the Act textually excludes publicly available personal data, relying on this for large-scale AI training is fraught with risk due to hybrid workflows and the potential for regulatory re-interpretation.
• Purpose and Minimization vs. AI Paradigms: The core principles of purpose limitation and data minimization are in direct conflict with the common AI practice of using massive, diverse datasets for general-purpose models.
• The "Right to be Forgotten" as a Technical Challenge: The right to erasure forces a technical reckoning for AI, making concepts like "Machine Unlearning" not just an academic pursuit but a potential compliance necessity.

Preview of the Next Lesson:

Many of the large datasets and AI models we've discussed are not stored or processed in a single country. They exist on global cloud infrastructure. This raises a critical question: what happens when personal data of Indian citizens is transferred outside of India? In our next lesson, we will assess the rules for cross-border data transfers in the context of global AI systems, tackling Section 16 of the DPDP Act.