India's Digital Personal Data Protection Act turns a vague question, where does our data actually live, into a legal one with a ₹250 crore price tag. For AI systems the honest answer is architectural: what enters the model, what can be deleted, and what never leaves your network.
The Digital Personal Data Protection Act is India's first comprehensive data protection law. It replaces the old SPDI Rules patchwork with a single regime built on three roles. A Data Principal is the person the data is about. A Data Fiduciary decides why and how personal data is processed, and carries nearly all of the obligations. A Data Processor handles data on a fiduciary's instructions, under contract. If you run an AI product, you are the fiduciary, and every model API you call is your processor.
The obligations read like a checklist until you try to implement them. Consent must be specific, informed, and as easy to withdraw as it was to give. Personal data must be erased once its purpose is served or consent is withdrawn. Breaches must be reported to the Data Protection Board and to every affected person. Security safeguards are mandatory, and failing them carries penalties of up to ₹250 crore per instance. The word instance matters: three failures are three fines.
Owns the rights: access, correction, erasure, grievance, nomination. Consent must be as easy to withdraw as to give.
Decides purpose and means. Carries consent, notice, security, breach reporting, and erasure duties. Penalties land here.
Processes on your instructions under contract. Every hosted model API you call sits in this seat, and you answer for it.
Classical compliance assumes personal data sits in databases, where you can find it, fence it, and delete it. A large language model (LLM) system breaks that assumption in four places at once. Data flows into prompts assembled at runtime. It is copied into vector indexes and caches. It reappears in conversation logs, which are themselves personal data. And if you fine-tune or train on it, it dissolves into model weights, where no delete statement can reach it.
Then there is the vendor question. Every hosted model API you call is a Data Processor under the Act, which demands a contract, a lawful basis, and a defensible answer on cross-border transfer. None of this makes AI illegal. It makes AI an architecture problem, and architecture is something you can get right on purpose. The rest of this essay is the shape of getting it right.
The Act gives every person the right to erasure, and erasure is where AI systems quietly fail. You can delete a row from a database. You cannot delete a fact from a trained model's weights, short of retraining the model. The engineering consequence is simple and strict: keep personal data out of anything you cannot delete from.
This is the compliance argument for retrieval-augmented generation (RAG). In a RAG system the model stays generic and the personal data lives in a store you control, retrieved at question time. Erase the record and the next answer simply no longer knows it. Fine-tuning on customer data, by contrast, bakes a copy into weights you can neither inspect nor forget. On the build-decision ladder from our pillar essay, the law now has a vote on how high you climb. Read the pillar essay on building with LLMs.
The Act permits cross-border transfer except to countries the government restricts, but sector regulators can and do go further, and the Rules leave room for tighter category-level restrictions. Many systems we build use both worlds: a private model inside the boundary for anything personal, and a hosted frontier model for reasoning over data that is already safe to share.
Our default answer for regulated clients is a private deployment. Open-weight models such as Llama, Mistral, or Qwen served on graphics hardware inside your own cloud account or data centre, in an Indian region. Documents, embeddings, logs, and the consent ledger stay in stores you administer. Nothing about the architecture is exotic; what makes it compliance-grade is that every box has an owner, a retention window, and a tested erasure path.
For the strictest environments we deploy fully on-premise with no outbound internet. The system still works, because it only needs your documents and a local model. The full operational picture is in our private LLM deployment practice. Private LLM and on-premise deployment.
The government can notify any fiduciary as a Significant Data Fiduciary (SDF) based on the volume and sensitivity of data it processes and the risk its processing poses. If you are running AI over large amounts of personal data in India, you should plan as if the designation is coming. SDFs carry four additional duties.
The fourth duty is the interesting one. If your models decide or influence decisions about people, the regulator expects you to show your algorithms are not harming their rights. That is an evaluation problem, and teams that already run evaluation suites against their AI systems will have the evidence sitting in their CI history.
Personally identifiable information (PII) protection under the Act is not a policy document. It is a set of mechanisms that run on every request. These are the same guardrails we treat as standard engineering in the pillar essay, pointed at a statute.
Find names, phone numbers, Aadhaar and account numbers before anything is indexed, not after a breach.
Store placeholders in the index; keep the mapping in a sealed vault with its own access log and erasure path.
The model never reads a record the asking user could not open themselves. Consent state is part of the query.
Conversation transcripts are personal data. They expire on a schedule you can defend in an audit.
Who asked what, which sources were read, what crossed the network boundary. Breach reporting is a query, not an investigation.
Retrieval, tool use, and strict guardrails running entirely inside the client's environment, with permission-aware access and an evaluation suite gating every release. The boundary-first architecture this essay describes, in production and handed over.
→ Read the case studyMap every place personal data touches your AI systems: prompts, indexes, caches, logs, fine-tunes, and every vendor call that leaves the network.
Wire consent capture and withdrawal into the products that feed the models, in plain language, with the withdrawal path as short as the grant path.
Choose hosted or private per workload, sign processor contracts, and move regulated data inside the boundary. Test the erasure path end to end.
Erasure verified, breach playbook rehearsed, audit trail queryable, DPIA and algorithmic due-diligence evidence ready before anyone asks.
The cheapest personal data to protect is the data you never collect. Before any AI feature ships, we ask what it actually needs to know. A support copilot rarely needs full identity. An analytics agent almost never does. Anonymised and synthetic data fall outside the Act's scope entirely, provided the anonymisation genuinely resists re-identification.
Minimisation is not a legal nicety. Less personal data means smaller indexes, cheaper redaction, shorter audits, and a breach story that ends in a shrug instead of a headline. It is the one compliance control that also makes the system faster and cheaper to run.
Yes. The Act applies to digital personal data regardless of what processes it, so prompts, vector indexes, conversation logs, and training sets are all in scope whenever they can identify a person. If your organisation decides why that data is processed, you are the Data Fiduciary and the obligations attach to you, not to your AI vendor.
It can be done lawfully, with conditions. You need a processor contract, enterprise terms that exclude training on your data, minimisation or redaction before the call, and no sector rule that pins the data inside India. Financial and health workloads often fail that last test, which is why regulated clients usually run a private model for personal data and reserve hosted APIs for data that is already safe to share.
The Act governs personal data, meaning data that can identify a person. Data that is genuinely anonymised, so that re-identification is not reasonably possible, falls outside its scope, and synthetic data generated to mirror real distributions is a practical way to build and test AI systems without carrying obligations. The caveat is that weak anonymisation that can be reversed is still personal data.
A class of fiduciary the government designates based on factors like the volume and sensitivity of data processed and the risk to individuals. SDFs carry extra duties: a Data Protection Officer based in India, independent audits, periodic Data Protection Impact Assessments, and due diligence that their algorithms do not put people's rights at risk. AI-heavy businesses are natural candidates and should plan for the designation rather than react to it.
Not as a blanket rule. The Act allows cross-border transfers except to countries the government restricts, but it leaves sector regulators free to impose stricter residency, and the RBI already does for payment data. The Rules also leave room for tighter restrictions on specific categories. The practical posture for regulated industries is to keep personal data in Indian regions by default and treat any transfer as an explicit, documented decision.
The Act's schedule tops out at ₹250 crore per instance for failing to maintain reasonable security safeguards, with lower slabs for other breaches such as failing to notify the Board of a breach or violating children's data duties. Because penalties are per instance, a systemic gap across many users can multiply quickly. The Data Protection Board weighs the nature, gravity, and duration of the breach when setting the amount.
It does not, and that is the point. There is no reliable way to delete one person's data from trained weights short of retraining, so the compliant architecture keeps personal data out of weights entirely. Hold it in retrievable stores where deletion works, use retrieval-augmented generation to bring it to the model at question time, and avoid fine-tuning on personal data unless it has been anonymised.
Yes, whenever they can identify a person, and support or sales conversations almost always can. That means logs need the same treatment as any other personal data: a defined purpose, a retention window, redaction where possible, inclusion in your erasure path, and coverage in your breach-reporting plan. Teams forget logs more often than any other store, and auditors know it.
Bring the workflow and the data map. In one conversation we can usually tell you which side of the boundary each workload belongs on, and what the runway to 2027 looks like for your stack.
Start a conversation →