I have attended four technology conferences in the past six months. DPDP Act has come up at every single one.
It appears in panels, usually between a slide about artificial intelligence and one about India’s digital growth story. People nod. Someone asks whether enforcement is really coming. A lawyer explains the penalty structure. The session ends. Everyone walks out and continues building products exactly the way they always have.
That pattern concerns me far more than the law itself. Because after fifteen years of building digital products, I have learned to recognise when an industry is treating a product problem as someone else’s problem. And that is precisely what is happening with DPDP right now.
The Digital Personal Data Protection Act 2023 (Official Act Link) is not a compliance exercise your legal team resolves in the background. It is a fundamental redesign of the relationship between your product and the people who use it. The moment you understand it that way, everything changes.
What the law actually says, in product language
The Act requires affirmative, informed consent. Not implied. Not buried in a paragraph users scroll past at three in the morning. Not a pre-ticked box that someone in growth quietly introduced to improve sign-up numbers.
It requires purpose limitation. Data collected for one reason cannot be silently repurposed for another. The insight your analytics team discovered last quarter, the one that led to a new feature that decision now has a legal dimension.
It requires the right to erasure. A user can ask you to delete their data, completely and verifiably. Kormoan has been providing digital product services since 10 years and we know if your product cannot do that today, it is not a legal gap. It is a product gap.
And it carries penalties up to ₹250 crore for serious violations. (Let’s not get in to this for now)
None of these are policies. Every single one of them is a product design decision.
The consent problem nobody is designing for
All this time, consent in Indian digital products has followed a simple philosophy: minimise friction, maximise data. We built products where privacy policies existed to satisfy lawyers, not to inform users. We created popups designed to be dismissed, not read. We normalised experiences where agreeing to everything was the path of least resistance and protecting your privacy required effort most people could not be bothered to spend.
DPDP ends that era. Or at least, it is supposed to.
The challenge is that most organisations are responding by updating their privacy policies and calling it compliance. That is not compliance. That is the same behaviour dressed differently.
Real compliance means redesigning the moment of consent as a genuine product experience. It means asking whether users actually understand what they are agreeing to, whether the language respects their intelligence, and whether the design gives them real choice or merely the appearance of it. Those are not legal questions. They are design questions. And very few product teams are sitting in those DPDP panels asking them.
Where AI makes this genuinely difficult
I want to be honest about something that does not have a clean understanding or answer yet.
AI products have a structural consent problem that DPDP exposes but does not fully resolve. When a user shares their data with your product, they consent to what they understand. They do not consent to what your model infers. Their financial anxiety. Their health concerns. Their likelihood to leave. None of that was in the consent notice, because nobody knew it would be inferred at the moment they signed up.
The Act was written with declared data in mind information a person consciously provides. It was not written with derived data in mind the probabilistic insights that emerge from processing that information through an AI system. That gap is real, it is unresolved, and every team building AI products in India should be thinking about it now rather than waiting for regulators to define it for them. That’s what let us build the Design for AI framework for Kormoan.
The organisations that get this right will not do so by waiting for clearer rules. They will do so by asking a more honest question: does our product treat user data the way we would want our own data treated?
We asked that question when we designed Lean-on. The product carries some of the most intimate data a person can share. Our first instinct was not to figure out what data we could collect. It was to figure out how little we could ask for while still making the experience meaningful. We chose not to require personal information until the user genuinely wanted to go deeper. Even the payment flow sits behind authentication, not behind a data wall. Every single data touchpoint was designed to be understood not buried, not assumed, not extracted.
That is not compliance. That is a design decision. And it is the kind of decision that will separate products people trust from products people eventually abandon or resent. That question will not appear in any compliance checklist. But it will determine who builds lasting trust and who eventually faces consequences for not having built it.
What I believe product teams should do
Walk through your product as a user. Every moment where data is collected every form, every permission request, every AI inference running quietly in the background ask whether the person on the other side understands what is happening and genuinely agreed to it. You will find things that surprise you.
Then redesign those moments not as compliance requirements but as product experiences. Because a consent experience that is clear, honest, and gives genuine control is not just legally safer. It is better design. And in a country of 1.4 billion digital citizens who are increasingly aware of what their data is worth, it is also better business.
My product prospective if you are build any digital product…
- Start with a consent audit, not a legal audit.
- Redesign consent as a product feature, not a legal disclaimer.
- Map your data flows before your lawyers do.
- If you are building AI products, start the derived data conversation now.
- Treat the Data Protection Officer requirement seriously.
DPDP is arriving whether the conference panels acknowledge it seriously or not. The question is whether your product is ready for it not legally, but fundamentally. That is the conversation I am not hearing enough of. And it is the one that matters most.
The truth, privacy by design
The DPDP Act transforms the legal checkbox into a product-level compliance system where user experience decisions directly determine legal validity. User experience decisions determine legal validity. That means designers are now compliance officers whether they know it or not. That means every consent flow, every data collection moment, every AI inference pipeline is a legal document expressed in interface design.
The organisations that understand this earliest will build better products and carry less legal exposure. The ones that wait for their lawyers to tell them what to build will spend the next two years retrofitting products that were never designed with this in mind.
DPDP is not a legal problem. It is a product problem. And product problems are solved in design, not in legal memos.
