Regulation by Design and the Governance of Technological Futures

Abstract Regulation by design is an increasingly common approach in the governance of digital technologies. Under this approach, the developers of digital systems must adopt technical measures that implement the specific requirements mandated by law in their software. Some jurisdictions, notably the European Union (EU), have turned to regulation by design as a mechanism to automatically enforce legal requirements, but this article argues that such an approach can have important implications for long-term governance. Drawing from examples of regulation by design in EU law, it shows that by-design provisions delegate rule-making power to software designers, whose interpretations of the law become entrenched in digital systems. This delegation process suffers from legitimacy deficits, which are compounded whenever digital systems continue to enforce the designer-made rules as they operate for years and, sometimes, decades. Yet, these legitimacy deficits are not unavoidable, as regulation by design can be used to force designers to adopt technical and organisational practices that mitigate the risks of rule entrenchment to future generations. By mapping the long-term risks of regulation by design and potential solutions to them, this article provides a first step towards approaches to regulation by design that do not sacrifice the future for present interests.


I. Introduction
Regulation by design (RbD)1 is a widespread approach to regulating digital technologies. 2nder this approach, regulators oblige the designers3 of digital systems 4 to ensure that their system design incorporates specific legal requirements. 5Designers, in turn, comply with such a requirement by turning the legal requirements into technical requirements, which embed the contents of the RbD provision into the code of the digital system. 6esigners thus ensure the automatic enforcement of the goals laid down by the regulator, as each task carried out by a compliant digital system necessarily follows the requirements embedded in its code.It is no surprise, therefore, that various jurisdictionsnotably, but not exclusively, 7 the European Union (EU) 8 have incorporated RbD provisions into their laws dealing with digital technologies.
This article examines whether this regulatory turn towards design has long-term implications for law and policy.At first glance, the answer might seem negative: since RbD produces its effects through the design of digital systems, these effects would cease once a system is modified or ceases to operate.However, some digital systems remain in operation for many decades, performing irreplaceable services as part of society's digital infrastructures. 9And, even when specific digital systems cease to operate, the design decisions made in their creation can influence the development of future technologies. 10Whenever one of these mechanisms operates, legal requirements embedded by design into a digital system might remain in force for longer than designers or regulators anticipated.
The persistence of digital systems over time can, I argue, hamper the ability of future generations to respond to the societal challenges they will face.To make this point, the remaining sections proceed as follows.Section II presents an overview of RbD as a regulatory modality that is heavily dependent on the technical work of designers and, as such, might struggle to impose legal requirements that cannot be fully represented in software code.Section III then shows how the decision to regulate through code impacts the legitimacy of RbD approaches, as by-design requirements entrench the designer's interpretation of the legal requirements laid down by the regulator.Section IV, in turn, examines the measures regulators adopt to forecast potential long-term risks of regulation and suggests how they can be extended to deal with the risks stemming from RbD.Finally, Section V summarises the argument and presents its implications for policymaking and the interpretation of RbD requirements in law.

II. Regulation by design as technological co-regulation
RbD is a form of regulation; as such, it is intended to influence human behaviour according to the aims of regulators. 11In the case of by-design regulation, this influence happens in two stages.First, an RbD provision in the law is directed at the designer of a digital system, who becomes obliged to ensure that the digital system meets the requirements stipulated by law. 12Once designers comply with this requirement, RbD produces effects in the behaviour of those who interact with the system; for example, by preventing them from using the system for certain purposes. 13Therefore, any by-design approach to regulation is a form of delegation in which regulators empower designers to enforce the stipulated legal requirements against those who use or are otherwise affected by the digital system.

