Software has become the invisible infrastructure of society. Money, communication, business, education, healthcare, and public services increasingly depend on systems whose existence we often notice only when something stops working. Cloud computing has made these systems easier to build and more flexible to use, but it has also deepened dependence on infrastructure that the user, organization, or state does not fully control. Artificial intelligence makes this question even more important: software no longer merely mediates human activity but can, within the authority granted to it, search for information, communicate with other systems, and carry out actions on behalf of people or organizations.

For this reason, it is no longer enough to assess digital infrastructure only by whether a service is fast and its data appears protected. It is becoming increasingly important to understand on whose behalf software acts, what permissions it has, who can change the program or environment it depends on, which external parties its operation relies upon, and what can later be verified about its actions. These are technical questions, but their answers increasingly determine how independently people, organizations, and states can shape their digital environment.

EFTI’s source “Crypto Cloud: ICP as a Cloud Protocol and the Next Software Foundation of the Internet” examines the technical foundation of this shift.[1]EFTI, “Crypto Cloud: ICP as a Cloud Protocol and the Next Software Foundation of the Internet.”efti.org This article moves from there to the societal and application layer: what capabilities can be built on such a foundation, and who ultimately controls those capabilities? The answer has to be explored across several scales at once. A global technological foundation creates new possibilities, states must fit those possibilities into their own legal and digital architectures, and at the local level we ultimately discover whether technology also increases the real agency of people and organizations.

The great value of cloud computing has been the ability to use compute, databases, and other services without having to build everything independently. A significant share of modern software depends on this model, and the growth of large cloud platforms has enabled even smaller organizations to access infrastructure that once would have been available only to much larger actors. Yet convenience also brings a deeper dependence on service providers, administrators, software layers, technology supply chains, and legal jurisdictions that the system’s user does not fully control.

For states, this question becomes especially important because digital infrastructure has become part of the state’s own operational capacity. Digital sovereignty therefore cannot be reduced to whether a server is physically located within national borders or whether data is stored in a suitable jurisdiction. Equally important are questions of who can operate, modify, or stop a system; who controls access and cryptographic keys; which external services its continuity depends on; and how much the correct functioning of critical software ultimately depends on trusting a single operator, administrator, or service provider.

Artificial intelligence changes this situation in two opposing directions at once. On one hand, it gives people and organizations the ability to create software much faster and to delegate increasingly autonomous tasks to digital systems. On the other hand, the same technology also amplifies the attacker. Estonia’s work on cyber defence for the AI era has highlighted that AI can make attacks faster, cheaper, more scalable, and capable of targeting many systems at once, while also shortening the time between discovering a vulnerability and exploiting it.[2]Estonian Information System Authority (RIA), “Estonian experts develop cyber defence doctrine for the AI era,” 16 September 2026; RIA, “What to expect in cyberspace in 2026.”ria.ee As the capability of the application layer grows, so too do the attack surface, system complexity, and demands placed on cybersecurity.

This does not make cybersecurity, audits, access control, or good system administration less important. Rather, it raises a deeper architectural question alongside them: what properties should the software infrastructure itself provide? In today’s cloud, reliability, data management, identity, permissions, keys, replication, monitoring, and security guarantees are largely assembled from combinations of separate services and layers. Each new system has to reconstruct, operate, and defend a meaningful part of that stack. If some recurring problems can instead be solved as properties of a shared network or protocol layer, then what changes is not merely another protective layer but the starting point on which software itself is built.

The future digital state therefore has a software stack broader than applications and AI alone. At the bottom lies the physical and jurisdictional foundation: hardware, data centres, operators, energy, geographic location, and legal jurisdiction. Above that is the software compute infrastructure: compute, storage, networking, software execution, cybersecurity, and continuity. Next come identity, permissions, registries, data, and system interoperability; above those sit AI models, agents, and automated workflows; and at the top are people, institutions, and public services.

