The Self-Driving State – now published by Springer. Discover the book

ReqPOOL
Back to the blogVision

Digital Sovereignty: What a State Must Not Give Up

Sovereignty means keeping rules, data, identity, and interfaces in public hands. What a state may source, what it must not, and why Europe matters.

Date

15 January 2025

Author

Florian Schnitzhofer

Reading time

9 min read

Tags

Self-Driving State, Digital Sovereignty, Public Service Platforms, Public Administration, Europe
Abstract dark blue surface with a fine grid of lines, a lighter blue band of light in the lower left, and a green plus sign at the right edge.

Public administrations today rely heavily on software, cloud services, and AI models that they neither own nor could build themselves. In itself, that is not a flaw; the state has never built everything it works with. Dependency becomes a problem where it reaches the components that sovereign action is made of. This article draws the line between what a state on the road to the self-driving state must keep in its own hands, what it may source without hesitation, and why the European level is the right scale for both.

Sovereignty means control, not in-house production

In our book "Der selbstfahrende Staat" (Springer Gabler 2024, in German), we describe the state through three characteristics: a defined territory, a permanent population, and a government that can enact and enforce binding rules. This government must be able to exercise control over territory and population without being dependent on external powers; the state is called sovereign because it is independent of other states. The definition comes from the analog world, where authority materializes in buildings and files as well as in civil servants.

In the digital state, sovereign action runs through software. Laws are implemented as rules in case-processing systems, decisions rest on register data, identity is verified digitally, and services are delivered through platforms. A state that does not control these four things no longer meets the definition at its decisive point: independence from external powers. That these powers today are platform corporations rather than states changes nothing about the matter.

Sovereignty does not mean self-sufficiency, however. In the book, we use the example of a translation service that is easy to operate in the browser while the software behind it runs on servers in California and keeps learning; for a smaller company, developing something like this would be impossible and unaffordable. The same holds for a state across many components. The yardstick, therefore, is not whether the state produces something itself, but whether it can answer three questions with yes:

  • Decide. Does the state determine what the software does, or does the vendor determine it with its roadmap?
  • Verify. Can the state, and can its citizens, trace why a decision turned out the way it did?
  • Replace. Can the state switch vendors without losing rules, data, or identities?

In the digital state, the sovereign is not the one who builds everything, but the one who can decide, verify, and replace at any time.

Four things a state must not let out of its hands

The three questions determine which components must remain in public hands. They are precisely the ones that form the backbone of the self-driving state in the book.

The rules: digital twins of legislation as a public good

A digital twin of a law is the formal representation of a prose statute: decision rules, parameters, and the semantics of the decision data in machine-readable form, comparable to a configuration file. In the book, we stipulate that digital twins of legislation are published at the same time as the prose text, audited by the judiciary, and placed under a free open-source license. Anyone may use and extend them; the executive, other state bodies, and companies embed them as the control unit in case-processing systems, online platforms, and ERP systems. The same principle applies to the open-source tax calculation core that state bodies develop and whose program code they publish free of charge.

The reason is not ideological. If the interpretation of a law exists only in the proprietary code of a vendor, citizens rely on the correctness of that vendor, not on the law. The state can neither verify such a decision itself nor change vendors without re-implementing the rules. If, on the other hand, the logic lives in the open digital twin, changing vendors becomes a technical exercise: the twin stays, the product around it is interchangeable. The rules are the layer on which lock-in must not occur, because they are the law itself.

The data and the interaction record

To carry out its sovereign tasks, the state has always had to hold data about its population. In the self-driving state, this data is interconnected, and the monopoly on the legitimate use of force extends, as we call it in the book using the example of taxation, to a data monopoly: companies make their data available to the state, and the state has the obligation to calculate and assess taxes on that basis, on its own authority and transparently. The technical basis for this is the interaction record, the successor of the traditional file, in which every interaction between citizens, companies, and the administration is logged independently of the specific application, decentralized in design and fully interoperable. What registers must deliver for this was described by Philipp Seper-Ambros in the article Registers Instead of Certificates.

For sovereignty, it matters less where the data physically resides than who determines the data model, access rights, logging, and keys. Storage and computing power can be sourced; data governance cannot. Server location alone offers no protection: the US CLOUD Act of 2018 allows US authorities to demand that US providers hand over stored data, regardless of the country in which that data resides. Data is sovereign only when the state holds it encrypted with its own keys, its structure is openly documented, and a move to another operator has been technically rehearsed.

Identity: Public Service Wallet and eID