Designers as rule-makers
The task delegated to designers is not, however, the mere enforcement of regulatory goals specified in law.Designers cannot comply with their legal obligations without interpreting them: by necessity, legal requirements are formulated in general terms, and designers need to identify how these general formulations apply to the specific contexts in which the system is expected to operate. 14Once the content of the applicable legal requirements is determined, designers must decide the technical means that address the demands of the law.Some legal requirements might force designers to refrain from using certain techniques,15 while others might demand hardcoding a specific rule into the system. 16As a result of these two processes, RbD becomes a form of co-regulation, in which the regulator delegates not just the executing power but also the power to determine the actual content of the regulatory requirements and the mechanisms used to enforce them. 17onsider the accuracy requirement introduced by the EU's proposed regulation for artificial intelligence (AI) systems ("AI Act"18 ).Under this RbD provision, any high-risk AI system must achieve a level of accuracy appropriate to its function. 19Such a requirement influences the behaviour of third parties: public and private actors will only be able to acquire and use AI systems that meet the accuracy standards, and the general population is reassured that any lawfully developed AI system will be accurate enough for its purpose. 20Still, designers have ample leeway to choose between techniques that meet the accuracy standard: they might choose to implement the most accurate system they can create, or they might create a system that is just accurate enough to meet the design requirements but can be more easily understood by its users. 21Designer decisions may produce different systems even if they start from the same requirements.
Since designers shape the digital system used to enforce RbD's legal requirements, a bydesign approach is unlikely to achieve the intended results if designers fail to carry out the requirements imposed by the regulator.In many cases, such a failure might rest solely on the shoulders of designers; for example, if they misinterpret the legal requirements or if their programming work is inadequate or fails to solve software defects.In other cases, failure might result from broader socio-technical issues: in the field of AI, for example, most designers are reliant on tools developed by a handful of providers, which they lack the power to alter in response to legal requirements. 22While both kinds of factors are relevant, the following discussion focuses on another potential source of RbD failures: the limits of expressing the law through software.

Expressing legal requirements in software
Over the past few decades, computer scientists have developed various techniques to represent legal requirements and instruments in software. 23Some of these approaches have been used in practice, powering digital systems that address various problems, such as the automation of rules on taxes and social security benefits24 or automated verification of compliance with standardised trade rules. 25These approaches suggest that, at least under some circumstances, legal requirements can be faithfully translated into software code, which then enforces the encoded requirements.Whenever that is the case, RbD might be a feasible approach for regulators.
Translating legal requirements into software can be relatively straightforward in some cases.For example, legal rules can be presented in conditional structures -"if [such and such] then [so and so]"26 very similar to the conditional logic in programming languages. 27If a rule's conditions and consequences can be encoded in the computer system, as is the case of the rules above, it is amenable to programming.However, such an encoding is not always possible if the conditions of the rule refer to aspects of humans and society that cannot be represented in the binary language or software, such as those concerned with the flourishing of human personality. 28Encoding also becomes a problem if the automation of a rule would undermine the very objectives it is meant to pursue, as is the case with the principle that a defendant in a jury trial should be judged by their peers. 29onsequently, the content of a legal rule might be an obstacle to its expression in software.
Further complications appear whenever RbD imposes other types of legal requirements.In many circumstances, RbD requirements do not oblige designers to implement legal rules, but principles. 30A legal principle creates duties on those bound by itin this case, the designerbut it does not specify the content of these duties, which must be evaluated on a contextual basis. 31Therefore, a designer bound to implement a legal principle must identify the possible issues that might emerge in each operational context for their system and propose technical solutions before they come to pass. 32Such an anticipatory response might not be feasible in all cases.
Two examples of by-design requirements might help to identify the limits of anticipatory treatments of legal principles.In the accuracy-by-design example presented above, we have a potential conflict of values between accuracy and transparency, as some highly accurate systems are inscrutable to human observers.This conflict, however, can be resolved during the design process.So long as the system is accurate enough to meet the applicable accuracy requirements and transparent enough to comply with the transparency-by-design stipulation, the designer is free to choose how to weigh these values in their system.And, once they make a choice that complies with the law, it will remain an acceptable solution to the clash between values until the circumstances change. 33ontrastingly, designers are likely to struggle whenever value judgments do not remain stable over time.Consider a scenario in which a social media platform is required to automatically remove posts containing hate speech.An erroneous decision to remove a user's post can be a substantial violation of the user's rights, especially that of freedom of expression, 34 so accuracy is a relevant factor for this requirement.Many unlawful posts might be detected through automated filters, 35 but these filters might also produce wrongful results, especially when faced with parodies and other humoristic content. 36The correctness of a removal decision depends not just on the context of the communication itselfwas it a joke?A legal form of protest?but also on what is culturally acceptable within a society.Designers are unlikely to capture all relevant factors beforehand, and, even if they do, the requirements they embed into software might become outdated if society becomes more (or less) receptive to certain kinds of discourse.
The examples above suggest that RbD might be inadequate if the legal requirements cannot be fully specified before implementation, or if relevant factors cannot be expressed in binary terms.In these circumstances, compliance with by-design requirements becomes a matter of risk management 37 : any design decision will be insufficient to cover all relevant aspects of some legal requirements; nonetheless, designers are still obliged to choose and adopt measures that mitigate known risks to the values at stake. 38If these choices do not match the regulator's priorities, or if they produce unacceptable side effects,39 the actual effects of the system on users and third parties will likely differ from those expected by the regulator. 40ompliance with broadly defined RbD requirements might thus undermine, or at least fail to promote, the goals that prompted regulators to choose a by-design approach in the first place.

