Indian builds, personal data, and AI: the problem we are taking on

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 now makes handling that data a legal responsibility, not just good manners. And AI features quietly make those data flows harder to see. This post is the problem, laid out plainly, and the start of a project to make every build we ship safe by default.

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 makes mishandling that data a liability with real teeth. Consent has to be real, purposes have to be stated, data you do not need should not be kept, and people have rights over their own records. For a small business shipping fast, that is a lot to get right 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 will report back as we go, and share what we learn in the open. If you want to compare notes, or you have a build you are worried about, write to us at hello@gattyworks.com.