DPDPA for Indian software: personal data and AI systems

Every product we ship for an Indian client touches personal data: a signup, a payment, a support chat, an analytics event. India's DPDP Act and final Rules create a phased set of legal duties for handling that data. Most product-facing duties were not yet in force when we updated this post on 15 August 2026, but the engineering work takes time. AI features also make those data flows harder to see. This post is the problem we started with.

The problem, plainly

Personal data is never in one tidy table. It is spread across the whole build: the email in your auth system, the phone number at checkout, the message in a support thread, the IP address in your logs. Most of it got there without anyone deciding it should.

The Digital Personal Data Protection Act and final Rules set out notice, consent, security, retention, and rights duties that commence in phases. For a small business shipping fast, getting ready for that system is a lot to handle quietly in the background.

AI makes the flows harder to see

An AI-forward product sends data to places the team often does not track. A prompt with a customer's name goes to a model provider. A support summary runs through an LLM. A log of that call sits on some disk for a month. Each hop is a place personal data can leak, and most of them never show up on a normal architecture diagram.

So the AI features that make a product feel modern are exactly the ones that quietly widen the surface you have to protect.

Why this is our problem, not just our clients'

It started as a client problem. A business we build for asked the obvious question: if we add these AI features, are our customers' details safe, and are we on the right side of the law? We did not have a clean, repeatable answer. That bothered us.

We ship a lot of Indian builds. If protecting personal data is a scramble on every one, we are doing it wrong. We would rather solve it once, properly, and make it the default in everything we ship, for our clients and for any Indian builder who wants to do right by their users.

What safe by default should mean

We are still defining this, but the shape is clear. For a build to count as safe, we want:

• Consent and notice that are real and specific, not a buried checkbox.
• Data minimization: collect and keep only what the feature actually needs.
• No personal data sent to a third-party AI provider without a clear, safeguarded reason.
• User rights wired in from day one: access, correction, and erasure that actually work.
• A breach plan that exists before a breach does.

How we are going to approach it

We are starting where we have control: our own builds. The plan is to turn that list into defaults and reusable patterns, test them against real client work, and tighten them as we learn. We are engineers, not lawyers, so we will check the legal edges with people who are. This is step one, written down so we can be held to it.

We did report back. The follow-up explains how we turned the law into a repeatable engineering audit, with stable checks, dated sources, and evidence attached to every finding. If you want to compare notes, or you have a build you are worried about, write to us at hello@gattyworks.com.