Building AI Under the DPDPA: Consent-First Machine Learning for India
Mohammed Usman is the founder and CEO of Masarrati with 15+ years in product engineering. He has led the development of 10+ production AI, blockchain, and cybersecurity platforms for enterprise clients across UAE, MENA, and Europe.
TL;DR
India's DPDP regime reaches AI directly: consent is the default basis for training data, product consent does not cover training, withdrawal must have designed effect, and SDF-scale organisations face DPIA and audit duties — with the clock running to November 2026 and May 2027. Build consent-scoped pipelines with per-record provenance, prefer retrieval over memorisation for personal data, evaluate synthetic paths, treat residency as a design variable — and note that a DPDPA-proof architecture is most of a PDPL-proof one.
Updated August 14, 2026
Every AI roadmap in India now has a regulatory dependency. The DPDP Act applies to AI and machine learning systems that process digital personal data — and commentary on the regime is consistent on the uncomfortable parts: consent is the default lawful basis, there is no GDPR-style legitimate-interests ground, and no research exemption that covers commercial model development. Analyses of the Act's application to AI describe consent for training use as needing to be specific — distinct from the consent gathered for the product's primary purpose — while noting exemptions for publicly available data and defined research contexts. With the Rules' phased clock putting consent managers live in November 2026 and full obligations in force by May 2027, model teams have a fixed window to make their pipelines lawful by construction.
The instinct in many organisations will be to treat this as a legal review gate at the end of the ML lifecycle. That fails structurally, because the decisions that determine compliance — what goes into the training set, under what consent, and how withdrawal propagates — are made at the start of the lifecycle, in the data engineering.
The four questions every India AI pipeline must answer
What is the lawful basis of each training record? A consent-first regime means the training corpus needs provenance: which records rest on consent for this specific purpose, which fall under the publicly-available exemption, which are out. That is a per-record metadata problem, and it is far cheaper to stamp at ingestion than to reconstruct across an existing lake.
Is training consent separate from product consent? Commentary on the DPDPA and AI is clear that consent to use a service is not consent to train models on the data the service collects. Engineering translation: purpose flags on the data path, checked by the training pipeline, with records excluded by default when the training purpose is absent.
What happens on withdrawal? Consent under the Act is revocable. For AI systems that means designed answers, not aspirations: exclusion from all future training runs immediately, removal from retrievable stores and feature systems, and a documented position — agreed with counsel — on models already trained, with retraining cycles that give withdrawal real effect over time.
Can you show your work? For organisations at Significant Data Fiduciary scale, reporting describes DPIA and audit obligations with algorithmic oversight. A model card is not enough; the artefacts that matter are data lineage from source consent to training run, evaluation records, and decision logs for automated decisions that affect people.
Architecture patterns that make this tractable
Consent-scoped data pipelines. Purpose and consent state as first-class columns, filters enforced in the pipeline code rather than in policy documents, and training-set assembly that emits a manifest — which records, under which basis, at which consent version — as a build artefact.
Retrieval instead of memorisation where possible. For assistants and copilots, retrieval-augmented generation keeps personal data in governed stores with permission-aware access rather than baked into weights — which converts an intractable unlearning problem into a tractable access-control one, and makes erasure meaningful.
Synthetic and aggregate paths for analytics. Where the use case tolerates it, moving personal data out of the training path entirely is the cleanest compliance posture — and worth genuine engineering evaluation before defaulting to raw personal data.
Residency as a design variable. Reporting on the Rules notes localisation expectations attached to significant fiduciaries. In-country deployment of models, vector stores and logs — the pattern we build as sovereign AI — keeps the residency conversation short.
One regime, two markets
For companies operating across India and the Gulf, the strategic observation is that India's DPDPA and the UAE's PDPL rhyme: both are consent-first regimes without a legitimate-interests escape hatch. An AI data architecture built properly for one — per-purpose consent, provenance, withdrawal propagation, residency options — is most of the way to compliant in the other. Masarrati builds for both markets, and we increasingly design one consent-aware pipeline architecture that serves the pair.
Where Masarrati fits
Masarrati engineers AI and agentic systems with consent-aware data pipelines designed in from the first schema — enterprise RAG platforms with permission-aware retrieval, generative AI solutions whose training and evaluation records double as compliance artefacts, and GRC automation that keeps DPIA and audit evidence continuously current. Headquartered in Hyderabad and serving clients across the GCC, we build under both the DPDPA and the PDPL. Interpretation of the law rests with your counsel; our contribution is a pipeline whose records answer their questions.