The state establishes identity. In the self-driving state, the Public Service Wallet bundles all of a person's IDs, certificates, and access authorizations, and the eID is available at all relevant interfaces of the authorities. The uniform digital EU identity is under construction; in the book, we refer to the European Blockchain Services Infrastructure, in which about 25 nodes were already active in 2023, one of them operated by Austria's Federal Computing Center. Regulation (EU) 2024/1183 now obliges member states to offer a European digital identity wallet.

Why identity cannot be delegated is shown by the alternative: if access to public services runs through the account of a commercial platform, that platform decides who appears as a citizen in the digital space, and it can block, alter, or analyze that access. Sovereignty also includes independence from the device. In the book, we describe it as a kind of fundamental right to use the services of the state without owning technical devices, through service centers and trained staff. A state that refers its citizens to the operating system of a particular manufacturer has handed part of its authority to that manufacturer.

The interfaces: Public Service Platforms and Public Service API

The fourth component determines the direction of dependency. In the book, we formulate it as a right of citizens that the state offers its services under its sovereign authority via its own Public Service Platforms and additionally provides all services as interfaces so that commercial platforms can integrate them. A bank or a real estate agency handles the registration of residence directly as part of an apartment sale; accounting software uses the state's tax calculation core via API, and a bakery no longer has to calculate its tax itself.

This reverses today's relationship. At present, administrations adapt to the interfaces that vendors dictate. In the self-driving state, the state defines the interface, and the market integrates it. Whoever owns the API owns the contract between the state and the platform economy, and that contract must not be written by the other side.

What a state can do without

The distinction makes procurement easier, not harder. Everything that does not belong to the four components may be sourced: data centers and cloud services, standard software, development tools, language models, and basic services such as translation or text recognition. The following overview summarizes where the line runs.

Component Stays in public hands Can be sourced
Rules Digital twins of legislation, calculation cores, auditing Tools for modeling and development
Data Data model, access rights, logging, keys Storage, computing power, operations
Identity Wallet, eID, trust anchors Devices, operating systems
Interfaces Definition of the Public Service API, platform logic Third-party front ends and services
Intelligence Decision rules, verifiability of results Language models, basic services

Four conditions make sourcing safe. First, the domain logic lives outside the product, in the digital twin of legislation. Second, the data can be exported in an open, documented format, contractually and technically. Third, replaceability is practiced, for instance through a second operator or a tested exit plan, rather than merely agreed in a clause. Fourth, deployment remains transparent: the transparent state, which we contrast with the surveillance state in the book, discloses its own data and processes and thereby prevents trust from having to be replaced by control.

The EU AI Act, Regulation (EU) 2024/1689, in force since August 2024, reinforces these conditions. It classifies numerous fields of public administration as high-risk applications and requires documentation, human oversight, and traceability. A state that does not control the decision logic of its own systems cannot fulfill these obligations; it can only pass them on to the vendor.

Europe is the right scale

No single member state operates the complete technology stack of a self-driving state on its own, nor does it have to. In the book, we describe the digital union of states as the level that establishes common standards for data exchange, data formats, and communication and creates shared platforms, infrastructures, and security standards, including cloud services and data centers used by the member states. As we relate in the book, the European Commission sees public procurement as an essential key: the strong collective purchasing power of the public sector is meant to act as a catalyst and stimulate demand for trustworthy and secure AI technologies in Europe.

That is the decisive mechanism. If 27 member states procure their systems against the same requirements, open digital twins of legislation, exportable data, standardized Public Service APIs, then the market delivers exactly that, and the non-European market does so too. The Interoperable Europe Act, Regulation (EU) 2024/903, applicable since July 2024, already obliges public bodies to assess the interoperability of cross-border services and to share solutions with each other. The path from obligation to lived practice runs through the tender: every award that names the four components and demands their replaceability shifts the balance of power a little.

My assessment is that the debate on digital sovereignty in Europe is too often conducted as a debate about data centers. A European cloud is useful, but it is not the layer on which sovereignty is decided. Those who do not control rules, data, identity, and interfaces have merely changed vendors with a European cloud. Those who control them can also use non-European services without losing their capacity to act. The resilience we described in the previous article in this series begins at the same point.

The next step

How digital twins of legislation, the interaction record, the wallet, and the Public Service API work together in the overall picture is described in our book Der selbstfahrende Staat. To learn how we support public administrations in anchoring the four components in architecture and tenders, see our page on public administration.

Share this article
Florian Schnitzhofer
Author

Florian Schnitzhofer

CEO ReqPOOL Group · More about Florian

Get in touch

Arrange a no-obligation initial conversation with our contact person.

Christian Buchegger

Chief Sales Officer & Authorised Signatory

Book an expert consultation