DPDP consent UX that founders can actually ship.
Practical notice, purpose limitation, and consent patterns for AI products selling to Indian regulated buyers — without freezing the roadmap.
·9 min read
TL;DR
For Indian buyers, DPDP-aware AI products need clear notice, purpose-bound processing, and consent UX users can understand — designed into onboarding and model features, not bolted on as a PDF. Brandlabs treats consent as a product surface with auditability, not a checkbox theater.
What does DPDP change for AI product UX?
It forces you to explain what personal data you take, why the model needs it, and how the user can withdraw or limit purpose — in language a founder and an end user can both parse. Hidden training toggles and vague “improve our services” copy will not survive a serious buyer review.
US teams often ship HIPAA-shaped controls first (access, BAAs, audit logs) and forget that Indian launches live or die on notice + purpose + consent clarity.
For AI features specifically, users need to understand:
- Which inputs become model context
- Whether outputs are stored
- Whether data trains anything (yours or a vendor’s)
- How to stop processing for a purpose without deleting the whole account
Brandlabs designs these as product flows in Foundation — not as a privacy policy link under the fold.
This is engineering and UX sequencing with counsel review. It is not legal advice on DPDP applicability.
What consent patterns can a small team ship in weeks, not months?
Layered notice at collection, purpose chips tied to features, separate toggles for optional AI processing, and a settings page that can withdraw consent and stop downstream jobs. Prefer explicit opt-in for sensitive or model-training uses; never bury them in a mega-accept.
A shippable starter set:
- Collection notice — plain language at signup and before first AI use
- Purpose map — each AI feature declares its purpose IDs
- Optional AI toggle — core account can work if AI is off (when product allows)
- Vendor disclosure — which processors see prompts/embeddings
- Withdrawal path — kills new inference and queues deletion/export jobs
Wire consent state into the API gateway so a revoked purpose cannot still hit the model.
If your product cannot function without personal data in prompts, say that upfront. Surprise is what destroys trust.
How do you keep consent aligned with prompts, logs, and evals?
Consent is a runtime signal: inference, logging verbosity, and eval dataset inclusion must read the same source of truth. If marketing says “we don’t train on your data” but evals copy production prompts into a shared store, you have a product bug — and a buyer diligence failure.
Checklist we run in Discovery Sprints:
- Consent flags on the user/tenant record
- Inference middleware checks purpose before call
- Audit events record consent version at request time
- Eval pipelines exclude or transform data per policy
- Support tools cannot paste raw prompts into tickets casually
Correct (our India compliance lab product) taught us the same lesson in another domain: visibility beats policy PDFs. Users and operators need to see status, not hunt for it.
Frequently asked questions
Is a privacy policy enough for DPDP?
Usually no for AI products that process personal data in prompts. Buyers will ask how notice, purpose, and withdrawal work in the product itself.
Do we need separate consent for every model call?
Not every token — but you do need purpose-level consent that covers the feature, plus re-notice when purpose or vendors materially change.
Is this legal advice?
No. Have Indian counsel review your roles, notices, and contracts. Brandlabs implements the product and architecture patterns those reviews require.