DPDP Act Compliance for AI: What Indian Companies Need to Know

DPDP Act compliance for AI is now a practical problem rather than a theoretical one. Your team is already pasting customer records into ChatGPT to draft replies, already asking a model to summarise a spreadsheet of employee data, already debugging a production error by handing over a log full of real identifiers. Each of those is a disclosure of personal data to another organisation, and India's Digital Personal Data Protection Act, 2023 does not carve out an exception because the recipient happens to be a model.

This post covers what the Act actually says, which of its duties are engaged the moment a prompt leaves your network, and what a technical control at that boundary can and cannot do for you.

What the DPDP Act, 2023 covers

The Act governs the processing of digital personal data — personal data in digital form, or in non-digital form that is subsequently digitised. Personal data is defined broadly: any data about an individual who is identifiable by or in relation to that data. It is worth sitting with that definition, because it is wider than the list of identifiers most people picture. A name attached to a salary figure is personal data. A support ticket describing a customer's medical situation is personal data.

The Act assigns roles. A Data Fiduciary is the person or entity that determines the purpose and means of processing. A Data Processor processes personal data on a Fiduciary's behalf. The individual the data is about is the Data Principal. If your company decides to run customer data through an AI tool, your company is the Data Fiduciary, and the obligations land on you.

Which obligations an AI prompt engages

Four duties come into play as soon as personal data goes into a prompt bound for an external provider.

• Lawful purpose and notice. Personal data may be processed only for a lawful purpose, with consent or for certain legitimate uses, and the notice given to the Data Principal has to describe the personal data being collected and the purpose. If your notice describes support and billing, an unannounced new processing purpose is a gap you have to close.
• Reasonable security safeguards. A Data Fiduciary must protect the personal data in its possession or under its control by taking reasonable security safeguards to prevent a personal data breach. This is the duty most directly engaged by an ungoverned prompt: data leaving your boundary in plain text, to a destination you have not assessed, is hard to describe as safeguarded.
• Accountability for processors. Engaging a Data Processor does not transfer your responsibility. You remain accountable for the personal data you hand over, including to a model provider, and the engagement is meant to rest on a contract.
• Breach notification. In the event of a personal data breach, the Data Fiduciary must notify the Data Protection Board and each affected Data Principal. To do that you need to know what was disclosed and to whom — which is a records problem before it is a legal one.

Why AI tools make this harder than ordinary vendors

You already have a process for onboarding a vendor: a review, a contract, a defined data flow. AI tools slip past it for three reasons.

The first is that adoption is individual. Nobody procures ChatGPT for the support team; a support agent opens a browser tab. There is no vendor review because, procedurally, there is no vendor.

The second is that the data is unstructured. Your database has a column marked as personal data. A prompt is free text, and the personal data is somewhere in the middle of a paragraph, next to a question about tone of voice. Controls that work on fields do not work on prose.

The third is retention. Once a prompt is submitted, what happens to it is governed by the provider's policy and plan, not yours. Retention windows vary between consumer and enterprise tiers and change over time. We cover the mechanics in How to Prevent PII Leaks When Your Team Uses ChatGPT and Other LLMs. The relevant point here is that a duty you hold is being discharged under terms you do not set.

Where a control point helps with DPDP Act compliance for AI

If prompts are going to leave, the useful place to intervene is the boundary they leave through. Route AI traffic through a single gateway you operate and that gateway can act on every request, rather than depending on each person remembering a policy.

Masking supports the security-safeguards duty

A gateway that inspects the prompt can find identifiers by their structure — Aadhaar, PAN, GSTIN, bank and UPI details, payment cards — and find the things with no fixed structure, such as names and organisations, by entity recognition. Replacing those values with opaque tokens before the request is forwarded means what reaches the provider carries placeholders rather than personal data, and the reply is restored on the way back so the work still gets done. That is a safeguard applied at the point of disclosure, which is the point that matters.

Access control narrows the exposure

Granting model access per user or group, with provider keys held centrally rather than scattered across employee laptops, gives you something you can actually revoke. It also makes the set of destinations personal data can reach a decision you made, rather than a consequence of which tool somebody signed up for.

An audit trail supports accountability and notification

Both the accountability duty and the breach-notification duty assume you can say what happened. A hash-chained record of every governed request — where each entry incorporates a hash of the one before it, so a later alteration breaks the chain — is a record you can put in front of someone. An ordinary log that can be edited without trace is a weaker thing to rely on.

What a tool cannot do for you

No product makes you DPDP compliant, and any vendor saying otherwise is selling you a problem. The Act imposes duties on your organisation as a Data Fiduciary, and most of them are not technical. Your lawful basis for processing, the notices and consent flows you present, your retention schedule, your grievance-redressal mechanism, how you handle a Data Principal exercising their rights — none of these are things software decides.

What a gateway does is close one specific and otherwise wide-open gap: personal data leaving your organisation in a prompt, uninspected, unlogged and unrestricted. It supports obligations. It does not discharge them, and there is no certification to point at.

A practical sequence

1. Find out what is actually happening. Which teams use which AI tools, on what data. This is usually more than anyone expects.
2. Classify by the Act's definition, not by intuition. Free-text fields — tickets, notes, transcripts — carry more personal data than structured tables.
3. Consolidate onto a single egress path, so there is one place where policy can be enforced.
4. Mask before egress, so a prompt that does leave carries tokens rather than personal data.
5. Record what was sent, in a form that stays credible if it is ever questioned.
6. Align notices, retention and the rest of your programme. The technical control is one input to that work, not a substitute for it.

Where the gateway runs matters for step four in particular: inspection has to happen before the network boundary, not after. That argument is made in full in Why On-Premise AI Gateways Matter for Data Privacy.

TorkQ is an on-premise AI governance gateway built for this boundary — detection and masking before prompts leave, per-user model access, and a tamper-evident audit trail. You can see it work on a real prompt on the TorkQ homepage.