Two ways to put law in code

In 2020 Oxford University Press published, in open access, a 341-page textbook by Mireille Hildebrandt — Research Professor on Interfacing Law and Technology at Vrije Universiteit Brussels and, at the time of the book’s drafting, holder of an ERC Advanced Grant for a project called “Counting as a Human Being in the Era of Computational Law.” The book was titled Law for Computer Scientists and Other Folk and was written, by Hildebrandt’s own account, after eight years of teaching law to master’s students at Radboud University’s institute of Computing and Information Sciences. It reads as a textbook. It is also something else: a sustained argument that modern legal protection is an affordance of printed text, that the move into a code- and data-driven environment puts that affordance under strain, and that there are exactly two routes through the strain — one of which preserves the protection and one of which destroys it while purporting to enforce it. The distinction Hildebrandt draws between legal by design and legal protection by design is the operative analytical contribution of the book, and it is the part most directly relevant to anyone working on regulatory comparison between the European Union and the United States.

Why by-design is not one thing

The phrase has slid into regulatory English as if it referred to a single technique. Hildebrandt’s first move is to insist that it refers to two, and that the difference between them is the difference between a system that protects and a system that disciplines.

The vocabulary of “by design” entered European data-protection law through Article 25 of the General Data Protection Regulation, which requires controllers to implement appropriate technical and organisational measures designed to give effect to data-protection principles. It has since multiplied. The EU AI Act now obliges providers of high-risk systems to build human oversight into the design of those systems under Article 14.1 Privacy by design, security by design, ethics by design, fairness by design, value-sensitive design — the phrase has detached from its original technical referent and become a regulatory mood. Almost nothing prevents it from meaning whatever the speaker would like.

Hildebrandt’s claim is that the loose usage obscures a real and consequential distinction. The fastest way to grasp it is with a concrete example.

Imagine a system that automatically decides whether a person receives a welfare benefit. One way to “embed the law” in that system would be to translate the rule into executable code — grant if income is below X and age above Y — and let the code run. Its controls close the alternatives before the case arises. Hildebrandt calls this version legal by design (LbD): the use of code to enforce ex ante — before the system acts — compliance with the norm.

There is another way. It does not try to make the system enforce the rule; it tries to make the system leave standing whatever it is that makes a rule protective. Concretely: that the person can ask why the benefit was denied and receive a reasoned answer; that they can contest that decision before someone who reviews it; that a “correct” automated calculation cannot override a fundamental right that the rule, at its edges, was meant to protect. Hildebrandt calls this second version legal protection by design (LPbD).

Three conditions are what LPbD preserves. Contestability — the practical possibility of bringing a decision before a forum that reviews it. Due process — the procedural guarantees that surround any consequential decision (being heard, knowing the reasons, having time to respond). And the substance of fundamental rights, which is distinct from their form: a system can formally comply with a right — having asked for consent, having informed the user — without respecting what the right was actually protecting.

The two versions are best understood reformulated as two distinct questions. LbD asks: how do I make the system comply with the rule?. LPbD asks: how do I make the system leave standing the things that make the rule protect?. They are structurally different questions, even though both dress themselves in the same formula. Confusing them is exactly what the entire book is trying to dismantle.

Before moving on, consider a case. If a system perfectly complies with its technical specification, but the affected person cannot understand why anything was denied to them and does not know whom to complain to, is it operating under LbD or under LPbD? The quick intuition is not always correct. We will return to this question when examining NIST’s AI RMF in the coda.

With the distinction installed, the two versions are recognised quickly in practice. The paradigm of LbD is smart contracts on distributed ledger technology (DLT): the contract is written, conditions trigger execution, execution happens, and the question of compliance dissolves into the question of whether the code ran. The paradigms of LPbD are Articles 22, 25, and 35 of the GDPR — legal obligations that require building systems in which the protections of data-protection law remain operative, not systems that are the law in some literalised form.