Digital sovereignty is not a separate layer inside this stack. Control, verifiability, data sovereignty, cyber resilience, continuity, interoperability, and independence should cut across the whole system. A domestic data centre or national cloud provider can be an important part of sovereignty, but physical location alone does not resolve questions of software execution, operator risk, cryptographic keys, authoritative system state, or dependence on a service provider. In an AI era where the upper layers are changing rapidly, the evolution of the software foundation beneath them becomes increasingly important as well.

Digital sovereignty does not imply withdrawal from the outside world or the construction of isolated national technology islands. The strength of the Internet itself lies in the fact that many independent actors can cooperate through common open protocols. The more interesting question is whether the same principle can be extended to computation and cloud software so that global interoperability and local control do not have to be opposites.

One possible answer is to move from the idea of cloud as a service toward the idea of a cloud protocol. In the conventional cloud-service model, a specific company provides the user with an environment that it operates and controls. An open protocol instead creates a common technical foundation on which compute environments owned and operated by different parties can function. From this perspective, Internet Computer Protocol, or ICP, is particularly relevant to EFTI.

ICP is not distinctive merely because it uses blockchain technology or supports digital assets. The protocol joins independent compute nodes into a replicated compute environment capable of running application logic, maintaining persistent state and data, and serving web interfaces. Consensus and cryptographic mechanisms give software execution properties that, in conventional cloud systems, typically require several separate infrastructure and security layers.[3]Internet Computer, Internet Computer Protocol, Cloud Engines, and ICP Quick Start — Sovereign Infrastructure.internetcomputer.org EFTI’s “Crypto Cloud” source examines this architecture in more technical depth; for society’s digital infrastructure, the more important implication is that some problems currently solved repeatedly at the level of individual applications and cloud environments can move down into a shared compute protocol.

EFTI uses ICP as the primary technological foundation for its software direction, but this does not mean claiming that one protocol is suitable for every task. The interest lies in the combination of properties: running complete software systems, replicated execution, protocol-level state, cryptographic guarantees, and the ability to reduce dependence on a conventional single application server or cloud operator. The real value of those properties still has to emerge through working systems, measurable costs, and well-understood use cases.

At the national level, this has developed into the idea of Internet Computer for Nations. States are not the only or necessarily the primary users of ICP; the same questions apply to companies, universities, and other organizations for which control of infrastructure, data residency, or long-term independence matter. National use is simply an especially demanding test because technical reliability, continuity, jurisdiction, cybersecurity, and public trust must all hold at once.

The most visible example today is Pakistan. In February 2026, the Pakistan Digital Authority and DFINITY signed an agreement to develop dedicated ICP infrastructure for Pakistan. The cooperation includes a sovereign environment located within the country, AI-ready software, a pilot national messaging application, and the development of local technical capability.[4]Pakistan Digital Authority, Pakistan Digital Authority and DFINITY Partner for Sovereign Cloud Infrastructure and AI Software Systems, 10 February 2026.pda.gov.pk At the same time, Pakistan is building other foundational layers of its digital state: a Government Cloud, national AI compute capacity, catalogue and identity services, and a governance model for digital infrastructure.[5]Pakistan Digital Authority, Working towards a sovereign digital backbone, 22 July 2026.pda.gov.pk ICP is not positioned there as a replacement for the entire digital state, but as one part of a broader effort to build its foundational layers.

This creates an interesting comparison for Estonia. Pakistan is in a position where several foundational elements of the digital state are still being built, making it possible to account for new architecture while those layers are being designed. Estonia did much of that work decades earlier. That is a clear advantage, but it also means that the next foundational change cannot begin from a blank page. Estonia’s question is not how to build a digital state on ICP, but how to integrate a new software foundation into an already functioning digital state while preserving the strengths that already exist.

