DPDPA Compliance for AI: Architectural Patterns for Engineering Teams

Achieving DPDPA compliance is one of the most pressing challenges for engineering teams building with large language models in India today. Under the Digital Personal Data Protection (DPDP) Act 2023, you cannot treat models as black boxes or assume that standard database encryption is enough.

The law introduces strict requirements for verifiable consent, purpose limitation, and the absolute right to erasure. When personal data flows into non-deterministic systems, traditional data pipelines break down. This guide details the architectural patterns required to make your systems compliant.

The Core Challenge: Why Standard AI Pipelines Violate DPDPA Compliance#

Traditional data architectures treat pipelines as one-way streets. Data is ingested, cleaned, stored, and then fed into applications or models. This design directly violates the core mandates of the DPDP Act.

Under Section 6 of the DPDP Act, processing the personal data of Indian citizens requires explicit, granular consent. This consent must be free, specific, informed, unconditional, and unambiguous. It requires a clear affirmative action from the user. Furthermore, you must present consent notices in English and the 22 scheduled regional languages of India.

       [ User Input ]
             │
             ▼
┌──────────────────────────┐
│    Inline LLM Gateway    │ ◄─── Real-time NER & Redaction
└────────────┬─────────────┘
             │ (Clean Prompt)
             ▼
┌──────────────────────────┐
│     Vector Database      │ ◄─── Metadata-filtered query (Consent ID)
└────────────┬─────────────┘
             │ (Context Chunks)
             ▼
┌──────────────────────────┐
│        Base LLM          │ ◄─── Zero PII stored in weights
└──────────────────────────┘

If your pipeline feeds raw customer data directly into model training or prompt logs, you lose control of that data. Section 8(3) of the Act requires a Data Fiduciary to ensure that processed personal data is accurate and complete if it is used to make decisions that affect the individual. Non-deterministic systems that hallucinate or use stale context run a direct risk of violating this accuracy mandate.

The cost of getting this wrong is high. The DPDP Act defines severe financial penalties:

• Up to ₹250 crore (INR 2.5 billion) for failing to observe reasonable security safeguards to prevent data breaches.
• Up to ₹200 crore (INR 2 billion) for failing to notify the Data Protection Board and affected users of a breach.

Static encryption at rest does not protect you when sensitive variables are sent directly to external APIs or stored in vector embeddings. You need dynamic, pipeline-level governance.

What Usually Goes Wrong: The Machine Unlearning Trap#

Many engineering teams assume they can clean up their data later. They train or fine-tune models on raw customer data, planning to handle erasure requests if a user asks to delete their account.

This is a critical mistake. Deep learning models do not store data in neat rows. They build complex mathematical relationships across millions of parameters. Once a model is trained on a dataset containing personal data, you cannot reliably delete or unlearn a specific user's information from those weights without running a costly, full retrain of the model.

If you fine-tune models on raw datasets containing Indian personally identifiable information (PII) like Aadhaar numbers, Permanent Account Numbers (PAN), or local phone numbers, you create a permanent compliance liability. Under Section 12(3) of the DPDP Act, users have the right to erase their personal data. If you cannot extract their data from your model weights, your system is non-compliant.

To solve this, you must enforce a strict architectural boundary. The base model must remain entirely cold and devoid of customer PII. Personalization and user context must be handled outside the model weights.

The Recommended Architecture: Decoupled LLM Gateway and RAG#

To keep your models clean, you must decouple model intelligence from personal data. The most effective pattern combines an inline LLM Gateway with a Retrieval-Augmented Generation (RAG) pipeline.

In this decoupled architecture:

1. The LLM Gateway acts as a reverse proxy. It intercepts all incoming prompts, runs real-time Named Entity Recognition (NER), strips out PII, and replaces it with secure placeholder tokens before the prompt ever leaves your network.
2. The Vector Database acts as a transient, highly controllable cache of personalized context. It does not train the model; it merely serves as a temporary lookup engine to ground the model's responses.
3. The LLM (whether self-hosted or a third-party API) only receives anonymized prompts and tokenized context. It never sees or memorizes the actual identity of the user.

This approach isolates your data. If a user withdraws consent, you do not need to retrain a model. You only need to delete their records from your application database and vector cache.

Implementing the Inline LLM Gateway for Indian PII Redaction#

