DPDP Act 2023: What Indian Banks Must Do Before Enforcement

Most DPDP compliance conversations stop at the data-at-rest layer — consent management, privacy notices, data subject rights, the DPO function. This piece is about the layer banks are systematically under-building: the AI inference layer, where the obligation actually gets triggered the moment a model touches a customer's personal data.

Every time a bank's AI system processes a customer's credit history, transaction pattern, identity document, or biometric data, a DPDP obligation attaches to that specific act of processing. The question isn't whether DPDP applies to AI — it does, unambiguously — it's whether the AI pipeline's architecture actually enforces that obligation at the point where processing happens, rather than three layers upstream at the consent-banner stage.

₹250 crore. The maximum penalty per instance under the DPDP Act's Schedule for a Data Fiduciary that fails to implement reasonable security safeguards. Banks designated Significant Data Fiduciaries carry additional obligations on top.

What DPDP creates at the AI layer, obligation by obligation

1. Consent verification before processing

Section 4 requires personal data to be processed only with consent or on a legitimate-use basis. For an AI system, that's a pipeline-level obligation: before a model processes a customer's personal data, the system has to be able to verify valid consent exists for that specific purpose — not a blanket terms-of-service acceptance from onboarding two years ago.

A credit-scoring model processing a customer's transaction history has to verify the customer consented to that data being used for credit decisions specifically. Purpose limitation is real here: consent for credit scoring doesn't extend to fraud detection, marketing, or insurance underwriting without separate consent for each use.

2. Data minimisation at inference time

Section 6 limits processing to what's necessary for the stated purpose. For a model, that's a feature-selection obligation: it can't use personal-data features that aren't necessary for its declared purpose. A document-extraction model declared as "identity verification" that also happens to process transaction history is in violation regardless of whether that extra data happens to improve the model's accuracy.

3. Right to correction and erasure

Sections 12–13 give data principals the right to correct inaccurate data and request erasure. For AI, this creates a genuinely hard downstream obligation: when a customer exercises a correction or erasure right, the bank has to identify every model that has processed or cached that customer's data and make sure the correction or erasure actually propagates to all of them.

This is the obligation that breaks on contact with reality. Most banks don't maintain an accurate record of which AI models have processed which customers' data — not because nobody cares, but because nobody built that instrumentation when the models went live. Without that record, a correction or erasure request can't be fulfilled meaningfully; you're left either guessing or doing a manual forensic exercise every time a customer asks.

4. Data localisation

Significant Data Fiduciaries — and banks processing large personal-data volumes are highly likely to be designated as such — face data localisation obligations. For AI inference pipelines using cloud-hosted models or third-party inference endpoints, that's an architectural constraint: personal data can't leave India for processing unless the Rules explicitly permit it.

The AI pipeline compliance checklist

Why the timeline matters more than the exact enforcement date

The specific details — which data categories require localisation, what exactly qualifies as a Significant Data Fiduciary in borderline cases, the precise consent-UI requirements — won't be fully settled until the Rules are finalized and any remaining ambiguity is clarified. But the architectural work needed regardless of those details — an AI processing inventory, inference-time consent checking, PII detection, data-residency enforcement — takes months to build no matter what the final fine print says.

Banks that start this architecture now can configure it to the specific requirements once they're fully settled. Banks that wait for total clarity before starting will be building and configuring simultaneously, under examination pressure, with far less room to get it right the first time.

Why this is harder than ordinary DPDP compliance

Privacy notices, consent UI, DPO appointment — a legal and compliance team can build that with moderate IT involvement. AI-layer DPDP compliance can't be done that way, because the changes are architectural, not documentary. Adding PII detection to a GenAI inference path means changing the serving stack. Per-model feature governance means changing the feature store. An AI processing inventory for data-subject rights means instrumenting every model deployment, not writing a policy about them.

None of that is a job for a compliance team working alone — it needs ML engineers and infrastructure teams in the room from day one. A realistic timeline for a bank with a meaningful AI footprint — discovery, gap analysis, architecture design, implementation, testing — runs 6 to 12 months, and that clock should already be running.

What to do this quarter

1. Build (or audit) your AI processing inventory first — without knowing which models touched which customer's data, nothing else on this list is actually fulfillable.
2. Move consent verification from login-time to inference-time, scoped to the specific purpose each model was built for.
3. Add PII detection to every GenAI output path before it reaches a customer, not after the first incident forces the question.
4. Review vendor contracts for AI providers specifically for DPDP-specific processing terms — most standard vendor paper has none.
5. Confirm your Significant Data Fiduciary status and localisation posture directly against the current Rules, rather than planning around a remembered headline date.