III. The legitimacy of regulation by design in the long run
The suitability of RbD approaches to regulation should not be evaluated solely from the technical perspective of effective design.Regulation is a social practice, in which a regulator seeks to influence the behaviour of the regulated actors.Sometimes this influence happens through the use of legally sanctioned coercion, or the threat of it, 41 but coercive approaches are not always effective, sometimes even backfiring against the regulator. 42ny regulatory approach thus depends on its legitimacy from the perspective of regulated actors; that is, on their willingness to follow regulatory requirements even when said requirements go against their interests. 43bD's reliance on software as an enforcement mechanism would seem to overcome these limits of coercion, as the rules embedded in the software are applied automatically whenever the conditions for their application are present.And, indeed, software systems do constrain human behaviour in novel and strong ways. 44However, at least three factors ensure the relevance of legitimacy for RbD approaches.First, by-design regulation is the product of software design practices, so the effectiveness of RbD depends on whether designers comply with the requirements to which they are subject.Second, the people subject to rules embedded in software design can sometimes change the system's operation 45 or the role the system plays in society. 46Finally, legitimacy might be relevant for moral and political reasons, such as the democratic ideal of ensuring people have a say in the rules that govern their lives. 47In light of these factors, even the most technical approaches to regulation may be affected if they are not perceived as legitimate.
As discussed in Section II, RbD regulates behaviour in two stages.In the first one, RbD operates as a traditional form of legal regulation, using the force of law to compel designers to implement legal requirements into software. 48The distinctiveness of RbD appears only in the second stage, in which technology is used to enforce regulation against the users and third parties that interact, directly or indirectly, with a digital system.Since the regulatory effects of technology are shaped by the technical decisions made by designers as they create digital systems, an analysis of RbD's legitimacy must consider whether delegating regulatory power to designers can be a legitimate form of regulation.
1.The legitimacy of delegating regulation to designers Various scholars have worked on the general challenges of what makes regulation legitimate 49 and the specific implications of technology for political legitimacy. 50Drawing from this scholarship, this section focuses on two social mechanisms that can legitimise a regulatory approach.Regulations can derive output legitimacy from the outcomes they produce: if an individual or group sees the effects of regulation as desirable, they are more likely to acquiesce to regulatory demands, even if those demands clash with some of their own interests. 51They can also gain input legitimacy by involving relevant actors in the regulatory processes, thus reassuring these actors that regulation accounts for their values and interests. 52These legitimacy-building mechanisms are not self-excluding, as sources of input legitimacy may reinforce, 53 compensate for 54 or undermine 55 one another.Legitimacy must, therefore, be evaluated in terms of how potential sources of legitimation manifest themselves and interact with one another in practice. 56ince RbD approaches rely on digital systems as enforcement mechanisms, their legitimacy is affected by factors related to how those systems are built and operated. 57From the perspective of output legitimacy, the discussion in Section II of this article suggests that encoding legal rules in software can be a double-edged sword.On the one hand, good RbD requirements can lead to systems that apply regulation uniformly and automatically.On the other hand, an RbD approach that imposes requirements that cannot be fully expressed in software will not produce the outcomes expected by regulators.In the latter case, a by-design approach might lose some, or even all, of its claim to being an effective means to promote regulatory aims.
By-design approaches also affect a regulation's input legitimacy.Some scholars have argued that the embedding of legal rules into software could bolster regulatory legitimacy by eliminating the possibility of arbitrary decision-making by human enforcers, 58 while others have suggested that enforcement by design weakens the legitimacy of alternative approaches, as it allows legislators to avoid the delegation of rule-making powers to executive bodies. 59Yet, as discussed in Section II.1, RbD necessarily entails delegating rulemaking power to designers, who are not subject to the same procedural requirements that foster popular representation in democratic legislatures. 60Consequently, RbD replaces the possibility of arbitrary decision-making by administrators with the possibility of arbitrary decision-making by designers, a switch unlikely to positively impact input legitimacy. 61