The difference matters in practice for at least two reasons. First, LbD claims a guarantee it cannot deliver: legal norms, written in natural language, are irreducibly multi-interpretable, and any code that purports to enforce them has had to pick one interpretation. Hildebrandt’s specific example is the contractual obligation to perform a task “within a reasonable time.” There is no algorithm for reasonableness; reasonableness is what courts decide, ex post, in the light of the case at hand. A smart contract that hard-codes reasonableness as some specific number of hours has not enforced the contract; it has substituted a different contract, less protective and less responsive to circumstance. Second, LbD displaces the institutional architecture that gives law its protective force in the first place: the courts that interpret the rule, the legislatures that decide its scope, the publics that contest its application. Once the code runs, there is nothing left to argue with.

Law in bookspace, law in cyberspace

The distinction makes sense only against the larger argument the book begins with — that legal protection as we know it is the product of a specific information and communication infrastructure, and that the infrastructure is changing.

The first chapter of Law for Computer Scientists presents a thesis about the relationship between law and what Hildebrandt calls information and communication infrastructures (ICIs). She distinguishes four: speakerspace (oral cultures), manuscriptspace (the handwritten text), bookspace (the printing press), and what she terms the “onlife world” — the emerging hyperconnected environment in which the difference between online and offline is dissolving and computational systems anticipate and act on human behaviour in real time.2 Each ICI affords a different kind of normativity. Oral cultures live by unwritten expectations and the memory of the group; manuscriptspace, by handwritten records subject to scribal variation; bookspace, by the elaborate hierarchies of codified law, treatises, and case law that the printing press made it economically possible to produce; the onlife world, by something not yet stabilised.

We arrive at the heart of the book: a strong thesis about where the protective character of modern law comes from. Hildebrandt puts it like this: modern positive law — the law of legislatures, courts, and constitutional democracy — is an affordance of bookspace.

The formulation is deliberately material. She does not say “inspired by” the book. She says affordance: something the printing press made possible, and that without the printing press would not exist as we know it. It is a strong thesis, and worth examining carefully. Hildebrandt rests it on three interconnected features of printed text.

First feature: stability plus ambiguity. A printed text is fixed. It survives its author; later generations can read it. But the fixing of the text does not resolve its meaning: natural language is structurally ambiguous, and no formulation is self-applying. If the point is not immediately obvious, consider Hart’s classic case. A statute says “no vehicle in the park.” Does that include a bicycle? A toy tricycle? An ambulance entering to handle an emergency? The text is fixed. The scope is not. And it cannot be.

Second feature: the practice it generates. The combination of stability and ambiguity forces a specific practice: the iterant interpretation of the same text by successive readers. Gloss on gloss. Case law on case law. It is worth resisting the temptation to see this as an accidental by-product — it is, in fact, what makes the printed law work as protection and not just as command. Without the practice, the text would be instruction; with it, it is law.

Third feature: the institutional architecture. The interpretive practice required, in order to institutionalise itself, a specific figure — an independent judiciary. The key question is why independent. The alternative clarifies. If those interpreting the rule are the same sovereign who issued it, there is no interpretation against the sovereign. And without interpretation against the sovereign, there is no protection from the sovereign. Over centuries, the judiciary distanced itself from the author of the norm, until it acquired the legitimacy to do exactly what it had once been forbidden to do: interpret the law against the one who had issued it.

Before moving on, try to articulate the thesis in your own words. Why, according to Hildebrandt, can the protective character of modern law not be separated from the technology that supports it? If the answer that comes to you sounds like “because the printing press made things easier”, it is worth re-reading the third feature with the question in mind. The thesis is stronger than that. The printing press did not facilitate protection — it made it possible. And that means a change of infrastructure can undo it.

The protective character of modern law, on this account, is not separable from any of these conditions. It comes from the fact that the rule is fixed in text and yet not closed in meaning; from the fact that the meaning can be contested; from the fact that the contestation is heard by an institution structurally distinct from the rule’s author. None of these features is automatic. Each is the achievement of a specific historical-technical infrastructure.

