Deploying LLMs under India's DPDP Act: an engineering checklist

If your LLM application processes personal data of people in India, the Digital Personal Data Protection Act, 2023 applies to it in the same way it applies to any other software: you need a lawful basis (usually consent), a clear notice, reasonable security safeguards, breach reporting, erasure when the purpose is served, and a way for people to exercise their rights. What changes with an LLM is where personal data hides: in prompts, retrieved context, vector indexes, logs, evaluation sets and third-party model providers. This checklist maps each obligation to the engineering controls that make DPDP Act AI compliance demonstrable rather than asserted.

This is general information for engineering teams, not legal advice. Read the primary texts linked below and confirm your obligations with qualified counsel before you rely on any of it.

Where do the DPDP Act and DPDP Rules stand today?

Parliament enacted the Digital Personal Data Protection Act, 2023 in August 2023. The Digital Personal Data Protection Rules, 2025 were notified in the Gazette in November 2025 (G.S.R. 846(E), dated 13 November 2025), as summarised in the Government's PIB backgrounder. Commencement is phased by Rule 1:

• Rules 1, 2 and 17 to 21, which set up the Data Protection Board, came into force on publication.
• Rule 4, on Consent Managers, comes into force one year after publication.
• Rules 3, 5 to 16, 22 and 23, which carry most of the operational duties for Data Fiduciaries (notice, security safeguards, breach intimation, erasure, children's data, rights, significant data fiduciaries and cross-border transfer), come into force eighteen months after publication.

Watch this timeline. In January 2026 MeitY consulted industry on proposals to shorten the eighteen-month window to twelve months and to bring some Significant Data Fiduciary duties forward. At the time of writing we have not found an amendment notifying that change, but check the Gazette and the MeitY site before you plan against either date.

Eighteen months is not long for a system that was not designed with these duties in mind. Retrofitting deletion into a vector index or a fine-tuned model is far harder than designing for it, so the time to make these decisions is during architecture, not during the last quarter before the deadline.

Separately, MeitY released the India AI Governance Guidelines in November 2025. They are principle-based guidance built around seven "sutras" such as trust, accountability and "understandable by design", rather than a new statute. They are useful for framing internal AI policy, but the binding obligations for personal data come from the DPDP Act and Rules.

Which DPDP obligations matter most for an LLM system?

The table of duties is long; these are the ones that translate directly into architecture decisions. Section references are to the Act unless marked as a Rule.

1. Notice and consent (sections 5 and 6)

A consent request must be preceded or accompanied by a notice describing the personal data and the purpose of processing. Consent must be free, specific, informed, unconditional and unambiguous, and limited to the personal data necessary for the specified purpose.

Engineering controls:

• Record, per user, which purposes they consented to and when, in a store your LLM pipeline can query at request time.
• Tag data sources by purpose before they are indexed for retrieval. If customer support transcripts were collected to resolve tickets, using them to train or evaluate a sales assistant is a new purpose and needs its own basis.
• Honour withdrawal: when consent is withdrawn, the pipeline must stop using that person's data for the purpose, which means filtering at retrieval time, not just deleting from the source system.

2. Data minimisation in prompts

The principle that consent covers only data necessary for the purpose maps cleanly onto prompt construction. Most LLM tasks do not need a customer's full name, phone number or account number to answer the question.

Engineering controls:

• Detect and redact or pseudonymise personal data before text leaves your boundary for a model provider. Replace identifiers with stable tokens and map them back after the response if the user-facing answer needs them.
• Strip personal data from documents at indexing time where the retrieval use case does not need it.
• Keep evaluation sets free of real personal data, or treat them as personal data stores with the same controls.

3. Reasonable security safeguards (section 8(5) and Rule 6)

Rule 6 lists minimum safeguards, including encryption, obfuscation, masking or tokenisation of personal data; access control over computer resources; visibility of access through logs, monitoring and review; continuity measures such as backups; retention of logs and personal data for one year for detecting and investigating unauthorised access, unless another law requires otherwise; and security provisions in contracts with Data Processors. According to the PIB backgrounder, failure to take reasonable security safeguards carries the highest penalty under the Act, up to ₹250 crore.

Engineering controls:

• Access-controlled retrieval. The retriever must enforce the same document permissions as the source system. A RAG assistant that lets any employee ask questions over HR files they could never open directly is a breach waiting to happen.
• Prompt and response logging with care. Logs are necessary for the visibility Rule 6 asks for, but prompt logs are themselves personal data. Encrypt them, restrict access, and redact where full text is not needed.
• Prompt injection defences for any system where retrieved content or user input can steer tool calls. An agent that can be instructed by a document to email out a customer record is a security failure, whatever the model's intent.

4. Data Processors and model providers (section 8(1) and 8(2))

The Data Fiduciary remains responsible for processing done on its behalf by a Data Processor, and may engage a processor only under a valid contract. A hosted LLM API, an embedding service and a vector database provider are all candidates for that role.

Engineering controls:

• Inventory every third party that receives personal data in the LLM pipeline, including evaluation and observability tools.
• Check each provider's data processing terms: whether inputs are used for training, how long inputs and outputs are retained, where processing happens, and what security commitments are made.
• Prefer configurations that minimise retention by the provider where your use case allows it, and record the configuration as evidence.

5. Breach intimation (section 8(6) and Rule 7)

On becoming aware of a personal data breach, a Data Fiduciary must inform each affected Data Principal without delay, and inform the Data Protection Board without delay, followed by detailed information within seventy-two hours (or a longer period the Board allows on written request).

Engineering controls: you can only report what you can reconstruct. Keep an audit trail that answers, for a given person: which prompts, retrieved documents and outputs contained their data, which providers received it, and when. Rehearse the seventy-two-hour report as a runbook, not as a policy document.

6. Erasure and retention (section 8(7), Rule 8)

Personal data must be erased when consent is withdrawn or once the specified purpose is no longer being served, unless another law requires retention, and the Data Fiduciary must cause its Data Processors to erase it too. Rule 8 also requires certain personal data, traffic data and processing logs to be retained for a minimum of one year for specified purposes. Your retention design has to satisfy both directions at once.

Engineering controls:

• Deletion propagation into vector indexes. Store a source-document and data-principal reference with every chunk so a deletion request can remove the embeddings, not just the original record. Re-embedding pipelines must not resurrect deleted content from stale snapshots.
• Caches and logs. Prompt caches, semantic caches and conversation histories need retention limits and must be included in deletion jobs.
• Fine-tuned models. Removing a person's data from model weights is not practical with today's tooling. If you fine-tune, keep personal data out of the training set in the first place, or be able to retrain from a cleaned dataset.
• Provider retention. Confirm, in writing, how a processor erases data you sent it.

7. Data Principal rights (sections 11 to 14, Rule 14)

People can request information about processing, correction, completion, updating and erasure of their data, and can nominate another person to exercise their rights. Rule 14 requires the means of making such requests to be published and grievances to be responded to within a period not exceeding ninety days.

Engineering controls: a per-person index across source systems, vector stores, logs and caches, so that an access or erasure request is a query rather than an investigation. If an LLM generates statements about individuals, keep enough provenance to correct the source of an inaccurate statement.

8. Children's data (section 9)

Processing a child's personal data requires verifiable consent of a parent or lawful guardian, and the Act prohibits tracking or behavioural monitoring of children and targeted advertising directed at them, subject to exemptions the Rules prescribe. Under the Act, a child is anyone under eighteen. Consumer-facing assistants, education products and anything that personalises responses based on behaviour need an age-assurance and consent design before launch.

9. Significant Data Fiduciaries (section 10, Rule 13)

The Government may notify certain Data Fiduciaries as Significant Data Fiduciaries. Rule 13 requires them to carry out a Data Protection Impact Assessment and an audit every twelve months, and to exercise due diligence that technical measures, including algorithmic software, used to process personal data are not likely to pose a risk to the rights of Data Principals. It also allows the Government to require that specified personal data is not transferred outside India. If your organisation could be notified, an LLM system needs documented evaluation, bias and risk testing that an auditor can review.

10. Cross-border processing (section 16, Rule 15)

The Act allows transfer of personal data outside India except to countries the Government restricts by notification, and Rule 15 adds that transfers must meet requirements the Government may specify about making data available to foreign states. Sector regulators may impose stricter localisation, and section 16(2) preserves those. Know where each model provider processes your data, and keep the option of in-region or self-hosted inference if your sector requires it.

A practical checklist for your LLM pipeline

1. Data map: every place personal data enters, is stored or leaves the LLM system, including logs, caches, vector stores and evaluation sets.
2. Purpose tags on every data source, checked at retrieval time against recorded consent.
3. Redaction or pseudonymisation before any external model call.
4. Permission-aware retrieval, tested with adversarial queries.
5. Encrypted, access-controlled audit logs with a defined retention period.
6. Deletion jobs that reach source records, chunks, embeddings, caches and processors.
7. Processor inventory with reviewed data-processing terms and processing locations.
8. A breach runbook that can produce the seventy-two-hour report.
9. A rights-request workflow that completes within the ninety-day limit.
10. An evaluation and risk-testing record you could hand to an auditor.

None of these controls is exotic. Most are ordinary data engineering applied to components that teams tend to treat as experimental. The risk is in leaving them until the system is already in production.

Frequently asked questions

Does the DPDP Act apply to LLM prompts?

Section 3 applies the Act to digital personal data processed within India, and to processing outside India in connection with offering goods or services to people in India, subject to the exclusions it lists. If a prompt contains such data, the Act's obligations apply to that processing. Treat prompts, retrieved context and outputs as personal data whenever they can contain it.

Can we use a foreign LLM API under the DPDP Act?

The Act permits cross-border transfer except to countries the Government restricts, but your sector regulator may be stricter and Significant Data Fiduciaries may face localisation requirements for specified data. Confirm the position for your sector with counsel and record where each provider processes data.

When do the main obligations take effect?

Most Data Fiduciary duties in the Rules come into force eighteen months after the Rules were published in November 2025. The Board provisions are already in force, and the Consent Manager rule follows after one year.

Is this legal advice?

No. It is an engineering reading of the published texts. Confirm your specific obligations with qualified counsel.

If you are designing or reviewing an LLM system that handles personal data, our AI and LLM Engineering team builds the controls above into the architecture from the start. Book a discovery call to talk it through.