Building AI Systems That Meet India's DPDP Rules: Five Design Decisions for Engineering Teams
India's data protection law has been on the books since 2023, but for most engineering teams it became real on 13 November 2025, when the government notified the Digital Personal Data Protection (DPDP) Rules. The Rules started an 18 month clock. The framework for consent managers is due about a year after notification, in November 2026, and the substantive obligations for most organisations apply from mid-May 2027.
For a team shipping an AI product, that timeline is shorter than it looks. Many of the obligations are far cheaper to meet in architecture than to retrofit into a system that is already in production. This article sets out what the Rules mean for AI systems in engineering terms, followed by five design decisions worth making now.
What the DPDP Act says about AI, and what it leaves open
The Act has no chapter on artificial intelligence. It applies when a system processes digital personal data, and in an AI system that covers far more than the training set. Prompts, uploaded files, retrieval sources, model outputs, application logs and data shared with AI vendors can all contain personal data. If they do, the Act applies to that processing.
Two questions come up in almost every AI project.
Is publicly available data free to use? Section 3(c)(ii) places outside the Act personal data that the individual has made public, or that someone made public under a legal obligation. That is narrower than it sounds. Personal data collected by scraping websites generally was not made public by the individual it describes, and the Minister of State for Electronics and IT told the Rajya Sabha in August 2024 that scraping public data remains subject to the IT Act and the DPDP Act, including consent and transparency duties. Legal commentary also cautions against treating the research exemption as a blanket permission for training commercial models.
Who is responsible, the model provider or you? The organisation that decides why and how personal data is processed is the Data Fiduciary and carries the obligations. A provider that processes data only on your instructions, such as a hosted model API, acts as a Data Processor. The Rules require the fiduciary to ensure that its processors apply equivalent security safeguards, so the accountability stays with you and the contract needs to reflect it.
One timing point deserves attention. In early 2026, MeitY was reported to be considering a shorter 12 month window for Significant Data Fiduciaries, which would bring their deadline forward to November 2026, and industry bodies asked the ministry not to proceed. Teams should confirm the current position with counsel before fixing a delivery plan.
Why AI systems feel the Rules more than conventional software
A conventional application stores a customer's data in a known set of tables. An AI system copies the same data into embeddings, vector indexes, caches, evaluation sets, fine-tuning datasets and prompt logs, often across several vendors. Each copy is a place where a consent withdrawal, an erasure request or a breach has to be handled. The obligations are the same as for any software, but the number of places they apply is much larger.
That is the reason to treat DPDP as an architecture question and not as a policy document.
Five design decisions to make now
1. Map personal data across the whole AI stack before release
Start with a data flow map that follows personal data from source to every place it lands: ingestion, preprocessing, training or fine-tuning sets, embeddings, retrieval indexes, prompts sent to external models, outputs, and logs. Record the purpose of each flow, the system that holds it, and the vendor involved.
This map is the foundation for everything that follows. Without it, a team cannot answer a regulator, a client or a data principal who asks where their data went.
2. Tie consent and notice to a specific purpose, and make withdrawal reach every copy
The Rules require a notice that is clear, written in plain language and separate from other terms, so that consent is specific and informed. For AI features, this means the notice should name the AI use, for example summarising a document or screening an application, and not rely on a general statement that data may be processed to improve services.
On the engineering side, store consent as a record that is linked to the data it governs. When a person withdraws consent, the system should be able to find and act on every derived copy, including the chunks and embeddings created from their documents. A consent flag in the user table alone will not do this.
3. Design for retention and erasure in vector stores, caches and training sets
The Act requires personal data to be erased once its purpose has been served or consent has been withdrawn, with advance notice to the individual in defined cases. Erasure is straightforward in a relational database and much harder in an AI stack.
Several patterns help:
Keep a stable identifier on every chunk and embedding so that all derived records for one person can be located and deleted.
Keep personal data out of long-lived training sets unless there is a clear purpose and basis for it, and prefer retrieval over training for data that may need to be removed.
Set retention periods for caches, prompt logs and evaluation sets, and automate their deletion.
There is a real tension to manage. Commentary on the Rules notes that certain logs and personal data must be retained for a minimum of one year to support breach detection. Masking personal data inside logs lets a team meet both needs: the log exists for security, and it does not become a second store of raw personal information.
4. Apply security safeguards at the prompt boundary and the retrieval layer
Rule 6 requires reasonable security safeguards. The measures it lists include encryption, obfuscation or masking, virtual tokens, access controls, monitoring, detection of unauthorised access, data backups, and security terms in contracts with processors. Penalties for failing on safeguards can reach INR 250 crore.
For AI systems, three places deserve particular care:
The prompt boundary. Mask or tokenise personal identifiers before text leaves your environment for an external model, and re-insert them afterwards where the use case needs it.
The retrieval layer. Retrieval must respect the same access permissions as the source system. An assistant that can retrieve a document the user is not allowed to open has created an access control failure.
Vendor terms. Confirm in contract whether a vendor retains prompts, uses them for training, or stores them outside India, and record the answer.
5. Write an AI-specific breach runbook
Under Rule 7, a breach must be reported to the affected individuals and to the Data Protection Board, with an initial intimation without delay and a detailed report within 72 hours. The Rules do not set a materiality threshold, so any personal data breach triggers the duty.
AI systems create breach scenarios that a standard security runbook may not cover: a model that reveals another user's data in a response, a prompt log exposed through a misconfigured dashboard, or a retrieval index that was built from a restricted source. Define these scenarios in advance, decide who investigates each, and test the 72 hour sequence in a drill.
If you may become a Significant Data Fiduciary
The Central Government designates Significant Data Fiduciaries by notification, based on factors such as the volume and sensitivity of data and the risk to individuals. Organisations cannot self-assess into the category, and as of 2026 no entity or class has been publicly notified. Clients of AI vendors in financial services, health and large consumer platforms are the more likely candidates.
Rule 13 adds four duties for a designated entity: a Data Protection Impact Assessment and an audit every 12 months, a report to the Board, due diligence that its algorithmic software is not likely to pose a risk to the rights of individuals, and compliance with any localisation direction for specified categories of data. The algorithmic due diligence duty has little precedent elsewhere, and it is the one that most directly affects how AI features are tested and documented. A vendor that can show evaluation records, bias testing and change logs for its models will be easier for such a client to buy from.
On localisation, the Act does not impose a general requirement. Transfers abroad are permitted except to countries the government restricts by notification, and the localisation duty in Rule 13 applies only to designated entities and only to categories of data the government specifies.
What to do in the next 90 days
Draw the personal data map for each AI feature in production or in build.
Review consent notices and rewrite any AI use that is covered only by general wording.
Add stable identifiers to chunks, embeddings and cached outputs so that deletion by person is possible.
Introduce masking at the prompt boundary and permission checks in retrieval.
Audit vendor contracts for prompt retention, training use and data location.
Write and rehearse the AI breach runbook against the 72 hour sequence.
Ask enterprise clients whether they expect to be designated, and agree who supplies the evaluation records they would need.
A perspective from Kreeda Labs
Our view is that DPDP readiness for AI is cheapest at design time. The decisions above, a data map, purpose-bound consent, deletion-ready storage and masking at the boundary, add modest effort when they are built into the first release and substantial effort when they are added after launch. Teams that treat them as architecture requirements also tend to find that enterprise buyers ask for exactly this evidence during procurement.
Conclusion
The DPDP Rules do not ask AI teams to stop building. They ask for systems that know where personal data is, can act on a person's choices, and can respond quickly when something goes wrong. With the main obligations arriving from May 2027, and some provisions earlier, the practical task for engineering leaders is to put those capabilities into the roadmap this quarter.
This article provides engineering guidance and is not legal advice. Organisations should confirm obligations and timelines with qualified counsel.
Comments