What happens when the ICI changes is the question the rest of the book is occupied with. Hildebrandt is careful not to argue that the move into computational systems is inherently destructive of legal protection. The argument is harder than that. Computational systems can be made to support legal protection, on two conditions: that the people building them understand what legal protection is, and that the protections of law are explicitly embedded in their architecture — not as an ethical afterthought, not as a compliance overlay, but as part of the design. The book is, on this reading, a long argument that the design choices are non-trivial and that getting them wrong looks indistinguishable, from the outside, from getting them right.

What text-driven law does

Hildebrandt’s preferred answer to “what is law?” is “what does it do?” The answer, on her account, is three things at once — and the protection it provides comes from the unresolved tension between them.

The book is structured around Gustav Radbruch’s mid-twentieth-century definition of law in terms of three constitutive values: legal certainty, justice, and the instrumentality of law as a means to the goals set by the legislature.3 Legal certainty is the foreseeability and stability of the rule; justice is the requirement that similar cases be treated similarly and that just desert correspond to what elicits it; instrumentality is the orientation of law toward the policy aims its democratic process has chosen. The three values are partly overlapping and often incompatible. A foreseeable decision may be unfair; a fair decision may be unforeseeable; the instrumentality of the law may pull against either or both.

Hildebrandt’s argument is that this irreducible tension is not a defect in modern law but the source of its protective character. Because the three values cannot be resolved at an abstract level, every legal decision has to justify itself as striving to serve all three at once. The justification is what makes the decision contestable. The contestability is what gives the person on the receiving end of the decision a procedural relationship to it. The procedural relationship is what distinguishes legal protection from mere instruction. A decision that simply happens, without a justification a court could later examine, is not a legal decision in the modern sense. It is something else.

The implication for computational systems is the operative one. A system that takes consequential decisions about people — that grants or denies credit, that selects or rejects job applicants, that flags or releases people from detention — is doing the work that legal decision-making does, in the sense that it determines outcomes of legal significance. If the system cannot articulate a justification, in a form that the affected person can challenge before an institution structurally distinct from the system’s operator, the protection that modern law provides has not survived the move into code. The system may be efficient. It may be accurate on whatever metric its designers chose. It is not under the rule of law.

This is the argument that runs underneath the GDPR’s Article 22, which Hildebrandt treats as the most direct legal response to the problem. Article 22 establishes a default prohibition on decisions “based solely on automated processing, including profiling” that produce legal or similarly significant effects. The exceptions — contractual necessity, statutory authorisation, explicit consent — come with mandatory safeguards: the right to human intervention, the right to express a point of view, and the right to contest the decision.4 The architecture of the provision is not an accident. It is the architecture of bookspace law, translated into a setting where the immediate decision-maker is not a person but a system.

Legal by design overstates its reach

The first sustained example is contract law. Hildebrandt’s choice of example is itself an argument: she picks the case in which “legal by design” looks easiest, in order to show that even there it fails.

A smart contract on a distributed ledger is, in its idealised form, a set of clauses translated into code that executes when specified conditions are met. The promise the technology makes — articulated repeatedly by its proponents in the second half of the 2010s — is that contractual performance becomes self-enforcing, trustless, and immune from ex post manipulation. The party owed performance does not need to sue. The party owing performance cannot refuse. The code runs.

The example Hildebrandt works through is a smart contract between an employer and an employee for the transport of goods between two points “within a reasonable time.” The off-chain performance of the contract — the actual driving — requires what the technology calls an “oracle,” a software interface that reports back on whether the contractual condition has been met. The oracle needs an unambiguous trigger. “Reasonable” is not an unambiguous trigger. To make the contract self-executing, someone has to specify what counts as reasonable in advance: a number of hours, a deviation tolerance, a definition of acceptable cause for delay. The act of specification is an act of interpretation. The interpretation has been removed from the domain of contract law, where reasonableness is a contested concept whose application depends on the circumstances of the case, and relocated to the domain of code, where it is one fixed number.

