Analysis by
Founder, Lex Wire Journal • Technology, Governance & Sovereignty Strategist
The Ability to Leave May Be the Clearest Test of Digital Agency
Technology platforms usually compete on what happens after a user enters the system.
Features. Performance. Convenience. Integration. Security. Intelligence. Price.
But one of the most consequential characteristics of a technological relationship may not become visible until the user decides to leave.
Can the user’s information be retrieved? Can it be moved in a usable format? Can another system understand it? Can identity, history, configurations, workflows, relationships, and institutional knowledge survive the transition? Can essential operations continue while the migration occurs?
Or does leaving mean starting over?
These questions transform exit from a contractual event into an architectural issue.
The Bottom Line
A meaningful right to choose technology requires more than the freedom to enter a relationship. It requires a realistic ability to leave. Portability, interoperability, continuity, and the preservation of essential information and capabilities determine whether exit is practically exercisable. In that sense, the ability to exit may become one of the core principles of digital sovereignty.
“Right to exit” is used here as a principle of technological governance, not as a claim that U.S. law currently recognizes a universal legal right to leave every digital service on portable terms.
The argument is more structural. If meaningful agency depends on the ability to choose among alternatives, then the architecture and rules governing exit help determine how much agency actually exists.
“The freedom to choose a system means less if choosing another system requires surrendering what you built inside the first one.”
Jeff Howell, Sovereignty & Law
Entry Is Easy to Measure. Exit Is Harder.
Digital markets make entry remarkably easy.
An account can be created in minutes. Software can be activated through a subscription. Data can be uploaded. Applications can be connected. Employees can be trained. AI systems can begin generating value almost immediately.
Exit occurs under very different conditions.
By the time an individual or institution considers leaving, the system may contain years of accumulated information. Other applications may depend on it. Employees may have developed workflows around it. Historical records may be represented in proprietary structures. Authentication and permissions may depend on the platform. AI systems may have been integrated with internal knowledge.
The cost of exit therefore can increase as the value of the relationship increases.
That creates a paradox: the more useful a system becomes, the more difficult it may become to leave.
Exit Is Where Agency Becomes Measurable
In From Access to Agency: What Digital Sovereignty Actually Means, agency was distinguished from access.
Access describes what a system currently permits a user to do. Agency concerns what meaningful choices remain available when circumstances change.
Exit provides a practical test of that distinction.
If a user can retrieve important information, preserve essential capabilities, choose an alternative provider, maintain continuity, and reconstruct necessary functions elsewhere, the original dependency may coexist with substantial agency.
If leaving requires abandoning data, identity, accumulated knowledge, relationships, workflows, or economically significant capabilities, formal choice can become much less meaningful.
The practical measure of technological choice is not simply whether another option exists. It is whether the user can realistically exercise that option.
Architecture Determines the Cost of Leaving
The previous Sovereignty & Law analysis, The Architecture of Dependence: How Technology Quietly Transfers Control, examined how technological dependence can accumulate across data, identity, applications, integrations, intelligence, infrastructure, and standards.
Exit reveals the cumulative effect of those architectural decisions.
A proprietary file format may seem insignificant until thousands of records must be migrated. A closed API may seem manageable until another application needs to replace the original system. Centralized identity may simplify administration until access to multiple services depends on a single provider. An AI platform may create enormous productivity gains until the organization discovers that the intelligence capability developed around its data cannot easily be reconstructed elsewhere.
None of these characteristics necessarily makes a system undesirable.
They simply reveal that architecture affects bargaining power by influencing the practical cost of exercising an alternative.
“Lock-in begins when the cost of leaving is no longer just the cost of switching software, but the cost of reconstructing capability.”
Jeff Howell, Sovereignty & Law
Portability Is More Than Downloading Your Data
The phrase “data portability” can make the problem sound simpler than it is.
Being able to download information does not necessarily mean the information can be used effectively somewhere else.
Useful portability can depend on format, metadata, relationships among records, permissions, schemas, documentation, interfaces, compatibility, and the ability of a destination system to recreate important functions.
A collection of exported files may technically return information to the user while failing to preserve much of the operational value that existed inside the original system.
Portability therefore has at least two dimensions: portability of assets and portability of capability.
Data Portability
Can the underlying information be retrieved completely and in a usable format?
Metadata Portability
Do context, relationships, classifications, permissions, timestamps, and other meaningful attributes survive?
Identity Portability
Can important identity, credentials, reputation, or authorization survive the transition where relevant?
Workflow Portability
Can essential processes be recreated without rebuilding them entirely?
Intelligence Portability
Can accumulated knowledge structures, configurations, retrieval capabilities, or other strategically important intelligence functions be preserved or reconstructed?
Operational Portability
Can the organization continue performing essential functions in another environment?
Regulation Is Beginning to Treat Switching as an Architectural Problem
The relationship between portability, interoperability, switching, and technological dependence is no longer merely theoretical.
The European Union’s Data Act directly addresses switching between providers of data processing services and switching to on-premises infrastructure. Its provisions address contractual terms, exportable data and digital assets, technical assistance, continuity, open interfaces, interoperability, and obstacles that can impede switching.
The regulation expressly recognizes that switching can involve extracting data from one provider, transforming it when necessary, and uploading it into another environment. It also introduces the concept of functional equivalence, which concerns re-establishing a minimum level of functionality in the destination environment based on the customer’s exportable data and digital assets.
The Data Act further requires covered contracts to address switching and requires providers to support a customer’s exit strategy with relevant information. Its technical provisions also address open interfaces and interoperability for covered data processing services.
The European Commission has continued implementing that framework. In April 2026, it adopted Implementing Regulation (EU) 2026/855 concerning interoperability requirements and procedures for access to data required for customer switching.
These rules do not establish a universal principle of digital sovereignty. They operate within a specific European regulatory framework. But they demonstrate something important: lawmakers are already treating the ability to switch providers as a problem involving architecture, data formats, interoperability, contractual rights, technical support, and continuity rather than simply contract termination.
“A right to leave becomes meaningful only when the architecture makes leaving possible.”
Jeff Howell, Sovereignty & Law
Exit Changes the Balance of Power Before Anyone Leaves
The importance of exit extends beyond the moment a user actually switches providers.
The credible ability to leave can affect the relationship while the user remains.
When alternatives are realistic, providers face continuing pressure to deliver value, maintain compatibility, respond to customers, and compete on terms, performance, and innovation.
When exit becomes prohibitively difficult, that pressure can weaken. The provider may acquire greater practical leverage because the customer’s accumulated dependency makes alternatives increasingly costly.
Exit therefore influences power even when exit never occurs.
The ability to leave is not only a remedy for a failed relationship. It is part of what keeps the relationship voluntary while it continues.
AI Makes Exit More Complicated Than Data Migration
Artificial intelligence makes the portability question considerably more difficult.
Traditional migration often focuses primarily on applications and data. AI-enabled environments can add models, retrieval systems, embeddings, indexes, prompts, configurations, evaluation processes, integrations, permissions, and accumulated workflow knowledge.
Some components may belong to the organization. Some may be proprietary to a provider. Some may be technically reproducible but expensive to reconstruct. Others may depend on capabilities that are unavailable outside the original platform.
This is why Your Data Is Not Your Intelligence distinguished ownership of source information from control over the intelligence systems built around it.
An organization may successfully export every source document and still fail to preserve the capability through which those documents had become searchable, connected, contextualized, and operationally useful.
NIST’s Generative AI Profile reinforces the need to evaluate generative AI across its lifecycle and to account for third-party models and systems. That broader governance perspective becomes especially relevant when organizations depend on combinations of internal information and externally controlled AI capabilities.
Law Firms Should Think About Exit Before AI Becomes Infrastructure
For law firms, these questions become particularly important as AI moves from experimentation into knowledge management and daily legal workflows.
A firm evaluating an AI platform naturally asks what the technology can do today. How well does it research? How accurately does it retrieve documents? How much time can it save? How securely does it handle client information?
Those questions matter.
But if the system is expected to become part of the firm’s long-term institutional intelligence, another category of questions belongs at the beginning of the relationship rather than the end.
What can the firm export?
In what format?
What metadata and relationships survive?
Which AI configurations or knowledge structures belong to the firm?
Can another model or platform operate on the firm’s repository?
How much institutional capability must be reconstructed after migration?
Can the firm continue operating if the provider relationship ends?
These are not arguments against third-party AI. They are questions about designing a relationship in which the firm’s responsibility for its clients and institutional knowledge is matched by sufficient control over strategically important capabilities.
A Sovereign System Does Not Have to Be a Closed System
Preserving exit does not require rejecting vendors or building every technological capability internally.
In many cases, the most resilient architecture may involve multiple providers, interoperable components, open standards, firm-controlled repositories, external models, cloud infrastructure, and specialized commercial applications working together.
The sovereignty question is not whether another party participates in the architecture.
It is whether the architecture preserves enough agency that no single dependency unnecessarily controls the organization’s ability to continue operating, change direction, or adopt something better.
“Sovereignty does not require owning every component. It requires preserving meaningful choice across the architecture.”
Jeff Howell, Sovereignty & Law
Exit Is Where Ownership, Control, and Agency Converge
The first six analyses in Sovereignty & Law now point toward a coherent framework.
Ownership asks what rights belong to the individual or institution.
Control asks who determines what can actually be done.
Agency asks whether meaningful choices remain available.
Architecture determines how those rights, capabilities, and dependencies are distributed.
Exit tests whether the resulting choices can actually be exercised.
The ability to leave may be one of the strongest indicators that participation remains a choice rather than a dependency without an alternative.
In a technological environment increasingly defined by platforms, cloud infrastructure, artificial intelligence, and interconnected digital systems, designing for exit may become as important as designing for access.
From Exit to Trust
Exit reveals how much control a technological relationship ultimately leaves with the user. But it raises another question.
If sovereignty requires understanding what must remain under our control, it also requires understanding what does not.
Modern systems cannot function without trust. The deeper question is where that trust should reside, when reliance on institutions is necessary, and when technology can allow important claims to be independently verified instead.
The next Sovereignty & Law analysis examines that transition: Verification Over Trust: How Technology Is Changing Where Trust Lives.
This article is part of Sovereignty & Law, a Lex Wire Journal editorial initiative examining how technology is changing the relationship between law, ownership, trust, agency, and power.