Long-term challenges to the legitimacy of regulation by design
The legitimacy of by-design approaches may also be affected by the passage of time. 62Given that RbD produces its effects by embedding legal requirements into software systems, these requirements are enforced for as long as the system remains in operation, unless its code is actively changed. 63However, changing a digital system after its design can be difficult, as those systems are complex technical objects, 64 often built upon components that designers lack the power and the technical resources to change. 65This difficulty in changing digital systems means, in turn, that such systems may lag behind the law whenever the latter changes, continuing to enforce outdated requirements for some time. 66f it is not feasible to adjust an existing digital system, its designers or regulators might decide instead to replace it with a new one. 67But replacement is not always a simple task: some systems might be too big to rebuild or carry out sensitive tasksor both, as is often the case with the systems used in domains such as banking, healthcare or the public administration. 68Even if replacement is possible, the legal requirements embedded in the system by design might be replicated in other systems: designers sometimes need to ensure the replacement system behaves as its predecessor, 69 and, even more often, design choices in the new system are themselves influenced by what was done in previous systems. 70As a consequence, the decision to embed legal requirements in a digital system might entrench these requirements by creating obstacles against future change.
Entrenchment is not a novel issue for legal scholarship.Certainty against arbitrary change is widely acknowledged as a desirable property of a legal system, 71 and one of the core ideas of modern constitutionalism is that modifications to constitutions should demand considerable technical and political efforts. 72However, the entrenchment promoted by the law is the entrenchment of legal text, which, by necessity, is formulated in general and abstract terms. 73Contrastingly, entrenchment in a digital system entails that any requirements embedded in the system's code will continue to operate as programmed-following the designer's interpretation of the original legal requirements.Whenever technical conditions create obstacles to technical change, an RbD approach can entrench not just the requirements imposed by the regulator, but the specific meaning given to them by the designer when the relevant technical decisions were made.
In the long term, the possibility of interpretive entrenchment through software can erode the output legitimacy of an RbD approach.If entrenchment prevents changes to a system, it will continue to enforce the requirements embedded into it during design.Yet, these requirements might become unacceptable as time goes by: the letter of the law or its interpretation can change, 74 societal change can make the original requirements irrelevant 75 or the system's operation might reveal biases that had escaped detection during design. 76These and other developments might require adjustments to the system, which entrenchment prevents, or at least makes more expensive.As a result, the operation of the digital system will undermine these new regulatory aims to the extent that they clash with the interpretation of the original legal requirements embedded in the system.
The long-term effects of design decisions also create problems for the input legitimacy of RbD approaches.Since the occurrence of interpretive entrenchment leads to the enforcement of the designer's interpretation of the legal requirements at the moment of design, it precludes systems from accommodating changes in perspectives over time. 77ntrenchment also creates obstacles to the representation of perspectives that were not accounted for in the original design, especially those regarding the rights and interests of future generations. 78For example, if future generations come to an agreement regarding the need for a change in regulation, they might struggle to make changes to older software systems, as the people who are familiar with such systems' architecture and technologies might be already retiredor long dead. 79RbD thus creates the risk that future generations end up governed by systems they did not shape and have little power to change.