The international picture extends beyond Pakistan. UNDP and DFINITY began working together in 2024 through the Universal Trusted Credentials initiative, which aims to strengthen trust in digital credentials and improve access to finance for small and medium-sized enterprises.[6]United Nations Development Programme, UNDP Partners with the DFINITY Foundation to Enhance Financial Inclusion of MSMEs, 3 July 2024.undp.org In 2026, that cooperation expanded into the exploration of sovereign cloud infrastructure and decentralized AI with UNDP country offices, civil society organizations, and public-sector pilots.[7]UNDP / DFINITY Foundation, UNDP and DFINITY Foundation Collaborate on Exploring Sovereign Cloud Infrastructure and Decentralized AI Deployment for Public Good, 2026.streetinsider.com Swiss Subnet represents another direction, bringing local jurisdiction, physical operation, and verifiable execution into a single infrastructure model.[8]Swiss Subnet, Sovereign cloud infrastructure for the AI era.subnet.ch These developments do not yet form a finished global standard, but they show that sovereign compute is already being explored from very different institutional starting points.

This leads to one of the central principles of the article. Global does not have to mean centralized, and sovereign does not have to mean closed. A shared protocol can operate across different jurisdictions, with different operators and for different purposes. Digital sovereignty therefore does not have to mean building a separate national technological world; it can mean participating in a common open network while retaining greater control over where and under whose conditions important software operates.

One technical part of this possibility is the Cloud Engine. A Cloud Engine is a separately configurable ICP subnet in which the nodes, their operators, physical location, and replication level can be selected while applications continue to use the same ICP software model.[3]Internet Computer, Internet Computer Protocol, Cloud Engines, and ICP Quick Start — Sovereign Infrastructure.internetcomputer.org This creates two different but connected ways of running cloud software within one protocol.

The public ICP network allows software to be deployed to a shared global infrastructure without requiring the developer to acquire or operate compute nodes directly. This is suitable for websites, public services, applications, and many other systems that have no reason to maintain a separate physical compute environment. Applications use the shared network, while compute, storage, and networking resources are accounted for in cycles.

A Cloud Engine provides a different deployment model for the same protocol. An organization can choose the nodes, operators, geographic location, and replication level, and use dedicated compute capacity. This can matter where more precise control over data residency, jurisdiction, operators, isolated resources, or larger data volumes is required. The public Internet cloud and the private Cloud Engine are therefore not two competing software worlds, but two deployment models of the same cloud protocol.

Resource accounting is also different. On the public network, applications pay for resources used through cycles. Under the current Cloud Engine technical model, canisters inside the Cloud Engine operate on a zero-cycle cost schedule: internal compute, data storage, messaging, and HTTPS outcalls do not consume canister cycles.[9]Internet Computer Skills, Cloud Engine Canisters, updated 21 September 2026.skills.internetcomputer.org This does not mean free or unlimited cloud computing, because the physical nodes still have finite capacity and infrastructure and operators must still be paid for. For systems with large data volumes or dense internal communication, however, this changes the cost model and opens the same software model to workloads for which usage-based accounting on the public network may not be the most natural option.

The same applies to more sensitive software. “Public” and “private” do not form a simple security scale: what matters is the trust model of the specific system, data residency, operators, and the required level of confidentiality. The public ICP network provides strong integrity guarantees for execution and state, but on standard application subnets full memory confidentiality against node operators is not automatic in every configuration; ICP is also developing hardware-protected execution environments for this purpose.[10]Internet Computer Developer Docs, Security Model.docs.internetcomputer.org A Cloud Engine adds the option to select the infrastructure and operators directly. The real question is therefore not whether one model is always more secure than the other, but which guarantees a particular system actually requires.

The broader architectural question goes further still. Individual systems in today’s cloud can be well protected, but many of the same infrastructure problems are still solved again and again across different applications and platforms: reliability, replication, state management, cryptographic keys, trust between services, auditing, and security configuration. The promise of a cloud protocol is to move some of these properties from the application layer into a shared network layer. This does not make good software architecture unnecessary, but it changes the baseline from which every new application starts.

