Can You Use Customer Data for AI Under the DPDP Act?

As per the DPDP Act, Data Fiduciaries can use customer data for building AI models if such data processing has a ground for processing or is exempted under a reason under the law. Under Section 6(1), consent is limited to the specified purpose and the personal data necessary for that purpose. Consent for service delivery alone therefore does not automatically authorize AI model training. Each project is presumably also individually assessed based on purpose, source and use of data.

Customer conversations, purchase histories and service records can support useful AI applications. For enterprises evaluating DPDP compliance solutions, the business decision is which customer records an AI project can use, for what purpose, and under whose control. Permission to resolve a complaint, generate recommendations and improve a shared AI model can involve different assessments.

The core DPDP processing provisions discussed here are scheduled to commence on 13 May 2027 under the notified phased framework. This article explains those requirements for planning. Existing applicable laws and sectoral obligations continue to matter during the transition. The SPDI Rules, 2011, continue to apply until Section 44(2) commences.

What does the DPDP Act require for AI use of customer data?

The DPDP framework regulates personal data processing, including processing through AI. Its scope turns on the data and activity involved. A customer identifier, conversation or purchase record can remain personal data when it relates to an identifiable individual.

For a DPDP Act AI assessment, separate the activities that use customer records.

Customer service chatbots retrieve information to answer a particular request. An order assistant may need delivery details and access controls that restrict responses to the relevant customer.

Model training and fine-tuning use examples to develop or adapt a model. A support conversation added to a training dataset needs an assessment of the training purpose and the records eligible for that use.

Personalization models use customer information to generate recommendations or offers. Teams should assess the recommendation purpose and the customer choices that apply to it.

Statistical analysis examines patterns such as common complaint themes. Such processing may be assessed under the research exemption in Section 17(2)(b), subject to its conditions.

These distinctions help teams assess the full workflow. For example, a chatbot may retrieve customer records to answer a question while its provider separately retains prompts for model improvement. Assess both uses before approving the integration.

What AI model training consent is needed under the DPDP Act?

AI model training consent must cover the specified training purpose. Consent obtained for a service does not automatically extend to training a model on the resulting customer records. Where consent is the basis, its scope depends on the specified purpose and the personal data necessary for that purpose. The DPDP Act also recognises certain legitimate uses under Section 7, with conditions tied to the particular activity.

When implementing an AI support assistant, the retailer needs to think about three things related to data use. Using the order information to resolve the customer's question about a delivery does achieve a specific goal of customer service. But "adding the conversation to a dataset for training a model to support future customers" has more considerations.

If already valid consent already covers the training purpose and relevant data, the company then needs to assess whether this is sufficient for the proposed data processing. If the training purpose is not covered by consent then a ground for processing must be identified before the processing can take place. A vague reference to service improvement will likely prompt questions about the training purpose.

Section 7(a) permits processing for the specified purpose for which an individual voluntarily provides personal data, where the individual has not indicated that they do not consent to that use. The provision's illustrations cover a pharmacy sending a payment receipt and a rental broker stopping processing once the client no longer needs help. These illustrations support a purpose-specific reading; treating every customer submission as available for unrelated AI development would extend the provision beyond those conditions.

For the optional AI model training consent purpose, the notices and consents should specify the records, the purpose of training, and how individuals can withdraw. Rule 3 states that notices must be intelligible on their own and state the scope of personal data and purposes. Rule 3(c)(i) also requires information on how individuals can withdraw consent, with ease comparable to giving it. Rule 3 applies from 13 May 2027.

Operational practice, which is to be adopted, would be: For each dataset eligible for AI model training, where the user opts to participate, and where a clear notice has been provided, the consent to train the model should be attached to the data, and the version of the notice preserved. Any user's choice to opt-in for AI model training should not be conflated with the service requested.

Is publicly available data excluded under DPDP Section 3(c)(ii)?

Section 3(c)(ii) excludes personal data made or caused to be made publicly available by the individual concerned, or by another person legally obliged under Indian law to publish it. Where the conditions of Section 3(c)(ii) are satisfied, the personal data falls outside the Act's scope.

Assessing publicly available data under DPDP therefore starts with the source of publication. A person's own public post and a leaked customer database have different provenance. On this reading, a leaked database is not data the individual made public. Finding both through a search engine does not establish that both qualify for the exclusion.

For publicly available data under DPDP, document who published the information and the basis for treating it as excluded. A supplier's description of a dataset as public should be supported by evidence that the publication meets Section 3(c)(ii).

AI projects also combine information. Adding private CRM records to public posts requires a separate assessment of the CRM data. Questions about inferred personal data, republication and information that later becomes private remain areas requiring legal interpretation.

The DPDP exclusion also leaves other applicable requirements to assess, including intellectual property, contractual and sectoral restrictions. Approval of publicly available data under DPDP should therefore include the publication conditions and other applicable restrictions.

