DPDP Phase 2: Consent Manager rules and AI training compliance

What changed and why builders should care

The Ministry of Electronics and Information Technology notified the Digital Personal Data Protection Rules on 14 November 2025, more than two years after the parent Act was passed. That single notification started three different clocks running. A handful of rules took effect immediately — most importantly the constitution of the Data Protection Board of India, the regulator that will actually issue penalties. Rule 4, governing Consent Managers, takes effect twelve months later on 13 November 2026. Everything else — the substantive duties around notice, security, breach reporting, data principal rights and the special obligations of Significant Data Fiduciaries — becomes enforceable eighteen months from notification, on 13 May 2027.

For AI teams that picture had been comfortably abstract until very recently. Now it is a deployment calendar. By the end of this year you need a story for how your consent capture interfaces will speak to a registered Consent Manager. By next May you need a documented lineage from every training record back to a lawful processing basis, an automated path for honouring withdrawal of consent, and an audit log the Board can read without your help.

This guide is dual-market. Indian builders sit at the centre of it because the law is Indian. UK builders are in scope wherever they process the personal data of data principals in India — which, in practice, is almost any UK AI firm with a Bengaluru GCC, a Pune BPO, an Indian SaaS user base or a multilingual training corpus that includes Indic content. The DPDP regime sits alongside, not instead of, UK GDPR and the Data Protection Act 2018, and the two frameworks overlap more than they diverge but the divergences are exactly where compliance teams burn time.

The three-phase timeline at a glance

The phasing is the single most important thing to internalise. Compliance teams that treat DPDP as a single deadline either over-invest now or scramble in May 2027.

Phase	Date	What is in force	What builders must ship
Phase 1 — Constitutional	14 November 2025	Rules 1, 2, 17–21. DPBI constituted, definitions, appeals procedure.	Appoint a Data Protection Officer if you are likely to be classed as a Significant Data Fiduciary. Begin data mapping.
Phase 2 — Consent Manager	13 November 2026	Rule 4. Consent Manager registration opens. Third-party intermediaries can register with the DPBI.	Design consent capture interfaces that can hand off to a Consent Manager. Decide whether to integrate at launch or wait for first-mover registrants.
Phase 3 — Substantive	13 May 2027	Rules 3, 5–16, 22–23. Notice obligations, security safeguards, breach notification, data principal rights, children's data, cross-border transfers.	Production-ready notice flows, withdrawal pipelines, breach reporting playbooks, training-data lineage, retention logs.

Those dates are calendar facts but the engineering work bunches in the eighteen months between Phase 2 and Phase 3. Anything that touches model training, fine-tuning or inference-time personalisation needs to be ready by May 2027.

What a Consent Manager actually is

The Consent Manager is the most novel piece of the Indian regime and the part most likely to confuse teams transplanting their UK GDPR playbook. It is not a vendor managing your consent strings. It is a third-party intermediary, registered with the DPBI, that the data principal nominates as their single point of contact for managing consent across all data fiduciaries they have ever interacted with.

Think of it as a portable consent dashboard with regulatory teeth. A user grants and withdraws consent through the Consent Manager's interface. The Manager passes the signal to every data fiduciary holding that user's data. The Manager itself is required to be data-blind — it sees the consent record but not the underlying personal data — and it owes a fiduciary duty to the data principal, not to the businesses paying integration fees.

What the registration bar looks like

The DPDP Rules set a high bar. Indian incorporation, a minimum net worth of ₹2 crore, demonstrable data-blindness, no conflicts of interest and an interoperable interface that other Consent Managers can talk to. Public-stack candidates frequently mentioned in commentary include teams building on the DigiLocker and Account Aggregator rails, and several proposals around a Consent Data Reporting model adapted from the financial sector. As of writing none of those are confirmed registrants — the registration process itself does not open until November 2026.

What this means for your consent stack today

Even before the registration window opens, you can do useful work. Refactor consent capture so each granular purpose is a separately revocable token. Persist the lawful basis next to every record at write time. Stop relying on a single global "I agree" flag — it will not survive the Phase 3 notice rules and certainly not the Consent Manager pull pattern.

The hard problem: training data and withdrawal

Here is where the law and the state of AI research collide uncomfortably. DPDP, like UK GDPR before it, gives data principals a right to withdraw consent. The Rules require data fiduciaries to cease processing on withdrawal and erase the data unless retention is required by another law. For AI teams the question is what "cease processing" means when the data has already been baked into model weights.

Machine unlearning — the ability to surgically remove a record's influence from a trained model without retraining from scratch — is an open research problem. Recent papers from groups at Stanford, Google DeepMind and the University of Toronto have shown promising techniques on small models, but nothing approaching production readiness for frontier-scale systems. Builders should not promise capabilities the field has not yet produced.

The defensible patterns in 2026 are softer than full unlearning but they are real:

• Purpose limitation at ingestion — record exactly which downstream models any given record may train, and refuse to use it for new purposes without re-consent.
• Lineage tooling — stamp every record with a stable identifier that survives through preprocessing, deduplication and tokenisation, so you can locate the record if a user invokes their rights.
• Retraining cadence — schedule periodic full retrains on the current consented dataset. Withdrawal becomes effective at the next checkpoint, which is a defensible posture even though it is not instantaneous.
• Inference-time exclusion — for retrieval-augmented systems, withdrawal is straightforward: drop the record from the retrieval index. For systems where the data sits only in weights, document the retraining cadence and be honest about it.

Sample audit log entry for a consent withdrawal

One concrete artefact every AI team will need is an audit log entry per consent event. Below is a minimal JSON schema we recommend as a starting point — it captures the lawful basis at the time of capture, the linked training corpus identifiers, and the planned propagation point. Adapt to your storage layer.

