The accompanying article appeared in ET today. The article indicates that The government is exploring a “law-to-code” solution, converting legal provisions into automated software rules, to help ensure compliance to privacy and data protection laws against emerging AI-driven cyber threats.
As is normally the case, this could be a media plant from a software company to get endorsement from MeitY for its software.
It is obvious that most companies trying to find a technical solution to implement DPDPA would be exploring AI options of their own. What is however strange in the report is the suggestion that it is the Government which is contemplating the conversion of legal rules into machine-executable algorithms and automatically process and enforce without human intervention.
This is completely against the security view that “Human Oversight” is essential for AI. We are already aware of how AI software hallucinates and creates Court judgements to develop judicial arguments. Now the authors of the article namely Mr Himanshi Lochab and Shubham Chkaraborthy argue that the entire DPDPA implementation can be handed over to an AI without human intervention. This will expose the organization which is a “Fiduciary” to all the risk of mis interpretation that the AI may execute.
It is possible that this article is an example of how “Synthetically Generated AI persona” can be referred to as an “Official”. We would request the publication to clarify the identity of the ghost official/s referred to in the article. Publication should also reveal the circumstances under which the statement was made and reason why the the journalists interpreted that the Government wants to translate the law into a code. Till then, we should treat this article as a PR exercise of the software company.
It is not clear how this response is related to the Anthropic Mythose or other AI threats.
The article says that there is AI threat like “An AI system attempts to access personal data without valid consent,” and this “Law-to-Code” software will automatically block it.
Another “Anonymous” cyber security expert has been quoted as saying “Since AI-powered cyberattacks can now operate at machine speed, governance also needs to be automated and applied at the same speed to counter such challenges”.
Any company can always implement an AI solution for Consent Management which blocks such access but it does not require a Government sponsored “Law-to-code” mechanism. Each company can implement its own solution under its responsibility as a Fiduciary rather than Government taking over the responsibility for interpreting the law and converting it into a software.
This would result in a Software Agent approved by the Government becoming the compliance manager of the data fiduciary and any data breach arising thereafter can be defended as a non punishable Government suggested implementation.
At the level of DPB there will be no authority to punish any company using such a software for any non compliance issue unless fines are imposed on the MeitY itself.
This is unlikely to be accepted by any Court.
More importantly this article would also significantly strengthen the challenge of the DPDPA in the Supreme Court by the PIL lawyers.
It would be a hara-kiri committed by the Government when the entire law is being challenged as “Unconstitutional” since the constitution of DPB itself is improper.
Whoever gave this idea to MeitY must be an agent of the DPDPA opponents. Mr Tushar Mehta should check why such actions are being taken at this point of time which can weaken the Government stand justifying DPDPA.
The article says that one of the officials stated that “We are supporting the industry with DPDP compliance, and we are looking into it”. It also quotes the official and states that this would eliminate the need for lawyers to interpret the law.
This is ridiculous to state the least.
Our own technical assistant expresses the opinion,
“The logic is seductive. AI-powered cyberattacks now operate at machine speed. Therefore, governance must operate at machine speed. Therefore, law must become code.”.. This is funny.
This article examines seven structural weaknesses in the law-to-code proposition as described but not to dismiss it.
Another foolish statement is “A ‘base code’ for legal provisions can ensure that systems are compliant by design without needing an army of lawyers to interpret every technical step.”
We want the publication and the Ghost official and Ghost Cyber security officials quoted in the article to note the following:
1. Legal language is deliberately vague to allow courts flexibility in interpretation. Converting it to deterministic code destroys that flexibility by design.
Legal language is not accidentally ambiguous. It is structurally ambiguous — drafted that way to accommodate the infinite variety of human circumstances that a legislature cannot foresee. The DPDP Act’s provisions are thick with terms like “reasonable security safeguards,” “permissible purposes,” “sensitive personal data,” and “significant data fiduciary.” None of these have a clean algorithmic definition.
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?
def check_retention(data_record, user_consent):
retention_limit = get_permissible_duration(
data_type=data_record.type,
purpose=data_record.purpose,
jurisdiction=data_record.location
)
if data_record.age > retention_limit:
trigger_deletion(data_record)
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.
2. Who Audits the Auditor? The Meta-Accountability Gap
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.
3. We Have Just Created a New Attack Surface
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.
4. Legal Evolution vs. Software Ossification
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.
5. Who Writes the Base Code Writes the Law
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.
6. The Cross-Border Data Problem Has No Algorithmic Solution
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.
7. Speed as a False Virtue: Fast Enforcement Is Not Better Enforcement
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.
