What DPDP Actually Gives You When an AI System Uses Your Data
The public conversation about India's Digital Personal Data Protection Act has been almost entirely oriented toward organisations. What must companies do? How should compliance teams respond? What does the penalty schedule mean for boards? These are legitimate questions. They are also the wrong starting point for understanding what the Act accomplishes.
The more revealing question is narrower: when an Indian company deploys an AI system that processes your personal data, what does DPDP actually give you as the person whose data is being used, and where does the Act's reach end?
The answer is more constrained than most users assume and more constrained than most compliance commentary acknowledges.
What the Act does give you
DPDP Chapter III establishes four rights for Data Principals: access to information about processing (S11), correction and erasure (S12), grievance redressal (S13), and nomination (S14). These are real rights. For conventional data processing, they are procedurally tractable. AI systems complicate each of them in ways the Act does not resolve.
The identification problem
S11 works when you know which Data Fiduciary to ask and when that Data Fiduciary knows what it holds. Both conditions become unstable in AI deployments. Many AI systems deployed by Indian companies are built on third-party foundation models, fine-tuned on proprietary data, and served through a further vendor's infrastructure. Your S11 right surfaces only the layer you have a direct relationship with.
The erasure problem
S12(3) gives you the right to request erasure of your personal data, subject to retention obligations. For a database record, erasure is a defined operation. For a trained model, it is not. A model trained on data that included your personal information does not contain that information in retrievable form. The model's parameters encode statistical patterns derived from training data collectively. Removing your specific contribution from trained weights is not an operation that exists in current practice at scale.
The regulatory pressure around this gap is intensifying elsewhere. The European Data Protection Board made the right to erasure its coordinated enforcement priority for 2025, involving 32 Data Protection Authorities across Europe. Its February 2026 report identified challenges that apply with compounded force to AI systems: absence of systematic data classification, reliance on inadequate anonymisation as a substitute for deletion, and no procedures for erasure in backup and derived systems. The report does not resolve how erasure applies to model weights, but the direction of regulatory attention is clear.
The DPDP Act and the November 2025 Rules are silent on this. The Data Protection Board of India, once constituted, will inherit a question that more mature regulatory frameworks have not yet answered. What a company is required to do when you invoke S12 against a system trained on your data remains, at present, open.
The consent problem
S6 requires consent to be free, specific, informed, unconditional, and unambiguous. S5(2) requires that where consent was given before the Act's commencement, the Data Fiduciary must issue fresh notice as soon as reasonably practicable, describing the data and the purpose for which it has been processed.
Most Indian users gave consent to platforms that now deploy AI systems against their data before those AI applications existed. Whether that consent extends to the use of profile data to train a matching algorithm deployed years later is precisely the question S5(2) and S6 together should force into the open. Whether companies are issuing that fresh notice, or relying on broad original consent to cover materially new processing purposes, is not visible from outside the organisation. The Data Protection Board of India, once operational, is the body with standing to examine this. It has not yet been constituted.
What this means in practice
A user interacting with an AI-powered Indian product today has formal rights under DPDP that are real but procedurally difficult to exercise in the AI context. The right to know what is being processed runs against the opacity of inference chains. The right to erasure runs against the architecture of trained models. The right to meaningful consent runs against the lag between when consent was given and when AI processing purposes were defined.
None of this is a criticism of the Act's intent. DPDP was enacted before these questions became operationally acute, and the same gaps exist in more mature regulatory frameworks. The relevant observation is this: the rights DPDP provides are worth exercising, and the S13 grievance mechanism is available now. The structural limits on those rights, in the AI context, are a gap in the regulatory architecture that Board guidance, enforcement precedent, or amendment will need to address.
The question to put to companies is not whether they comply with DPDP in general. It is whether their compliance programme has mapped AI processing activities against Chapter III rights specifically, and what their answer would be if a Data Principal invoked S11 against a model trained on that Principal's data.