Standard PII detection libraries are usually trained on Western datasets. They frequently miss Indian-specific identifiers. Your inline gateway must run specialized, real-time NER and regex patterns optimized for the Indian context.

You must configure your gateway to detect:

• Aadhaar Numbers: 12-digit numbers following the Verhoeff algorithm.
• PAN (Permanent Account Numbers): 10-character alphanumeric strings (five letters, four digits, one letter).
• Indian Mobile Formats: Numbers starting with +91, 91, or 10-digit formats beginning with 6, 7, 8, or 9.
• Local Addresses: Highly variable regional address structures that standard Western parsers miss.

You can implement this gateway using custom Envoy proxies or tools like Langfuse. Below is an example of an inline tokenization gateway written in TypeScript.

import { Request, Response, NextFunction } from 'express';
 
// Simple patterns for Indian PII
const PAN_REGEX = /[A-Z]{5}[0-9]{4}[A-Z]{1}/g;
const AADHAAR_REGEX = /^[2-9]{1}[0-9]{3}\s[0-9]{4}\s[0-9]{4}`|^[2-9]{1}[0-9]{11}`/;
const INDIAN_PHONE_REGEX = /(?:\+91|91)?[6-9]\d{9}/g;
 
interface TokenMap {
  [token: string]: string;
}
 
export class PiiGateway {
  private tokenStore: Map<string, TokenMap> = new Map();
 
  public redactPrompt(userId: string, rawPrompt: string): { cleanPrompt: string; tokens: TokenMap } {
    const tokens: TokenMap = {};
    let cleanPrompt = rawPrompt;
    let counter = 0;
 
    // Redact PAN
    cleanPrompt = cleanPrompt.replace(PAN_REGEX, (match) => {
      const token = `__INDIAN_PAN_${counter++}__`;
      tokens[token] = match;
      return token;
    });
 
    // Redact Aadhaar
    cleanPrompt = cleanPrompt.replace(AADHAAR_REGEX, (match) => {
      const token = `__AADHAAR_${counter++}__`;
      tokens[token] = match;
      return token;
    });
 
    // Redact Phone Numbers
    cleanPrompt = cleanPrompt.replace(INDIAN_PHONE_REGEX, (match) => {
      const token = `__PHONE_NUM_${counter++}__`;
      tokens[token] = match;
      return token;
    });
 
    this.tokenStore.set(userId, tokens);
    return { cleanPrompt, tokens };
  }
 
  public restoreResponse(userId: string, modelResponse: string): string {
    const tokens = this.tokenStore.get(userId);
    if (!tokens) return modelResponse;
 
    let finalResponse = modelResponse;
    for (const [token, originalValue] of Object.entries(tokens)) {
      finalResponse = finalResponse.replaceAll(token, originalValue);
    }
    
    // Clear transient tokens after use to minimize storage footprint
    this.tokenStore.delete(userId);
    return finalResponse;
  }
}

This tokenization process ensures that the raw data remains strictly within your secure application layer. The external model only processes the tokenized structure.

Enforcing Erasure: Consent State as a Database Column in Vector Embeddings#

In a RAG system, user files, support tickets, and chat histories are chunked, converted into vector embeddings, and stored in a vector database. If a user withdraws consent under DPDPA Section 12(3), those embeddings must be deleted immediately.

Running periodic batch scripts to clean up vector databases is an anti-pattern. It leaves non-compliant data live for days. Instead, you should store consent metadata alongside every vector chunk in databases like pgvector, Pinecone, or Milvus.

By structuring your vector database to include a consent_id or user_id as metadata, you can execute real-time, metadata-filtered deletions. Here is an example of implementing this with pgvector in PostgreSQL.

import { Client } from 'pg';
 
interface VectorDocument {
  id: string;
  userId: string;
  consentId: string;
  embedding: number[];
  content: string;
}
 
export async function deleteUserVectors(dbClient: Client, userId: string): Promise<void> {
  const query = `
    DELETE FROM vector_embeddings 
    WHERE metadata->>'user_id' = $1;
  `;
  
  try {
    const res = await dbClient.query(query, [userId]);
    console.log(`Successfully deleted `{res.rowCount} vector chunks for user`{userId}.`);
  } catch (error) {
    console.error(`Failed to delete vector chunks for user ${userId}:`, error);
    throw error;
  }
}

