DPDP and AI: training data, chatbots and staff using AI tools

The DPDP Act has no chapter on artificial intelligence, and it does not need one. Every AI system that collects, stores, trains on or makes decisions with personal data is processing under the Act (s. 2(x)), and needs a basis: consent, or one of the legitimate uses in section 7. There is no "legitimate interests" ground, so training a model on customer data usually needs consent you probably do not have. Data a person made public herself is outside the Act (s. 3(c)(ii)), but that exclusion is narrower than web scraping assumes. Most duties start on 13 May 2027.

Like the Act (s. 2(y)), we say "she" and "her" for every person.

Jump to what you need:

• CTOs and data science leads: Training on personal data, A worked example, Public data, Provider retention, Erasure and models.
• Product and CX heads: Chatbots, Agents, Automated decisions.
• CIOs, HR and legal: The staff AI policy, Vendors, Large fiduciaries.

What applies now

Until 13 May 2027 the SPDI Rules bind body corporates, requiring consent for sensitive personal data such as health, financial and biometric information. India has no AI statute. MeitY's India AI Governance Guidelines of 5 November 2025 are guidance; the drafting committee recommended relying on existing laws, reinterpreted or amended where necessary, notably copyright and data protection (MediaNama). The main cross-sector binding measure, in force from 20 February 2026, makes intermediaries label synthetic content (S.S. Rana). SEBI-regulated entities are solely responsible for investor data privacy and security, and for the outputs of AI tools they use under SEBI's Intermediaries (Amendment) Regulations notified on 6 February 2025 (AZB & Partners). The EU AI Act reaches Indian firms selling AI into Europe.

Map your AI uses first

Put every row into your data map: data, purpose, basis, processors, hosting, retention.

Training a model on personal data: which basis

The Act allows processing only for a lawful purpose, on consent or a legitimate use (s. 4(1)). For training, run through the options in this order.

Consent. It must be free, specific, informed, unconditional and unambiguous, with a clear affirmative action, and limited to the data necessary for the specified purpose (s. 6(1)). "To improve our services" will not do; the notice must name the purpose and describe the use it enables (Rule 3(b)(ii)). A box that says "Use my conversations to train the assistant that answers customer queries", unticked by default and separate from the terms of service, can work. Making the service conditional on agreeing to training fails the "unconditional" test.

Voluntary provision, s. 7(a). It covers the specified purpose for which she gave you her data, so long as she has not said she objects. Our view: training a general model on it is a different purpose, beyond what 7(a) covers. The Act's own illustration for 7(a), a pharmacy customer giving her number for a receipt, supports a narrow reading.

Employment, s. 7(i). It covers processing "for the purposes of employment" and to protect the employer from loss or liability. Training an internal model on employee records to flag payroll exceptions may fit. Our assessment is that training a product you will sell, on employee data, does not.

Research and statistics, s. 17(2)(b). The Act does not apply to processing necessary for research, archiving or statistics, if the data is not used to take any decision specific to a person and the Second Schedule standards are met (Rule 16). Commercial product development may not be "research" at all. An evaluation model whose outputs never touch individuals may qualify. A production model that scores, ranks or answers individual customers takes decisions specific to them, and does not.

De-identified data. Data that no longer relates to an identifiable individual is not personal data (s. 2(t)), and the Act sets no anonymisation standard. Pseudonymised data, with names replaced by IDs that you or a vendor can reverse, stays personal data. Free text is the hard case, because case notes and transcripts carry names, places and details that re-identify people.

Where none fits, train only on newly consented, tested de-identified or synthetic data.

Worked example: 40,000 support tickets

This illustration is a composite, not a client story. A consumer lender wants to fine-tune a model that drafts first replies to support tickets, using 40,000 tickets from the past two years. No customer was asked about training.

The de-identification test. After automated redaction, two analysts who know the systems take a random sample of 400 tickets and try to identify the customer using only the ticket and the company's own records. In the first round they identify 11, mostly through unusual loan amounts or a branch named alongside a date. The team adds rules for amounts and branch names, re-runs redaction on the whole set, and tests a fresh sample of 400. They identify none.

