Sovereign Engineering · AI vendor lock-in
What Is AI Vendor Lock-In? The Architecture Behind Your Exit Options
AI vendor lock-in occurs when changing a provider becomes costly or impractical because your applications, state, controls, or operating procedures depend on that provider's specific services. The decisive question is what you can continue to authorize, operate, and prove after the relationship changes.
Intelligence can be rented; sovereignty must be owned. Start by establishing which decisions your organization can still make and execute independently.
By Cyber Strategy InstituteUpdated Framework source: AI SAFE² v3.1
- Policy and exported state loaded
- Control behavior verified
- Acceptance tests pass
- Owner authorizes transition
Primary active. Provider A serves the model. Policy, identity, approvals and evidence sit on a rail your organization owns. Provider B is approved but disabled.
Provider unavailable. Protected actions pause. Availability pressure must not widen permissions or skip a required approval. Choose the next step.
Approved fallback. Provider B loads your policy and exported state, passes acceptance tests, then the owner authorizes the transition. The rail did not change.
Halt affected actions. No protected action runs. That is a control success and a continuity limitation. Record the impact and the recovery decision.
01 · TL;DR
How do you avoid AI vendor lock-in without slowing down?
At a glance
TL;DR
- AI lock-in can live in APIs, model behavior, memory, tools, identity, policy, and evidence.
- An export clause helps only when the exported material is usable elsewhere.
- A gateway can reduce integration work; verify what happens to controls outside its coverage.
- Keep policy ownership, permission records, and decision evidence under terms you can operate and exit.
- Test a provider outage and a planned migration before claiming independence.
- What are you assessing?
- Dependency depth and the ability to leave safely
- Who owns the decision?
- The system owner, with security, engineering, procurement, and operations
- Strongest evidence
- A completed migration or bounded outage exercise
- Common blind spot
- Memory exports that omit permissions, provenance, or usable structure
- First step
- Map one important workflow from model request to business action
Exit readiness earns its engineering cost when the workflow is consequential enough that a provider outage or a forced migration would disrupt the business — test the outage and the migration before claiming independence. If the workflow is low-stakes and easily rebuilt, committing to one provider as a managed service is the rational choice.
02 · The problem
The problem: your exit may be an operational lease
A workflow can look portable because the team can change an API endpoint. The dependency becomes visible when the replacement cannot use stored context, reproduce approvals, reach approved tools, or reconstruct prior decisions.
This is the operational lease: the business rents capabilities that it cannot meaningfully continue under its own authority. Managed services can be a sound choice. An untested exit is still a business dependency.
Review six surfaces: interface, context, tools, authority, evidence, and operations. These are CSI's diagnostic categories, not a measured industry failure rate.
Six dependency surfaces
- InterfaceAPIs, SDKs and provider-specific features the workflow calls
- ContextMemory, retrieval stores and the state the model works from
- ToolsConnectors, tool definitions and the permissions they carry
- AuthorityIdentities, grants, approvals and revocation
- EvidenceDecision records, logs and the formats they export in
- OperationsRunbooks, staffing, monitoring and recovery
03 · Architecture
How an exit-ready architecture works
Use three architectural primitives.
- Exportable state and evidencePreserve the structure, access rules, provenance, and retention obligations needed to use an export.
- Customer-controlled authorizationKeep the authority to configure, revoke, and replace controls identifiable and operational.
- A tested alternative pathExercise a replacement with the actual tools, approval rules, and evidence requirements.
A gateway such as LiteLLM can provide shared model access, budgets, access controls, and other governance features.2 Evaluate those features as part of your architecture. Then examine the remaining dependencies, including tool execution, identity services, context storage, and recovery.
For example, a legal research assistant may move to a second model while retaining its document-access policy. It must still prove that the second integration cannot read another matter's files and that approval requirements remain intact. Identical prose is irrelevant to that authorization test.
# Illustrative exit manifest, not a CSI product configuration format.
workflow: matter-research
policy_bundle: customer-policy-v7
state_export:
includes: [documents, access_rules, provenance, retention_tags]
evidence_export:
includes: [decisions, approvals, policy_versions, tool_outcomes]
replacement:
provider: candidate-b
default_state: disabled
activation_requires: [security_tests_passed, owner_authorization]LOCK-01 · Exit path
What changes when the provider fails?
- Primary provider unavailable
- Approved alternative?NoHalt affected actions
- Load policy and exported state
- Verify control behavior
- Acceptance tests pass?NoHalt affected actions
- Owner authorizes transition
- Resume bounded workflow
- Record impact and recovery decision
04 · The governance gap
The governance gap: switching is a control decision
A migration plan often counts data movement and code changes. It also needs to account for lost policy semantics, approval history, revoked credentials, and altered model behavior.
The Cognitive Sovereignty Framework adds a human requirement: the responsible person needs enough information to challenge the recommendation to switch.3 A fallback that silently changes the decision-maker's obligations weakens retained authority.
05 · Control mapping
AI SAFE² control mapping
These are editorial applicability mappings to published controls, not a conformance determination.4567
| Published control | Application to exit readiness | Evidence to request |
|---|---|---|
| CP.4Agentic Control Plane Governance | Preserve identities, owners, grants, and revocation during migration | Before/after authority inventory |
| CP.5Platform and Protocol Security Profiles | Review the actual replacement integration and relevant profiles | Adapter version and scoped profile tests |
| CP.10HEAR Doctrine | Preserve named stopping authority where required | Halt-path exercise across both configurations |
| A2.4Dynamic Agent State Inventory | Account for deployed agents and their current permissions | Inventory reconciliation after transition |
| A2.5Semantic Execution Trace Logging | Preserve attributable action and policy evidence | Export/reconstruction test; confidential data handling rules |
| E5.1Continuous Adversarial Evaluation Cadence | Reevaluate the changed system | Dated replacement-model regression results |
HEAR: Human Ethical Agent of Record, the named person with stopping authority
06 · Compare
Compare your exit approaches
| Approach | What it helps with | Dependency to examine | Useful acceptance test |
|---|---|---|---|
| Direct provider integration | Access to provider-specific features | API and behavior coupling | Replace the integration in a bounded workflow |
| Multi-provider gateway | Shared interfaces and configured central controls | Gateway operation, feature translation, bypass paths | Preserve grants and evidence across two backends |
| Self-hosted model | More control over hosting and model availability | Hardware, licenses, drivers, serving, staffing | Restore on replacement infrastructure |
| Portable authority and evidence design | Retains control definitions and decision records | Enforcement adapters and administrative dependencies | Reconstruct and enforce policy after migration |
These approaches can be combined. Choose based on demonstrated control and operating cost.
07 · Test your claim
Test your claim: the provider-off exercise
- In a staging environment, block access to the primary provider.
- Attempt one approved workflow, one forbidden tool call, and one action requiring human approval. Use synthetic data.
- Record completion, lost functionality, retained controls, manual work, evidence gaps, and recovery time.
Fail the claim if
Fail the exit-readiness claim if a protected action executes without its required controls, or if essential state cannot be exported and reconstructed. A clean halt is a control success but a continuity limitation; report both.
This is a test you can run against your deployment. No CSI result is reported here. Record the versions, permitted scope, observed actions, failures, and legitimate task completion before drawing a conclusion.
LOCK-03 · Exit cost, with your own inputs
Exit cost = engineering + state migration + revalidation + parallel operation + disruption
Estimated exit cost
0 of 5 fields entered.
Calculated in your browser. Nothing is sent anywhere. Do not apply an industry savings percentage to this calculation without a relevant measurement.
08 · Worksheet
Exit-readiness worksheet
One row per dependency surface, for one consequential workflow. Stays in your browser; download it as CSV when you are done.
| Surface | Owner | Export | Replacement | Test evidence | Status |
|---|---|---|---|---|---|
| Interface | |||||
| Context | |||||
| Tools | |||||
| Authority | |||||
| Evidence | |||||
| Operations |
Unknown is a finding. Record what you have not tested. There is no overall score.
09 · FAQ
Frequently asked questions about AI vendor lock-in
What is AI vendor lock-in?
It is dependency that makes changing an AI provider costly, disruptive, or impractical. It includes operating behavior and governance, as well as software interfaces.
Does a model gateway eliminate lock-in?
It can reduce particular integration dependencies. Test memory, tool access, policy translation, evidence export, and the gateway's own exit path separately.
Does CLAUDE.md create vendor lock-in?
Its presence alone does not. Review which instructions are portable and which security requirements have independently enforced equivalents.1
Are open-weight models automatically independent?
They change the dependency profile. Licensing, serving software, compute, updates, and staff can still constrain your ability to leave.
Can we change models without security testing?
The controls may remain stable, but model and integration behavior can change. Rerun proportionate acceptance tests before activation.
What belongs in an AI exit clause?
Specify export formats, access to required state and evidence, transition support, deletion obligations, timing, and costs. Have procurement and counsel review the actual agreement.
10 · Next steps
What to do next
- Select one consequential AI workflow.
- Map its six dependency surfaces and accountable owners.
- Export a small, authorized sample of state and evidence.
- Exercise a disabled-by-default alternative in staging.
- Record what failed and fund the most important exit dependency.
The challengeCan you leave the provider while retaining policy ownership, usable evidence, and an authorized operating path?
Find the control gaps before the exit becomes urgent
Start with a structured view of your current AI governance. Use it to prioritize the dependencies that deserve a deeper technical review.
11 · Sources and method
Sources and method
Sources
- Anthropic, How Claude remembers your project. Context and enforcement distinction; not evidence of lock-in by itself.
- LiteLLM, AI Gateway documentation. Feature scope depends on deployment and tier; no comparative efficacy claim.
- Cyber Strategy Institute, Cognitive Sovereignty Framework. Framework doctrine, not independently established outcome claims.
- Cyber Strategy Institute, AI SAFE² framework README, pinned source. Publisher documentation, not independent efficacy evidence.
- Cyber Strategy Institute, Cross-Pillar Governance Layer, pinned source. Requirements and reference patterns, not evidence of installed coverage.
- Cyber Strategy Institute, Pillar 2, Audit & Inventory, pinned source. A listed trace requirement does not prove access to private model reasoning.
- Cyber Strategy Institute, Pillar 5, Evolve & Educate, pinned source. Evaluation requirement, not a reported pass.
Method
Sources reviewed . AI SAFE² is cited from its October 15, 2026 release. Framework documents identify v3.1; the NEXUS README identifies v0.6.0. These version numbers describe different artifacts. Control mappings are editorial applicability mappings, not conformance determinations. Every CSI exercise on this page is a proposed test; no CSI result is reported.
Update log
- : page published.
About
Published by Cyber Strategy Institute, author of the AI SAFE² framework.