Building DPDP Compliant RAG Systems in India: Secure Your AI Data
Navigating India's Digital Personal Data Protection Act 2023 while deploying RAG systems is crucial for Indian businesses. Discover how to engineer secure, privacy-preserving LLM applications that handle sensitive Indian personal data with confidence.
By Krapton Engineering10 min readAI Engineering

As Indian businesses rapidly adopt AI, particularly Retrieval Augmented Generation (RAG) systems, the challenge of handling sensitive personal data securely and compliantly intensifies. With the Digital Personal Data Protection Act (DPDP Act 2023) now in force, ensuring your RAG architecture protects data principals' rights is not just good practice—it's a legal imperative.
This guide, written by principal AI engineers, delves into the practical architectural and engineering steps required to build robust, DPDP-compliant RAG systems for the Indian market, addressing everything from PII masking to secure vector database strategies.
TL;DR: Building DPDP compliant RAG systems in India requires integrating privacy-by-design principles across the entire RAG pipeline, from data ingestion and PII masking to secure vector database management and LLM output guardrails. This proactive approach ensures compliance with the Digital Personal Data Protection Act 2023 and builds trust with Indian data principals.
Key takeaways
- The DPDP Act 2023 mandates strict handling of personal data, making privacy a core engineering concern for RAG systems in India.
- PII masking and anonymisation must occur at the data ingestion and pre-processing stages, before data enters the embedding model or vector database.
- Secure vector database architectures, including row-level security and tenant isolation, are crucial for preventing unauthorised access to sensitive Indian data.
- Implementing robust retrieval guardrails and LLM output filtering prevents accidental exposure of personal data during generation.
- Proactive data governance and regular audits are essential for maintaining DPDP compliance in production RAG systems.
The DPDP Imperative for RAG Systems in India
The Digital Personal Data Protection Act, 2023 (DPDP Act 2023) fundamentally reshapes how Indian organisations collect, process, and store personal data. For RAG systems, which often interact with diverse datasets—including customer support logs, internal documents, or financial records—this means a heightened responsibility. Any system that processes "personal data" of a "Data Principal" (the individual to whom the data relates) must do so lawfully, transparently, and for a specified purpose.
RAG systems are particularly vulnerable because they retrieve relevant information from a knowledge base to augment an LLM's response. If this knowledge base contains unmasked Personal Identifiable Information (PII) or other sensitive data, there's a significant risk of exposure through the LLM's output, leading to DPDP non-compliance and potential penalties. As a "Data Fiduciary," your organisation is accountable for protecting this data.
Architecting Data Privacy into Your RAG Pipeline
Ensuring DPDP compliance in RAG is not an afterthought; it must be designed into every stage of your pipeline. From data ingestion to the final LLM response, each step requires careful consideration to prevent PII leakage and ensure data integrity.
Data Ingestion & Pre-processing: PII Masking & Anonymisation
The first line of defence against PII exposure is at the data ingestion and pre-processing stage. Before any data is chunked, embedded, or indexed, it must be thoroughly scanned and processed to identify and mask or anonymise sensitive information. This includes Indian-specific identifiers like Aadhaar numbers, PAN details, UPI IDs, bank account numbers, and phone numbers.
In a recent client engagement for a D2C brand's customer support RAG, we found direct PII exposure in chat logs, including customer phone numbers and partial payment details. Our solution involved a pre-processing layer that used a combination of custom entity recognition models and robust regex patterns to mask sensitive identifiers before chunking. For instance, a phone number might be replaced with `[PHONE_NUMBER]`, or an Aadhaar number tokenised.
Techniques like tokenisation (replacing PII with non-sensitive tokens), format-preserving encryption, or outright redaction are critical. The goal is to ensure that no raw PII ever reaches your embedding model or vector database.
import re
def mask_indian_pii(text: str) -> str:
# Mask Aadhaar numbers (12 digits, optionally spaced)
text = re.sub(r'\b\d{4}\s?\d{4}\s?\d{4}\b', '[AADHAAR_NUMBER]', text)
# Mask PAN numbers (5 chars, 4 digits, 1 char)
text = re.sub(r'\b[A-Z]{5}[0-9]{4}[A-Z]{1}\b', '[PAN_NUMBER]', text)
# Mask Indian phone numbers (10 digits, common formats)
text = re.sub(r'(\+91[\s-]?)?[6789]\d{9}\b', '[PHONE_NUMBER]', text)
# Mask UPI IDs (e.g., user@bankname)
text = re.sub(r'\b[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\b', '[UPI_ID]', text)
return text
# Example usage
# sensitive_text = "My Aadhaar is 1234 5678 9012 and PAN is ABCDE1234F. Call me on +919876543210."
# masked_text = mask_indian_pii(sensitive_text)
# print(masked_text)
# Output: "My Aadhaar is [AADHAAR_NUMBER] and PAN is [PAN_NUMBER]. Call me on [PHONE_NUMBER]."
Chunking & Embedding for Privacy
Your chunking strategy directly impacts the risk of PII exposure. Large chunks might inadvertently combine masked PII with other context that could lead to re-identification. Conversely, overly small chunks might lose necessary context. Aim for entity-aware chunking where possible, ensuring that sensitive entities, once masked, are not fragmented or re-associated in a way that compromises privacy.
The embeddings themselves should be generated from the masked data. This means the numerical representation of your data, stored in the vector database, contains no direct PII, making it inherently more secure. This is a crucial step towards building secure RAG for Indian data.
Secure Vector Databases & Access Controls
The vector database is the heart of your RAG system, storing the embedded knowledge base. Securing this component is paramount, especially when dealing with Indian personal data.
- Data Localisation: For certain data types, like payment data, RBI mandates data localisation within India. While not universally applied to all personal data under DPDP, it's a strong consideration for sensitive information. Choose cloud providers and vector database services that offer data centres within India.
- Access Control: Implement robust access controls. If you're using a self-hosted solution like pgvector on PostgreSQL, leverage Row-Level Security (RLS) to ensure that only authorised users or services can query specific data rows. For managed vector databases, ensure strict API key management and consider multi-tenant architectures.
- Tenant Isolation: For SaaS products serving multiple Indian businesses, strict tenant isolation is critical. On a production rollout for an insurance claims processing RAG, our initial approach with a shared vector index risked cross-tenant data leakage if retrieval wasn't perfectly scoped. We pivoted to a multi-tenant architecture with separate vector indices for each client, enforced by strict API gateway validation of tenant IDs. This significantly reduced the attack surface and ensured data segregation.
Retrieval & Reranking with Privacy in Mind
Even with pre-masked data, the retrieval phase requires careful orchestration. The goal is to retrieve relevant information efficiently without inadvertently compromising privacy:
- Pre-retrieval Filtering: Before embedding similarity search, apply filters based on user roles or data permissions. This ensures that a user can only query data they are authorised to access, even if the embeddings exist.
- Post-retrieval PII Detection: As an additional guardrail, implement a lightweight PII detection mechanism on the retrieved chunks *before* they are sent to the LLM. This acts as a final check, catching any PII that might have slipped through earlier masking stages or been reconstructed from context.
When NOT to use this approach
If your RAG system exclusively processes public, non-sensitive information (e.g., publicly available product documentation, general knowledge articles) and is not exposed to any personal data, over-engineering for DPDP compliance can add unnecessary latency and cost. For internal-only RAGs with strictly controlled access and no PII, simpler architectures might suffice. However, for any system touching external users or sensitive operational data, particularly in sectors like fintech, healthcare, or e-commerce, DPDP compliance is paramount and these privacy engineering steps are indispensable.
LLM Generation & Output Guardrails
The final stage, where the LLM generates a response, is another critical point for privacy. While the input should already be PII-safe, the LLM itself could theoretically hallucinate or reconstruct sensitive information.
- Prompt Engineering: Explicitly instruct the LLM in your system prompt to avoid generating or inferring any personal data. For example, "Do not include any names, addresses, phone numbers, or other personal identifiers in your response."
- Output Filtering: Implement a final layer of PII detection and masking on the LLM's output before it reaches the end-user. This is your last chance to catch and redact any sensitive information that might have been generated. This aligns with the IndiaAI Mission's focus on responsible and secure AI development, emphasising robust data governance.
Cost-Benefit Analysis: Building vs. Buying DPDP Compliance
Deciding whether to build DPDP compliance features in-house or leverage existing tools and managed services is a strategic choice for Indian businesses. Both approaches have cost implications, influenced by factors like developer salaries (often quoted in LPA), infrastructure costs, and the overhead of maintaining compliance.
| Feature/Aspect | Build In-House (Krapton Engineering) | Buy/Managed Service |
|---|---|---|
| PII Masking & Anonymisation | Custom regex, NLP models (e.g., SpaCy), data pipelines. Higher upfront development cost (₹18-25 LPA for a specialist engineer), high control. | Dedicated privacy APIs, data governance platforms. Subscription fees (USD or INR, plus GST), less control over custom logic. |
| Secure Vector Database | Postgres with pgvector, custom RLS, self-managed cloud VMs. Infrastructure cost, internal expertise. | Managed vector databases (Pinecone, Qdrant Cloud) with enterprise security features. Opex model, often billed in USD, simplifies operations. |
| Access Controls & Auditing | Custom IAM integration, audit logging, CERT-In compliance. Significant engineering effort, ongoing maintenance. | Enterprise-grade data platforms, compliance suites. Streamlined auditing, often includes compliance certifications. |
| DPDP Compliance Expertise | Hire or train dedicated legal & engineering compliance experts. High internal cost. | Consultancy services, vendor support for compliance. External expertise, recurring fees. |
| Time to Market | Slower, requires significant development and testing cycles. | Faster, leverages pre-built, tested solutions. |
While building in-house offers maximum control and customisation, it demands substantial investment in engineering talent and ongoing maintenance. For many Indian startups and SMEs, leveraging managed services or partnering with an experienced AI development company like Krapton can provide a faster, more cost-effective path to DPDP compliance. We offer AI development services to help Indian businesses build secure and compliant systems, and can even assist in automating compliance workflows.
FAQ
What is the Digital Personal Data Protection Act 2023?
The DPDP Act 2023 is India's comprehensive data privacy law. It governs the processing of digital personal data within India, establishing rights for data principals and obligations for data fiduciaries, focusing on consent, data minimisation, and security measures. It's crucial for any AI system handling Indian personal data.
How does PII masking differ from anonymisation in RAG?
PII masking replaces sensitive data with non-sensitive placeholders (e.g., replacing an Aadhaar number with `[AADHAAR_NUMBER]`). Anonymisation aims to irreversibly alter data so that a data principal cannot be identified, even indirectly. For RAG, masking is often sufficient as the goal is to prevent LLM exposure, not necessarily full anonymisation for public release.
Can open-source LLMs be DPDP compliant for RAG in India?
Yes, open-source LLMs can be DPDP compliant, provided your organisation implements robust data governance. The compliance burden lies primarily with how you manage the data (ingestion, masking, storage) and the output, rather than the model itself. Self-hosting open-source models gives more control over data residency and processing.
What role does data localisation play in DPDP compliant RAG?
While DPDP Act 2023 does not mandate universal data localisation, it is a significant consideration, especially for sensitive sectors or where RBI regulations (e.g., for payment data) apply. Storing your RAG's knowledge base and processing data within India can simplify compliance and reduce cross-border data transfer complexities under the Act.
Build a Production-Ready, DPDP-Compliant RAG System with Krapton
Navigating the complexities of DPDP Act 2023 while building advanced RAG systems requires deep expertise in both AI engineering and Indian regulatory compliance. Don't risk data breaches or non-compliance fines. Our team of principal AI engineers understands the nuances of secure data handling for the Indian market.
Ready to build a secure, production-grade AI system that respects data privacy? Share your project brief with Krapton and let's engineer your next DPDP-compliant RAG solution.


