“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:
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.
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.