The result. The team treats the redacted set as no longer personal data (s. 2(t)), records both test rounds, the rules, the reviewers and the date, and repeats the test whenever the redaction rules change. The redaction is itself processing of the original tickets and needs a basis. Our view: preparing de-identified data from tickets given under s. 7(a) is arguable, not settled. Until 13 May 2027, the SPDI Rules also govern any financial information in the tickets. Running the finished model on new tickets to draft replies for that customer's own problem is processing for the purpose she gave the data for, under 7(a).

Public data and the section 3(c)(ii) exclusion

The Act does not apply to personal data "made or caused to be made publicly available" by the person it relates to, or by someone legally obliged to publish it (s. 3(c)(ii)). The Act's illustration: X, while blogging her views, has publicly made available her personal data on social media; the Act does not apply. AI developers lean on this clause for web data.

What the text covers. Data she made public herself: her own blog, her public posts, the profile she published. And data someone was required by an Indian law to publish, such as the particulars a statute requires a register or a company filing to make public.

What it does not cover.

• Data about her that someone else made public: a news report, a friend's post, a tagged photo, a review that names her, a leaked database.
• Data behind a login, a paywall or a closed group. Our position is that "publicly available" means available to the public.
• Data you can no longer show was public. A scraped corpus with no record of source and date gives you nothing to prove the exclusion with.

What the text leaves open. The clause says nothing about purpose, so it is arguable that once data is public, any later use is outside the Act. We recommend relying on it only for what she published, in the context she published it. Once you combine public data with data you hold under the Act, or derive a profile, score or inference about her, treat the output as in scope.

A web-scale corpus mixes all of these, and you cannot apply the exclusion record by record without knowing which is which. Copyright, website terms, the IT Act and sector laws still apply.

Customer data, AI vendors and who the fiduciary is

A fiduciary decides the purpose and means of processing; a processor acts on its behalf (s. 2(i), 2(k)).

What to put in an AI vendor contract, beyond your standard processing terms (the full clause set is in Data fiduciary or processor?):

• no training or fine-tuning on your data, prompts or outputs without your written approval;
• the retention mode for prompts and outputs, where they are kept, and deletion on request and at contract end, with confirmation (s. 8(7)(b));
• the list of sub-processors and hosting regions, with notice before changes;
• notice to you of any breach within hours, with the facts you need for Rule 7;
• support for access, correction and erasure requests, including data in logs, caches and vector indexes.

Provider retention modes and the one-year log floor

Providers usually offer several retention modes for API traffic: a default in which inputs and outputs are kept for a period for abuse monitoring, sometimes with human review of flagged content; a zero-retention mode in which nothing is stored after the response; and, for consumer products, retention for training unless switched off.

The Rules pull the other way. Every fiduciary must keep the personal data, traffic data and logs of its processing, including processing by its processors, for at least one year, for the Seventh Schedule purposes (Rule 8(3)). Rule 6(1)(e) separately asks for a year of logs and personal data to detect and investigate unauthorised access.

Our decision rule, which is a recommendation and not a reading the Board has confirmed:

In our view the duty sits on you, so a provider's zero retention does not breach Rule 8(3) so long as you keep the record.

Chatbots that collect personal data

A chatbot that asks for a name, a phone number or an account detail is a collection point. Where consent is the basis, the notice must accompany or precede the request (s. 5(1)). In a conversation, the whole notice comes with or before the first question. It must itemise the data and the purpose, describe the service it enables, and give a link and the means to withdraw consent, exercise rights and complain to the Board (Rule 3). The request must name a person who can answer her questions (s. 6(3)), and both must be available in English or an Eighth Schedule language (s. 5(3), 6(3)).

An illustrative opening for a course-enrolment bot run by a skilling programme, written to Rule 3. Adapt the data, purposes and links to your own processing.

Namaste. I'm the automated assistant for Sahyog Skills. To enrol you in a course I will ask for your name, mobile number, age, district and the course you want. We use these only to enrol you and send you class updates, and we keep this chat for 12 months. Separately, I will ask whether we may use this chat to improve this assistant. You can say no and still enrol. You can withdraw consent at any time by typing STOP or at sahyog.example/privacy. To see, correct or erase your data, or to raise a grievance, write to privacy@sahyog.example or visit sahyog.example/privacy. You can also complain to the Data Protection Board of India; how to do so is at sahyog.example/privacy/board. Type HINDI for this message in Hindi. Are you 18 or older? Reply YES or NO.