The question, then, is not merely whether an existing cloud solution “works.” It is also which dependencies and risks have come to seem normal simply because the current cloud model is familiar, and which of them could be solved more systematically. A new architecture should not be adopted merely because it is new, but neither should the existing model be treated as final simply because many layers of security and operations have accumulated around it.

Alongside digital sovereignty, security is an equally important question. Cyberattacks against companies, hospitals, and public systems are no longer isolated exceptional events, but part of the everyday background of the digital world. According to estimates compiled by TEHA Group and Microsoft, the annual global economic cost of cybercrime grew from roughly $0.9 trillion in 2018 to $9.2 trillion in 2024, with the existing trend projecting $15.6 trillion by 2029.[17]TEHA Group in collaboration with Microsoft (2025), estimated annual cost of cybercrime worldwide, 2018–2029. Public data series: Statista, “Annual cost of cybercrime worldwide 2018–2029.”statista.com

These future figures should not be treated as precise predictions. They largely extend the existing trend into a period in which AI is simultaneously changing how software is built, defended, and attacked. The actual trajectory may differ — and could be steeper. What matters most is the scale of the change already underway: cybersecurity has become one of the major systemic challenges of the digital society.

One reason lies in the architecture of software itself. Traditional cloud infrastructure often consists of many separate layers: application servers, databases, identity services, networks, keys, APIs, and external service providers. Each component may be well protected on its own, but every additional dependency and connection also creates another trust boundary. An attacker does not need to break the entire system if compromising its weakest connection is enough. ENISA likewise identifies growing digital dependencies as a factor that expands the attack surface.[18]ENISA, Threat Landscape 2026, 30 September 2026.enisa.europa.eu

Cybersecurity, therefore, is not merely a protective layer built around software. It directly reflects the architecture of the software itself. The more fragmented the foundation, the more components and connections must be secured separately.

ICP approaches this problem from the other direction. Some properties that must be implemented through separate infrastructure layers in traditional cloud environments are built into the protocol itself: replicated computation and state, canister isolation, cryptographically verifiable state, and distributed key management. Application logic and data can operate within the same network-managed compute environment, reducing both separate infrastructure layers and the trust boundaries between them.[10]Internet Computer Developer Docs, Security Model.docs.internetcomputer.org

This does not mean security no longer requires attention. Flawed application logic, incorrect access controls, and compromised users remain risks. What changes is the foundation: some security problems no longer need to be solved from scratch by every application because they are already properties of the underlying protocol.

It is equally important that existing public digital infrastructure cannot be replaced all at once. ICP’s value therefore extends beyond building new applications. A protocol-based layer can also help connect existing systems more securely by moving critical logic, state, or coordination onto a stronger foundation. If integration points are often among the most vulnerable parts of a system, the objective can be reversed: make the connection points some of the strongest parts of the system.

A new cloud protocol therefore becomes more than an alternative place to run software. It can provide a foundation for building new systems more coherently, reducing trust boundaries across existing systems, and progressively strengthening critical digital infrastructure that is already in operation.

Estonia is not starting from a blank page when it comes to digital trust. Digital identity, electronic signatures, registries, X-Road, and public e-services have developed over a long period into a coherent trust environment. X-Road reflects one of the core principles of Estonia’s existing digital architecture particularly well: independent information systems can exchange data securely without requiring the data to be centralized or all parties to use the same application technology. The provider of a data service retains control of its own data, while the architecture of the underlying information system can remain independent of X-Road.[11]Estonian Information System Authority, X-Road Data Exchange Layer.ria.ee Any new software foundation should therefore preserve these strengths rather than begin from the assumption that the existing system must be replaced.

