What DPDP Act Rule 6 Requires When Your Organisation Uses AI
Using AI tools with personal data creates DPDP obligations. Learn what Rule 6 requires for AI workflows by May 2027 and what a DPDP data protection solution needs to do.
Abeer Sehrawat • Jun 4, 2026
AI is changing how enterprises collect, process and store personal data. Under the DPDP Act, that creates specific obligations. This article covers what Rule 6 security safeguards mean for AI systems, what algorithmic due diligence requires if you are a Significant Data Fiduciary, and what a DPDP-compliant data protection solution for AI needs to do.
Understanding how data shared with AI can lead to DPDP violations
Every time an employee pastes customer data into an AI tool or connects a workflow to an external model, your organisation is potentially in violation of the DPDP Act. Most businesses using AI today have not mapped these risks. Here is what is actually happening.
Sending data to an AI model is sharing it with a third party
When an employee types a customer's name, phone number or account details into an AI tool like ChatGPT or Copilot, that information does not stay inside your organisation. It travels over the internet to the servers of whoever built that tool: OpenAI, Microsoft, Google, or another provider. From a legal standpoint, you have just shared personal data with a third party.
Under the DPDP Act, that creates two obligations. First, your original notice (the privacy notice you showed the customer when you collected their data) must have disclosed that their information could be sent to an external AI provider. If it did not, you are processing their data for a purpose they were never told about. That is a violation under Section 5.
Second, before any AI provider touches your customers' data, you need a formal contract with them called a Data Processing Agreement. This contract sets out what they can do with the data, how they must protect it, and when they must delete it. Most enterprises have not signed one. That is a violation under Section 8(2).
The AI provider is not a co-owner of that data. They are a vendor processing it on your behalf. The legal responsibility sits entirely with you.
The only way to remove this obligation structurally is to ensure the AI provider never receives real personal data in the first place. If personal data is replaced with synthetic equivalents before a prompt leaves your environment, the provider is not processing personal data at all. They fall outside the scope of Section 8(2) entirely.
You cannot fulfil Data Principal rights if data is inside a model
Under the DPDP Act, any individual in India can ask you to erase their personal data. This is called the right to erasure, under Section 12(3). You must comply unless you have a legal reason to retain it.
But here is the problem with AI: when personal data is used to train a machine learning model, it does not get stored as a file you can delete. Instead, it gets absorbed into the mathematical structure of the model itself, essentially becoming part of how the model thinks. There is no button you can press to remove one person's information from a trained model. The data is not there in a form that can be identified or extracted.
This creates a structural problem. If a customer asks you to erase their data, and their data was used in model training, you cannot comply. The inability to erase is itself a violation of Section 12(3), separate from any question about whether the training was lawful.
The only safe position is to prevent personal data from entering model training in the first place.
Using data to train models violates purpose limitation
When you collect personal data from a customer, you collect it for a specific reason: to process an order, manage an account, provide support. That reason is stated in your privacy notice and the customer consents to it.
Purpose limitation means you cannot then use that same data for something different without telling the customer and getting fresh consent. The DPDP Act is explicit about this: Section 6(1) restricts data use to the purpose stated in the notice, and Section 5 requires that notice to be given before data is collected.
Training an AI model is a completely separate purpose. It is not order fulfilment. It is not account management. If a customer's data (their name, their purchase history, their support queries) was fed into a training run without their knowledge, that processing was never consented to. You needed a separate notice and separate consent before using their data that way.
This applies regardless of whether the model is built by a vendor or trained in-house. Every processing activity needs its own lawful basis.
What the DPDP Rules say about data entering AI systems
Given the risks above, the DPDP Rules set out what you are required to do to protect personal data. Two rules are most relevant for organisations using AI: Rule 6, which covers the security safeguards every Data Fiduciary must implement, and Rule 13, which requires algorithmic due diligence for Significant Data Fiduciaries. Here is what each of them means in practice for AI use. For a broader overview of your obligations as a Data Fiduciary, see our complete guide to DPDP Rules 2025.
What Rule 6 of the DPDP Act requires you to do for AI usage
Rule 6 sets out the security safeguards every Data Fiduciary must implement. It comes into force on 13 May 2027. For organisations using AI, the implications are significant. Most traditional security controls do not address them.
1. Encryption and masking at the point of AI interaction
Rule 6 requires personal data to be protected through technical controls including encryption. In AI workflows, this means data must be masked or anonymised before it reaches a model. A customer's name, phone number or account ID should never appear in a raw prompt. This obligation sits with the Data Fiduciary regardless of which model provider they use.
2. Access controls proportionate to data sensitivity
Not every employee who uses an AI tool should have access to every category of personal data. Rule 6 requires access to be controlled and monitored. In practice, this means role-based permissions on which AI tools can process which data categories, and audit trails showing who sent what.
3. Proportionality: safeguards must match the risk
Rule 6 ties the required level of safeguard to the sensitivity of the data and the risk it carries. Health data, financial data and children's data processed through AI tools require stronger controls than general contact information. A single blanket policy will not satisfy this.
4. Log retention for AI interactions
Rule 6 requires access logs to be retained for a minimum of one year, even after the underlying personal data has been erased. These logs must show who accessed what personal data and when. For AI workflows, that means capturing what personal data was present in a prompt, what was masked, what reached the model, who initiated the interaction, and when. Most enterprise AI tools do not natively produce logs at this level of granularity. Building this infrastructure before the May 2027 deadline is strongly advisable.
Algorithmic due diligence for Significant Data Fiduciaries using AI
If the Central Government designates you as a Significant Data Fiduciary, you take on additional obligations under Section 10 and Rule 13, which comes into force 13 May 2027. Rule 13 requires algorithmic due diligence for SDFs whose processing involves automated decision-making that poses risks to Data Principals. This is not a general obligation for every enterprise using AI. It applies only to designated SDFs. No designations have been made yet, but large platforms in social media, healthcare and BFSI should begin preparing now.
What the algorithmic due diligence must cover
Under Rule 13, the due diligence must address:
- The risks that the SDF's algorithmic processing poses to Data Principals, such as automated decisions made on insufficient or biased data, personal data absorbed into a model that cannot be erased on request, or sensitive information inferred from unrelated inputs
- The measures the SDF is taking to address those risks
- The outcomes of those measures
Findings are reported to the Data Protection Board as part of the annual compliance process. The exercise must be repeated whenever the SDF makes significant changes to its algorithmic processing.
How to operationalise Rule 6 and other safeguards in AI workflows
Understanding what Rule 6 requires is one thing. Building it into how your organisation actually uses AI is another. Here is what this looks like in practice.
1. Map every AI touchpoint where personal data flows
Start by auditing which AI tools are in use across your organisation and which data categories they are exposed to. Employees using personal accounts on tools like ChatGPT are a significant blind spot. You cannot control what you have not mapped.
2. Define who can use which AI tools with which data
Not every employee needs access to every AI tool, and not every AI tool should be able to process every data category. Rule 6 requires access to be controlled and auditable. In practice, this means setting role-based permissions and ensuring there is a record of who used which tool and what data was involved.
3. Implement a data protection layer before prompts reach models
The most effective control point is between your data and the model. A purpose-built AI data protection layer intercepts prompts before they leave your environment, identifies personal data, masks or redacts it, and logs the interaction. General DLP tools were not designed for the structure of LLM prompts and responses.
4. Ensure your breach detection covers AI-specific vectors
Traditional breach detection looks for bulk data exfiltration. AI systems have a different risk profile: data leaking through model outputs, responses that reconstruct personal data from training, or prompt injection attacks. Your detection and logging infrastructure needs to cover these vectors.
What to look for in a DPDP data protection solution for AI
General-purpose DLP, SIEM and access management tools were built before large language models existed. They were not designed to inspect prompts, track data flows through inference pipelines, or produce the kind of per-interaction logs that Rule 6 and Rule 8 require. If you are evaluating a DPDP data protection solution for AI use, here is what it needs to do.
Can it detect and transform personal data at the prompt level?
Under Rule 6, personal data must be protected before it is processed. Many enterprises respond to this by restricting or blocking AI tools entirely. That solves the compliance problem but creates a different one: your teams lose access to productivity tools your competitors are using freely.
Redaction and masking are only marginally better. When a solution strips or tokenises personal data from a prompt, the AI receives an incomplete or garbled input and the output quality degrades. You have protected the data but broken the workflow.
The more effective approach is synthetic data substitution. A solution that replaces personal data with realistic synthetic equivalents (a different name, a different phone number, a plausible but fictional account ID) lets the AI process a coherent, contextually intact prompt. The model produces a full-quality response. The employee gets their answer. No real personal data ever reached the provider.
There is a further compliance benefit: if the LLM provider never receives real personal data, they are not processing it. That takes them outside the scope of your Section 8(2) Data Processing Agreement obligation entirely.
For any of this to work, detection needs to understand natural language. Pattern-matching on known formats like phone numbers or email addresses will miss names embedded in sentences, account references in context, or any PII that does not follow a standard structure.
Does it produce Rule 8-compliant processing logs?
Rule 8 requires processing logs and traffic data to be retained for a minimum of one year, even after the underlying personal data has been erased. For AI workflows, the solution must log what personal data was present, what was masked, what reached the model, who initiated the interaction, and when. Most AI tools do not natively produce logs at this level of specificity.
Is it built for AI or adapted from something else?
Traditional DLP tools flag bulk file transfers and keyword matches. They were not designed for the structure of LLM prompts or the data patterns that emerge in conversational AI. A solution adapted from a general security tool will have gaps. Ask any vendor: what is your detection mechanism for personal data inside unstructured natural language, and what does your Rule 6 access log look like?
How Mavs AI addresses DPDP data protection for enterprise AI
Mavs AI sits between your enterprise and the AI tools your teams use. Before a prompt leaves your environment, Mavs AI identifies personal data and replaces it with synthetic equivalents that the model cannot distinguish from real data. Your employees get full-quality AI output. The LLM provider never processes personal data, which means they fall outside the scope of your DPDP processor obligations entirely.
| Compliance requirement | How Mavs AI addresses it |
|---|---|
| Technical safeguards at the prompt boundary | Replaces personal data with synthetic equivalents before the prompt reaches any model. Output quality is preserved. The LLM provider never sees real personal data and is out of scope as a processor under Section 8(2). |
| Centralised access control | Policies set by user and data category, in real time. Access revoked in one click. Full audit trail of who used which AI tool and what data was involved. |
| Per-prompt audit trail | Every prompt, every substitution, and every response logged immutably for one year. Each personal data element is linked to its synthetic substitute in the log, giving you exact breach reconstruction without relying on vendor logs. |
| Algorithmic due diligence | Personal data stays out of model processing entirely, satisfying the core safeguard requirement for Significant Data Fiduciaries. |
Mavs AI covers AI risk across employees, apps and agents, and governance. For a detailed comparison with other security tools, see our DPDP compliance page.
FAQs
Does the DPDP Act apply to AI tools used by enterprises?
Yes. The DPDP Act applies to any automated processing of personal data, and sending personal data to an AI model is automated processing under Section 2(x). It doesn't matter whether the tool is used internally or via a third-party provider. If personal data of individuals in India is involved, your organisation as the Data Fiduciary is responsible for ensuring that processing meets the Act's obligations.
What does Rule 6 of the DPDP Act require for AI systems?
Rule 6 sets out the technical safeguards Data Fiduciaries must implement. For AI systems:
- Mask or encrypt personal data before it reaches a model
- Control who can process which data categories through AI tools
- Maintain access logs showing who accessed what and when
- Calibrate safeguards to the sensitivity of the data being processed
Rule 6 comes into force on 13 May 2027, along with the rest of the substantive Data Fiduciary obligations under the Act.
Do you need a Data Processing Agreement with your LLM provider under the DPDP Act?
Yes. Section 8(2) requires a Data Fiduciary to engage Data Processors only under a valid contract. An LLM provider that processes your data is a Data Processor. Without a Data Processing Agreement covering purpose, data categories, security obligations and deletion requirements, you will be in breach of Section 8(2). This obligation comes into force on 13 May 2027, but the compliance work (identifying your AI providers, reviewing their terms, and executing contracts) needs to happen well before that date.
What happens if personal data is used to train an AI model without consent?
Training on personal data is processing under Section 2(x). If individuals never consented to that purpose and it wasn't disclosed in the notice under Section 5, the training was unlawful. The Data Fiduciary faces exposure under Section 33 for processing without a lawful basis. If those individuals later request erasure under Section 12(3), you have no way to comply for data already baked into a trained model. That creates a separate, ongoing violation.
My employees are using AI tools at work. What should I do under the DPDP Act?
Start by mapping which AI tools are in use and what personal data they're exposed to. Employees using personal accounts on tools like ChatGPT create the same DPDP exposure as sanctioned tools. You are the Data Fiduciary regardless of how the data reached the model.
Four things need to be in place:
- Your notices to Data Principals must disclose that their data may be processed via AI tools
- You must have Data Processing Agreements with each AI provider under Section 8(2)
- Personal data must be masked before it reaches any model, as required by Rule 6
- Access to AI tools that process personal data must be controlled and logged
The deadline is 13 May 2027, when Rule 6 becomes fully operative.
