India’s Digital Personal Data Protection Act, 2023 arrived before most organisations had an AI policy. Now the two are colliding: employees are pasting customer records into chat assistants, uploading contracts for summarisation, and asking AI tools questions whose very phrasing contains personal data. Under the DPDP Act, your organisation — as a Data Fiduciary — remains answerable for how that personal data is processed. This article sets out the questions a compliance team should ask about any enterprise AI adoption, and how the architecture you choose changes the answers.
A note before we begin: this is an architecture discussion, not legal advice. Your obligations depend on your sector, your data, and the DPDP rules as they apply to you — work through them with your counsel.
Why AI tools deserve their own compliance review
Most enterprise software processes the data you deliberately put into it. AI assistants are different in three ways that matter under a data-protection lens:
- The input is unpredictable. Any employee can put any data into a prompt at any moment. The tool’s data-protection posture is therefore your organisation’s data-protection posture.
- The processing is opaque. When the AI service runs on a third party’s infrastructure, you rely on their contractual assurances about retention, training use and access — assurances your auditors cannot independently inspect.
- The data may travel. Public AI services commonly process requests on infrastructure outside India, which brings cross-border transfer considerations into what looks, to the employee, like typing a question into a box.
Under the DPDP Act, “we didn’t know our people were pasting it into an AI tool” is not a defence. It is the finding.
Eight questions to ask before you adopt
- Where is the processing physically happening? On your infrastructure, in an Indian region of a public cloud, or wherever the provider routes it? Can the vendor state this in writing, per workload?
- Who can access the prompts and outputs? Provider staff? Sub-processors? Under what circumstances, and is that access logged somewhere you can see?
- Is your data used to train or improve anyone’s models? If the answer requires reading a policy page that can change, treat it as “maybe”.
- What is retained, and for how long? Purpose limitation and storage limitation are core DPDP disciplines — an assistant that quietly retains conversation history on external systems extends your data footprint every day.
- Can you demonstrate security safeguards? The Act expects reasonable security safeguards for personal data. For an AI tool, that means access control, encryption in transit and at rest, and — critically — an audit trail of privileged access you can actually produce.
- What happens on a breach? If personal data in prompts is exposed at the provider, how quickly would you even know? Your notification obligations don’t pause while a vendor investigates.
- Can you honour Data Principal rights? If an individual asks what personal data of theirs you hold and process, does data sitting in a third-party AI service’s logs fall inside or outside your answer?
- Can you turn the tool off without losing the capability? Exit is a compliance question too. If your working knowledge has accumulated inside a provider’s service, leaving it is no longer a procurement decision — it’s a migration project.
How architecture changes the answers
Notice what the hard questions have in common: they are hard because the processing happens on infrastructure you don’t control. A privately deployed AI platform changes the shape of the problem rather than the wording of the policy:
- Processing location becomes your data centre or your private cloud tenancy — a fact you can show, not a clause you cite. Employee prompts and documents are reasoned over next to where they already live.
- Access and audit become your controls: ZenithAI ships a fail-closed privileged-access audit and egress logging with redaction, so “who saw what” is a report, not a request to a vendor.
- Retention follows your policy, because the stores are yours. Workspaces are private to their creators, with administrative publishing under your governance.
- Model training is off the table by construction: open-weight models served locally on your hardware have no telemetry path back to a model vendor. Our models page covers how the tiers are built.
Be precise about what this does and doesn’t mean. Private deployment is an architecture that supports your DPDP obligations — it shrinks the surface your compliance team must explain and puts the evidence under your control. It is not a compliance certificate, and no software purchase makes an organisation “DPDP compliant” by itself: your notices, consent flows, grievance handling and policies still do that work.
A practical way to start
Run the eight questions above against your current AI usage — including the unofficial usage your teams have already adopted. Where the answers depend on a third party’s assurances, note them as residual risk; where they depend on your own infrastructure, note them as evidence. That one-page exercise usually makes the architectural conversation with leadership very short.
If you want to see what the private-deployment answers look like in practice, request a demonstration — and bring your compliance team to it. The deployment model is designed to be walked through with auditors in the room.
Banking or an NBFC? The same architecture question runs through the RBI’s 2026 model-risk draft — see what RBI’s AI rules ask of your stack.