Does the research exemption under Section 17(2)(b) cover commercial AI?

On a reading of the statutory text, the research exemption under Section 17(2)(b) does not expressly restrict research to academic institutions or non-commercial work; counsel should confirm this interpretation. Its conditions concern processing necessary for research, archiving or statistics, personal data that will not be used to take decisions specific to an individual, and compliance with prescribed standards. Where the exemption applies, the provisions of the whole Act do not apply to that processing.

Rule 16 connects the research exemption under Section 17(2)(b) to the Second Schedule of the DPDP Rules, 2025. Its standards include processing in a lawful manner, purposes limited to research, archiving or statistics, necessary data use, reasonable efforts towards accuracy, limited retention, security safeguards and accountability.

A company should assess the actual activity and intended use. Describing a project as AI research does not establish eligibility. Equally, commercial involvement alone does not settle the question against it.

For example, studying aggregate service demand and using customer records to determine individual offers raise different questions. Teams should reassess the research exemption under Section 17(2)(b) when an exploratory project moves into deployment that makes decisions about individuals. The boundary between model development and later commercial use remains a matter for legal review.

OneConsent also covers the wider framework in its guide to DPDPA exemptions under Section 17.

What should a DPDP Act AI checklist cover before training begins?

When evaluating DPDP consent management software, organizations should assess how it supports purpose-specific consent, withdrawal workflows and the records needed for an AI project review. The following checklist is a recommended governance approach.

1. Define the use precisely. Describe the task, the intended users and whether outputs influence individual decisions. Replace broad labels such as AI innovation with a concrete purpose.

2. Map every data source. Include CRM fields, transcripts, uploaded documents and information about other people mentioned in customer conversations. Identify records involving children for separate assessment.

3. Record the basis for each activity. Connect each purpose to its processing basis. Record AI model training consent where relied upon, or the assessment supporting a particular legitimate use, exclusion or exemption. Keep the supporting notice and evidence available.

4. Limit the records supplied. Test whether approved knowledge articles, aggregated information or fewer customer fields can achieve the objective. Assess whether masked records remain identifiable.

5. Review the provider's actual use. Examine retention, prompt logging, training settings, sub processors and storage locations. Under Section 8(2), engaging a processor requires a valid contract; Section 8(1) leaves the Data Fiduciary responsible for processing on its behalf.

6. Test withdrawal and deletion. Trace what happens to the source record, training copies, retrieval indexes and provider-held information. Assign an owner for each action and document applicable retention requirements.

7. Approve changes to the project. Reassess new data sources, purposes and vendor settings. An approval for a support assistant should identify whether later model training is within scope.

Provider roles deserve particular attention. A supplier processing records solely on the enterprise's instructions and a supplier determining its own model development purposes may require different legal treatment. DPDP consulting services can help organizations assess provider roles and ensure contract wording reflects the actual processing arrangement.

The DPDP readiness guide provides a broader starting point for assessing organizational privacy processes.

What happens when AI model training consent is withdrawn?

Where processing relies on consent, Section 6(4) gives individuals the right to withdraw consent with ease comparable to giving it. Under Section 6(6), the Data Fiduciary must stop processing and cause its Data Processors to stop within a reasonable time following withdrawal, unless processing without consent is required or authorized by law. Separately, Section 8(7) requires the Data Fiduciary to erase personal data and cause its processors to erase it on withdrawal or when it is reasonable to assume the specified purpose is no longer served, whichever is earlier, unless retention is necessary to comply with law.

When AI model training consent is withdrawn, the recommended operational response is to trace affected records across active datasets, retrieval systems and providers. Retention for a legal purpose should be assessed separately from permission to continue optional model development.

Trained models introduce a further technical question. Removing a training file does not establish that a model has forgotten its contents. Research on machine unlearning, which seeks to remove learned information, shows that effectiveness and evaluation remain challenging.

The Act and Rules do not prescribe a universal machine unlearning procedure. Legal and technical teams should evaluate any personal data retained or exposed by the system, the applicable obligations and the measures available. Model architecture, dataset traceability and provider commitments should form part of this assessment before training begins.

Connect AI approvals to consent operations

A DPDPA consent management platform can support the consent processes that connect an approved AI purpose with customer choices and the records eligible for use. The project assessment should address AI model training consent, any reliance on publicly available data under DPDP, and any proposed research exemption under Section 17(2)(b). Teams should be able to explain why a dataset qualifies, which uses are authorized and what happens when a customer's choice changes.

OneConsent is a consent management platform that supports consent capture, preference management, audit logs and rights handling. These capabilities can support the consent processes around an enterprise AI project, alongside its legal assessment and technical controls.

Book a demo to explore how OneConsent can support purpose-based consent management and privacy operations.