IV. Addressing the long-term risks of regulation by design
Regulators are not unaware of the potential long-term effects of RbD approaches.In fact, some regulatory approaches use design requirements as a tool not only to govern present systems but also to foster specific paths of technological development. 80But, as the previous sections suggest, any such future-shaping effects from an RbD design also entrench how designers interpret legal requirements at the moment of design, an interpretation that might lack input and output legitimacy.Additionally, regulators might lack the legitimacy to impose their legal requirements on future generations, 81 especially if these requirements prevent changes in the applicable law 82 or to the constitutional structures of society. 83his is not to say that entrenchment risks make design an inherently illegitimate tool for regulation.Section III.2 of this article suggests that the likelihood of entrenchment grows with the complexity of the digital system, and so a small system might not produce much in terms of entrenchment.Likewise, the severity of any adverse effects will grow if the entrenched requirements deal with sensitive political topics such as fundamental rights and the rule of law, 84 but entrenchment might not be too much of a problem in other domains.The stability provided by entrenchment might even be a source of legitimacy, as is often the case with constitutional norms. 85At the end of the day, the decision of whether the positive effects of RbD are worth the risk of entrenchmentor whether such entrenchment is desirableis a political decision made in the present by the regulator, but one that will have consequences in the future.
As the introduction to this special issue shows, regulators are increasingly called to consider the impacts of their actions on future generations. 86In technology regulation, such reflections on the future are usually mediated by the ideal of "futureproof regulation". 87According to this ideal, regulation should be constructed so that the regulatory framework continues to operate in the same way even if technologies change. 88For example, the draft AI Act pursues futureproof regulation of AI systems by two mechanisms: on the one hand, its technical requirements are formulated with reference to the expected outcomes and not to specific technologies 89 while on the other hand, it adopts mechanisms such as regulatory sandboxes 90 and periodic reviews of the effectiveness of the regulatory outcome 91 to evaluate whether existing provisions are still suitable as new technologies come into play.Mechanisms such as those allow regulators to use the same regulatory approach in a broad range of functionally equivalent technologies 92 and reduce the adjustments needed to incorporate new technologies into the existent approach.Futureproof regulation thus contributes to ensuring its relevance over time. 93utureproofing an RbD approach creates two obstacles to dialogue with future generations.The first obstacle is shared with other forms of regulation: since futureproof regulation is expected to stay roughly in its current shape as time passes, it codifies the interests of present regulators.Current approaches to futureproofing mitigate this present-centric outlook through anticipatory methodologies, which identify future opportunities and risks associated with the regulated technologies. 94Yet, identifying future risks is not enough to ensure the interests and values of future generations are properly accounted for.As an example, debates on nuclear waste management acknowledge the potential risks of waste to future generations but often frame the response to these risks as a zero-sum game between present and future interests. 95To mitigate this reading of future interests and values in presentist terms, society will need to rely on mechanisms such as law-making oversight practices, 96 expanded mechanisms for participation in governance 97 or judicial pathways for addressing issues of intergenerational justice. 98owever, futureproofing the law is not enough to futureproof an RbD approach.Even if the legal requirements imposed by RbD address future values and interests, designers might still comply with those requirements through approaches that favour the present over the future (eg by adopting technical configurations that are more likely to entrench said requirements).An approach to this second stage would need to combine two strands of work: participatory approaches to software design, which allow designers to engage with the perspectives of individuals and groups affected by the system 99 ; and approaches to engaging with the future described above.Design methodologies for that purpose have begun to emerge, 100 but any such practices will need to deal both with the challenges of identifying future preferences and the limits of participatory design practices. 101Between these technical limits and the legitimacy issues designers face as long-term rule-makers, 102 it seems unlikely that RbD approaches will manage to fully incorporate future perspectives into designer decisions.
If the concerns of future generations cannot be addressed at the moment of design, regulators can still adopt measures that weaken the effects of interpretive entrenchment on future generations.Some of these measures might have an organisational character.For example, regulators might oblige designers to adopt quality management processes to identify and address risks stemming from the operation of the digital system, 103 thus ensuring that the system is constantly updated to cope with legal requirements.Another potential measure would be forcing the recall of software systems that impose unacceptable risks, 104 a practice that removes from circulation systems that cannot be repaired by their maintainers.Furthermore, regulators can also reduce the barriers to change in old, still-functional systems by establishing knowledge pools that prevent the loss of knowledge about old technologies as their creators retire or die.None of these measures is a design requirement, 105 but they remove or mitigate some potential causes of interpretive entrenchment identified in Section III.2.In doing so, they provide safeguards against the long-term risks of RbD approaches. 106inally, RbD itself might provide some tools for mitigating the risk of interpretive entrenchment through software.Over the last few decades, software engineers have developed techniques that simplify the management of the complexity of software systems.
For example, modular software architectures allow designers to make changes to parts of the system without needing to alter everything else,107 while automated registers of a system's operation allow designers to trace the sources of defects or otherwise undesirable outcomes,108 and reliance on established design patterns might bolster the legitimacy of designers and render the system's technical architecture more intelligible. 109If RbD requirements oblige designers to follow such design practices, the ensuing systems become more amenable to future changes.This malleability, in turn, allows future generations to make changes to existing digital systems if they deem such changes necessary.In doing so, an RbD approach might help future generations to exercise control over the rules embedded in future systems rather than subjecting them to the will of the past.

V. Concluding remarks
In the previous sections, I have argued that RbD approaches can have long-term implications, as they turn software designers into rule-makers whose decisions are enforced by digital systems that often operate for decades.Given the ubiquity of software in modern societies, the effects of RbD requirements are not confined to digital environments such as the Internet, as the systems built in compliance with such requirements are used to make decisions, create recommendations and perform other tasks that affect the lives of people.In a digitalised society, software design is a horizontal concern for governance.
The entrenchment risks associated with RbD should not lead us to discard the approach itself.Instead, they suggest the need for mechanisms to measure these riskssuch as indicators of entrenchmentand tools for mitigating it (eg through the reinterpretation of existing RbD provisions and new legislative instruments).By accounting for the potential effects of RbD, regulators might be able to leverage the potential gains from software without sacrificing the interests of future generations.Design cannot save us from the tyranny of the past by itselfbut it can be a tool for empowering future generations to make their own political choices.