Where your AI lock-in actually lives

You have probably had the vendor lock-in conversation with yourself already. You picked a model, you noticed how much of your week now runs through it, and you reassured yourself that leaving would be survivable because the competitors do roughly the same job at roughly the same price. That reassurance is about the model. The model is not the part that holds you.

The part that holds you is everything you built around it. The connectors that reach your files. The automations that fire on a schedule and quietly keep a process alive. The notes, prompts and saved views that exist in exactly one product’s format. Swapping a model is a configuration change you can make on a Tuesday. Swapping the layer underneath it is a rebuild. This guide is about finding out which of your dependencies are which, before the day you need to know. It is not for anyone running their own inference or negotiating an enterprise contract. If your setup is two subscriptions, an API key and a folder of automations, this is the version that applies to you.

The model is the cheapest thing in your stack to replace

Both of the vendors most likely to be on the other end of your API key publish a documented path to being replaced. Anthropic ships an OpenAI SDK compatibility layer: point the base URL at https://api.anthropic.com/v1/, swap the key, change the model names [2]. Google’s version is the same shape, with requests going to https://generativelanguage.googleapis.com/v1beta/openai/, and the docs describe the change as “updating three lines of code and using your Gemini API key” [3].

That is genuinely cheap, and it is also the smallest part of the job. Read the caveats and you can see where the days actually go. Anthropic states plainly that its layer is “primarily intended to test and compare model capabilities, and is not considered a long-term or production-ready solution for most use cases” [2]. Through it, the strict parameter for function calling is ignored, so tool output is not guaranteed to follow your schema; audio input is stripped; prompt caching does not work; and multiple system messages are hoisted and concatenated into one, because that is all the underlying API accepts [2]. Google’s compatibility support is “still in beta while we extend feature support”, any parameter not on the supported list “will be silently ignored by the compatibility layer”, and reasoning cannot be turned off on Gemini 2.5 Pro or 3 models [3].

So the switch is three lines plus every vendor-specific behaviour you tuned around. The practical defence is boring and takes an hour. Keep the model name in one configuration value rather than scattered through your code and prompts. Next to it, keep a written list of the vendor-specific features you depend on: caching, strict tool schemas, a particular system-message layout, anything with a vendor’s name in it. That list is your actual migration plan, and it is much shorter to write now than to reconstruct later.

Lock-in has moved to the wiring between the model and your data

The interesting question is no longer which model you call. It is what the model is plugged into. The Model Context Protocol is the current answer to that at the connection layer: an “open-source standard for connecting AI applications to external systems”, described in its own docs as being “like a USB-C port for AI applications”, used to reach data sources, tools and workflows [1]. It is supported across Claude, ChatGPT, Visual Studio Code and Cursor, among others, which is the entire point of a protocol: build the server once, and the client on the other end becomes a choice rather than a commitment [1].

Set that against the alternative you are more likely to have used, which is a product’s own built-in integration. Native integrations are faster to switch on, better documented inside the product, and completely non-transferable. When you leave, they do not come with you, and neither does the configuration you did inside them. Neither option is wrong. What is wrong is not knowing which one you picked.

The audit is one column in a spreadsheet. List every place where an AI tool touches your real material: your documents, your inbox, your customer records, your codebase, your calendar. For each row, write down whether that connection is a feature of one product or an implementation of a protocol that several products speak. The rows in the first column are the ones that will need rebuilding by hand, and they are usually the rows carrying the most valuable access.

Nvidia’s interconnect deal is the same trade, one layer down

The clearest illustration of this pattern is happening in hardware, where the money is large enough that nobody bothers to be subtle about it. Nvidia describes NVLink Fusion as “the high-bandwidth, low-latency connective technology and IP that enables hyperscalers and AI natives to deploy custom XPUs and CPUs into NVIDIA’s world-leading AI infrastructure platform”, and lists MediaTek, Marvell, Samsung and others as custom silicon partners [7].

In August 2026 Nvidia invested $3.5 billion in MediaTek and brought its custom chip work into that ecosystem, giving MediaTek’s customers access to Nvidia’s rack-scale architecture [8]. Nvidia’s Dion Harris, a senior director for HPC and hyperscaler infrastructure, told TechCrunch: “Nvidia is an AI infrastructure company. We expanded beyond pure computing chips years ago” [8]. The buyers who spent years designing their own accelerators specifically to reduce their dependence on Nvidia can now end up running that custom silicon inside Nvidia’s rack, on Nvidia’s interconnect. They diversified the component and kept the platform.

Your version of this costs less and works the same way. Moving from one model to another while every connector, automation and document store stays exactly where it is looks like diversification and is not.

