India's DPDP Act 2023 Explained — And How AI Handles Data Principal Requests at Scale

Your company just received this email:

"I would like to know all personal data your organisation holds about me. This is a formal request under the DPDP Act."

It lands in a shared privacy@yourcompany.com inbox. Someone reads it. Forwards it to legal. Legal forwards it to engineering. Engineering says they need to check three databases. Nobody notes the date it arrived. Three weeks pass. When someone finally circles back, there are nine days left on the 30-day window the DPDP Rules require. Not enough time to locate the data, get legal sign-off, draft a response in the right language, and send it.

On day 32, you're in violation.

That scenario is the default for most Indian companies right now. Not because they're careless — but because nobody built the infrastructure for it.

I built DPDP Copilot to close that gap: a self-hosted operator tool that accepts public data requests, classifies them with Claude, drafts compliant multilingual replies, tracks every action as immutable evidence, and monitors SLA status in real time.

But before the tool, you need to understand what you're actually dealing with. Let's start with the law.

The Digital Personal Data Protection Act 2023 received presidential assent on 11 August 2023 and represents India's first comprehensive data protection legislation. Its structure borrows from GDPR while adapting to India's specific context — a 1.4 billion-person population, 22 scheduled languages, deep mobile penetration, and a digital public infrastructure layer (UPI, Aadhaar, DigiLocker) that most jurisdictions don't have.

The implementing Rules — the Digital Personal Data Protection Rules 2025 — were notified on 13 November 2025, giving the Act its operational teeth.

The Four Rights Every Data Principal Has

The Act grants every "data principal" — the person whose data is being processed — four actionable rights. When someone exercises any of these, your organisation (as the "data fiduciary") has a legal obligation to respond.

The Response Timelines

The DPDP Rules 2025 set specific mandatory windows for responding to data principal requests:

For reference: GDPR (EU) requires responses within one month for most data subject requests; California's CCPA gives 45 days. India's framework is broadly comparable in its demands — but applies at the scale of 1.4 billion people, across 22 scheduled languages. That's where the operational challenge is categorically harder.

What "Evidence" Actually Means Under DPDP

The Act and the Rules create a documentation burden that most organisations underestimate. You need to be able to prove:

• That the request was received on a specific date
• That it was handled (classified and routed) in a timely manner
• What response you gave and when
• Whether the response fulfilled the request or why it couldn't

This is audit evidence. If the Data Protection Board investigates a complaint, you need to produce this trail. A forwarded email chain is not audit evidence. A Slack thread is not audit evidence. An append-only timestamped log — with the original message, the classification, the drafted response, and the send event — is.

The Financial Exposure

The Act's First Schedule specifies penalties by category of failure. The two most operationally relevant:

Other penalty tiers: ₹200 crore for violations related to children's personal data (Section 9); ₹150 crore for Significant Data Fiduciary obligation failures; ₹50 crore for other provision breaches. These numbers are large enough to matter to mid-market companies, not just enterprises.

The most common setup at Indian companies dealing with DPDP requests right now:

• A privacy@ email address that gets checked sporadically
• No deadline tracking — the 30-day window doesn't appear anywhere visible until it's almost gone
• No classification — the person who reads it decides manually whether it's an access request, deletion request, or complaint
• Reply drafted manually, from scratch, in English, by whoever processes it that week
• No audit trail beyond the email itself, which may be deleted if an inbox is cleaned

This isn't negligence. It's the logical outcome of a process designed before the Act existed. The process was "email us with your concern" — and it worked fine when data requests were rare. The DPDP Act changes the legal weight of those requests, but most companies haven't updated their infrastructure to match.

The Three Ways Manual Processes Break

1. The deadline blind spot

When a request lands in an email inbox, the 30-day clock doesn't appear anywhere. Nobody stamps the receipt date. Nobody sends an automatic acknowledgement. The request sits until someone opens the inbox. If that takes a week — completely normal for a low-traffic shared inbox — you've already used 23% of your response window without touching the request. Legal review, data location, and drafting will eat most of what's left.

