Unpacks who's accountable under DPDP when an AI system processes personal data — vendor contract red flags, the training-data consent gap, and why Section 9's children's-data rules apply regardless of the technology.
Buried in most AI vendor contracts is a clause that reads something like "customer data may be used to improve our services." It sounds routine — the kind of line nobody in procurement flags twice. Under the DPDP Act, that clause is doing something significant: it's quietly shifting the vendor from a Data Processor acting on your instructions into an independent Data Fiduciary making its own decisions about your customers' data. And if nobody catches it, the business that collected the data in the first place is still the one accountable when a regulator asks who authorized that use.
This is the core tension running through AI and data protection in India right now: the DPDP Act wasn't written with AI specifically in mind, but its provisions still apply to it — and the accountability question doesn't get simpler just because a machine learning model sits in the middle of the processing chain.
Does the DPDP Act Actually Apply to AI?
There's no dedicated AI chapter in the DPDP Act, and no India-specific AI law currently in force. But the Act doesn't need a special chapter to apply, because "processing" is defined broadly enough to capture what AI systems actually do with data. Under Section 2, processing includes any automated operation performed on personal data — collection, storage, use, and sharing among them. Training a model on a dataset containing names, images, or behavioral records is processing. Running a live model that makes decisions using someone's data is processing. If personal data is involved, the DPDP Act's obligations attach, regardless of how sophisticated the system doing the processing happens to be.
The genuinely open question isn't whether the Act applies — it's how its consent-based framework, built with more conventional processing in mind, maps onto AI-specific realities like large training datasets and models that keep learning after deployment.
Who's Accountable: A Practical Breakdown
The DPDP Act's Fiduciary/Processor framework still does the work here — it just needs to be applied carefully to each AI relationship:
| Scenario | Who's the Data Fiduciary | Who's the Data Processor |
|---|---|---|
| A business uses an AI tool (e.g., a chatbot, recommendation engine) built by a vendor, processing the business's own customer data | The business | The AI vendor, provided it only processes on the business's instructions |
| The AI vendor uses that same customer data to further train or improve its underlying model | The AI vendor (for that specific use) | — |
| A business builds and trains its own AI model in-house using customer data it collected | The business | Any cloud/infrastructure provider involved, if strictly instruction-based |
| A business uses a third-party AI API (e.g., for content generation) that also logs and reuses submitted prompts | Both — the business for its own use, the API provider for its model-improvement use | — |
The second and fourth rows are where most businesses carry unrecognized exposure. If an AI vendor's terms allow it to use submitted data for its own model training, that vendor isn't acting purely as your processor anymore — it has its own purpose, which makes it a Fiduciary for that specific use. Your original consent from the customer, gathered for a stated purpose like "customer support," doesn't automatically extend to "training a third party's AI model." That gap is exactly the kind of thing a Data Protection Board inquiry would look for.
Training Data Has a Consent Problem of Its Own
A significant share of the data used to train AI systems — especially systems built or refined after the fact — was originally collected for an entirely different purpose, sometimes years before anyone conceived of the AI use case. The DPDP Act's requirement for specific, informed consent doesn't accommodate that gap automatically. Consent given for "processing your order" doesn't retroactively cover "training our recommendation model." The "voluntary provision of data" legitimate use under Section 7 sometimes gets treated as a blanket workaround here, but it's a narrow provision tied to specific circumstances — not a general substitute for consent whenever AI is involved.
In practice, this means any organization building or fine-tuning an AI model on previously collected personal data needs to go back and ask whether that specific use was actually covered by the original notice and consent — and if it wasn't, treat it as a fresh processing purpose requiring its own basis.
The Gap Around Automated Decisions
One place the DPDP Act is noticeably lighter than some international frameworks: it doesn't contain a provision giving individuals a specific right to object to being subject to a purely automated decision with significant effects on them — something other data protection regimes address explicitly. That's a real gap, not just a technicality, particularly for AI systems used in contexts like credit assessment, hiring, or insurance underwriting. It doesn't mean automated decision-making is unregulated in India — the Act's general access rights still let a Data Principal ask what data is being processed and why — but it does mean businesses deploying AI in high-stakes decisions shouldn't assume the absence of an explicit statutory requirement is the same as an absence of risk. Building in some form of human oversight for consequential automated decisions is a sound practice on its own merits, even where the Act doesn't yet mandate it directly.
Children and AI Systems: A Stricter, Technology-Neutral Line
Section 9's restrictions on children's data don't carve out an exception for AI. The prohibition on tracking, behavioral monitoring, and targeted advertising directed at children applies regardless of the underlying technology — which means a recommendation engine, personalization model, or engagement-optimizing algorithm that builds profiles of individual users runs directly into this restriction the moment it's plausible that some of those users are under 18. Platforms with a mixed-age or unverified-age user base carry meaningfully elevated risk here, because the burden falls on the platform to know, or take reasonable steps to establish, whether it's inadvertently profiling minors through an AI system built for adult users generally.
What Businesses Deploying AI Should Actually Do
Given the gaps and ambiguities above, a practical approach for any business using AI on personal data includes: mapping exactly which AI tools and vendors touch personal data and what each one's terms actually permit; checking every AI vendor contract specifically for "service improvement" or "model training" clauses that quietly expand the vendor's role beyond a processor; confirming that training data has a legal basis that actually covers the AI use case, not just the original collection purpose; and building age-verification safeguards wherever an AI system could plausibly be processing a minor's data.
Where This Is Still Evolving
India doesn't yet have AI-specific legislation, though MeitY has been developing broader AI governance guidance, and sector regulators like the RBI and IRDAI may layer their own AI-related expectations onto specific industries over time. The DPDP Act should be treated as the current baseline for AI accountability in India — not necessarily the final word, as the regulatory picture around AI specifically continues to develop.
Getting a Clear Picture of Your Own AI Exposure
Most organizations using AI tools today haven't actually mapped which of those tools touch personal data, what each vendor's terms permit, or whether the original consent covers the AI use case now running on top of it. That mapping exercise is exactly the kind of gap TheDPDPAct.com's assessment platform is built to surface — treating your AI vendor relationships with the same scrutiny as any other third-party processor, so accountability questions get resolved before a regulator or a customer raises them first.