For decades, law has lived mostly in documents.
Policies, contracts, consent forms, compliance checklists, audit trackers, regulatory matrices and legal opinions were all written, reviewed, approved and stored as text. The legal and compliance world was built around documents, signatures, files, folders and human interpretation.
That model worked when business itself moved at the speed of paper, meetings, emails and manual review. But business no longer runs that way. Today, decisions, approvals, data flows, customer interactions, risk assessments and even governance processes happen inside platforms, applications, workflows, cloud systems and AI tools.
That is why the idea of “law-to-code” is becoming important.
Recent reports suggest that the Government of India is exploring ways to convert legal provisions into automated software rules, particularly to strengthen privacy and data protection compliance in the face of AI-driven cyber risks. The idea may sound technical at first, but it points to a much larger shift in how law, compliance, technology and business operations are beginning to intersect.
At its core, law-to-code asks a simple but powerful question: should legal obligations remain only in documents, or should they also operate directly inside the systems where business actually happens?
From Files, Folders and Signatures
When I started my corporate legal career more than two decades ago, legal and compliance work was already going through a transition. Paper was still very much the default, but electronic formats were beginning to enter everyday corporate life.
Policies were printed, signed, filed and stored. Contract clauses were negotiated in long-form documents. Compliance checklists, audit trackers, legal opinions, regulatory matrices and internal approvals all had a heavily document-based existence.
At the same time, organisations were slowly moving these materials into electronic formats. Physical files became PDFs. Manual trackers became Excel sheets. Printed templates became Word documents. Approvals started moving into emails and shared folders.
That was an important shift. It made legal and compliance work easier to store, search, circulate and retrieve. It reduced dependency on physical files and made collaboration faster.
But it did not fundamentally change the nature of compliance.
The documents became digital, but the obligations inside them remained passive. They could record a rule, but they could not enforce it. They could explain an obligation, but they could not make sure the obligation was applied correctly. They could guide human behaviour, but they could not always prevent a mistake before it happened.
In other words, legal and compliance materials became electronic, but they did not become executable.
Electronic, But Not Executable
For many years, this document-led model was workable because business processes were slower, more manual and more dependent on human review. Someone could read a policy, interpret a clause, apply a checklist or escalate a regulatory question. The system depended on people remembering the rule, understanding the rule and applying it correctly at the right moment.
That model still matters. Human judgment remains essential in law and compliance. But the model is becoming harder to sustain as businesses become more digital, more automated and more data-driven.
Today, many compliance failures do not happen because an organisation has no policy. They happen because the policy is not properly reflected in the actual workflow. The document says one thing, but the system allows something else.
A privacy policy may say that consent is required before processing personal data. But if the platform does not check consent before processing starts, the policy remains only a statement of intent. A retention policy may say that data must be deleted after a defined period. But if there is no automated deletion workflow, no review trigger and no access restriction, the rule depends entirely on someone remembering to act. A contract may say that only authorised users can access certain information. But if the system permissions are not configured accordingly, the clause does not protect the data in practice.
This is the gap that law-to-code tries to address.
The Business Has Moved Into the System
Most business activity today does not happen in filing cabinets or policy manuals. It happens inside systems.
Decisions are made through systems. Data moves through systems. Approvals are routed through systems. Customers interact through systems. Employees work through systems. Vendors are onboarded through systems. Financial transactions, HR processes, security reviews, procurement decisions and customer communications are increasingly managed through software.
If the business runs through technology, but the law remains only in documents, there will always be a gap between what the organisation promises and what the organisation actually does.
This is why law-to-code is not just a technical idea. It is a governance idea.
It asks organisations to move from asking, “Do we have a policy?” to ask, “Does the system actually enforce the policy?”
That is a very different question.
So, What Is Law-to-Code?
At its simplest, law-to-code means translating legal and regulatory obligations into machine-readable rules, automated workflows and system-level controls. It is the process of taking a legal requirement and asking a practical question: how should this obligation actually operate inside the technology environment?
Technically speaking, law-to-code can involve translating legal rules into algorithms or software logic that systems can process, apply and enforce. In simple cases, it may look like an if-then rule. If a certain condition exists, the system must take a certain action.
If consent is missing, block processing.
If data retention has expired, trigger deletion or anonymisation.
If a transaction crosses a reporting threshold, generate an alert.
If an employee is not authorised for a certain category of data, deny access.
If an AI use case falls into a restricted category, require additional approval before deployment.
Of course, not every legal rule can be reduced to simple software logic. Law often involves interpretation, context, judgment and proportionality. But many compliance obligations do have operational components that can be translated into workflows, controls, triggers, permissions, alerts and audit trails.
That is where law-to-code becomes powerful.
Privacy Is the Easiest Place to See It
Privacy and data protection are natural examples.
If the law requires valid consent before using personal data for a specific purpose, the organisation should not merely store a consent policy somewhere. The system should check whether valid consent exists before processing begins.
If consent is missing, expired, withdrawn or not broad enough for the intended use, the system should block the action or escalate it for review.
If personal data must be retained only for a defined period, the retention rule should not sit passively in a policy document. It should trigger deletion workflows, access restrictions, review alerts or anonymisation processes when the permitted period is over.
If individuals have rights to access, correction or deletion, the system should be capable of identifying the relevant data, routing the request, tracking timelines and maintaining evidence of completion.
If data is allowed to be used only for a defined purpose, the system should prevent or flag processing that goes beyond that purpose.
This is privacy compliance moving from advice to architecture.
It is no longer enough to say that the organisation respects privacy. The system must be designed to respect privacy.
Not Just a Privacy Story
Law-to-code is not limited to privacy laws.
In financial services, it may apply to KYC checks, AML screening, transaction monitoring, reporting thresholds, customer suitability rules and risk-based approval workflows.
In employment, it may apply to working-hour limits, leave entitlements, payroll calculations, statutory benefits, notice periods, contractor classification controls and mandatory approvals for sensitive employment actions.
In tax, it may apply to GST or VAT logic, invoice requirements, withholding tax triggers, tax residency checks and reporting obligations.
In cybersecurity, it may apply to access controls, incident reporting timelines, logging requirements, vulnerability management, breach escalation protocols and evidence preservation.
In procurement, it may apply to vendor due diligence, sanctions screening, conflict checks, approval thresholds, data protection assessments and mandatory contractual safeguards.
In AI governance, it may apply to model approval workflows, prohibited use cases, human oversight requirements, risk classification, data usage restrictions, explainability requirements, testing obligations and audit trails.
Across all these areas, the underlying shift is the same.
Compliance can no longer be treated only as a documentation exercise. Increasingly, it has to be embedded into the systems where business decisions and data flows actually occur.
Lawyers Do Not Need to Become Engineers
This shift also changes the role of legal and compliance teams.
Lawyers do not need to become software engineers. But we do need to become better at expressing legal obligations in a way that product, engineering, security, data and operations teams can implement.
A legal instruction such as “ensure compliance with applicable privacy law” may be acceptable in a contract or policy, but it is not enough for system design.
Engineering teams need more precise inputs.
What specific rule must the system enforce?
What event should trigger the rule?
What data is needed to apply the rule?
What should happen if the rule fails?
Who can override it?
What approvals are required?
What evidence should be retained?
Can the control be audited later?
These are not purely legal questions, and they are not purely technical questions. They sit at the intersection of law, product design, data architecture, security, operations and governance.
That is why law-to-code requires a different style of collaboration. Legal teams must move from broad legal statements to operational clarity. Technology teams must understand that compliance is not just a post-facto review or a documentation requirement. Business teams must understand that speed without embedded controls can create significant risk.
The real value lies in bringing these teams together early enough, before systems are built and before risks become difficult to correct.
AI Makes the Gap More Visible
The rise of AI makes this even more urgent.
AI systems can process data, generate outputs, identify patterns, make recommendations and influence decisions at a speed and scale that manual compliance processes cannot easily match.
If legal and compliance controls are not built into the operating layer, governance will always be reactive. Organisations will find themselves reviewing outputs after the fact, investigating issues after deployment or trying to retrofit controls into systems that were never designed for them.
That is not sustainable.
AI governance, in particular, needs rules that are capable of operating inside real workflows. If a proposed AI use case involves personal data, the system should trigger a data protection review. If the AI tool is being used in a sensitive decision-making context, the workflow should require human oversight. If a model is approved only for a limited purpose, the system should restrict its use to that purpose. If certain data cannot be used for training, that restriction should be reflected in the data pipeline.
In this sense, law-to-code may become one of the practical foundations of AI governance.
It helps convert high-level principles such as fairness, accountability, transparency, privacy and human oversight into more concrete controls.
But Not Every Rule Can Become an If-Then Statement
At the same time, law-to-code must be approached carefully. Legal rules are not always binary. They often involve context, exceptions, proportionality, reasonableness and human judgment.
A system may be able to automate a consent check or a retention trigger, but it may not be able to determine fairness, necessity or legal risk in every situation. A platform may be able to block unauthorized access, but it may not be able to decide whether a particular business decision is reasonable in all circumstances. A workflow may be able to flag a high-risk AI use case, but the final judgment may still require legal, ethical, technical and business review. So the objective should not be to replace lawyers or compliance professionals with software.
The better objective is to automate what can be safely automated, standardise what can be standardised and preserve human judgment where interpretation is required. That distinction is important.
Law-to-code is not the end of legal judgment. It is the operationalisation of legal judgment. It helps ensure that the parts of law that can be translated into controls are actually implemented in the systems that run the business, while leaving room for human review where the law requires interpretation.
The New Governance Question
For organisations, this will become a serious governance question.
It will no longer be enough to ask whether there is a policy. The more important question will be whether the policy is reflected in the system.
Does the platform enforce the rule?
Does the workflow capture the approval?
Does the data architecture respect the limitation?
Does the access control reflect the contractual obligation?
Does the audit trail prove compliance?
Does the system prevent avoidable violations before they happen?
These questions will matter not only for legal teams, but also for boards, management teams, product leaders, technology leaders, risk teams, security teams and regulators.
The organisations that manage this well will not treat compliance as a layer added at the end. They will design compliance into the operating model.
That is the real shift.
From Beautiful Policies to Working Controls
Looking back, the journey from paper to electronic documents was an important step. But it was only a partial transformation.
The next phase is different.
It is not just about digitising legal and compliance content. It is about making legal and compliance obligations operational, testable and auditable inside the systems that run the business.
The future of compliance will be less about beautifully drafted policies sitting on intranet pages, and more about reliable controls embedded into daily operations.
This does not mean that documents will disappear. Contracts, policies, legal opinions and governance frameworks will continue to matter. But documents alone will not be enough.
The real test will be whether those documents can influence how systems behave.
Can the policy become a workflow?
Can the obligation become a control?
Can the approval requirement become a system trigger?
Can the audit requirement become an evidence trail?
Can the legal rule become part of the architecture?
That is the promise of law-to-code. Not law becoming less human. But law becoming more operational, more scalable and more capable of keeping pace with the software-driven world in which businesses now operate.
(Views are personal)
