How The DPDP Rules Regulate AI And Other Algorithmic Software, The Protections They Provide, And Where Their Reach Ends
Prepared by Shubhank Suman, AI, Privacy, and IP Counsel
The DPDP Rules were not drafted as an AI law. They do not use the words “artificial intelligence”. Yet Rule 13 contains one sentence that directly addresses algorithmic software. Rule 13(3) requires a Significant Data Fiduciary, or SDF, to: “observe due diligence to verify that technical measures including algorithmic software adopted by it [...] are not likely to pose a risk to the rights of Data Principals.” This is currently one of the clearest points at which Indian data protection law addresses the risks created by algorithmic systems. The Rule does not regulate AI generally. It does not prohibit automated decision-making or give individuals a right to human review like Article 22 of GDPR. Instead, it requires a notified SDF to assess whether the technology it uses to process personal data could put Data Principal rights at risk. That makes Rule 13(3) an algorithmic due diligence obligation, not a complete AI governance regime. This note explains what the Rule requires, who must comply, what systems it may cover, and how it differs from Article 22 of the GDPR.
What Rule 13(3) Covers, And Why It Exists
Area Covered | Why and what Rule 13(3) addresses it |
|---|---|
Access to personal Data | An SDF must understand its algorithmic software well enough to provide the information required under Section 11, including a summary of the personal data being processed, the related processing activities, and the required details of data sharing. If a black-box system prevents the SDF from identifying or tracing this information, the right of access may become ineffective. Section 11 does not, however, give the Data Principal a right to inspect the algorithm, access its source code, or obtain an explanation of its logic. |
Accuracy and Correction Under Section 12, an SDF must be able to correct, complete or update a Data Principal’s personal data upon receiving a valid correction request. The correction must be reflected not only in the main database but also across any algorithmic systems, profiles or classifications that continue to process or rely on that data. If the system continues to use an outdated copy or derived profile after the underlying data has been corrected, the Data Principal’s right to correction has not been effectively implemented. | |
Erasure | Under Section 12, when erasure is required, the SDF must be able to erase the Data Principal’s personal data from every relevant part of the algorithmic system, including connected databases, prompts, logs and profiles. Erasing only the main record is insufficient if the software continues to store or process the same personal data elsewhere. Rule 13(3) therefore requires the SDF to examine whether its algorithmic software can effectively implement an erasure request and prevent further processing of personal data that must no longer be retained. |
Grievance Redressal | Under Section 13, an SDF must provide an effective grievance-redressal mechanism for complaints concerning its obligations under the DPDP Act. Where a grievance involves algorithmic processing, the SDF should be able to identify the relevant personal data, trace how the software processed it, and investigate whether that processing caused the alleged non-compliance. Section 13 does not, however, create a separate right to contest an algorithmic outcome merely because it was automated. |
Rule 13(3) must be read with Section 10 of the DPDP Act. Section 10 allows the Central Government to designate a Data Fiduciary, or a class of Data Fiduciaries, as an SDF. It also requires an SDF to undertake measures such as periodic Data Protection Impact Assessments and audits, along with any other prescribed measures necessary to ensure compliance with the Act.
Rule 13(3) uses that rule-making power to introduce algorithmic due diligence. The DPDP Act itself does not expressly refer to algorithms. The direct reference appears in the Rules. This has two consequences. First, the obligation is limited to SDFs. An organisation does not become an SDF simply because it processes large volumes of personal data or uses high-risk AI. SDF status must be assigned by the Central Government. Second, the scope of the obligation may be changed through amendments to the Rules, provided those amendments remain within the rule-making authority granted by the Act.
For businesses, the immediate position is straightforward: If an organisation has not been notified as an SDF, Rule 13(3) does not directly apply to it. This remains true even if the organisation uses AI extensively. Other provisions of the DPDP Act and Rules may still apply to its processing, but the specific algorithmic due diligence obligation under Rule 13(3) is limited to SDFs.
2. What The Rule Is Actually Asking You To Do
What Rule 13(3) Actually Requires, Rule 13(3) requires a Significant Data Fiduciary to “observe due diligence to verify” that technical measures, including algorithmic software, are not likely to pose a risk to the rights of Data Principals. Each part of that defintion matters. Read together, the words require an SDF to examine the technology it has adopted, identify how that technology could interfere with rights under the DPDP Act, and retain evidence showing that the identified risks were properly assessed and addressed.
•“Technical Measures Including Algorithmic Software”
Rule 13(3) does not refer directly to artificial intelligence. It refers more broadly to “technical measures including algorithmic software.” Since AI systems operate through algorithms, they fall within this expression. However, the provision is not limited to AI. It also covers other algorithm-based software, including rules-based systems, recommendation engines, profiling tools, automated decision systems and software that automatically stores, modifies, transmits or shares personal data.
The relevant question is therefore not whether the technology qualifies as AI. The question is whether it is an algorithm-based technical measure adopted by the SDF to process personal data and whether its operation could put Data Principal rights at risk.
Rule 13(3) consequently requires the SDF to examine both AI and non-AI software. The SDF must consider what the system does with personal data, what profiles, classifications or inferences it creates, and whether its operation allows rights under Sections 11 to 13 of the DPDP Act to be exercised effectively.
For example, if a lender uses algorithmic software to create a credit-risk profile, the customer should be able to access the relevant personal data, correct or erase it where required, and raise a grievance that the lender can meaningfully investigate. If the source data is corrected but the software continues to use an outdated profile, the technology may make the right of correction ineffective.
The provision is therefore technology-neutral. It covers AI because AI relies on algorithms, but it is deliberately wide enough to include other algorithm-based software that may affect the processing of personal data and the rights of Data Principals. This is an important shift in the way privacy compliance is ordinarily conducted. A conventional review concentrates on the personal data itself: what was collected, why it was collected, whether the processing is permitted, with whom the data is shared and how long it is retained. Rule 13(3) requires the SDF to examine a second layer: what the system does to, with and because of that data.
•“Observe Due Diligence To Verify”
The words “due diligence” and “verify” require the SDF to do more than adopt a policy, complete a checklist or rely on a vendor’s assurance. The SDF must actively examine the algorithmic software and have a reasonable, evidence-based basis for concluding that it is not likely to put Data Principal rights at risk.
“Due diligence” refers to the adequacy of the assessment carried out by the SDF. “Verify” requires that its conclusion be supported by information, testing and documented findings. The extent of this assessment should depend on how the software processes personal data and how seriously its operation could affect Data Principal rights. Software used to recommend content may require less scrutiny than software used to assess creditworthiness, rank job applicants, detect fraud or control access to a financial account.
The responsibility remains with the SDF even where the software is developed, hosted or operated by a third-party vendor. For example, a bank using a vendor’s fraud-detection system cannot treat the vendor’s statement that the system is “accurate” or “legally compliant” as sufficient verification. The bank must obtain enough information to understand how personal data is used, whether relevant data can be accessed or corrected, how disputed alerts can be investigated, and whether the system may interfere with grievance redressal or other rights under the Act.
•“Not Likely To Pose A Risk To The Rights Of Data Principals”
The SDF must assess whether its algorithmic software could prevent or weaken the exercise of rights available to Data Principals under the DPDP Act. The focus is therefore not on the algorithm’s technical accuracy, but on whether the system allows the SDF to meet its legal obligations and give practical effect to those rights.
For example, the system should not make it difficult for a Data Principal to obtain information about the personal data being processed under Section 11. It should allow inaccurate or incomplete personal data to be corrected, and personal data to be erased where required, under Section 12. It should also allow the SDF to trace and investigate an algorithmic outcome when a grievance is raised under Section 13.
Suppose a customer corrects their employment status in a lender’s main database, but the lender’s credit-scoring system continues to use the old information. Although the correction appears in one database, the right under Section 12 has not been made effective across the actual processing system.
1.The risk may also arise where an algorithm:
2.prevents the SDF from identifying the personal data being processed or shared;
3.continues using personal data after it has been corrected or erased;
4.creates profiles or inferences that cannot be linked back to the relevant Data Principal;
5.discloses personal data to an unintended recipient;
6.makes it impossible to investigate a complaint about an algorithmic outcome;
7.or retains personal data when the purpose of processing has ended and retention is no longer necessary.
Rule 13(3) therefore requires the SDF to check whether its technology supports compliance with the Act’s requirements relating to lawful processing, data accuracy, security safeguards, retention, erasure, access and grievance redressal. It does not create new rights against algorithms. It requires the SDF to ensure that the technology it uses does not make existing rights and obligations ineffective in practice.
3. Why This Is Really An AI Governance Rule
Ordinary data protection compliance focuses on the personal data being processed: what is collected, why it is used, where it is stored and with whom it is shared. Rule 13(3) goes one step further. It requires the SDF to examine the technology processing that data and determine whether the way the technology operates could put Data Principal rights at risk.
This means that an algorithm cannot be treated as a neutral tool outside the privacy compliance framework. If software analyses customer behaviour to create a profile, recommends content, classifies individuals for pricing, credit or eligibility, or automatically decides whether personal data should be transmitted or shared, the SDF must assess the software itself. The assessment must consider not only the data entered into the system, but also the profiles, inferences, classifications and decisions produced from that data.
For example, a customer-profiling system may use lawfully collected information but generate an incorrect or outdated profile that the customer cannot access or correct. Similarly, an automated sharing system may disclose accurate personal data to the wrong recipient. In both cases, the risk arises from how the technology processes or acts on the data, rather than from the initial collection of the data. Rule 13(3) does not prohibit profiling, recommendations, segmentation or automated sharing. Nor does it regulate every use of AI. It requires an SDF to understand how its algorithmic software operates, assess whether that operation could interfere with rights under the DPDP Act, and put appropriate safeguards in place.
That is what makes Rule 13(3) an AI governance obligation: it brings the technology itself within the SDF’s privacy accountability framework. The SDF must be able to explain what the system does, how it uses personal data, what risks it creates for Data Principal rights, and how those risks have been assessed and controlled.
4. What This Means For Rights Your Customers Already Have
Access, under Section 11: personal data often moves through several connected systems before reaching an output. If your architecture cannot trace it back, you may struggle to respond properly to an access request.
Correction and erasure, under Section 12: a single wrong data point can shape an output long after the fact, and once data has trained a model, deleting the original record may not remove its influence. You need to know how a correction reaches every system using that data, and whether deleting the source record is enough on its own.
Grievance redressal, under Section 13: a customer can be affected by an automated decision without ever being told an algorithm was involved. Your grievance process needs to trace a complaint back to the system that produced the outcome, not only to the underlying data.
Sections 11 to 14 create the relevant Data Principal rights. Rule 13(3) adds a separate obligation on the SDF to ensure that its technology does not make those rights unworkable.
However, Rule 13(3) does not convert those rights into the equivalent of Article 22 of the GDPR. Article 22 directly protects an individual against certain decisions based solely on automated processing and, in specified cases, provides safeguards such as human intervention and the right to contest the decision. Rule 13(3), by contrast, requires the SDF to understand and control its algorithmic software so that existing DPDP rights remain capable of being exercised. The distinction is important.
Under Article 22, the individual can challenge being subjected to the qualifying automated decision itself. Under the DPDP framework, the Data Principal can seek access to relevant personal data, request its correction or erasure, and raise a grievance concerning the Data Fiduciary’s compliance. Rule 13(3) supports these rights by requiring the SDF to ensure that its technology does not prevent access, continue using corrected or erased data, or make a grievance impossible to investigate. There is therefore some functional overlap between the two provisions, but they operate differently. Article 22 is decision-focused and rights-based. Rule 13(3) is system-focused and obligation-based. Article 22 asks whether the individual should have been subjected to the automated decision. Rule 13(3) asks whether the SDF has exercised sufficient due diligence to ensure that its algorithmic software does not place existing Data Principal rights at risk.
Point of comparison | Rule 13(3), DPDP Rules | Article 22, GDPR |
|---|---|---|
What it does | Asks the Significant Data Fiduciary to check its own technology for risk before and during use | Gives the individual a right not to be subject to certain automated decisions at all |
Who can use it | The SDF polices itself; the Data Principal benefits only indirectly | The data subject invokes it personally and directly |
What triggers it | Any technical measure, "including algorithmic software," used to host, display, upload, modify, publish, transmit, store, update or share personal data | A decision "based solely on automated processing," including profiling, with a legal or similarly significant effect |
The standard applied | Risk-based: is the software "not likely to pose a risk" to Data Principal rights | Rights-based: was the person subjected to a qualifying automated decision at all |
Human intervention | Not mentioned anywhere in the Rule | Expressly guaranteed in the specified cases |
Right to contest the outcome | Not provided | Expressly provided |
Who checks compliance | The SDF itself, through its own due diligence, reviewed later in its DPIA and audit | The individual directly, alongside the supervisory authority |
Reach | Only Significant Data Fiduciaries, a small notified category | Every controller, regardless of size |
Taken together, Rule 13(3) is a genuine obligation, but a narrow one. It forces the largest processors to put their algorithms on the same compliance footing as everything else they do with personal data, instead of leaving AI systems entirely to the engineering team. But your customer has no direct way to invoke it. Unlike a GDPR data subject relying on Article 22, your customer cannot demand human review of a specific decision, or an explanation of how a particular outcome about them was reached. The obligation runs from you to the Data Protection Board, through the DPIA and audit reports Rule 13 already requires, not from you to the individual customer. And the Rule does not say what "due diligence" actually looks like, how thorough it needs to be, or what the Board will treat as sufficient if something goes wrong. Until the Board issues guidance or takes an enforcement action, those judgment calls are, in effect, left to you.