2. Classification inconsistency

"Please delete my data" is an erasure request. "I never gave you permission to use my data" is a grievance. "I want to update my phone number" is a correction request. "Can you send me everything you have on me" is an access request. A trained compliance professional can distinguish these consistently. Your Monday-morning on-call engineer who reads the shared inbox probably cannot — especially for requests written in Hindi, Bengali, or Tamil.

When requests are misclassified, they get routed to the wrong person, get the wrong response template, and sometimes get the wrong legal treatment. An erasure request handled as a grievance will likely produce a response that doesn't fulfil the legal obligation under Section 12(b), even if it sounds polite.

3. Evidence that can't survive audit

An auditor asks: "On what date did you receive and process this erasure request?" If your answer is "let me check the email thread," you have a problem. Email is mutable, searchable by keyword but not by event type, and has no integrity guarantees. An auditor looking for REQUEST_CREATED at timestamp T followed by REPLY_SENT at timestamp T+22 days needs a structured log, not an inbox.

When I was designing DPDP Copilot, the central question was: where does AI actually add value, and where does it introduce risk?

DPDP compliance has two types of tasks: tasks that require human judgment about legal gray areas, and tasks that require consistent application of known rules to varied inputs. AI is well-suited to the second category and badly suited to the first.

Deciding whether your company has a legal obligation to retain data for a pending investigation? That's human judgment. Classifying an incoming message as an access request vs. an erasure request? That's pattern recognition on natural language — exactly what a well-prompted LLM is built for.

LLM Classification: Automating DPDP Request Triage

Naive rule-based classification for DPDP requests fails quickly. "Please delete my account" is an erasure request. "I want my data removed from your marketing list" is also an erasure request but uses entirely different vocabulary. "Remove me" submitted in a support ticket might be an erasure request or might just be asking to be unsubscribed from emails — context determines which.

A rules-based system that catches "delete my data" literally will miss most real-world submissions. People write in fragments, in their native language, with emotional context, in ways that don't follow a template.

An LLM with a well-structured prompt classifies these correctly without needing exhaustive keyword lists:

The system prompt establishes the legal framework: "You are a DPDP compliance assistant classifying data principal requests under India's DPDP Act 2023." The model maps the message to the correct legal category.

The output is constrained to a JSON object with a single key. The application validates that type is one of the four legal categories. If the model returns something outside those four values, it's rejected and retried — the system never persists a classification it can't validate.

Multilingual Reply Drafting: Where AI Eliminates Weeks of Work

India has 22 scheduled languages. The DPDP Act creates a right to grievance redressal — and for that mechanism to be genuinely accessible, you need to respond in a language the person can understand.

Without AI, producing compliant response templates in Hindi, Bengali, Tamil, and Marathi means hiring translators, reviewing legal language, maintaining version parity across languages, and updating all templates whenever requirements change. That's a significant operational cost — one that most companies defer indefinitely, defaulting to English-only responses that disadvantage non-English speakers.

With a well-prompted LLM, drafting happens at response time. The model drafts a response that acknowledges the specific request type, confirms receipt, states the applicable response timeline, and explains next steps — in the language the data principal chose. These are suggested replies — an operator reviews them before sending. The human stays in the loop for all final communications.

Prompt Caching: Cost-Efficient at Scale

The system prompts for both classification and drafting use cache_control: { type: 'ephemeral' } via the Anthropic SDK, enabling prompt caching.

If you're processing dozens of data principal requests per day, the system prompt — identical for every request — gets cached by Anthropic's API after the first call. Subsequent calls are billed at a fraction of the full input token cost. At scale, prompt caching reduces API costs by 50–80% for the classification and drafting steps.

Retry Logic: Resilience Against Transient Failures

The LLM calls use exponential backoff retry logic. Only rate limit errors and server errors trigger retries — not client errors. The delay doubles with each attempt: 1 second, then 2, then 4. Three attempts total. A transient API hiccup doesn't fail the entire processing pipeline for a data principal's submission:

The Public Request Form

The entry point for data principals is /grievance — no login required. Requiring a login to submit a data rights request is a barrier that conflicts with the spirit of the Act. If someone can't easily submit an erasure request, the mechanism isn't truly accessible.

The form collects the request message (free text — people write what they mean in their own words) and preferred response language (English, Hindi, Bengali, Tamil, Marathi). There's no account creation, no verification code, no CAPTCHA wall.

What Happens in the Background on Submission

When the form is submitted, a single API call to POST /api/public/requests triggers a multi-step synchronous pipeline:

By the time an operator opens the inbox, the request is already classified, a draft reply exists, and the SLA clock has been running since submission.

The Operator Inbox

The inbox at / is protected by authentication. It shows all requests for the active organisation — request type, message preview, live SLA status (Within SLA / Due Soon / Overdue), and creation timestamp. SLA status is computed at read time on every page load — no background workers, no stale cached values.

Marking a Reply as Sent

When an operator sends the response (currently: manually via email, then clicks "Mark as Sent"), the system updates status to CLOSED and logs REPLY_SENT with a timestamp. The gap between REQUEST_CREATED and REPLY_SENT is the documented response time — computable to the second from the evidence log.

The evidence design is the most important part of DPDP Copilot from a compliance standpoint. Everything else is workflow tooling. The evidence log is what you use when the Data Protection Board comes calling.

Append-Only by Design

The evidence_events table has no update or delete paths in the application. Once an event is written, it stays. Audit evidence that can be modified isn't evidence — it's a story you're telling.

The created_at field uses DEFAULT now() — the database server's timestamp, not the application's Date.now(). Database server clocks in a managed PostgreSQL instance are NTP-synchronized and authoritative. Application clocks can drift.

The Four Event Types

REQUEST_CREATED — logged at the moment of database insertion, before any processing. This is the legal timestamp of receipt. If classification then fails, the absence of REQUEST_CLASSIFIED tells you where the pipeline stopped.

REQUEST_CLASSIFIED — logged immediately after the AI classification succeeds and the type is validated. Contains the classified type in event_data.

REPLY_SUGGESTED — logged when the AI draft is written to the request record. Contains the language and model used.

REPLY_SENT — logged when an operator marks the reply as sent. Contains the operator identity and channel. This closes the request lifecycle in the evidence log.

The presence of all four events, in chronological order, within the applicable window means the request was handled correctly from intake to response. An auditor reviewing the CSV export can verify this in seconds:

Auditor reads it: request received Sunday 10:00 AM, responded Tuesday 2:22 PM — 52 hours elapsed. Well within any reasonable response window. The PDF export includes the organisation name, request metadata, original message verbatim, suggested reply, and the full timeline — one page, shareable with a regulator.

SLA management is where most compliance tools fail. They either track SLA status as a static database field (which becomes stale the moment the clock ticks past the deadline) or they rely on background jobs (which can fail silently and leave the status indicator wrong).

DPDP Copilot takes a third approach: compute SLA status at read time, every time. The sla_due_at timestamp is written once, at request creation. On every inbox load, every request detail page load, computeSlaStatus(slaDueAt) runs. No database update. No background worker. The status shown to the operator is always accurate as of the current server time.

Setting the Right Internal SLA

The DPDP Rules 2025 set a 30-day legal maximum for access/correction/erasure responses. How you set your internal target depends on your process:

• A startup where one person handles requests end-to-end: 7–10 days is achievable and leaves buffer
• A mid-size company requiring legal review and data lookup: 14–21 days as the internal target, with the legal 30-day window as the backstop
• A large enterprise with formal approval workflows: set the SLA to match your internal policy; the evidence log tracks compliance with your own commitments

The configurable orgs.sla_days field in the database — not yet wired to request creation in the current version, but on the roadmap — will let each organisation set its own target without changing code.

The Status vs. SLA Distinction