This is not a failure of implementation. It is a structural property of any attempt to translate a multi-interpretable legal norm into executable code. The translation requires the selection of a single interpretation, and once the interpretation is fixed in code it is no longer responsive to the contextual considerations that gave the original norm its protective reach. The smart contract has not enforced the legal obligation. It has substituted a different obligation, more rigid and less protective, and has done so without the institutional checks — democratic deliberation about scope, judicial interpretation about application — that would otherwise discipline the substitution.

LbD seems to be an inept term for what is actually achieved. As long as this is kept in mind, incorporating checks and balances, smart contracts and smart regulation may nevertheless contribute to compliance.

— Hildebrandt

Hildebrandt’s verdict is calibrated. She does not say that smart contracts have no place. She says that calling them “legal compliance by design” overstates what they can do. As long as the checks and balances — including the legal remedies that allow the underlying contract to be contested in a court — are preserved, the technology can contribute to compliance. It cannot replace the institutional architecture that defines what compliance with a legal obligation means in the first place.

The same argument extends to “smart regulation”: the use of distributed ledger systems to self-execute regulatory policies. The conflation is more dangerous here than in private contract. Where smart contracts at least operate between identified parties who have notionally consented to the substitution, smart regulation operates on the general public. To translate a regulatory policy into self-executing code requires an interpretive choice about what the policy means; that choice fuses the legislative and executive functions, and pre-empts the adjudicative function. The result, Hildebrandt argues, should not be understood as a kind of law. It should be understood as public administration — and like all public administration, it must remain contestable in a court of law. The legality principle, on which administrative decisions in continental European systems are required to rest, demands that those subject to a decision be able to obtain a justification capable of being challenged. Self-executing code that does not preserve that possibility has stepped outside the rule of law.

What legal protection by design requires

If LbD is the failed version, LPbD is the working version — but only on two conditions, both of which the book names explicitly.

We have arrived at the operative part of the argument. If Hildebrandt rejects legal by design and defends legal protection by design, what does the second one concretely require? The question is not trivial. If the answer were soft — “build ethically,” “consider human values” — the whole proposal would lose its edge, because any company could claim compliance and no one could refute it.

Hildebrandt is unusually direct here, and the argument is worth reconstructing in two movements.

First, she dispatches the ethical option. Why does it not suffice for the engineers designing the systems to be ethical? For two reasons that merit attention. The first is market-structural: ethical commitments cannot level the playing field. The company that decides to build ethically may be pushed out by the company that decides not to. The second is constitutional, and it is the sharper of the two: making the protection of fundamental rights depend on the goodwill of a private boardroom is, quite simply, abdicating constitutional democracy. Protection cannot depend on those it is meant to constrain. The whole point of writing protections into law is precisely that the protection does not depend on the goodwill of those it constrains.

With that cleared, the two formal requirements appear.

Requirement one: legitimacy of origin. The scope of the design obligation must be determined through democratic participation. What does this mean operationally? That someone — the legislature, a participatory assembly, whatever constitutional mechanism applies — has decided what counts as a fundamental right in this case and how it should be translated into technical requirements. The engineer does not decide. Neither does the boardroom of the deploying company. The constitutional procedure authorised to decide it decides.

Requirement two: contestability ex post. Those subject to the obligation must be able to bring its application before a court. It is not enough for the rule to exist; there must be a forum where it can be challenged when applied badly. Without that forum, the rule may have been written democratically and applied autocratically, and the difference erases.

Both requirements are conditions of legitimacy. They are also conditions of effectiveness: without them, the design obligation has no institutional mechanism by which to be enforced, corrected, or updated. An obligation that no actor can enforce is an obligation that, in practice, does not exist.

Stop a moment before continuing. Which of the two requirements do you think is easier to neglect in current regulatory practice? When the AI Act’s conformity-assessment regime is examined in the coda — with its harmonised standards, its CE mark, its technical specifications — the question will return. And the answer will not be obvious.

The architecture matters. Each of the three provisions does work that the others cannot do alone. The DPIA forces a controller to articulate, in advance, what the risks of the system are and what safeguards have been built to address them — and to update this articulation when the risks change. Data protection by design and default forces the safeguards to be built into the technical and organisational architecture of the processing, not bolted on at the user-facing level. The prohibition on solely automated decision-making preserves an individual right of contestation against the most consequential outputs of the system. The first two operate on the system; the third operates on the individual decision. The combination is what makes the architecture protective.