The sample is illustrative. The Board has no confirmed online complaint facility as of 25 October 2026, so point to your own page explaining how.

Design rules:

• Separate purposes. Enrolment and training are two purposes. Ask for each separately, so she can refuse one and keep the other (s. 6(1)).
• Oversharing. People type more than you ask for: Aadhaar numbers, diagnoses, other people's details. Consent covers only data necessary for the purpose (s. 6(1)). We recommend a warning before free-text fields, masking of identifiers you did not ask for, and keeping them out of training sets and analytics.
• Withdrawal as easy as consent. If she consented in chat, she should be able to withdraw in chat (s. 6(4)), and the withdrawal has to reach your processors (s. 6(6)).
• Children. A child is anyone under eighteen (s. 2(f)). Before processing a child's data you need the verifiable consent of a parent (s. 9(1)), checking that the person consenting is an adult (identifiable where a law requires it), from reliable identity and age details (Rule 10(1)). You may process data to confirm a user is not a child (Fourth Schedule, Part B, item 6). If the answer is no, stop collecting the child's data until a parent has been verified. A bot aimed at students may not track, behaviourally monitor or target ads at them (s. 9(3)). Methods for verifying parents are in Verifiable parental consent.
• Rights through the bot. Route requests that arrive in chat to the same tracker as email requests, and quote your contact details in every reply (Rule 9).

Agents, synthetic data and test logs

Agents acting through tools. An agent that reads a CRM, sends emails or issues refunds processes personal data each time it calls a tool. Give it its own credentials with the narrowest access the task needs (Rule 6(1)(b)), log every tool call against the person affected (Rule 6(1)(c)), and require a person to approve actions that are hard to reverse, such as a payment, a closure or a message to a third party. An agent tricked by text in an email or web page into sending data elsewhere has caused a breach (s. 2(u)). Withdrawals and erasures must reach the agent's memory and caches too (s. 6(6), 8(7)).

Synthetic data. Generating synthetic records from real ones is itself processing of the real data, and needs a basis. The output is outside the Act only if it no longer relates to identifiable people (s. 2(t)). Test it as you would the ticket set.

Evaluation and red-team logs. Test sets built from real tickets or chats, and the logs of red-team runs, are personal data with the same retention and access rules as production. We recommend synthetic personas for red-teaming, and real data in evaluation sets only after the de-identification test.

Staff pasting data into AI tools: a policy you can adopt

A support executive pastes a complaint into a free chat assistant; a programme officer uploads case notes to summarise them. Each discloses personal data to a third party with no processing contract (s. 8(2)), for a use the person was never told about, and depending on the tool's terms the provider may keep or train on it.

A personal data breach includes any "unauthorised processing" or accidental "disclosure" or "sharing" that compromises confidentiality (s. 2(u)). Our view is that a paste into an unapproved tool that keeps the data can meet that definition, and from 13 May 2027 that would trigger notice to the Board and to each affected person, with no minimum size (s. 8(6), Rule 7). The CERT-In Directions list "data breach", "data leak" and attacks or suspicious activity affecting AI and machine-learning systems (Annexure I, items xi, xii and xx) among reportable incidents, if they apply to you (CERT-In). See DPDP breach response for both clocks.

We recommend approving a tool rather than banning AI outright, because a ban with no alternative leaves staff to use whatever is on their own phones, where you can see nothing. An illustrative policy, which other Commons Trust guides link to:

1. Scope. This policy covers every employee, contractor and volunteer, on any device, when working for us.
2. Approved tools only. Use only the AI tools on the approved list, through company accounts, with training on our inputs switched off by contract or setting. The list is published on the intranet and owned by IT.
3. What never goes in. Never enter the following into any tool that is not approved: - customer, beneficiary, donor, patient or employee data; - children's data; - government ID numbers; - health or financial details about a person; - credentials, or code containing secrets.
4. Minimum necessary. Even in an approved tool, include only what the task needs. Remove names and identifiers where the task works without them.
5. No decisions without review. AI output used to decide anything about a person (a refund, a loan, a hire, a benefit) is checked by a named person before it is acted on.
6. No unsupervised agents. Do not connect an AI tool to email, the CRM or any system holding personal data without IT approval.
7. New tools. Ask IT before using a new tool for work. If it will see personal data, it goes through security review and onto the processor list first.
8. Logging. Use of approved tools on work systems is logged, to enforce this policy and to investigate incidents.
9. Mistakes. Report a mistaken paste to [the incident lead] the same day. Reporting quickly is never a disciplinary matter; hiding it is.
10. Ownership and review. [Named owner] owns this policy and reviews it every six months.

Our view: monitoring employees' use of AI tools on work systems to enforce the policy fits s. 7(i), which covers safeguarding the employer from loss or liability. For contractors and volunteers, s. 7(i) is uncertain; tell them in writing before the policy applies and treat the basis as an open question. Tell staff it happens, and give them an approved tool in the same week you publish the rule.

Automated decisions and the accuracy duty

The Act has no equivalent of GDPR Article 22, the right not to be subject to a decision based solely on automated processing, and no right to human review. It has one duty that does much of the same work. Where personal data is likely to be used to make a decision that affects the person, or disclosed to another fiduciary, you must ensure its completeness, accuracy and consistency (s. 8(3)).

For a model, that reaches further than the input record:

• Inputs. An outdated address, a mismatched name or a stale repayment record that drives a rejection breaches s. 8(3).
• Outputs. A score, label or summary about a person is personal data, because data includes opinions (s. 2(h)). Our view is that if it is inaccurate and used to decide, the duty applies to it too.
• Generated text. Keep a person between a model's statements about individuals and decisions about them.

She can ask for a summary of her data and the processing (s. 11(1)(a)) and for correction (s. 12(2)), at least where she consented or gave the data under 7(a). We recommend using your grievance mechanism (s. 8(10)) as the practical human-review route: a rejected applicant who complains should reach a person who can look at the decision.

Significant Data Fiduciaries: checking algorithmic software

No Significant Data Fiduciary has been notified as of 25 October 2026. If you are notified, the SDF duties that bear on AI are:

• a Data Protection Impact Assessment every twelve months, assessing and managing the risk to people's rights (s. 10(2)(c)(i), Rule 13(1)), with significant observations reported to the Board (Rule 13(2));
• an independent data audit (s. 10(2)(b));
• due diligence to verify that "technical measures including algorithmic software" adopted for "hosting, display, uploading, modification, publishing, transmission, storage, updating or sharing" of personal data are not likely to pose a risk to people's rights (Rule 13(3)).

Rule 13(3)'s list fits recommendation and content systems; it does not name analysis, scoring or decision-making. We treat credit and fraud models as within it, because they "display" or "update" personal data and the DPIA must cover them anyway.

Due diligence, as we would run it:

The government may also require specified personal data and its traffic data to stay in India for an SDF (Rule 13(4)). For the full SDF programme, see DPDP for a corporate group.

Erasure, withdrawal and trained models

You must erase personal data when she withdraws consent or when the purpose is no longer served, whichever is earlier, unless a law requires retention, and make your processors erase it too (s. 8(7)). She can also ask for erasure (s. 12(3)). After a withdrawal you must stop processing within a reasonable time (s. 6(6)), though processing before the withdrawal stays lawful (s. 6(5)).

Whether trained weights are "personal data" is unsettled; a model that can reproduce her details makes the case that they are. The best answer is architecture: keep personal data in retrieval stores and datasets you can delete from, and out of weights where you can. Then an erasure request becomes a database operation, not a retraining project.

Keep the logs Rules 8(3) and 6(1)(e) require separately, access-limited, and erase them after the year, unless another law requires longer.

Calling a model hosted abroad

A prompt with personal data sent to a model hosted abroad is a transfer. From 13 May 2027, transfers are allowed unless the government restricts the destination by notification (s. 16(1)), subject to any requirements on making data available to a foreign State (Rule 15). As of 25 October 2026 we have found no restriction notified. Until then, the SPDI Rules govern body corporates that transfer sensitive personal data abroad.

