Most DPDP guidance for AI stops at "get consent". The provisions that actually reshape an architecture are more specific than that, and two of them are hard to satisfy after the fact.
Purpose limitation is the one that bites
Consent under the Act is bound to a stated purpose. Data collected to service a loan is not, by default, available to train a model on — even a model that will be used to service loans better.
This catches teams who assume that data already held is data already available. It is not, and the fix is not a clause added to a privacy policy after the model exists. Either the consent covers the purpose or the training set has to come from somewhere else.
Practically that means one of three things: collect consent for the purpose, use data that predates the relationship in an aggregated form, or anonymise well enough to leave the Act's scope — the last of which is harder than it sounds.
Withdrawal has to be actionable
A data principal can withdraw consent. Removing their row is easy. Removing their influence from a trained model is not.
There is no clean technical answer to unlearning, so the architectural answer is to avoid needing one:
- Keep the training corpus traceable to its consent basis, per record. If you cannot say which records a model was trained on, you cannot honour a withdrawal.
- Keep retraining cheap enough to be routine. If retraining is a six-month project, withdrawal becomes a problem you defer rather than action.
- Prefer retrieval over fine-tuning where the requirement allows. A retrieval system forgets when you delete the document; a fine-tuned model does not.
That last point is the strongest practical argument for retrieval-augmented architectures in regulated Indian contexts, and it is rarely the one people cite.
The right to correction meets the model
A data principal can require inaccurate personal data to be corrected. For a record, that is an update. For a system whose output was derived from that record — a score, a segment, a decision — it raises a harder question about what else has to change.
The answer that survives scrutiny is a reproducible pipeline: if you can regenerate the derived output from corrected inputs, correction is a rerun. If the derivation happened once and the reasoning was not retained, it is an investigation.
Anonymisation, tested rather than asserted
Pseudonymised data — a name replaced by an identifier — remains personal data. Only genuine anonymisation leaves the Act's scope.
The bar is whether re-identification is reasonably possible, and rich behavioural data is notoriously easy to re-identify from a handful of attributes. Treating an anonymisation claim as a hypothesis to be tested, rather than a label to be applied, is the difference between a defensible position and one that fails on first challenge.
Where the model runs
Using a hosted model API makes that provider a processor acting on your instructions. Retention terms, sub-processing, and processing location all become contractual questions rather than technical preferences.
For regulated entities the sectoral rules narrow it further. RBI's payment data localisation requires storage in India. Outsourcing directions govern what a third party may do and what audit rights you must retain. Those decide, before any technical evaluation, whether a hosted API is usable for a given workflow — which is why data boundary is the first design decision rather than a security review item.
What this looks like in the build
- Map the data before choosing anything: what is personal, under what consent basis, collected for what stated purpose.
- Draw the boundary: what leaves the environment, what never can, what is redacted or tokenised in between.
- Prefer retrieval where the requirement allows, so deletion is deletion.
- Make training data traceable and retraining routine, so withdrawal is actionable.
- Log for reconstruction: inputs, context, model version, output — enough to explain a decision months later.
- Name an accountable owner. The Act assumes one exists.
The framing that helps
DPDP is often presented as a constraint on what AI can do. In practice most of what it requires — knowing what data you hold, why you hold it, where it goes, and being able to explain a decision — is what a well-engineered system needs anyway.
The systems that struggle with the Act are the ones that could not answer those questions before it existed.