Estonia’s current attention is understandably focused strongly on artificial intelligence. Eesti.ai brings together practical projects in education, healthcare, business, and the public sector, while Estonia is also separately assessing its need for domestic AI compute infrastructure. According to Eesti.ai, the country currently lacks sufficient local compute capacity to develop, deploy, and manage the next generation of digital services at the required scale.[12]Eesti.ai, Projects, including AI compute infrastructure.eesti.ai

This creates a possible blind spot for Estonia. AI is not developing separately from the rest of the Internet. While new models, agents, and automated services are being added on top of the existing digital infrastructure, the compute layer beneath those services is also changing. If the focus remains only on what AI can do on top of today’s infrastructure, we may overlook the opportunity to evolve the software foundation on which AI-era services are built.

Digital identities for AI agents provide a useful example. Eesti.ai projects are exploring the legal and technical possibilities for registering AI agents, and in September 2026 the government discussed a project for which a legal basis is being prepared to allow agents to act securely and under controlled authorization on behalf of people.[13]Government of the Republic of Estonia, Digital identities for AI agents, 17 June and 24 September 2026.valitsus.ee This is an important question, but identity does not have to be treated separately from the rest of the software architecture. In ICP, technical identity is already a natural part of the protocol: a user or software entity is authenticated as a principal, while Internet Identity uses keys and delegated permissions to make authenticated calls.[15]Internet Computer Developer Docs, Principals, Internet Identity, and Identity and Access Management.docs.internetcomputer.org This does not replace Estonia’s eID or its legal significance, but it opens the possibility of exploring how Estonia’s existing identity layer and protocol-level identity could work together in the future.

In this respect, Estonia’s position differs from Pakistan’s. Pakistan is currently building its Government Cloud, national AI compute capacity, identity and data infrastructure, and ICP-based sovereign environment in parallel.[4]Pakistan Digital Authority, Pakistan Digital Authority and DFINITY Partner for Sovereign Cloud Infrastructure and AI Software Systems, 10 February 2026.pda.gov.pk[5]Pakistan Digital Authority, Working towards a sovereign digital backbone, 22 July 2026.pda.gov.pk New compute architecture can therefore enter the foundational layers from the beginning. Estonia has the opposite advantage: a strong, proven digital state built over decades. At the same time, that very maturity makes architectural change harder, because the existing system cannot and should not simply be rebuilt from scratch.

Estonia’s question is therefore different. Not “how do we build a digital state on ICP?” but “where can a new software layer best complement the existing digital state?” X-Road can continue to provide secure data exchange, eID can continue to provide human identity and digital authorization, existing registries can continue fulfilling their roles, and conventional cloud and AI compute can provide large-scale computation. A new network-based software layer can be introduced where stronger control, security, transparency, and verifiability create real value.

This opportunity is not limited to a narrow niche of “verifiable compute.” The same foundation could support complete new public services and critical workflows, management of AI-agent actions, authentication and authorization, cryptographic key use, or processes where it is important to later prove what actually occurred. In one case, the architecture may support an entire new information system; in another, only one especially important part of an existing process. The right scope should be determined by the use case, not by the technology itself.

This approach also aligns with Estonia’s own current digital-state direction. RIA’s 2026–2030 strategy emphasizes a coherent digital architecture, interoperable solutions, service resilience, a high level of cybersecurity, and stronger digital independence.[14]Estonian Information System Authority, RIA Strategy 2026–2030 and “RIA is looking for a Chief IT Architect: the digital state needs a stronger holistic view,” 8 September 2026.ria.ee In 2026, RIA has also separately highlighted the need to view Estonia’s digital state as a technological whole across institutional and information-system boundaries.[14]Estonian Information System Authority, RIA Strategy 2026–2030 and “RIA is looking for a Chief IT Architect: the digital state needs a stronger holistic view,” 8 September 2026.ria.ee Exploring a new architectural option is therefore not opposition to Estonia’s existing digital state, but a question of what foundation can carry its next stage of development.

