How do you avoid AI vendor lock-in? Data portability and exit plans

You avoid AI vendor lock-in by keeping control of the assets that make a system work for you (data, labels, prompts, configuration and integrations), by writing portability and exit terms into the contract, and by testing a real export before you depend on the service. Choosing a supplier with a good model is not enough, because models change quickly while the surrounding data and workflow are expensive to move.

Where does lock-in actually come from?

In practice, switching cost is spread across several layers. Teams often focus on the model and overlook the rest.

What does the EU Data Act change for buyers?

The Data Act entered into force on 11 January 2024 and began to apply on 12 September 2025. Its chapter on switching between data processing services, which covers cloud and edge services, aims to let customers move between providers without high charges, lengthy procedures or lost data. According to the European Commission, platform and software-as-a-service providers must offer open interfaces and export data in a commonly used, machine-readable format, while infrastructure providers must aim for materially comparable outcomes when a customer moves to a service of the same type.

Law firm Garrigues summarises further details: customers may be required to give no more than two months' notice to start switching, the outgoing provider must keep the service running and assist with migration for a maximum of 30 days, and customers have at least 30 days after termination to retrieve their data. Until 12 January 2027, providers may charge only for costs directly linked to the switch, and from that date switching and egress charges end.

These rules concern data processing services. Whether a specific AI product counts depends on how it is delivered, so ask your supplier and your counsel rather than assuming coverage. The Data Act also lets providers exclude their own data, such as trade secrets, provided the exclusion does not hinder migration, so the definition of exportable assets still matters in the contract.

Read also

Platform or point solutions? How to structure the AI vendor landscape in fashion

What should an exit plan contain?

1. An inventory of every asset the vendor holds for you: data, labels, feedback, configurations, prompts, logs and documentation.
2. The export format and frequency for each asset, with a named person responsible for receiving it.
3. The notice period, run-down support and data-deletion confirmation the supplier will provide.
4. A fallback: either a second supplier that could take the workload or an internal manual process for critical steps.
5. A cost estimate for switching, including staff time, parallel running and retraining.
6. A test date, and the result of the last test.

How do you test portability before you commit?

Ask for a sample export during procurement, not after signing. Load it into a neutral tool or a second environment and check that records are complete, identifiers are stable and enrichment (such as product attributes or customer segments) is preserved. Many failures appear here: exports that omit relationships between records, or that contain only the final output and not the inputs that produced it.

For AI features specifically, ask whether you can reproduce results. If the vendor changes the underlying model, will you be told, and can you pin a version? Without that, a switch is not the only risk: silent change inside the same contract can alter your outputs.

How can contract terms reduce lock-in?

• Ownership of inputs, outputs and any model tuned on your data stated explicitly.
• Termination assistance at a defined price, not left to negotiation at the moment of exit.
• Notice of model changes, deprecations and price changes.
• Shorter initial terms or break clauses tied to measurable service levels.
• Data deletion with written confirmation after migration.
• Escrow or continuity arrangements for smaller suppliers whose failure would stop a critical process.

Read also

AI Act roles explained: is your fashion company a provider or a deployer?

Is building in-house a way out?

Sometimes, but it replaces one dependency with another. McKinsey's 2026 survey found that 32% of respondents had decided against buying at least one software product or feature because they could build it in-house with agentic coding tools, and that about 20% of organisations are scaling software coding agents. That shows the buy-or-build balance is shifting, and it gives buyers a credible alternative in negotiation. It does not remove costs: a custom tool needs maintenance, security review and staff who understand it, and key-person risk simply moves inside the company.

A practical habit is to review lock-in at each renewal. Ask what has been added to the platform since signing, which new data now lives only there, and whether the last export test still works. Dependence tends to grow quietly through new features and new users, so the exit plan must be updated with it, and the cost estimate for leaving should be shown to the budget owner each year.

The aim is not to avoid dependence, which is impossible, but to keep the cost and time of leaving low enough that the supplier has to keep earning the contract.