{
  "event_id": "evt_01HYZ8K4N9",
  "event_type": "consent_withdrawal",
  "data_principal_id_hash": "sha256:a3f...c1e",
  "consent_manager_id": "cm_meity_reg_0042",
  "purpose_code": "model_training:multilingual_asr",
  "originally_granted_at": "2026-03-12T08:14:00Z",
  "withdrawn_at": "2026-11-21T11:02:17Z",
  "lawful_basis_at_capture": "consent",
  "linked_corpus_ids": ["corpus_v17", "corpus_v18"],
  "linked_model_versions": ["asr-bulbul-v3"],
  "propagation_plan": {
    "retrieval_index": "remove_within_24h",
    "fine_tune_corpus": "exclude_at_next_retrain",
    "next_retrain_eta": "2027-02-01"
  },
  "operator": "system:withdrawal_pipeline",
  "operator_signature": "ed25519:7f9..."
}

Two design choices in that schema are worth flagging. First, the data principal identifier is hashed — the audit log itself should be data-blind to anyone who later queries it. Second, the propagation plan is concrete and dated — vague phrasing such as "as soon as possible" will not survive a DPBI inquiry.

Anonymisation in the AI era

DPDP, like most modern privacy regimes, exempts genuinely anonymous data from its scope. The catch is that anonymisation is no longer a property of the data alone — it is a property of the data plus every other dataset an attacker can plausibly join. Re-identification attacks against allegedly anonymised health, mobility and search-log datasets have been demonstrated repeatedly in the academic literature over the last decade, and the rise of large language models has lowered the bar for an attacker working from sparse signals.

Practically, this means that the simple "remove names and addresses" approach that satisfied a 2015 compliance check no longer clears the bar. Builders training on user-generated text, voice or behavioural logs should plan for differential privacy noise where it can be tolerated, k-anonymity grouping for tabular features, and a documented re-identification risk assessment that the Board can review on request.

Cross-border data flows and the UK angle

For UK firms the question is when DPDP attaches. The answer is straightforward: any processing of the personal data of a data principal located in India brings DPDP into play, regardless of where the processing infrastructure sits. A London-based AI startup with an Indian user base is in scope. A Manchester analytics firm that uses an Indian GCC for data labelling is in scope, both as a data fiduciary in respect of the Indian employees it employs and potentially as a processor for its own customer data flowing through the GCC.

The overlap with UK GDPR is large but not total. Lawful basis under UK GDPR includes legitimate interest, contract and consent. DPDP relies primarily on consent and on a narrower notion of "legitimate uses". UK firms that have built their data-protection programmes around legitimate-interest assessments will need to redo that work for Indian data. Cross-border transfer rules are also tighter under DPDP — the Central Government can blacklist destinations, and as of writing no Adequacy decision exists in either direction.

The builder checklist

Pulling everything together, here is the work that needs to be done — split between what to ship by Phase 2 and what falls due at Phase 3.

Ship by November 2026

• Granular, per-purpose consent capture with separately revocable tokens.
• An abstraction layer for Consent Manager integration — treat it as a pluggable provider, not a single vendor.
• A tagged data inventory: which datasets are personal data, which are anonymised, which mix.
• A Data Protection Officer appointment if you are tracking towards Significant Data Fiduciary status.
• Initial training-data lineage tooling with stable record identifiers from ingestion through to model checkpoints.

Ship by 13 May 2027

• A production withdrawal pipeline that propagates a consent revocation to retrieval indices, fine-tune corpora and the documented next retraining cycle.
• Notice flows that meet the Phase 3 specificity requirements — purpose, retention, withdrawal mechanism and contact details for grievance redressal.
• Audit logs structured for DPBI inspection, ideally signed and append-only.
• A breach response playbook with the 72-hour notification path mapped to your on-call rotation.
• A re-identification risk assessment for any dataset claimed as anonymised.
• For UK firms with Indian operations, a reconciliation document showing where DPDP and UK GDPR diverge and how each obligation is met.

Where this connects to other regulatory work

DPDP does not sit on its own. The deepfake amendments expected to ride on the same Rules framework are covered in our companion piece on the DPDP deepfake rules and what they mean for synthetic-media builders. Teams working on Indian multilingual models will recognise the consent shape from our earlier coverage of the Sarvam multilingual stack, where data-collection partnerships were already structured around granular per-language consent. The broader sovereignty context around India's sovereign AI funding sets the political backdrop for why the DPBI is being given real budget and real teeth.

For UK builders the cross-jurisdictional reading list also includes our coverage of the EU AI Act high-risk deadline. Firms operating across the UK, EU and India in 2027 will be subject to all three regimes simultaneously, and the penalty stacks are not netted off — the same data leak can attract a UK GDPR fine, a DPDP penalty and an EU AI Act sanction in parallel.

Primary sources we relied on for this piece: the MeitY notification published on the Ministry of Electronics and Information Technology portal, the consolidated Rules text on dpdpa.gov.in, the IAPP analysis of the operative dates, and the Lexology and Fisher Phillips commentaries published in the days after the November 2025 notification. We have linked the more concrete commentary points inline; the secondary sources we cross-referenced for the timeline are listed in our editorial notes.

Bottom line

Phase 2 is not a single date — it is a hinge between a constitutional regime and an enforceable one. AI builders who use the next eighteen months to put real lineage, real consent abstractions and real withdrawal pipelines in place will find the May 2027 deadline manageable. Those who treat DPDP as a checklist to be filled in the week before will find that ₹250 crore is a number with real bite, and that the DPBI is unlikely to be sympathetic to the argument that machine unlearning is hard. It is hard. The compliance work is to acknowledge that honestly in your documentation, not to wave it away.