Digital sovereignty does not end at the national border. Municipalities, schools, companies, organizations, and communities are also becoming increasingly dependent on software that they may have little influence over. Local digital capability does not mean that every municipality should build its own cloud or every school its own information system. It means having enough understanding, skills, and technical freedom to define one’s own needs, evaluate different solutions, participate in their creation, and, where appropriate, build software independently.

Artificial intelligence makes this level particularly interesting. Work that until recently required a large development team can increasingly be carried out with far fewer resources. At the same time, good systems do not become automatic. As writing code becomes easier, understanding the problem precisely, choosing the architecture, designing permissions, organizing data, validating results, and deciding what should be turned into software in the first place all become more important.

Practical software education is therefore a natural part of society’s digital infrastructure. The aim does not have to be teaching as many programming languages or cloud services as possible, but giving people the ability to move from a real problem to a working complete application and understand its parts. AI can be a natural development tool in this process, but not a substitute for systems thinking. This capability can matter to a professional developer, a small-business founder, a municipal employee, or a young person discovering that software is not something built only by large technology companies somewhere else.

Local capability also includes the ability to choose the underlying infrastructure. Not every system needs a private Cloud Engine, and not everything needs to run on a public crypto cloud. Conventional cloud, the public Internet cloud, private Cloud Engines, and local infrastructure are different tools. Digital independence grows when a person or organization understands the differences and can select the right architecture for the problem, rather than when one model is declared universally correct in advance.

The local level is also where large architecture meets real life. A national pilot can show that a system is technically reliable, but actual use reveals whether people understand it, whether it helps them do something better, and whether the technology increases or reduces their own capacity to act. Local experience can in turn provide national and global levels with knowledge that cannot be obtained from an architecture diagram alone.

Society’s digital infrastructure is not merely an analytical topic for EFTI. This work also helps define the institute’s practical software direction: to research, discuss, teach, and selectively build. At the global level, this means understanding developments around ICP and broader cloud architecture and building technical and architectural clarity. At the Estonian level, it means comparing those possibilities with the existing digital state, X-Road, identity systems, cybersecurity, and AI development. At the local level, it means practical software education, public-interest applications, and collaboration with schools, municipalities, companies, organizations, and communities.

EFTI’s aim is not to prescribe one final future architecture or to operate every layer itself. The institute’s value can lie in connecting these scales: bringing global development into an Estonian context, linking technical knowledge with societal needs, building local capability, and developing enough real software in selected areas to test ideas in practice. The first concrete concepts in this direction are subnet.ee and Smart Türi, but neither defines the full scope of EFTI’s national or local work.

subnet.ee is EFTI’s early research and pilot direction at the Estonian level, not a finished national infrastructure.[16]EFTI, subnet.ee — Estonian sovereign cloud infrastructure pilot concept.subnet.ee Its purpose is to explore what an ICP Cloud Engine located in Estonia and operated by local parties could look like, how such an environment could be governed, and for which applications it might provide meaningful advantages alongside existing solutions.

A good pilot should not begin by trying to build the largest possible system. It is more useful to choose an important but bounded problem and make the entire system visible: who the parties are, what permissions they have, where data resides, what can be technically verified, how integration with existing information systems works, and who is responsible when something fails. The same experiment makes it possible to compare cost, performance, reliability, and operational overhead with a conventional architecture. If a Cloud Engine provides no meaningful advantage in a particular use case, that is also a valuable result because the next choice can be made with better knowledge.

For Estonia, it is especially interesting to explore integration with an already functioning digital state rather than constructing a parallel world beside it. X-Road can remain the data-exchange layer where it already performs that role well, while ICP-based software can take on tasks requiring a different model of execution, state, or independence. Connecting Estonia’s eID with protocol-level identity could also become one possible research direction. subnet.ee is therefore primarily an experiment in understanding where a global cloud protocol, local infrastructure, and Estonia’s existing digital architecture can genuinely meet.

