India DPDP Act AI Compliance Checklist

Act No. 22 of 2023 covers digital personal data and assigns duties to Data Fiduciaries around lawful purpose, notice, consent where relied upon, accuracy, security safeguards, breach response, retention, and Data Principal rights. For enterprise AI, those obligations become operational at the HTTP request boundary. A prompt can contain a name, employee record, interview answer, account number, or other regulated data before a model provider receives it.

I use a simple test for checklist: can the control owner retrieve the identity, purpose, data classification, destination, policy version, and outcome for one specific AI request? The review spreadsheet has 12 rows, but the useful column is the one containing a live record ID for each control. That is the level of evidence a serious review needs. Teams that start with a generic privacy questionnaire usually miss the model request where personal data actually crossed the boundary.

Scope the AI processing before mapping controls

Start with an inventory of applications, agents, model providers, API routes, and data categories. Record the business owner and technical owner for each use case. The inventory should identify the person or workload initiating a request, the model receiving it, the processor relationship, the declared purpose, and the retention path for prompts and responses.

The primary DPDP Act source anchors the legal or standards interpretation. The control team should preserve the exact edition or statutory text used for the mapping, with an approval date. That detail prevents a later assessor from finding a neat matrix built against an obsolete edition.

Discovery must include direct APIs, embedded assistants, and vendor features that call models behind a SaaS interface. A browser bookmark list catches only the visible part. Network records, expense data, identity-provider application lists, and procurement records provide separate discovery signals. Each identified flow receives a stable system ID so evidence can be tied to the same object over time.

Bind identity and purpose to each request

Authentication identifies the caller. The control record also needs the role, delegated authority, business purpose, and relevant data subject or candidate context. Static service keys identify an application and often erase the human or agent behind a request. Pass identity context with the model call, then resolve it at the policy decision point.

For DPDP Act, define permitted purposes in terms that engineering systems can evaluate. A support summarizer may process a case record through one approved route, while a recruiting tool may analyze a recorded interview only after the required notice and consent events exist. Deny a general coding assistant access to a production customer table.

Purpose tags require a named owner who can create a purpose, the approver, the review interval, and the systems allowed to assert it. Log the resolved purpose beside the identity. Free-text labels typed by a caller provide weak assurance because the calling application can simply choose a convenient value.

Classify data before it leaves the environment

Prompt-level classification should run before an HTTP request reaches the model. Document the categories, detection methods, confidence thresholds, redaction rules, and denial rules. Include structured fields and attachments because regulated data often appears in a PDF, transcript, or copied table rather than in the first line of a prompt.

The enforcement outcome should be deterministic for each policy version. Permit an approved category and route. Redact defined fields when the business purpose survives removal. Deny a request when policy prohibits the destination or the data cannot be handled safely. Record the classifier result and action without reproducing sensitive prompt content unnecessarily.

Test the awkward paths by using a misspelled name, a scanned document, a mixed-language transcript, an agent-generated follow-up request, and a response containing data absent from the original prompt. Record expected and observed outcomes. Five concrete tests tell an assessor more than a control statement saying the platform monitors sensitive information.

Preserve request-level audit evidence

A useful evidence record contains a request ID, timestamp, verified identity, delegated user where relevant, system and route IDs, purpose, data classification, destination model, policy version, decision, and enforcement action. Add a cryptographic signature or another tamper-evident mechanism. Keep access to the evidence store separate from application administrators.

Write-path independence addresses the self-attestation problem. When the AI application both makes the decision and writes the audit record, a crash or compromised credential can remove the evidence. A decoupled policy point commits the record as part of the request path. The application receives the model response only after the policy decision has been recorded.

Evidence retention follows the applicable DPDP Act mapping, contracts, and other law. Maintain a schedule for decision metadata, prompt content, response content, consent or notice artifacts, exceptions, and deletion events. Minimize stored content where metadata proves the control. When content must be retained, restrict access and record every retrieval.

Assign owners and test exceptions

Every mapped control needs one accountable owner, one operating team, a review cadence, evidence location, and failure response. Separate policy approval from day-to-day administration. A security engineer can operate the gateway while privacy, legal, compliance, or recruiting owners approve the rule set.

Exceptions need an expiry date and a narrower compensating control. Record who approved the exception, which systems and identities it covers, its reason, and the test required before closure. An exception called temporary with no date tends to become permanent configuration.

Run quarterly samples and event-driven tests after a model change, provider change, material incident, or new data category. Select allowed, redacted, and denied requests. Confirm that the record matches the live policy and that deletion or retention actions complete in downstream stores. Track failed samples as corrective actions with owners and dates.

Evidence package for an assessor

Prepare an evidence package that can stand alone. Include the scoped AI inventory, approved policy, data-flow diagram, control mapping, owner list, risk assessment, processor register where applicable, test plan, results, exception log, incident procedure, retention schedule, and a sample of signed decision records.

The diagram should show authenticated user or agent, application, policy decision point, permitted model endpoints, evidence store, and named trust boundaries. Avoid a decorative cloud labelled AI because it hides the processor and route that matter.

Sampling should be reproducible. Record the query, date range, population size, selection method, and evidence hashes. A second reviewer should be able to retrieve the same records. The DPDP Act mapping then becomes a maintained chain connecting a requirement to a control, an owner, an implementation, and proof.

DeepInspect

DeepInspect sits inline between authenticated users or agents and HTTP-based LLM APIs. It evaluates identity, role, purpose context, prompt classification, route, model authorization, and policy before forwarding the request. The boundary covers model traffic; it does not replace endpoint controls, application security, consent collection, or the organization's broader privacy program.

Each permit, redact, and deny decision produces a tamper-evident record containing the policy version and enforcement outcome. Those records give DPDP Act owners operational evidence for the AI request layer and a stable reference for sampling, exceptions, incident reconstruction, and control testing.

Book a technical deep dive at deepinspect.ai.