Early versions of DPDP Copilot conflated two concepts: the workflow status of the request (open, closed?) and the computed SLA urgency (within deadline?). The second database migration separates these — status is the workflow state (OPEN or CLOSED); the live SLA urgency is always computed by computeSlaStatus at read time. This matters for reporting: answering "what percentage of requests were responded to within the internal SLA?" requires separating workflow state from deadline state.

India's 2011 census (the most recent with detailed language data) recorded 19,569 raw mother tongue entries — consolidating to 121 languages with more than 10,000 speakers each. The DPDP Act and Rules 2025 require grievance mechanisms to be genuinely accessible, which practically means: if your users write to you in Hindi, a response mechanism that only understands English is not accessible.

DPDP Copilot supports five languages in the current version:

• English — the default, always available
• Hindi — 528 million speakers (2011 census)
• Bengali — 97 million speakers
• Tamil — 69 million speakers
• Marathi — 83 million speakers

What the AI Draft Looks Like in Practice

Here's the same erasure request processed in two languages.

Input:

"I never gave consent for you to sell my data. Please delete everything you have about me immediately."

Suggested reply — English:

Suggested reply — Hindi (same message, same legal references):

The structure is identical. The legal references (Section 12(b), DPDP Act 2023) are consistent. The tone is professional but accessible. An operator who reviews the Hindi draft can run it through a translation tool to verify quality before sending — the AI draft is a starting point, not a blindly trusted final output.

Why Dynamic Drafting Beats Static Templates

A naive approach would translate a fixed English template into other languages once, then serve those static translations. This works for simple acknowledgements but fails for personalised responses that need to reference the specific request content.

Because DPDP Copilot drafts replies by passing the original message to the model, the suggested reply can acknowledge specific details the data principal mentioned — not just their request type. If someone writes "I asked you to stop sending me SMS messages three months ago and you're still doing it," a good response acknowledges that history. A static template can't. The LLM approach generates a contextually appropriate response — which is a qualitatively different outcome from translation.

The database schema is designed around compliance requirements first, application convenience second.

Index Strategy

Two composite indexes cover the two main query patterns:

Both indexes include org_id as the leading column because every query in the application is org-scoped. An index that starts with org_id is used by the query planner even for queries that also filter by request_id — the org scope eliminates most of the table before the planner looks at other columns.

Self-Hosted by Design

DPDP Copilot is self-hosted. That's a deliberate product decision.

DPDP requests often contain sensitive personal data — names, contact details, account information, and sometimes sensitive categories of data like health or financial details. The organisation processing these requests is the data fiduciary. Routing that data through a third-party SaaS for classification and storage creates its own compliance risk: you're a data processor, processing data principal requests by sending them to another data processor, with all the consent and data transfer implications that entails.

Running the tool in your own infrastructure keeps the data principal's message in your trust boundary. The only data that leaves your environment is the message text sent to Anthropic's API for classification and drafting. That's a single, scoped, auditable data transfer that you control.

Docker Compose Quickstart

Open http://localhost:3000 for the operator inbox. Open http://localhost:3000/grievance for the public form.

Production Considerations

Session signing: Generate ADMIN_SESSION_SECRET with openssl rand -hex 32. In development you can skip this; in production the session cookie must be signed or it's trivially forgeable.

Database: For production, use a managed database (AWS RDS, Google Cloud SQL, Supabase) with automated backups. The evidence table is your legal record — you want it on infrastructure with point-in-time recovery.

HTTPS: Run behind a reverse proxy (nginx, Caddy) that terminates TLS. Session cookies should have Secure and SameSite=Strict.

Rate limiting: The public /grievance form has no rate limiting in the current version. A reverse proxy rate limit on the public intake endpoint prevents abuse without touching the application code.

Honesty about limitations is part of useful tooling documentation.

Current Limitations

No outbound delivery. The "send reply" workflow doesn't actually send anything. It marks the reply as sent in the evidence log and closes the request. The operator sends the drafted reply via their existing channel (email, portal) and then clicks "Mark as Sent." This is a limitation of the MVP — real outbound email delivery is the obvious next step.

