← Sovereign AI

⏱ About 20 min✦ 20 XP

Portability and Exit

Portability is the capacity to move your work, data, and workflows from one tool to another without prohibitive loss or effort. Exit is the act of leaving a provider. Together, portability and exit readiness form the practical mechanism by which tool sovereignty is maintained. A tool you cannot leave without enormous cost is not a tool you control — it is a tool that controls you. This lesson is practical. It covers what portability requires technically, how to build for it from the start, how to assess your current portability posture, and how to recover portability if you discover you have already accumulated significant lock-in.

What Portability Requires

Portability is not a single property — it is the conjunction of several conditions, all of which must hold for you to actually be able to leave. Data portability: your inputs, outputs, conversation histories, fine-tuning datasets, and any other data created through your use of the tool must be exportable in a format that other tools can read. JSON, plain text, CSV, and standard database formats are portable. Proprietary binary formats, encrypted exports readable only by the same provider, and formats with no documented schema are not. Workflow portability: the processes you have built around the tool — prompt templates, system prompts, integration code, automation scripts — must work with alternatives. If your prompts are tuned to one model's quirks in ways that do not generalize, they are not portable. If your integration code calls provider-specific endpoints with no abstraction, it is not portable. Knowledge portability: your own understanding of how to use AI tools must transfer. If your mental model is completely specific to one provider's interface — their specific commands, their specific error messages, their specific fine-tuning format — then switching providers means relearning from scratch. Building generalized knowledge about AI tools, not just provider-specific knowledge, is a form of portability investment. Capability portability: the things you can do with the current tool must be achievable with alternatives. This is where capability gaps matter. If your current tool supports a specific feature — multi-modal inputs, a particular tool-use format, a specific retrieval mechanism — and no alternative does, then true portability to any alternative is impossible for those capabilities.

Portability Must Be Built In, Not Bolted On

Attempting to retrofit portability after deep integration is expensive and often incomplete. The time to build for portability is at the beginning: choosing open formats, writing abstraction layers, keeping your data in locations you control, and testing alternatives before you need them. Portability built in from the start costs a little extra. Portability recovered after the fact costs a great deal more, and often cannot be fully recovered.

Building for Portability

Concrete practices that build portability into your AI workflows from the start: Abstraction layers: rather than calling a provider's API directly in your application code, write an abstraction — a function or class that your application calls, which in turn calls the provider. This abstraction isolates the provider-specific code in one place. When you switch providers, you rewrite the abstraction layer, not your entire application. Libraries like LangChain, LiteLLM, and similar model-agnostic frameworks implement this pattern at a higher level. Open formats for data: store your prompts, conversation histories, fine-tuning data, and evaluation sets in JSON, plain text, CSV, or other open formats. Do not store them in a provider's proprietary interface. Version control your prompts in git, just as you would version control code. Regular exports: if you use a tool that stores data for you, export it regularly. Do not allow your only copy of important data to live in a provider's system. This is analogous to not allowing your only copy of important files to live in a free cloud service. Alternative testing: periodically run your key tasks through an alternative provider. This serves two purposes: it keeps your knowledge of alternatives current, and it reveals whether your prompts and workflows are portable or have drifted toward provider-specific optimization. Capability mapping: maintain a clear list of which capabilities you use from each provider. For each capability, identify whether a realistic alternative exists. This makes your portability exposure visible — you cannot manage what you have not mapped.

Match each portability practice to the type of portability problem it primarily addresses.

Terms

Writing an abstraction layer that wraps all provider API calls
Storing all prompt templates and conversation exports in plain-text files under version control
Learning the conceptual foundations of how LLMs work across providers, not just one provider's interface
Running your top five tasks through an alternative model monthly

Definitions

Knowledge portability — general understanding transfers; provider-specific commands do not
Workflow portability — isolates provider-specific code so only the abstraction needs rewriting
Capability portability — validates that alternatives can actually perform your critical tasks
Data portability — keeps data in open, provider-independent formats

Drag terms onto their definitions, or click a term then click a definition to match.

Exit readiness is slightly different from portability. Portability is a property of your setup. Exit readiness is a posture — the state of being prepared to actually exercise that portability when needed. It requires: knowing which provider you would switch to and having it tested; having a current export of your data; having your abstraction layer implemented and working; knowing approximately how long a full migration would take; and having designated who would execute the migration in your organization. Exit readiness does not mean you are planning to leave. It means you have maintained the option. The cost of maintaining exit readiness is much lower than most people expect once the foundational practices are in place. The cost of not maintaining it is discovered only at the worst moment — when you need to leave urgently and cannot.

A developer writes all her application's AI calls directly against one provider's SDK, using provider-specific function names, parameter formats, and error handling. She has no abstraction layer. Which portability problem does this primarily create?

Which of the following is the most accurate definition of exit readiness?

An abstraction layer wraps all calls in one place, so that switching providers requires rewriting only the , not the entire application. Storing data in formats like JSON or plain text ensures it can be read by any future tool. Periodically testing keeps your knowledge of alternatives current and validates that your workflows are genuinely .

Portability Audit and Recovery Plan

  1. Choose a real or realistic AI-powered workflow — a writing process, a coding workflow, a research process, or an automation you use regularly.
  2. Part 1 — Portability Audit: Assess the workflow on all four portability dimensions. For each, describe concretely what would happen if you had to switch to an alternative provider tomorrow:
  3. - Data portability: What data would you need to move? Is it currently in a portable format? What would be left behind?
  4. - Workflow portability: How much of your process is specific to the current provider's interface, quirks, or features? How much is general?
  5. - Knowledge portability: How much of what you know is transferable versus specific to this provider?
  6. - Capability portability: Are there specific capabilities this provider offers that have no clear alternative?
  7. Part 2 — Recovery Plan: For each portability gap you identified, write one specific action you could take this week to improve it. Actions should be concrete and completable — not 'improve portability' but 'export conversation history to JSON today and store in a local folder.'
  8. Part 3 — Exit Readiness Assessment: On a scale of 1-5, how exit-ready is this workflow? What would need to be true for it to reach a 5?
← Back to Sovereign AI