MeitY has proposed to issue an AI software for compliance of DPDPA.
Details have been discussed in the earlier article
Listen to these views also
This issue needs a National Debate.
P.S: The podcasts have been generated using NotebookLM. There could be minor errors. The basic information is available in the post
Naavi
Consider the seemingly simple rule that personal data should not be retained beyond a “permissible duration.” To encode this, a programmer must answer: permissible according to whom? In what context? For which category of data? Determined at what point in time? Can the period be extended? Under what circumstances?
# Attempt to encode DPDP retention rule
def check_retention(data_record, user_consent):
retention_limit = get_permissible_duration(
data_type=data_record.type, # What taxonomy?
purpose=data_record.purpose, # Who verifies purpose?
jurisdiction=data_record.location # Data crosses borders
)
if data_record.age > retention_limit:
trigger_deletion(data_record) # Deletion of what, exactly?
# What about backups? Logs? Analytics caches?
# What about data lawfully held for litigation?
# What about legitimate research exceptions?
Every one of those marked terms requires a human judgment call or an entire secondary legal framework to resolve it. The EU’s GDPR has been in force since 2018 and legal teams still regularly disagree on what “legitimate interest” means. Code cannot resolve what jurisprudence has not.
The law-to-code proposition assumes a clean mapping between legal text and logical conditions. It is not clear that mapping exists for a rights-based statute, as the ET Insight callout itself concedes, acknowledging that law-to-code has never been applied to abstract, rights-based laws that carry hefty punitive consequences.
If the code is wrong, everything downstream is wrong — automatically, at scale, without any human noticing until the damage is done. This is the meta-accountability gap: the system that enforces compliance has no independent compliance check of its own.
Under current frameworks, a compliance failure is visible as a human decision that can be traced, audited, and contested. Under law-to-code, a compliance failure is an algorithm producing the wrong output across millions of transactions simultaneously. It may not surface until it has caused widespread harm and the question of who is legally liable for a mis-encoded legal rule does not have a clean answer in any jurisdiction.
The article frames law-to-code as eliminating the need for an “army of lawyers.” But armies of lawyers exist, in part, to catch each other’s errors and to present divergent interpretations before a judge. Remove that human adversarial layer and you remove the primary error-correction mechanism in the legal system.
India’s DPDP Act specifies penalties up to ₹250 crore per violation. If an enterprise’s automated compliance system incorrectly classifies data and causes millions of accidental violations — was that the enterprise’s fault? MeitY’s fault for producing a flawed base code? The software vendor’s fault? This is not a theoretical question. It is the first serious legal dispute that will follow implementation.
The article cites Anthropic’s Mythos as the threat model justifying law-to-code. Models like Mythos, it notes, can identify security flaws and system loopholes that decades of human expertise may have failed to detect.
Now consider: if the compliance system that enforces the DPDP Act is itself a software system — with a code architecture, edge cases, and logical gaps, then the same class of AI that motivated the system’s creation can be used to attack it. A sophisticated adversary does not need to beat human lawyers. They only need to find the conditions under which the compliance code produces a false positive, a false negative, or an exploitable exception.
Law-to-code does not eliminate the attack surface. It relocates it from legal ambiguity to software vulnerability a domain where attacks are faster, cheaper, and far more scalable. We have not solved the problem. We have re-encoded it in a more brittle medium.
This is not a hypothetical concern. Tax compliance software has been exploited. Financial risk models have been gamed. Fraud detection systems have been adversarially probed for their decision boundaries. There is no reason to expect a data-protection enforcement system to be immune especially once it is well understood, publicly described, and operating at scale.
Law is designed to evolve. Court judgments reinterpret statutes. Parliamentary amendments update provisions. Regulatory guidance shifts what “compliance” means in practice. A statute that was enacted in 2023 will mean something subtly different in 2028 not because the text changed, but because the courts and regulators have refined its application.
Code does not evolve this way. A rule encoded in software in 2024 enforces the 2024 interpretation of the law, indefinitely, unless someone explicitly patches it. The history of legacy software in government and finance is a history of systems encoding outdated assumptions long after the underlying reality changed because updating them is expensive, risky, and easily deprioritized.
| Dimension | Legal system | Encoded compliance system |
|---|---|---|
| Adapts to new court interpretations | Yes — through precedent | No — requires software update |
| Handles genuinely novel circumstances | Yes — judges reason by analogy | No — undefined cases produce errors |
| Accounts for context and intent | Yes — central to legal reasoning | No — only evaluates defined conditions |
| Can be contested and appealed | Yes — adversarial process built in | Unclear — who do you sue when the algorithm is wrong? |
| Reflects evolving social norms | Yes — through legislative amendments | Only with costly re-engineering cycles |
A rapidly evolving regulatory environment, which India’s data protection landscape demonstrably is, may be precisely the wrong context in which to embed compliance in brittle, slow-to-update software systems.
The ET Insight callout describes a “base code” for legal provisions. It does not describe who writes that base code, who reviews it, who has the authority to update it, or what democratic accountability mechanism governs it. This omission is not a detail. It is the entire political economy of the proposal.
If MeitY writes the base code, it becomes the de facto interpreter of the DPDP Act- not the legislature that passed it, and not the courts that are constitutionally empowered to interpret it.
This is a meaningful concentration of state power dressed in the neutral language of technical infrastructure. The appearance of algorithmic objectivity “the system decided, not the ministry”, is precisely what makes it politically durable and democratically problematic. Regulators in any jurisdiction tend to encode their preferred interpretation of ambiguous provisions. With law-to-code, that interpretation becomes infrastructure.
Every discretionary decision that is currently made by a human legal officer subject to appeal, review, and political accountability, becomes, under law-to-code, an automatic output of software. The software is not neutral. It encodes the choices of whoever wrote it. Those choices are made less visible, less contestable, and less subject to oversight precisely because they are wrapped in the authority of automation. The phrase “the algorithm flagged this” tends to end conversations that “the regulator decided this” would have continued.
The DPDP Act governs the processing of personal data of Indian residents. But data does not respect national borders. Data flows through servers in multiple jurisdictions, processed by multinational cloud providers, accessed by global teams, subject to conflicting legal obligations in different countries simultaneously.
A compliance rule that says “block access to personal data without consent” encounters immediate problems when the access request originates from a US-based engineer maintaining a global system, the data sits on a Singapore server, the Indian user’s consent was obtained under a privacy policy drafted for GDPR compliance, and the company’s legal obligations under US national security law may conflict with its obligations under the DPDP Act.
No single codebase can encode all of these obligations simultaneously without producing contradictions. Jurisdictional conflicts in data law are not edge cases they are the normal operating condition for any global digital service. Law-to-code, applied unilaterally, does not resolve these conflicts. It selects one jurisdiction’s interpretation by default and pretends the others do not exist.
The article’s central argument is speed: AI attacks operate at machine speed, therefore governance must too. This is intuitive but not obviously correct. Speed is a virtue in some parts of a governance system. It is a liability in others.
Fast enforcement of a correct rule is indeed better than slow enforcement. But fast enforcement of a wrong rule is categorically worse than slow enforcement of that same wrong rule — because the harm scales with the speed of execution. Automated blocking of data access that is actually legitimate; automated triggering of deletion workflows on data that is lawfully held; automated penalties on enterprises for violations the algorithm misclassified — all of these outcomes are not just possible, they are mathematically certain at scale. No complex system achieves zero error rates.
The relevant comparison is not “fast automated enforcement vs. no enforcement.” It is “fast automated enforcement with some error rate vs. slower human-in-the-loop enforcement with a different error rate.” For a statute carrying penalties of up to ₹250 crore, the cost of false positives may exceed the benefit of catching additional true positives. That calculation has not been made publicly.
There is also a more subtle problem: speed changes behavior. A compliance regime that can block your data operations in real time, automatically, without human review, creates a chilling effect on legitimate data activities. Researchers, journalists, healthcare providers, and public interest organizations operating at the margins of “permissible purpose” may find themselves systematically blocked by a system that cannot understand context and may not bother appealing a decision that arrives as an automated rejection rather than a human ruling.
None of the above weaknesses invalidate the underlying ambition. The DPDP Act does need to be enforced at a scale and speed that purely manual compliance processes cannot achieve. AI-driven threats do operate faster than human compliance teams can respond. India does have a genuine opportunity to pioneer a new model of data governance that the rest of the world would study and potentially adopt.
But the specific framing of “law to code” as presented a base code that converts legal provisions into automated software rules conflates two distinct things: automated compliance tooling (genuinely useful, widely deployed, technically tractable) and automated legal interpretation (genuinely novel, poorly understood, constitutionally fraught).
The former tools that automate the operationalization of already-interpreted compliance requirements — is valuable and achievable. The latter software that determines, without human review, whether a legal obligation has been violated is where the seven weaknesses above live.
A more defensible architecture might look like: machine-speed monitoring and alerting, with human-in-the-loop decision authority for consequential enforcement actions. AI that flags probable violations for human review, not AI that issues automatic penalties. A publicly auditable, versioned base code governed by a multi-stakeholder body, not a ministry’s internal engineering team. And explicit statutory acknowledgment that the code is not the law — that it is an interpretive tool subject to the same contestability as any other regulatory guidance.
The suggestion as presented is a typical “Aloo this side-Gold other side” logic. We request a national debate on this suggestion.
The Regulatory recognition available to DPO as a custodian of the trust of Data Principals supported by the role of the Independent Data Auditors who are assigned the role of being the eyes and ears of the DPB has placed a question mark on the future role of CISO in an organization Vis-a-Vis the DPO.
CISO is today the custodian of data in a company which includes both Personal Data and Non Personal Data. The regulatory statute for data has been the ITA 2000. The regulatory body is the CERT In. When a Data Breach happens, the notification is required to be made to the CERT IN and if there is any individual who has suffered a loss, he may seek compensation from the Adjudicator.
With the advent of DPDPA, the DPO assumes charge as the custodian of Personal Data and Data Protection Board assumes charge of the adjudicator. Personal Data Breach notification will go to DPB. The DPO is expected to report to the Board.
The role of DPO is a little ambiguous as per the law.
The DPDPA states that the DPO “represent the Significant Data Fiduciary under the provisions of this Act” but for what purpose is not clear. He will be an individual responsible to the Board of Directors or similar governing body of the Significant Data Fiduciary. Again what what responsibility is not clear.
What is clear is that he will be based in India and will be the point of contact for the grievance redressal mechanism under the provisions of this Act. The rules donot go beyond the need to provide the business contact.
However, under DGPSI, the role of the DPO is identified as
“A Person who is an employee and is responsible for the implementation of technical and organizational measures for compliance and also representing the organization with the outside world including being responsible to answer the queries of any data principal.”
If we adopt this definition, DPO will be the custodian of personal data in the organisation which includes the employees and outsiders.
Thus an organization will have two custodians of data, the CISO and the DPO. The management has to therefore clearly identify their roles so that there is harmony in their functioning.
If DPO is mandated by law to report to the Board and CISO is not, then it appears that DPO will have a status higher than that of the CISO.
On the functional side it appears that the Information security threats are the consequences of the Privacy threats. In other words, the risk of identity theft of employees and the customers lead to risks of cyber attacks and there after losses that ITA 2000 tries to address.
Hence protection of Personal Data is condition precedent to protection of non personal data.
This could indicate that DPO role is more fundamental than that of CISO.
In the era of AI and Synthetic Identity threats protection of personal data of employees and preventing frauds by fake AI generated persona is part of the responsibility of the DPO. These could be high end technical issues which a DPO may not find it easy to digest.
In this scenario, the need for DPO and CISO to work in unison becomes critical.
While some organizations may try to avoid conflict by designating the CISO himself as the DPO this appears to be incorrect since DPO is a Fiduciary of a Fiduciary and is responsible to the Data Principals also while a CISO is an internal soldier to protect the organisation. They have to be considered distinct. There will be conflict in their purpose and end objective.
Hence the management needs to resolve this issue to ensure that the two senior executives function in harmony. DGPSI system where both report to the Governance Committee headed by an Independent Director is a step that creates equality of status of the two senior executives.
Are there better ways of organizational structure?… Comments are welcome.
Naavi
Association of Independent Data Auditors of India is conducting an introductory webinar on “Emergence of Independent Data Auditor” profession in India.
Interested persons may attend the webinar on 23rd May 2026 at 11AM.
The Registration link is available here:
https://us02web.zoom.us/j/88286391275?pwd=wrP6fgGrCWTOVPv9p53RFvo22JgeJo.1
A request circulated by the Secretary AIDAI is reproduced below for your information.
Naavi
Dear Professional Friends,
We are delighted to inform you that the ASSOCIATION OF INDEPENDENT DATA AUDITORS OF INDIA (AIDAI), was established in April 2026 as a pioneering new vertical of FOUNDATION OF DATA PROTECTION PROFESSIONALS IN INDIA (FDPPI).
This initiative marks a significant milestone in India’s evolving data protection and digital governance landscape, arriving at a time when organisations across sectors are preparing to align themselves with the transformative framework introduced under the Digital Personal Data Protection (DPDP) Regime.
AIDAI has been conceived as a forward-looking professional platform dedicated to building a credible ecosystem of INDEPENDENT DATA AUDITORS (IDA) capable of supporting organisations in achieving robust privacy and compliance standards. The platform creates a unique and timely professional pathway for experienced CAs, ICMAs, CS, Legal, GST practitioners and similarly placed professionals, and Governance practitioners, presently in auditing field, to expand their expertise into the rapidly emerging domain of Data Protection Auditing and Privacy Compliance Services. For more information, please listen to YouTube presentations @
https://www.youtube.com/watch?v=_p2JWVG47Qk and
https://www.youtube.com/watch?v=B4MF_RdCAX4&t=390s
As you are aware FDPPI is a Section 8 non-profit organisation driven by a nationwide network of distinguished Data Protection and Privacy professionals under the able leadership of Vijayashankar Nagaraja Rao, popularly known as Naavi, a pioneer in the field of Cyber Laws in India. With a vibrant membership base of over 500 professionals across India, FDPPI has consistently worked towards promoting awareness, capacity building, professional excellence, and responsible data governance practices in the country.
Now AIDAI aims to expand privacy-compliance services by formally empanelling qualified professionals to perform DATA PROTECTION AUDITS, ASSESSMENTS, AND ADVISORY SERVICES for businesses seeking compliance under DPDPA 2023, DPDP Rules 2025, and related frameworks. Here are 3 different Empanelment categories of IDA’s and their benefits
1) Probationary Independent Data Auditor (PIDA): Rs3540/- inclusive of GST
Empanelment of Probationary Independent Data Auditors is open to all interested persons to take up Data Auditing.
Benefits: Mentored placement with experienced auditors, discounted training and practice labs, access to sample audit materials, and a pathway to AIDA upon meeting experience and training milestones.
2) Accredited Independent Data Auditor (AIDA): Rs7080/- inclusive of GST
Empanelment of Accredited Independent Auditors is restricted to those who hold relevant certifications in Privacy or Information Security or Law or Chartered Accountancy, or Cost Accountancy or Company Secretary or other approved certifications. (Check for clarification if required). Necessary evidence needs to be provided for confirmation.
Benefits: Inclusion in AIDAI directory, eligibility for Sectorial-focused audit projects, access to audit templates and checklists, discounted FDPPI resources and webinars, and referral support for client engagements.
3) Certified Independent Data Auditor (CIDA) : Rs11800/- inclusive of GST
Empanelment of Certified Independent Data Auditors is restricted to those who have passed the CIDA examination of FDPPI.
Benefits: Priority listing for large-scale audit assignments, eligibility to lead multi-auditor engagements, FDPPI endorsement for client proposals, continuing professional development credits, and preferential rates on FDPPI training and certification renewals.
Welcome to Introductory Free Webinar: Saturday, 23rd May 2026 @ 11:00AM to introduce AIDAI, explain the empanelment process, and answer your questions, we are organizing a webinar on Saturday, 23rd May 2026 @ 11:00AM.
The session will cover empanelment criteria, application process, code of conduct, empanelment workflow, and commercial terms. There will be a live Q&A to address role-specific queries for Legal and GST professionals.
Please register to join the webinar using the Zoom link below:
https://us02web.zoom.us/j/88286391275?pwd=wrP6fgGrCWTOVPv9p53RFvo22JgeJo.1
Meeting ID: 882 8639 1275
Passcode: 700473
Time: Saturday, 23rd May 2026 @ 11:00AM
We believe AIDAI will create meaningful professional opportunities and help expand high-quality data protection audit capacity, especially for MSMEs that need practical, affordable compliance support. We look forward to your participation and questions during the webinar.
Warm regards,
Srivatsa. R
Chapter Representative, FDPPI / AIDAI
secretary@aidai.org.in
For more details visit https://aidai.org.in and https://fdppi.in;
In February 2025, we had introduced the concept of “Super Data Fiduciary” as part of our discussions on DPDPA Compliance for Hotels who work under a Brand Franchise basis. Examples of this category were the Oyo, Treebo, Airbnb or even the Hotel brands like Hilton, Taj, Hyatt, Radisson or Hospital Brands like Apollo or Manipal, Fortis or Kims, or Wockhart etc.
The law clearly recognizes only two types of entities under DPDPA namely the Data Fiduciaries and Data Processors.
(Under ITA 2000, there are two types of entities namely “Intermediaries” and “Data Consumers”. A “Data Consumer” under ITA 2000 such as say is always a Data Fiduciary. An “Intermediary” under ITA 2000 can be a Data Processor or a Data Fiduciary depending on the functions.)
We can however derive a category of Data Fiduciaries as “Joint Data Fiduciaries” if the purpose and means of use of personal data is shared between two different entities. The data fiduciary which collects the data for a specified purpose is the main data fiduciary and another entity which may determine the means of finance will be the Joint Data Fiduciary. The question of sharing of “Purpose” does not arise since collection is purpose based and who ever declares the purpose and collects the data becomes the Data Fiduciary and the second person who processes the data is always the Data Processor or a Joint Data Fiduciary.
Now all instances of Business relationships related to DPDPA cannot be classified as an activity between a Data Fiduciary, Joint Data Fiduciary and a Data processor. The umbrella Brand owner may have only licensed the use of the brand name but is not directly involved in the collection of personal data. But a data principal who approaches say Atria may be seeing Atria Hotel as part of the Radisson Blue brand. His relationship is dependent on the brand image of Radisson rather than Atria. Most Franchisee may in order to protect their own reputation may also impose policies and procedures on their affiliates and even have a “Data Sharing” mandate.
In such cases the conflict is whether the data principal wants to share his data with Radisson brand or Atria Brand? Who is the Data Fiduciary in the minds of the data principal? If the data principal tomorrow raises a legal claim on Radisson for any negligence of Atria, what is the legal liability?. These are difficult questions to answer.
It is in this context that we introduced the concept of a “Super Data Fiduciary” who stands at the top of the Fiduciary pyramid on perception basis, under which an operational data fiduciary collects personal data of the data principal, processes it himself or through other Joint data fiduciaries, Data Processors etc.
Now a similar concept appears to be essential for developing the DGPSI system for the Educational Sector where the University remains at the top . Below the university are the Colleges. Colleges have their own autonomous departments both for teaching, examination, Research, Library maintenance, Sports Maintenance etc.
Personal Data is actually originated at the College level where admissions happen. (The CET system may be an exception where the admissions are allocated by the CET authority to a specific college.)
Colleges provide the education, conduct examinations and the examination authority declares the results under the banner of the University. Colleges consume the information as given and record it as part of the student records.
Thus there may be different “Data Generators” within the Education system who are the first data fiduciaries for the given purpose. Others become joint data fiduciaries or Data Processors. The University however remains the Super Data Fiduciary where every thing is done under their name but executed by other autonomous delegated departments.
Conceptually each of the delegated departments should be considered as “Data Fiduciaries” and the university should be a “Super Data Fiduciary”.
For the purpose of DGPSI, we may need to adopt a precise definition of the Super Data Fiduciary as a jurisprudential thought and we adopt the following definition.
“A Super Data Fiduciary is an entity which, though not necessarily the primary collector or operational processor of personal data, exercises overarching reputational, governance, policy, economic or ecosystem control over subordinate Data Fiduciaries operating under a common brand, institutional framework or delegated authority.”
Points to ponder:
1.The liabilities of the Super Data Fiduciary under DPDPA is not defined and hence DGPSI need to deefine the responsibilities.
2. a)The University often comes under the direct governance of a State Government and could be a claimant for the status of “Instrumentality of State” and the associated exemptions. But should this privileged status is to be given to the Colleges? is a moot question.
b) Does the current interpretations of the “Instrumentalities of State” given out in various Supreme Court decisions in the context of the status of employment of different persons can also be applied to the Data Processing environment? is another moot point to be clarified.
Let us discuss these in another article in our bid to to explore the DGPSI-Education framework.
Naavi