This is the architecture that the EU AI Act, in its high-risk provisions, has now extended. Article 14 of the AI Act requires high-risk systems to be designed with human oversight built in; Article 13 requires transparency to the deployer; Articles 26 and 86 require deployers to inform affected persons and, in some cases, to give explanations.5 The framework operates alongside Article 22 of the GDPR, which the AI Act does not displace; the GDPR continues to provide the horizontal individual right to contest solely automated decisions, and the AI Act adds product-style requirements on the providers and deployers of the systems. Whether the layering produces a working combination, or whether the AI Act’s technical-standards regime ends up sliding back toward something more like LbD, is the open question of the next several years.

Ethics, code, and the force of closure

The book’s closing chapter is the one Hildebrandt herself describes as the one that “stirs the imagination.” It is also the most pointed on what is at stake.

The argument is straightforward and consequential. Law provides closure on contested questions in a way that ethics cannot and should not, because constitutional democracy rules out the imposition of any particular ethical view as the law of all. The procedure by which law arrives at closure — legislative enactment, administrative implementation, judicial review, all conducted under the rule of law — is the closure-providing mechanism that a constitutional democracy authorises. Ethics, by contrast, is the realm of reflection. Its outputs are arguments, not enforceable rules. This is not a defect in ethics; it is a feature.

What changes in the onlife world is that there is now a third source of closure. Computer code, embedded in algorithmic decision-making systems, can foreclose alternatives at the level of architecture: the system that grants or denies credit closes the question of credit for the applicant whether or not a court would have decided the same way. The closure is real. It has the force of technology. And — this is the move that gives the chapter its title — when the closure is provided by code under the heading of “ethics,” it acquires the legitimacy of an ethical commitment while operating with the force of technical enforcement. The result, in Hildebrandt’s phrase, is that “ethical design” becomes a competitor to legal protection rather than a contribution to it. Ben Wagner’s characterisation of the resulting practice as “ethics-shopping” and “ethics-washing” describes the same problem from a different angle.

Whereas ethics is not a competitor of law, algorithmic decision-making systems are just that.

— Hildebrandt

The argument is not anti-ethical. It is meta-ethical. Constitutional democracies embed a particular relationship between law and ethics in their foundational architecture: the rule of law creates space for citizens to develop their own ethical commitments and to act on them, within limits that protect equivalent space for others. The limit-setting function is law’s. The space-creating function is law’s. Ethics operates inside the space. When code begins to do the limit-setting function, without going through the procedures by which the limit-setting function is legitimately performed in a democracy, the structural relationship is inverted. The architecture of constitutional democracy is, in that inversion, threatened — not by malicious intent, but by the substitution of one closure-providing mechanism for another without anyone having decided that the substitution should happen.

The example Hildebrandt returns to throughout the chapter is algorithmic risk assessment in criminal justice — specifically, the COMPAS system used in U.S. courts to assess recidivism risk and, by extension, to inform parole and sentencing decisions.6 The case is useful to her not because it is the worst-case but because it is the cleanest illustration. The Berkman Klein Center’s “Detain/Release” teaching module, which Hildebrandt cites at length, demonstrates empirically that when judges are given a risk score they begin to “correct” their decisions against it without understanding the score’s accuracy or the probabilities its categories correspond to. The framing power of the tool, in the module’s phrase, “takes the air out of the room.” The score is not law. It does not have the legitimacy of law. It has the force of technology — and the force is enough to alter, systematically, the decisions of the human judges it supposedly only advises.

The closing prescription is restrained. Hildebrandt does not propose that algorithmic decision-support systems be removed from public administration or criminal justice. She proposes that they be used to challenge legal judgment rather than to replace it — to keep courts and administrators “nimble and sharp” rather than to scale and streamline their decisions into something that resembles judgment without performing it. The proposal depends on a sustained collaboration between lawyers and computer scientists; the book ends, in effect, with an invitation.

