The Digital Personal Data Protection Act 2023 contains no special regime for artificial intelligence. This is sometimes read as meaning it doesn't apply. The opposite is true: because it's technology-neutral, pasting personal data into a chatbot is processing personal data, and the ordinary obligations attach.
This is a practitioner's read of which ones bite, and where a technical control helps. It isn't legal advice, and we're an engineering team, not a law firm.
Purpose limitation is the awkward one
The Act requires personal data to be processed for the purpose it was collected for, with consent tied to that purpose.
A customer gave you their phone number so you could contact them about their order. An employee pastes a support thread containing that number into an AI tool to draft a reply. That is a new processing operation, involving a new processor, for a purpose the data principal never consented to.
Nobody set out to do anything wrong. The employee is trying to answer the customer faster. But the obligation doesn't care about intent, and this is by a wide margin the most common way AI usage creates exposure.
Where a control helps: detecting personal data in the prompt before it's sent, and either redacting it or explaining why it shouldn't go. Redaction is the interesting option — the employee still gets their drafted reply, and the phone number never left.
You remain the Data Fiduciary
Using a third-party AI tool doesn't transfer responsibility. If your employee sends personal data to a model provider, you are still the Data Fiduciary for that data. The provider is, at best, a processor you have no agreement with.
That's the structural problem with shadow AI in a DPDP context: you have processors you haven't contracted with, haven't assessed, and can't enumerate.
Where a control helps: the enumeration part, at minimum. Most organisations cannot currently list which AI tools their staff use. Browser-level visibility answers that in the first week, which is the prerequisite for every other decision.
Breach notification runs on a short clock
Under CERT-In directions, certain incidents must be reported within six hours of becoming aware of them. Six hours is not long. It's especially not long if the first step is establishing what happened.
If personal data went into an AI tool and you need to determine scope, you need a record: what categories, which tool, when, how many times, whose. Reconstructing that from browser history and interviews does not fit in six hours.
Where a control helps: a per-decision audit trail recording category, tool, timestamp, and the policy in force — without recording the prompt itself. You want enough to scope an incident and not so much that the log becomes a second breach.
Data minimisation cuts both ways
The Act expects you to process only what's necessary. This applies to your security tooling too.
A prompt-security product that ships every prompt to a vendor's cloud for analysis has solved a governance problem by creating a larger one. You've centralised the most sensitive free text in your organisation into a third party's database.
This is a substantial part of why our detection runs on-device. It isn't only a latency or cost decision — it's that the alternative is difficult to defend under the same principle we're helping customers meet.
A fair question to ask any vendor here: does your AI security tool send prompt content off the device, and if so, where does it go and how long is it kept?
What technical controls can and cannot do
A control can detect personal data before it's transmitted, apply a consistent policy, produce an audit trail, and give you the visibility to answer questions about scope.
A control cannot establish a lawful basis for processing, produce consent you don't have, make you compliant, or substitute for a data protection impact assessment. Compliance is an organisational property. Tooling is evidence that a control existed and functioned.
We hold no certifications and we're not certified against the DPDP Act. What we provide is a technical control and the evidence trail that supports one. Anyone selling you a checkbox is selling you something that doesn't exist.
A reasonable starting point
- Find out what's actually in use. You can't govern what you can't see, and the answer is usually surprising.
- Start with detection, not blocking. Run in warn mode. See what your traffic actually contains before you decide what to stop.
- Block the unambiguous cases first. Private keys and government identifiers have no legitimate reason to be in a prompt. Start where there's no debate.
- Redact rather than block where you can. Blocking creates workarounds; redaction lets the work continue without the exposure.
- Keep the audit trail lean. Enough to scope an incident, not so much that the log is itself a liability.
The organisations handling this well aren't the ones that banned AI tools. Bans push usage onto personal devices, where visibility is zero. The ones handling it well made the safe path the easy path.