If you're training a model, running an AI-powered support tool, or building an app that touches Indian users' personal data, the Digital Personal Data Protection Act, 2023 already applies to you — whether or not you've read it. Most teams building AI products in or for India haven't mapped their pipelines against it, and that gap is where the real risk sits: not in some distant enforcement action, but in architecture decisions being made this month that will be expensive to undo later.
The DPDP Act doesn't mention "AI" anywhere in its text. It doesn't need to. It regulates personal data — collection, storage, processing, sharing — and every AI system that touches personal data is, functionally, a personal data processing pipeline with extra steps. This guide walks through what the Act actually requires, where AI systems create friction with those requirements, and what a working compliance posture looks like in practice.
What the DPDP Act Actually Covers
The DPDP Act is India's first comprehensive data protection law, passed in 2023, with rules finalized to bring it into operation. It replaces a patchwork of IT Act provisions and sector-specific guidelines with a single framework governing how "personal data" — any data that can identify a living individual — is collected, used, and stored.
The Act organizes the world into three roles:
- Data Principal — the individual the data is about. In most AI contexts, this is your user, customer, or the person whose data appears in a training set or input prompt.
- Data Fiduciary — the entity that decides why and how personal data is processed. If your company builds or operates the AI system, you're almost certainly the fiduciary, even if you're using a third-party model API underneath.
- Data Processor — anyone processing data on the fiduciary's behalf, under contract. Your cloud host, your model vendor, and your analytics provider can all fall into this bucket.
The obligations fall almost entirely on the fiduciary. That matters for AI teams specifically because a lot of AI infrastructure is layered — you might call an external LLM API, store embeddings in a vector database, log prompts for debugging, and pipe outputs into a CRM. Under the DPDP Act, you don't get to point at the model vendor and say "compliance is their problem." You decided to process the data through that pipeline, so you're on the hook for it.
Key Obligations for Any Data Fiduciary
| Obligation | What it means in practice |
|---|---|
| Notice | Tell users, in clear language, what data you're collecting and why, before or at the time of collection |
| Consent | Get specific, informed, unambiguous consent for each purpose — not a blanket "I agree" |
| Purpose limitation | Use data only for the purpose it was collected for; don't quietly repurpose it |
| Data minimization | Collect only what's necessary for the stated purpose |
| Storage limitation | Delete data once its purpose is served, unless retention is legally required |
| Security safeguards | Implement "reasonable security safeguards" to prevent breaches |
| Breach notification | Report personal data breaches to the Data Protection Board and affected individuals |
| Grievance redressal | Provide a way for users to raise complaints and get them resolved |
None of this is exotic if you've dealt with GDPR. But the way AI systems are built — scraping web data, fine-tuning on customer interactions, retaining prompts indefinitely for "improving the model" — cuts against nearly every one of these principles by default.
There's also a category of "Significant Data Fiduciary" in the Act, reserved for entities the government designates based on the volume and sensitivity of personal data they process, the risk to electoral democracy or state security, or similar factors. Significant Data Fiduciaries face extra obligations: appointing a Data Protection Officer based in India, conducting periodic data protection impact assessments, and undergoing independent data audits. Most AI startups won't start in this category, but any company that scales an AI product to millions of Indian users, or that processes especially sensitive categories of data, should assume it's a realistic destination and plan governance structures accordingly rather than treating the designation as a hypothetical.
It's also worth noting what the Act explicitly carves out. Personal data that has been made publicly available by the individual themselves, or by someone else under a legal obligation to make it public, falls outside some of the Act's restrictions. There are also exemptions for processing necessary for legal proceedings, for research and statistical purposes under prescribed conditions, and for the state in specified circumstances. These carve-outs matter for AI teams because "we scraped publicly available data" is a common justification for training corpora — but the exemption is narrower than it sounds, and it doesn't cover data that was public in one context but never intended for the uses an AI system puts it to.
Why AI Systems Collide with This Framework
Traditional software processes data for a defined function: a checkout flow uses your address to ship a package. AI systems, especially generative ones, blur that clarity in a few specific ways.
Purpose creep is built into the pipeline. A support chatbot collects a customer's query to answer it — that's the stated purpose. But if that transcript also gets logged and later used to fine-tune the underlying model, you've introduced a second purpose the user never consented to. Under the DPDP Act, that second use needs its own basis for processing, not an inherited one.
Training data doesn't have clean consent trails. Foundation models are trained on enormous datasets scraped from the public internet, purchased from data brokers, or aggregated from partner platforms. If any of that data includes personal data of Indian individuals — and at internet scale, some inevitably does — tracing back a valid, specific consent for that individual's inclusion is close to impossible. This is one of the genuinely unresolved tensions between how large models get built and how the Act expects data to be sourced.
Outputs can reveal training inputs. Language models occasionally reproduce fragments of their training data, including personal details, in generated output. If that output surfaces someone's personal information without their knowledge, it's a processing event under the Act regardless of whether anyone "meant" for it to happen.
Vendor chains obscure accountability. A typical AI product might route data through a model API, a vector database, an observability tool, and a CRM — four or five vendors touching the same personal data. The fiduciary still owns the compliance obligation across that entire chain, which means due diligence on subprocessors isn't optional paperwork; it's the mechanism by which you actually stay compliant.
Practical Implications for Builders and Businesses
None of this means you need to stop building. It means the compliance work has to happen in the architecture, not just in a privacy policy document that nobody updates. Here's what that looks like concretely.
1. Map every place personal data enters your AI pipeline
Before you can comply with anything, you need an honest inventory: what personal data goes into prompts, what gets logged, what gets stored in embeddings, what gets sent to third-party APIs, and what (if anything) gets used for fine-tuning. Most teams are surprised by how much data flows through logging and observability tools that were bolted on for debugging and never revisited.
2. Separate "operate the product" from "improve the model"
These are two different purposes and need two different consent bases. If you want to use customer interaction data to fine-tune or evaluate models, that needs to be disclosed explicitly and, in most cases, requires an opt-in separate from the consent to use the product itself. Bundling them into one blanket consent checkbox is the kind of thing that looks fine until it's examined.
3. Build data minimization into prompts, not just databases
It's common for teams to pass more context into an LLM prompt than the task actually requires — full customer records when only a first name and order status are needed, for example. Every additional field is additional exposure, both to the model vendor and to anyone who might later access logs. Trim prompts to what the task needs.
4. Set real retention limits on logs and embeddings
AI observability tools default to retaining full prompt-and-response logs indefinitely, because storage is cheap and debugging is easier with more history. That default is in direct tension with storage limitation. Decide how long you actually need logs for debugging and enforce automatic deletion after that window, not "we'll get to it eventually."
5. Vet vendor data-handling terms, not just their security page
When choosing a model API provider or AI infrastructure vendor, check specifically: do they use your data to train their own models by default? Where are they processing and storing it? Do their subprocessor lists change without notice? These questions determine whether your vendor choice creates compliance risk you can't see from the outside.
6. Design for the rights users will exercise
The Act gives Data Principals rights to access, correct, and erase their data, and to withdraw consent. For AI systems, "erasure" is the hard one — deleting a record from a database is straightforward; removing someone's influence from a trained model is not currently solvable in the general case. Practically, this pushes toward architectures where personal data lives in retrieval systems and databases (which you can purge) rather than baked into fine-tuned model weights (which you generally can't).
Cross-Border Data Transfers and Model Hosting
A lot of AI infrastructure — model APIs, vector databases, cloud compute — is hosted outside India. The DPDP Act permits cross-border transfer of personal data by default, but reserves the government's right to restrict transfers to specific countries via notification. This is a meaningful difference from stricter regimes that require case-by-case transfer mechanisms, but it's not a blank check: if a country gets restricted, any AI vendor routing data through it becomes a compliance problem overnight.
The practical takeaway is that vendor and region selection for AI infrastructure shouldn't be treated as a pure cost-and-latency decision. Knowing where your model provider actually processes data, and having a documented ability to route around a restricted jurisdiction if the list changes, is basic resilience planning at this point.
This also intersects with a separate, non-DPDP consideration that a lot of AI teams conflate with data protection law: sector-specific data localization rules. Financial services and some other regulated sectors already have rules requiring certain data to stay within India, independent of what the DPDP Act says about cross-border transfer generally. If your AI product touches payments, lending, or insurance data, the localization requirement from the sector regulator can be stricter than anything the DPDP Act itself imposes, and it doesn't go away just because your AI infrastructure defaults to a US region.
Building Consent Flows That Actually Hold Up
A lot of DPDP compliance conversations focus on the backend — logging, retention, vendor contracts — and skip the part users actually see: the consent request itself. The Act requires notice and consent requests to be in clear and plain language, available in English and any of the languages listed in the Eighth Schedule of the Constitution, and specific enough that a user understands exactly what they're agreeing to. A generic "By using this app, you agree to our Terms and Privacy Policy" link buried in a signup footer doesn't meet that bar for an AI product that's, say, sending a user's queries to a third-party model API and separately logging them for model evaluation.
Practically, this means consent UI for AI products should distinguish between:
- Necessary processing to deliver the feature the user is asking for (answering a support query, generating a document draft).
- Optional processing for secondary purposes like model improvement, analytics, or personalization — presented as a genuine opt-in, not a pre-checked box.
- Third-party sharing, where personal data leaves your systems and goes to a model vendor, analytics tool, or partner — disclosed specifically enough that a user could reasonably guess who's receiving their data and why.
Consent also has to be as easy to withdraw as it was to give, per the Act's requirements. For an AI product, that means having an actual mechanism — not just a support email — for a user to say "stop using my data for model training" and having that request propagate to wherever that data lives, including any downstream systems that received it.
Open Questions and Real Limitations
It's worth being honest about what the Act doesn't resolve, because these gaps are where enforcement uncertainty lives.
- No AI-specific guidance yet. The Act and its rules are drafted in general, technology-neutral language. There's no sector-specific clarification for generative AI, model training, or synthetic data the way some other jurisdictions have started to produce. Builders are applying general principles to specific technical situations and making reasonable interpretations, not following settled precedent.
- Training data provenance is largely unsolved. There's no established mechanism for a company to verify, retroactively, that a foundation model's training corpus didn't include improperly sourced Indian personal data. Most companies building on top of major model providers are inheriting this uncertainty rather than resolving it.
- Machine unlearning isn't a mature technology. The right to erasure implies a technical capability — removing one person's data influence from a trained model — that doesn't reliably exist yet at production scale. Until it does, the safest posture is minimizing what goes into training data in the first place.
- Enforcement posture is still forming. How aggressively the Data Protection Board pursues AI-specific violations, and what penalties look like in practice, will become clearer only as cases develop. That uncertainty cuts both ways: it's not a reason to delay compliance work, but it also means some interpretive questions don't have definitive answers yet.
What to Watch Next
A few developments will shape how much this changes for AI teams specifically:
- Sector or technology-specific rules or guidance notes clarifying how the Act applies to AI training, synthetic data, and automated decision-making.
- Data Protection Board rulings or advisories that set early precedent on what "reasonable security safeguards" and valid consent actually look like in enforcement practice.
- Cross-border transfer restriction notifications, which would directly affect where AI infrastructure can legally be hosted.
- Movement in machine unlearning research, which would materially change what's technically feasible for honoring erasure requests against trained models.
Teams that build data mapping, consent granularity, and retention discipline into their AI systems now won't need to scramble when any of these land.
FAQ
Does the DPDP Act apply to AI companies specifically?
The Act doesn't single out AI companies — it applies to any entity, AI-based or not, that processes personal data of individuals in India. If your AI product collects, stores, or processes personal data, you're a data fiduciary under the Act regardless of the underlying technology.
Do I need separate consent to use customer data for training or fine-tuning a model?
Generally yes. Using data to operate a product and using the same data to fine-tune or evaluate a model are different purposes, and the DPDP Act's purpose limitation principle means each purpose needs its own clear, specific consent rather than one bundled agreement.
Can I use a foreign AI model API and still comply with the DPDP Act?
Yes, cross-border data transfer is permitted by default under the Act, subject to any country-specific restrictions the government may notify later. You remain responsible as the data fiduciary for ensuring your vendor's data handling meets the Act's security and purpose obligations, regardless of where the vendor is based.
What counts as personal data in an AI context?
Any data that can identify a living individual, including names, contact details, and identifiers embedded in free text like chat transcripts or support tickets. If a prompt, log, or embedding contains information traceable to a specific person, it's personal data under the Act.
How do I handle a user's request to delete their data if it was used to train a model?
Deleting the data from your databases and retrieval systems is achievable; removing its influence from an already-trained model generally isn't with current technology. The practical mitigation is architecting systems so personal data lives in erasable stores rather than being baked into fine-tuned model weights in the first place.
What are the penalties for non-compliance under the DPDP Act?
The Act empowers the Data Protection Board of India to levy financial penalties on data fiduciaries for violations such as failure to implement reasonable security safeguards or failure to notify a data breach. Penalty amounts scale with the nature and severity of the violation.
Is there a grace period before the DPDP Act is enforced?
The Act allows for phased implementation, with different provisions and obligations coming into effect on timelines set by government notification rather than all at once. Businesses should treat the current period as a window to fix architecture and consent flows, not as an indication that obligations don't yet apply.
Mapping your AI pipeline against these obligations before an audit or incident forces the issue is worth the effort, and Woyce Technologies can help teams work through that assessment hands-on.