Coda — what the book is for

Two things the book establishes, one it leaves productively open, and one note on its specific usefulness to a researcher comparing the EU AI Act and the NIST AI Risk Management Framework.

What the book establishes is, first, that the protective character of modern law is contingent on a specific information infrastructure — the affordances of printed text, the institutions that grew up around those affordances, and the practices of iterant interpretation those institutions sustained. The contingency is not a weakness of the analysis but its centre: protection of this kind is not a metaphysical given but a historical achievement, and the move into computational infrastructures puts it under strain that requires deliberate work to address. Second, the book establishes that the work to be done has a precise structure. There are two ways to put law in code. One of them — legal by design, the dream of self-enforcing rules — over-promises, over-reaches, and ends up substituting for the institutional architecture that gave law its protective force in the first place. The other — legal protection by design — sets two formal requirements (democratic determination of scope, judicial backstop of contestability) and uses them to discipline the design of computational systems so that the protections of law survive within them.

What the book leaves open, productively, is the question of whether the AI Act has chosen the right side of the distinction. The Act’s high-risk regime contains both LbD and LPbD elements. Its human-oversight provision under Article 14 is recognisably LPbD: it requires that systems be designed so that meaningful human intervention remains available, that the deployer be in a position to override outputs, that the affected person not be locked out of the institutional architecture by the speed of the machine. Its conformity-assessment regime, by contrast, can slide toward LbD: technical standards, CE-marking, harmonised norms that translate the substantive requirements into specifications a system either meets or does not. Whether the layering of these mechanisms produces a working LPbD architecture or collapses into a procedural overlay on what is functionally LbD will depend on how the standards are written, how the courts read them, and how the relationship between the AI Act and the GDPR’s horizontal individual remedies under Article 22 is worked out in practice over the next decade.

The note on usefulness is specific. For a researcher asking whether a U.S. federal agency operating under the NIST AI Risk Management Framework can demonstrate substantial compliance with EU AI Act requirements, Hildebrandt’s distinction is a diagnostic of the first order. The NIST AI RMF is, in its construction, neither LbD nor LPbD. It is a voluntary risk-management instrument: a process oriented to identifying, measuring, managing, and governing AI-related risks at the level of the system and the institution. Its four functions (govern, map, measure, manage) operate on the systemic side of the architecture. They do not contain — and are not designed to contain — an individual right of contestation, a substantive prohibition tied to a fundamental right, or a procedural relationship between the affected person and the decision. The architecture is the architecture of risk management, not the architecture of legal protection by design.

This does not mean that the NIST AI RMF cannot contribute to the compliance regime an EU AI Act high-risk obligation requires. It can. It contains many of the elements that Article 9 of the AI Act demands of a risk-management system, and the parallel construction is recognisable from both sides. What the NIST AI RMF cannot do, on its own, is supply the LPbD layer — the contestability, the substantive prohibitions, the individual procedural relationship to the decision — that the AI Act inherits from the GDPR and embeds in its own provisions. The question for a comparison study is therefore not whether the NIST AI RMF “covers” the AI Act, in some abstract sense, but whether the regulatory environment in which a U.S. federal agency operates supplies the LPbD layer through some other instrument: the Administrative Procedure Act, the constitutional due-process doctrines applicable to state action, the sector-specific statutes (FCRA, ECOA, the Fair Housing Act) that establish substantive prohibitions and individual remedies in particular markets, or, in the case of OMB Memorandum M-24-10 and its successors, federal procurement requirements that have begun to operationalise LPbD-like obligations within the executive branch.

The framework Hildebrandt provides is, in this respect, not a polemic about which side is right. It is a typology that makes the comparison possible to draw without conflating the systemic governance work that both regimes do with the legal-protection work that only one of them, at present, has been built to do. The NIST AI RMF is excellent at the first. It was never built for the second. Whether the second can be supplied by what surrounds it is the question Hildebrandt’s book gives a researcher the tools to ask.