Single-admin authentication. One username/password pair from environment variables. No user table, no role model, no per-operator audit trail. Fine for a team of one; a problem for a compliance team of five.

Static org configuration. Active organisation selected via DEFAULT_ORG_ID in the environment. Database schema supports multiple orgs; the application routing doesn't yet.

No structured contact data. Contact information is embedded in the free-form message. No contact_email field means no reliable way to programmatically route the response back to the data principal.

PDF XSS risk. The PDF template interpolates user-provided text directly into HTML without escaping. Highest-priority security fix on the roadmap.

No notifications. Operators have no way to be alerted when a new request comes in or when a request is approaching its internal SLA deadline.

The Roadmap

DPDP Copilot handles the data principal rights workflow. That's one piece of a complete DPDP compliance programme.

What DPDP Copilot Covers

• Receiving data principal requests (Access, Rectification, Deletion, Grievance)
• Classifying them correctly and consistently
• Drafting multilingual responses
• Tracking internal SLA deadlines
• Generating the audit evidence trail
• Exporting evidence for regulatory review

What It Doesn't Cover

• Data discovery: Finding where a person's data lives across your systems. That's a data catalogue problem.
• Consent management: Recording what data was collected under what consent. That's a separate consent registry.
• Privacy notices: Generating or maintaining the notice required under Section 5. That's a legal document workflow.
• Data breach notification: Section 8(6) requires prompt notification to the Board and affected persons. That's a separate incident response workflow.
• Cross-border transfer compliance: The Act restricts transfers of personal data to certain countries. That's a data governance and infrastructure question.

A full DPDP compliance programme needs all of these. DPDP Copilot handles the rights management piece — the part that creates the most immediate operational urgency because it has a hard deadline on individual transactions and a direct escalation path to the Data Protection Board.

The Risk Reduction at a Glance

Compliance and legal teams at Indian companies processing personal data of Indian residents under the DPDP Act. If you're a data fiduciary — collecting or processing personal data — you have obligations under this Act. If you don't have a structured process for handling data principal requests, you need one.

Engineering teams building privacy infrastructure who need a reference implementation of DPDP request handling. The codebase is open-source. The data model, the API structure, the evidence logging pattern, the SLA computation logic — all of it is readable, runnable, and adaptable.

Startups at the early compliance stage who don't yet have a dedicated compliance team. The tool runs on a single machine. Configuration is a .env file. The public form can be linked from your privacy policy. You don't need a compliance department to run it — you need someone who checks the inbox.

Organisations handling multilingual Indian user bases where an English-only inbox isn't accessible to all the people it's supposed to serve. If your users write to you in Hindi and Tamil, they deserve responses in Hindi and Tamil — and the time cost of manual translation has historically made that impractical. It isn't anymore.

As the Data Principal

You purchased something from a company. You're getting SMS marketing messages you didn't opt in to. You want to file an erasure request and a formal grievance.

You go to https://yourcompany.com/grievance. You write:

"I never gave you permission to send me SMS promotions. I want you to delete my phone number and all data you hold about me. I also want to formally complain about this."

You select Hindi as your preferred language and submit. You receive an acknowledgement: "Your request has been received and logged. Reference: [UUID]. Our compliance team will be in touch."

As the Compliance Operator

You open the operator inbox the next morning. You see a new request, classified as Grievance (the model detected the formal complaint language alongside the deletion request), with WITHIN_SLA status.

You click into the request. You read the original message. The suggested reply in Hindi is already drafted. You read it — it acknowledges the complaint, confirms the erasure request has been noted, and explains next steps in Hindi.

You make a small edit to reference your company's specific erasure process. You copy the draft, send it via your email system, and click "Mark as Sent" in the tool.

The evidence timeline:

Total response time: 23 hours. Well within any reasonable SLA window. The CSV export documents this. If the data principal escalates to the Data Protection Board, you have a timestamped, exportable record of the complete interaction.