Skip to content
d.uhlmann (home)Nederlands
Back to Blueprints
Strategy5 min read

Architecting the Exit: How to Avoid AI Vendor Lock-In

Retaining institutional intelligence through decision telemetry logging, manual SOP drills, contractually secured fine-tuning data, and deterministic AI contracts.

A padlock resting on a glowing laptop keyboard
Table of Contents

Many new AI features are coming to market, and many of them promise significant efficiency gains on the operational side of a business. Some even deliver on those promises. I am a strong advocate of AI and believe most organizations should be all-in on it. But there are things to consider before going all-in. One of them I call “AI lock-in”: your organization becomes locked into cloud AI tools, and the way out is costly or even impossible.


What Makes AI Different From Previous Technology?

Most software offerings of the past were fairly similar in nature. Whether you bought a logistics system or an ERP, the operational and financial processes behind it were clearly defined. The system mirrored those processes, improved parts of them, and delivered efficiency through automation.

With AI, the tables start to turn. Imagine you run a distribution center (DC) for the goods you sell. Over the years the DC grows, but your experienced staff knows how to keep the cost per square meter under control and ship products on time. All processes are documented, and team leads know when to make exceptions.

Now a new AI system is introduced to improve the DC’s efficiency. It learns and automates many decisions. Behind the scenes, an LLM improves over time and needs less documentation and fewer people.


Why Is This a Problem?

The moment an organization hands critical processes to an AI it does not fully understand or control, it also hands over responsibility and power. This is often forgotten, because organizations tend to see only the benefits.

Let’s assume the software works fine. Over the years, documentation of the old processes gathers dust, and key people leave or retire. When new employees ask why a certain type of product is stored in a certain place, the answer becomes: “The software decided.”

Now the SaaS vendor raises prices by 25% next year, and another 25% the year after. The organization asks itself: how fast can we replace this tool, and what would it cost? AI tools are often integrated deeply into the enterprise stack and touch many systems, for example via MCP servers. If your processes, logs, and knowledge are not in order, you may feel obliged to accept most price increases because you depend on the software. That is AI lock-in, and from an IT strategy and financial perspective it is a bad place to be.


What to Do Instead

You can still use the enormous potential of AI while avoiding this situation. The right combination of tactics depends on your setup: a full SaaS service, a product whose backend LLM may change, whether you have something like Azure API Management in front of it, and so on. It is very individual, but these approaches are a good starting point.

1. Decision Telemetry Logging

If a warehouse system uses AI to make decisions, keep a log of every decision it makes. Ideally, make this a requirement during vendor selection: the tool must be able to produce a log entry for each decision. For example:

json
{
  "decision": "Move big truck tire from Zone A to Zone B",
  "confidence": 0.92,
  "variables": ["historical June demand spike in Zone B", "supplier lead time +2 days"],
  "logic_applied": "Heuristic cluster optimization",
  "date": "2024-10-12"
}

Step by step, you build up a database of every decision. This has three concrete advantages:

  • You have a trail when an audit comes.
  • The decisions can be used to train your own model later.
  • You can process-mine the logs to find patterns, for example for internal training material or onboarding new joiners.

2. “SOP Drills” & Operational Disaster Recovery

If you use AI in critical areas, you must be able to stay operational when the AI starts going off the rails, for example through model drift or confidently wrong output. If the DC’s AI tool starts producing nonsense, the organization must be operationally capable of running the DC manually to keep revenue flowing. For organizations affected by NIS2, this is also part of the business continuity requirements, but that is another topic.

3. Model Weights & Embeddings Export

This one is more technical. If the vendor uses your data to fine-tune the product to your needs, make sure the contract obliges the vendor to export that fine-tuning data on request. That way, internal or external AI experts can reuse it if you switch.

4. Make Non-Deterministic AI Deterministic

In regulated areas such as finance, it can make sense to use a design pattern called contracting. You force a non-deterministic model, such as an LLM, to return answers in a predefined, effectively hardcoded format. The model receives a contract it must fulfill, in practice often a JSON schema. This keeps you in control of your processes even when an LLM makes the decisions under the hood.


Summary

Look beyond the marketing of AI-driven efficiency and the long-term risk becomes clear. Traditional software automated our static processes (yes, I know nobody wants to hear it, but good old BPMN 2.0). AI automates our dynamic decision-making, sometimes without us understanding exactly what it is doing at a given moment. When an organization hands critical operational logic to a closed, third-party SaaS platform without strict architectural guardrails, it enters a dangerous holding pattern.

As human and process knowledge walks out the door, and standard operating procedures become dusty Word documents, the vendor gains more and more leverage over your business continuity and your bargaining position on price. Without an exit strategy, a price increase traps you, not only through data migration costs but through complete operational lockdown.

Mitigating AI lock-in means moving from passive consumption to architectural governance: strict decision telemetry logging, manual SOP drills that safeguard continuity and satisfy regulations like NIS2, and contractually secured fine-tuning data. That is how you keep ownership of your firm’s institutional intelligence.


The Cost of Convenience Is Compliance

AI promises, and is starting to deliver, operational efficiency. But convenience should never be traded for control over an organization’s core processes. Handing those processes to an AI black box without building an exit runway isn’t innovation; it is a major operational risk.

My goal is not to slow AI adoption out of fear, but to architect it with intention. Before you sign your next AI platform deal, ask these questions and write down the honest answers:

  1. Can we decouple our interface from the underlying model?
  2. Do we contractually own, and have export access to, the fine-tuned weights and embeddings generated from our data?
  3. Does the tool provide a continuous, human-readable decision telemetry log for our own auditing and business continuity records?

If the answer to any of these is “no”, you are not buying a solution; you are leasing a dependency, and it will get more expensive over time as AI itself gets more expensive. Build your abstraction layers early, keep operational documentation up to date (including proper knowledge transfer when people leave), and make sure that your company, not your vendor, holds the institutional intelligence.


This post reflects the personal opinion of the author and does not constitute legal or professional advice.