DPDP Act & AI Automation: What Actually Changes

Most coverage of India's Digital Personal Data Protection Act is written for lawyers, which leaves engineering teams guessing about what to actually build. Automation is squarely in scope, because automation touches personal data by definition — a voice agent records what a caller said, a lead system stores contact details, a support bot logs conversations. This piece is about the engineering consequences rather than the legal ones. Treat it as scope for a build, and confirm what specifically applies to your organisation with your own counsel, because the obligations differ by how much data you handle and in what role.

Consent has to be a record, not a checkbox. The practical requirement is that you can answer, for any individual, what they agreed to and when. A tick box that sets a boolean does not survive that question. What does is a consent record: the person, the purpose consented to, the timestamp, and the version of the notice they saw. Notices get reworded over time, and without versioning you cannot reconstruct what someone actually agreed to. This is a small table and a discipline about writing to it, and it is dramatically cheaper to add now than to reconstruct from logs later.

Purpose limitation constrains what your automation may do with data it already has. Data collected to fulfil an order cannot be silently repurposed to train a model or drive a marketing sequence. In practice this means tagging data with the purpose it was collected for and having downstream systems respect that tag. For an automation stack this is the awkward one, because pipelines are built to move data between systems and purpose tags are exactly what gets dropped in transit. Decide early which of your flows are fulfilment and which are marketing, and keep them separate at the data layer rather than by convention.

Deletion has to actually delete, including the copies. A user exercising their right to erasure means the record leaves your primary database — and also your analytics warehouse, your backups within their retention window, your CRM, the transcript store from the voice agent, and any vendor you pushed it to. Most teams discover at this point that they have no inventory of where personal data has spread. Building that inventory while the system is small is straightforward. Building it after three years of integrations is an archaeology project, and it usually happens under time pressure from a complaint.

Automated decisions need an explanation path. If an automated system declines an application, prioritises one customer over another, or routes someone to a worse outcome, you should be able to say why. That means logging the inputs a decision was made on, not merely the output. For model-driven steps this is more involved than it sounds, and the honest engineering answer for consequential decisions is often to keep a human in the loop rather than to attempt post-hoc explanation of a model's reasoning.

Security expectations are now specific enough to design against. Encryption at rest and in transit, access control that follows least privilege, and audit logs showing who accessed what. None of this is exotic, and it substantially overlaps with what a SOC 2 process would ask of you and with GDPR's requirements if you have European users. That overlap is the useful insight: building it once satisfies several regimes at once, which is the argument for doing it at the start rather than treating each as a separate project.

Retrofitting all of this costs several times what building it in does. Consent records, purpose tags, a data inventory and audit logging added at design time are a small share of an automation project. Added after launch, each one becomes a migration against live data plus a backfill for records that never captured the fields. We design these into automation engagements from the start for exactly that reason; the India AI automation page covers how that fits alongside the other constraints of building here, including multilingual delivery and ERP integration.