When your primary application receives a webhook signaling that a user has withdrawn their consent, you must trigger this deletion query immediately. This ensures that the user's data can no longer be retrieved to ground any future LLM prompts.

Managing the 22-Language Consent Challenge at the Data Layer#

The DPDP Act requires that the notice and consent request be presented in English and the 22 languages specified in the Eighth Schedule of the Indian Constitution. If your application serves users across multiple states in India, you must deliver localized consent notices dynamically.

To handle this at the data layer, build a localized consent service that serves notices based on user locale or browser headers. This interaction must map back to an immutable Consent Ledger.

┌────────────────────────────────────────────────────────┐
│                     Consent Ledger                     │
├──────────────┬──────────────┬───────────┬──────────────┤
│  consent_id  │   user_id    │  lang_id  │  terms_hash  │
├──────────────┼──────────────┼───────────┼──────────────┤
│  con_89231   │  usr_9012    │    hi     │  sha256_...  │
│  con_89232   │  usr_4431    │    ta     │  sha256_...  │
└──────────────┴──────────────┴───────────┴──────────────┘

Your Consent Ledger schema should record:

• User Identifier: A unique ID linking the user to their data.
• Language Code: The specific language in which the notice was displayed (e.g., Hindi, Tamil, Bengali).
• Notice Version: The version of your terms and privacy policy.
• Timestamp: The exact time consent was granted.
• Cryptographic Hash: A SHA-256 hash of the exact terms shown to the user to prove what they agreed to.

This ledger serves as your verifiable audit trail. If a regulatory audit occurs, you can prove exactly when, how, and in what language each user granted consent.

System Risks, Latency Trade-offs, and Mitigations#

Adding an inline gateway and metadata filters introduces system overhead. You must balance compliance with application performance.

Latency Penalty of Inline NER#

Running deep transformer models for PII detection on the prompt path can add 50 to 150 milliseconds of latency. For real-time applications like conversational search, this is noticeable.

• Mitigation: Use lightweight, CPU-friendly models for initial screening. A hybrid approach works best: run fast, optimized regex patterns and small spaCy pipelines on CPU first. Only route complex, ambiguous text blocks to heavier transformer models.

Handling NER False Negatives#

Users may write their personal details in creative or obfuscated ways (e.g., writing "nine eight four..." instead of digits) or use regional slang that standard NER models fail to catch.

• Mitigation: Implement fallback guardrails on the output side of the LLM. Before any generated text is displayed to the user or saved to database logs, run a final, low-latency regex sweep to catch leaked PII.

Where to Start: A Step-by-Step Migration to Compliant AI#

If you have an existing system that was not built with these patterns, you can transition to a compliant architecture by following these four steps:

Step 1: Conduct a Data Flow Audit#

Map every point where customer data enters your system. Identify where prompts are logged, how vector embeddings are generated, and whether any customer data is used to fine-tune base models.

Step 2: Deploy the LLM Gateway Proxy#

Introduce an inline gateway between your application server and your model APIs. Start by running it in shadow mode: log detected PII without redacting it to measure the accuracy of your NER models and adjust your regex patterns.

Step 3: Refactor Your Vector Database Schema#

Update your vector database tables to include consent_id and user_id metadata columns. Write migration scripts to populate these fields for existing records, and implement real-time deletion webhooks.

Step 4: Integrate the Localized Consent Ledger#

Deploy a localized consent collection interface supporting the required regional languages. Ensure that all user consents are cryptographically signed, recorded in your ledger, and mapped directly to your active data pipelines.

Designing these patterns into your system early protects your architecture from costly redesigns as regulatory enforcement scales. To begin, audit your current prompt logs to identify where unredacted customer data is currently being stored.

Decoupling Data and Intelligence for Long-Term Compliance#

DPDPA compliance is not a legal paperwork exercise; it is an engineering constraint. If you allow PII to leak into your model weights, you create an irreversible compliance liability that no policy document can fix. The only sustainable path is to treat your models as stateless execution engines and enforce strict, metadata-driven boundaries at the gateway and database layers.

Your immediate next step is to run a dry run on your current production logs. Extract a sample of 1,000 historical prompts, run them through the TypeScript regex and NER filters detailed above, and measure how much Indian PII is currently leaking to your external model providers. This baseline will show you exactly where your pipeline is exposed before you write a single line of production gateway code.