Analysis by
Founder, Lex Wire Journal • Technology, Governance & Sovereignty Strategist
Dependence Is Often Designed Into the System
Technological dependence rarely begins with an explicit decision to surrender control.
It usually begins with convenience.
An organization adopts software because it solves a problem. Data accumulates inside it. Employees build workflows around it. Other applications connect to it. Institutional knowledge becomes organized according to its structure. Training, processes, permissions, and habits develop around the system.
Eventually, replacing the technology means more than replacing software. It can mean reconstructing part of the organization’s operating environment.
Nothing improper necessarily occurred. The technology may have worked exactly as intended. The organization may have received substantial value from the relationship.
Yet the architecture has changed the organization’s available choices.
The Bottom Line
Technological dependence is not created only by contracts or vendor relationships. It can be created by architecture. When information, identity, workflows, integrations, institutional knowledge, or essential capabilities become difficult to move or reproduce outside a particular system, the architecture itself begins to influence where control resides.
This distinction matters because architecture often appears neutral. Interfaces, databases, APIs, identity systems, file formats, permissions, integrations, and cloud infrastructure can look like technical implementation details.
But implementation choices determine what can connect, what can move, what can be independently verified, what can be replaced, and what stops functioning when a relationship ends.
“Architecture is not merely how a system works. It helps determine where control lives.”
Jeff Howell, Sovereignty & Law
Dependence Can Accumulate Quietly
Most organizations do not design their technology environments all at once.
Systems accumulate.
One platform manages documents. Another handles customer relationships. Another manages communications. Specialized applications support accounting, research, analytics, workflow, security, or knowledge management. Cloud providers supply infrastructure beneath them.
Each decision may be reasonable independently. But over time, the relationships among those decisions can create a different system than anyone consciously designed.
Data moves between applications. Authentication becomes centralized. APIs create dependencies between systems. Employees learn particular interfaces. Historical information accumulates in proprietary structures. Business processes begin assuming that particular services will remain available.
The result is not simply a technology stack. It is an architecture of dependence.
The dependency may remain invisible precisely because everything is working.
The Real Test Appears When Something Changes
Dependence becomes easier to observe when the assumptions supporting the relationship change.
A provider raises prices. A product is discontinued. An integration is no longer supported. A company is acquired. A service experiences a prolonged outage. Contract terms change. Regulatory requirements shift. A new technology becomes strategically preferable.
The organization may technically remain free to choose another provider.
But whether that freedom is meaningful depends on architecture.
Can the data move? Can another system interpret it? Will integrations survive? Can permissions be reconstructed? Will institutional knowledge be preserved? Can employees continue essential work during the transition? How much must be rebuilt before an alternative becomes viable?
These questions reveal a distinction between formal choice and exercisable choice.
A choice is not equally meaningful when the cost of exercising it includes losing the capabilities required to function.
Architecture Can Transfer Control Without Transferring Ownership
This is where technological dependence becomes particularly important to law and governance.
Control can shift without a formal transfer of ownership.
An organization can own its data while relying on another company’s infrastructure to access it. It can own its intellectual property while depending on proprietary software to use it efficiently. It can retain contractual rights while lacking the technical ability to exercise those rights without the cooperation of an intermediary.
This is the distinction examined in Your Data Is Not Your Intelligence: Why AI Changes the Meaning of Information Ownership. Formal ownership and practical technological control can diverge even when the underlying contractual allocation of rights remains unchanged.
Architecture determines much of the practical distance between the two.
“Control does not always move through a contract. Sometimes it moves through the design of the system.”
Jeff Howell, Sovereignty & Law
AI Makes Architectural Dependence More Consequential
Vendor dependence predates artificial intelligence. Organizations have dealt with proprietary software, incompatible formats, migration costs, platform dependence, and technology lock-in for decades.
AI changes the significance of the problem because the technology can become part of how an institution interprets its own knowledge.
In Who Controls the Intelligence? The Hidden Governance Question Behind Enterprise AI, the issue was framed as a distinction between control over underlying information and control over the systems that transform that information into useful intelligence.
As organizations connect AI to internal documents, communications, research, transactions, workflows, and institutional history, dependence can extend beyond software functionality.
The organization can begin relying on an external architecture to retrieve knowledge, identify patterns, synthesize information, generate analysis, and support decisions.
The deeper that capability becomes embedded in operations, the more difficult it may become to distinguish the organization’s intelligence from the infrastructure through which that intelligence is accessed.
AI Governance Already Requires Attention to Third-Party Dependence
Existing AI governance frameworks provide a foundation for examining these relationships even though they do not generally describe the issue as technological sovereignty.
The NIST AI Risk Management Framework treats governance as a cross-cutting function throughout the AI lifecycle and directs organizations to establish structures, policies, processes, and accountability for managing AI risk.
NIST’s Generative Artificial Intelligence Profile specifically addresses risks associated with third-party generative AI models and systems. Among other recommendations, it calls for due diligence across the AI lifecycle and attention to third-party intellectual property, privacy, security, and other risks.
The governance implication is significant. Organizations cannot evaluate an AI capability solely by asking whether the system performs well. They also need to understand the dependencies created by the broader technical and contractual environment in which the capability operates.
The Layers Where Dependence Can Accumulate
Architectural dependence is rarely located in a single component. It can accumulate across several layers of a system.
Data
Where is information stored, in what formats, and how completely can it be retrieved?
Identity
Who controls authentication, credentials, permissions, and the user’s ability to establish or preserve identity?
Applications
Which essential functions depend on proprietary software, interfaces, or workflows?
Integrations
Which systems depend on APIs, connectors, or technical relationships controlled by another party?
Intelligence
Which models, retrieval systems, indexes, configurations, or knowledge layers make institutional information useful?
Infrastructure
Which cloud, compute, network, or hosting services must remain available for essential capabilities to function?
Standards and Formats
Are important assets represented in ways that alternative systems can meaningfully interpret and use?
An organization can have substantial control at one layer and very little at another. That is why technological sovereignty is better evaluated across an architecture than reduced to a binary claim that a system is either sovereign or dependent.
Open Standards and Interoperability Can Preserve Choice
One way architecture can preserve agency is by reducing unnecessary barriers between systems.
Interoperability allows different systems to exchange and use information. Open standards can make that exchange less dependent on the permission or proprietary design of a single provider.
This does not eliminate switching costs or guarantee competition. Nor does an open standard automatically make a system secure, portable, or sovereign. But technical compatibility can make alternative choices more exercisable.
The importance of interoperability is reflected in contemporary regulation as well. The European Union’s Digital Markets Act imposes obligations on designated gatekeepers intended in part to improve contestability and fairness in digital markets. Depending on the service involved, those obligations include requirements concerning interoperability and user access to generated data.
The policy context differs from the sovereignty framework developed here, but the underlying structural insight is related: the design of digital systems can affect whether users and competitors have meaningful alternatives.
Law Firms Make Architectural Dependence Visible
Law firms provide a useful example because their technology environments increasingly contain multiple layers of sensitive and strategically important information.
Client documents may live in one environment. Communications may live in another. Billing, research, document management, knowledge systems, practice management, cybersecurity, and AI capabilities may each involve separate providers.
The question is not whether firms should eliminate those vendors. In many cases, specialized providers offer capabilities, security, support, and scale that firms could not efficiently reproduce themselves.
The governance question is whether the firm understands where critical dependencies exist and whether its architecture preserves enough control to satisfy its responsibilities and adapt when circumstances change.
ABA Formal Opinion 512 illustrates the continuing responsibility lawyers retain when using generative AI. Lawyers must consider existing professional duties including competence, confidentiality, communication, supervision, candor, and reasonable fees even when AI capabilities are supplied by third parties.
As AI becomes more deeply connected to firm knowledge and workflows, architecture therefore becomes part of the governance conversation. A firm cannot evaluate responsibility only at the interface where a lawyer enters a prompt. It must understand enough about the surrounding system to make informed decisions about where information and essential capabilities reside.
Dependence Is Not the Same as Vulnerability
It is important not to turn technological dependence into a synonym for technological failure.
Dependence can be rational. It can create enormous value. Organizations routinely depend on electric utilities, telecommunications networks, cloud infrastructure, professional services, financial institutions, software vendors, and countless other specialized systems.
The relevant question is not whether dependence exists.
It is whether a dependency has become sufficiently consequential, concentrated, opaque, or difficult to reverse that it materially constrains agency.
“The sovereignty question is not whether you depend on technology. It is whether your dependencies have quietly acquired power over your choices.”
Jeff Howell, Sovereignty & Law
Architecture Can Be Evaluated Through Agency
This returns the analysis to the concept developed in From Access to Agency: What Digital Sovereignty Actually Means.
If sovereignty is understood as the preservation of meaningful agency within relationships of dependence, architecture can be evaluated according to the choices it preserves or forecloses.
Visibility
Do we know which systems and providers essential capabilities depend upon?
Substitutability
Can another system or provider realistically perform the essential function?
Portability
Can important information and configurations move in usable form?
Interoperability
Can alternative technologies connect without rebuilding the entire environment?
Continuity
Can essential functions survive disruption or transition?
Exit
Can the relationship actually be ended without surrendering essential information, identity, or capability?
These questions turn sovereignty from an abstract aspiration into something that can begin to be evaluated through system design.
The Most Important Architectural Question May Be Whether You Can Leave
A system’s architecture reveals itself most clearly at the boundary between participation and exit.
If information can move, standards permit interoperability, identity can persist, critical capabilities can be reconstructed, and alternative providers can realistically be substituted, dependence may coexist with substantial agency.
If leaving means abandoning accumulated information, identity, relationships, institutional knowledge, or essential functionality, architecture has created something closer to structural dependence.
Architecture determines more than how we enter a system. It helps determine what remains ours when we leave it.
That makes exit one of the clearest places to examine whether technological choice remains real or has become merely theoretical.
The next Sovereignty & Law analysis examines that principle directly: The Right to Exit: Why Portability May Become a Core Principle of Digital Sovereignty .
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.