An export button is not the same as portability

Most tools have an export. Very few exports give you back a working system, and the gap between the two is where switching costs hide.

n8n is at the generous end. Workflows are JSON, and you can download them from the editor, import from a file or URL, or move them with the CLI or the API [4]. That is a real artifact you can keep in version control. Note the sharp edge the docs flag: exported workflow JSON “include credential names and IDs”, and while the IDs are not sensitive, the names can be depending on how you named them, so the docs tell you to remove or anonymise that information before sharing a file [4]. Note also what the file is worth. It is a complete description of your logic that is only legible to another n8n.

Notion shows the other failure mode, where the export exists but arrives in a shape that has lost the structure you cared about. You can export as PDF, HTML, or Markdown and CSV, with non-database pages coming out as Markdown and databases as CSV [5]. Comments come with you, at both page and block level, resolved and unresolved [5]. Form view databases cannot be exported at all, and you are told to use a table view instead [5]. Workspace-level exports are on Business and Enterprise plans for PDF, “can take up to 30 hours to process, depending on the size of the workspace”, and the download link “will expire after 7 days” [5].

Three questions settle any tool. Does an export exist. Does it include the parts that carry your logic rather than just your words. Does anything other than the tool you are leaving know how to read it. Notion’s Markdown export returns your writing and not your databases as databases. n8n’s JSON returns your logic and not a system that runs anywhere else. Both are better than nothing, and neither is a migration.

Run the escape drill on a normal Tuesday

Do the export now, while nothing is on fire, and then try to use it. Open the file. Look for the thing you would most miss. Time the whole exercise and write the number down, because that number, not the vendor’s marketing about openness, is your switching cost for that tool.

The details you find are the ones you never want to meet under deadline. A 30-hour processing window and a link that expires after 7 days [5] is a fine footnote in September and a serious problem in the week you are trying to leave. Credential names embedded in a workflow file [4] are a five-minute cleanup when you are calm and an accidental disclosure when you are rushing.

If you are established in the EU, some of this is now the provider’s problem rather than yours, and the dates are worth knowing. The Data Act has been applicable since 12 September 2025, and requires providers to remove the obstacles customers face when they want to switch, so that switching happens “quickly and smoothly, and without losing any data or the functionality of applications” [6]. During the transitional phase running from 11 January 2024 to 12 January 2027, providers “may still charge their customers for the costs incurred in relation to switching and data egress”, and from 12 January 2027 the Act “will also entirely remove switching charges, including charges for data egress” [6]. That changes what a provider is allowed to bill you for leaving. It does not rebuild a single one of your automations.

Price the switch before you renew anything

Annual plans are usually sold on the discount and bought on the assumption that you would leave if things got bad. Put a number on leaving first, then decide whether the discount is worth it.

The arithmetic is unglamorous: count the automations, prompts and integrations that only work inside one product, estimate the hours to rebuild and re-test each one somewhere else, and multiply by what an hour of your time is worth. Most people are surprised twice. The count is higher than they thought, because small automations accumulate without ceremony, and the per-item time is longer than they thought, because rebuilding is the easy half and re-testing against real inputs is the other half.

The output is a budget, not a verdict. Sometimes the honest answer is that the number is large, the tool is good, and you are staying, which is a decision rather than a drift. What the number should change is the marginal one. When you are about to build automation thirteen inside a product you cannot export from, and the same job could run on a protocol or a JSON file that travels [1][4], the cost of the portable version is now something you can compare against a figure instead of a feeling.

What still goes wrong

An open protocol is not automatic portability. MCP standardises how an application connects to your systems [1]; it does not standardise the model on the other end, and two models given identical tools behave differently enough that your prompts still need re-testing after a move. A protocol also does not tell you who is running the server. A hosted connector built on an open standard can still be one company’s service with one company’s terms, and the standard buys you the option to replace it, not the work of doing so.

Compatibility layers fail quietly, which is worse than failing loudly. Google’s documentation says unsupported parameters are “silently ignored by the compatibility layer” [3], so a migration can look like a success while dropping the exact setting you spent a week tuning. Anthropic’s guidance is to use the native API for the full feature set and treat the compatibility layer as a testing tool [2]. If you switch through a compatibility shim and only check that responses come back, you have tested that the pipe is connected, not that the output is still good.

The last limit is that portability has a price and it is not always worth paying. The portable option is often the slower one to set up, the uglier one to maintain, and the one without the polished interface. For a one-person business, a native integration that works this afternoon can be worth more than an abstract right to leave in three years. The goal of this guide is not to make you choose the escape hatch every time. It is to make sure that when you accept lock-in, you accepted it, and you know roughly what it would cost to change your mind.