What can still stop you:

• Sector rules that are stricter survive the Act (s. 16(2)). RBI's 2018 directive requires payment system data to be stored only in India.
• SDF localisation, if you are notified and the data is specified (Rule 13(4)).
• CERT-In logs. The Directions require 180 days of ICT logs within Indian jurisdiction. CERT-In's non-binding FAQs (18 May 2022, Q35) have been read as allowing storage abroad if logs can be produced promptly, but commentators disagree, and Q36 keeps financial-transaction records in India. Our recommendation: keep a copy in India.
• Customer contracts, which in regulated sectors often fix hosting regions.

Keep a transfer register for AI: each model, where it runs, what personal data reaches it, and what limits it.

Where the law is unclear

These are our positions until the Board or the courts decide otherwise.

Does s. 3(c)(ii) let you train on anything public? No. Rely on it only for data she published herself, or that a law required someone to publish, used in the context it was published. Why: the text names who must have made the data public. Would change if: the Board reads the exclusion as attaching to any public data, for any purpose. Confidence: medium.

Are trained model weights personal data? Treat them as personal data where the model can reproduce a person's details. Why: data about an identifiable individual is personal data whatever its format (s. 2(t)). Would change if: the Board or a court treats weights as non-personal unless data can be extracted from them. Confidence: low.

Is commercial model training "research" under s. 17(2)(b)? Not where the model is used to make decisions about individuals. Why: the exemption ends when data is used "to take any decision specific to a Data Principal". Would change if: rules or the Board define research to include model development. Confidence: low.

Is a paste into an unapproved AI tool a personal data breach? Yes, where the tool keeps or may use the data. Why: s. 2(u) covers unauthorised processing and accidental disclosure or sharing that compromises confidentiality. Would change if: the Board treats disclosure to a provider that deletes promptly as no compromise. Confidence: medium.

Does Rule 13(3) cover decision models? Yes, in practice. Why: the verbs in the rule fit most models, and the SDF's DPIA must cover them anyway. Would change if: the government clarifies the rule's scope. Confidence: medium.

When must a model stop using withdrawn data? Stop new training on it at once and remove it from retrieval stores within your normal withdrawal window; retrain on your next scheduled cycle. Why: s. 6(6) asks for cessation "within a reasonable time", and s. 6(5) keeps earlier processing lawful. Would change if: the Board sets a deadline for retraining. Confidence: low.

A plan for AI before 13 May 2027

1. By Friday 13 November 2026. List every AI tool, model and agent in use, including free tools staff use on their own. Add each to the data map with purpose, basis, vendor, hosting location and retention mode.
2. By Friday 4 December 2026. Publish the staff AI policy with an approved tool. Switch every approved tool to zero retention or the shortest window, confirm it in writing, and start your own one-year gateway log.
3. By Friday 15 January 2027. Amend AI vendor contracts: no training on your data, retention mode, sub-processors and regions, breach notice in hours, erasure support.
4. By Friday 12 February 2027. Rewrite chatbot openings to Rule 3, with separate questions for each purpose and an age check before any child's data is collected.
5. By Friday 12 March 2027. For each model and agent that decides or acts on people, document inputs, accuracy testing, permissions and human review. Decide, in writing, the basis for every training set, and delete or de-identify, with a recorded test, the sets that have none.
6. Week of Monday 12 April 2027. Rehearse one AI incident in your breach drill, such as a mistaken paste or a bot that exposed another user's chat, and one erasure request that reaches a retrieval index.
7. By Wednesday 12 May 2027. Re-check the register, close or accept remaining gaps in writing, and brief the board.

For the full dated programme, see DPDP compliance deadline: 13 May 2027.

How we wrote this guide. We worked from the text of the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), as corrected by G.S.R. 892(E)), the CERT-In Directions of 28 April 2022 and CERT-In's FAQs of 18 May 2022. The AI governance guidelines and the 2026 IT Rules amendment come from the linked reports, last checked 25 October 2026. Statements marked "our view", "our position" or "we recommend" are our judgement, not the law. This guide explains the law; it is not legal advice.