Smart Türi is one possible local software direction for EFTI: a digital collaboration space designed to connect people’s knowledge, discussions, documents, and initiatives. Its starting point is a real place and a real need. In any municipality, people know a great deal about their streets, parks, schools, and everyday problems; the local government holds documents and decisions, schools have their own experience, and businesses and associations possess different capabilities. Much of this knowledge, however, remains scattered across conversations, files, social media, and people’s memory.

The idea behind Smart Türi is to gather the relevant context around a question so that every new discussion does not have to start from zero. A school route, public green space, or local development issue could bring together residents’ observations, photographs, previous decisions, documents, and proposals. Instead of merely producing another stream of posts, the system could gradually become community memory.

This also opens the possibility of collective digital intelligence. One person may know local history, another may notice an everyday problem, a third may know how to solve it, and a fourth may know how to implement the solution. AI can help summarize long discussions, find related material, recall earlier decisions, and surface unresolved questions. Its role is not to decide on behalf of the community or artificially merge different views into a false consensus, but to help people notice, remember, and use their own collective knowledge more effectively.

This connects to EFTI’s idea of conscious software. It does not mean that software itself is conscious, but that its designers remain conscious of the relationships and behaviour the system encourages. Whereas many contemporary platforms are optimized for attention and time spent on the screen, the purpose of local public software can instead be to improve understanding, make important information easier to find, and connect digital communication back to real-world cooperation.

Türi, as Estonia’s spring capital, a garden town, and a nature-oriented living environment, gives this idea one particular local expression. Nature-centeredness does not have to be only a visual motif but can become a principle: technology should fit the needs of local life and people, rather than forcing people to adapt themselves to the system. The same software principle could take a very different form in another town, municipality, school network, or community.

Smart Türi is therefore not the final model of EFTI’s local software direction, just as subnet.ee is not the institute’s only possible Estonia-level project. They are two early ways of exploring the same broader question at different scales: what kind of infrastructure gives people more ability to decide for themselves, and what kind of software helps them actually use that capability?

This work cannot mature inside a single institute. It brings together cloud infrastructure, cybersecurity, public administration, education, software development, business, and local knowledge. EFTI therefore seeks open collaboration with technical, institutional, educational, and local partners who are interested not merely in observing the next generation of digital infrastructure but in researching, testing, and, where appropriate, building it together.

Society’s digital infrastructure develops when its different levels provide honest feedback to one another. The promises of global technology can be tested against the real requirements of Estonia’s mature digital state. A national pilot can reveal which guarantees hold and which questions remain unresolved. A local application can show something a purely technical experiment cannot: whether people understand the system, whether it helps them use their knowledge more effectively, and whether the technology increases their own ability to act together.

The movement is not only top-down. A local need can inspire new software, software can reveal the need for different infrastructure, and an experiment in one country can in turn help improve a global protocol. Global, national, and local are therefore not three floors of a hierarchy, but interconnected dimensions of the same system.

Estonia’s first digital leap gave people and institutions the ability to find one another reliably in the digital environment, communicate, and exchange data. The next stage may extend that same trust environment into the actions of software itself—not by moving everything onto one new solution, but by identifying precisely where stronger control, security, and verifiability are needed and how a new foundation can fit with what already exists. At the same time, the rapid growth of AI should not obscure the fact that the computational and software foundations on which the next generation of services will be built are changing too.

ICP is EFTI’s deliberately chosen foundation for exploring this possibility. subnet.ee asks what one Estonian infrastructure-level expression of it might look like; Smart Türi asks what value a consciously designed digital environment might create for a local community. Alongside both, it is equally important to grow people and organizations capable of understanding their own needs, evaluating technological choices, and increasingly shaping systems themselves.

Society’s digital infrastructure is not only what our systems run on. Its deeper value emerges when technical capability helps people and institutions understand their world more clearly and gives them greater ability to shape it themselves.