Owning Your AI Future, Post 2 of 6
In the first post of this series, we argued that the all-in-one AI platform trades a fragmentation problem for a dependency problem, and that the dependency is the part the business case never prices. This post gets concrete. If lock-in is the cost, where exactly does it accumulate?
The instinct is to point at the model. Which large language model am I committed to? What happens when a better one ships? It is a reasonable worry, and we will spend a later post dismantling it, because the model turns out to be the least durable lock-in of all. The lock-in that actually holds you lives somewhere quieter, in layers most organizations never think to inventory until the day they try to leave.
By then it is too late to inventory cheaply. So here is the inventory in advance: five places AI vendor lock-in shows up in your data layer, why each one is sticky, and why together they cost far more than any model commitment ever could.
Lock-in does not concentrate in the model, which is increasingly swappable. It concentrates in the embeddings, the orchestration logic, the governance framework, the egress terms, and the context: the layers you do not think to inventory until you try to move, by which point moving is exactly what they prevent.
One: Proprietary embeddings and vector formats
The first place lock-in hides is also the easiest to overlook, because it looks like plumbing. To make your data usable by AI, the platform processes it into embeddings and stores them in a vector format. That format is almost never portable.
This matters more than it sounds. Embedding your corpus is not free: it costs compute, time, and tuning. When that work is captured in a proprietary store, you have not just paid for it once. You have agreed to pay for it again, from scratch, the day you move to any other system, because the embeddings do not travel and the format does not translate. The more data you process, the deeper the commitment, and the processing is continuous. Every new document, every updated record, every fresh source deepens an asset you cannot extract.
It is lock-in disguised as setup. By the time you would notice it, you have years of accumulated processing living in a format that exists nowhere else.
Two: Orchestration logic welded to one runtime
The second place is the logic that defines how your agents actually behave: how they reason, what tools they call, in what sequence, under what conditions, with what fallbacks. This is where real engineering investment goes, and in a single-vendor platform it is almost always written against that vendor’s runtime.
Logic written against one runtime is meaningless outside it. The agent behavior you spent months refining does not describe a portable specification of how your business works. It describes how this vendor’s system executes, in this vendor’s syntax, with this vendor’s assumptions baked in. Move platforms and you are not migrating that work. You are rebuilding it.
This is the layer organizations underestimate most consistently, because the cost is invisible while things are going well. The orchestration just runs. Its captivity only becomes legible when you try to take it somewhere else and discover there is nothing to take, only something to redo.
Three: Governance trapped inside the vendor’s framework
The third place is the one that should worry risk and compliance leaders most, and it is the one this series will return to at length: the access policies, the audit trails, the controls that determine what AI can see and do, all implemented inside a framework you do not own and cannot export.
When governance lives in the vendor’s system, leaving means rebuilding your entire control plane from zero. Every policy redefined. Every audit trail re-established. Every approval renegotiated. For most organizations that prospect is enough on its own to make leaving unthinkable, which is precisely why it functions as lock-in. The control layer that was supposed to keep you safe becomes the thing that keeps you captive.
There is a deeper irony here. Governance is meant to give the enterprise authority over its AI. When it is implemented as a proprietary, non-portable framework, it quietly transfers a different authority to the vendor: the authority that comes from being too costly to leave. We will make the full argument in a later post: governance you cannot take with you is not really governance at all.
Four: Egress terms that make leaving expensive by design
The fourth place is the most deliberate, because it is written into the contract rather than the architecture. Even when your data is technically extractable, the terms of extraction are frequently structured to make leaving costly: egress fees, format dependencies, throttled export, retrieval priced to discourage the very thing it enables.
This is lock-in as policy rather than as plumbing, and it is worth naming plainly because it is the most honest form. The proprietary embeddings and welded orchestration create lock-in as a byproduct of how the system works. Egress terms create lock-in on purpose. A vendor that charges you to leave has told you something true about how it understands the relationship: your inability to walk away is part of the value it is capturing.
The cost here is not only financial. It is the leverage you lose at every renewal, in every pricing conversation, every time the roadmap drifts from your priorities. A vendor that knows extraction is expensive negotiates accordingly, and so do you: from a position you handed away the day you signed.
Five: The business context that lives in the vendor’s system, not yours
The fifth place is the most valuable, and the most dangerous, because it is the one the entire arrangement is quietly designed to produce.
As AI operates inside your business, it accumulates context: the understanding of how your enterprise actually runs. The entity relationships. The operational definitions. The domain vocabulary, the rules, the constraints that determine what a correct action looks like in your specific business. This contextual layer is the difference between AI that answers generic questions and AI that solves your problems, and it does not exist on day one. It accrues, slowly, through use.
That accumulated context is the single most strategic asset the whole engagement creates. And in a single-vendor platform, it accrues inside the vendor’s environment rather than yours. You have not just adopted a tool. You have agreed to let the most valuable thing the tool produces be held somewhere you cannot reach without permission and a renewal.
This is the lock-in that should concern any leader thinking past the current quarter. You can survive losing embeddings; you reprocess. You can survive rebuilding orchestration; it is painful but finite. What you cannot easily survive is discovering that your enterprise’s hard-won understanding of itself: the context that makes your AI genuinely yours: belongs, functionally, to a vendor you have outgrown.
The pattern underneath the five
Step back from the list and a pattern emerges. None of these five is the model. Every one of them lives below the model, in the layers where your actual investment accumulates: your processed data, your logic, your controls, your contracts, your context.
That is not a coincidence. It is the architecture of dependency. The model is the part the vendor wants you looking at, because the model is the part that is genuinely interchangeable and therefore safe to discuss. The lock-in is in everything underneath, precisely because that is where leaving gets expensive. A platform optimized to retain you will always concentrate its stickiness in the layers you inventory last.
The alternative cannot be “pick a better vendor” or “negotiate better egress terms.” Those are mitigations, and mitigations leave the architecture intact. The alternative has to be structural: keep the layers that matter on a foundation you own, above models and tools that remain interchangeable.
Which is why the alternative cannot be “pick a better vendor” or “negotiate better egress terms.” Those are mitigations, and mitigations leave the architecture intact. The alternative has to be structural: keep the five layers that matter, the embeddings, the orchestration, the governance, the context, and the freedom to extract any of it, on a foundation you own, above models and tools that remain interchangeable. That is what it means to integrate a platform without surrendering your architecture, and it is the foundation Datafi was built to provide.
The rest of this series builds that case out. Next, we take on the lock-in everyone worries about and almost no one should: the model itself, and why betting your architecture on a single LLM is a strategy with an expiration date already on it.
Post 3 in this series turns to the model layer directly: why frontier models are converging and commoditizing on a months-long cycle, why a stack welded to one provider inherits that provider’s pricing and roadmap, and why durable advantage was never going to live in whichever model is briefly ahead.
Datafi is a Business AI Operating System designed for mid-enterprise organizations that need the full power of an integrated AI platform without surrendering ownership of the data, context, and governance that make AI worth adopting. Learn more at datafi.co.
Series: Owning Your AI Future
Part 1, The Trap: Rethinking the Premise
Post 1: The Hidden Cost of The All-In-One AI Platform
Post 2: Five Ways AI Vendor Lock-In Shows Up in Your Data Layer
Part 2, The Tradeoffs: An Honest Accounting
Post 3: The Model Is Not the Moat, Why Betting on One LLM Is a Losing Strategy
Post 4: Governance You Cannot Take With You Is Not Governance
Post 5: Build, Buy, or Get Locked In, The False Choice in Enterprise AI
Part 3, The Path: A Pragmatic Roadmap
Post 6: Owning Your AI Future, The Case for an Open Contextual Layer
