We learned the lock-in lesson once already, the hard way, with the cloud. We signed up for elastic compute and somewhere along the way discovered that the data had gotten heavy, the egress fees were real, and the managed services we leaned on didn't have clean equivalents anywhere else. So we got smart. We started writing data-portability and egress terms into contracts. We asked about capacity guarantees so a noisy quarter wouldn't throttle us. Procurement and security learned to read those clauses like a credit agreement.
Now we're doing AI deals, and most of those same contracts have a hole in them you could drive a roadmap through. We're negotiating hard on the data going in and the tokens coming out, and we're leaving the most valuable, least portable asset on the table entirely: the prompts, the context, and the accumulated memory that make the system actually useful to us. That's the next vendor-risk line item. Let me make the case.
The real switching cost isn't the model. It's everything you built around it.
Here's the mechanic people miss. The model itself is the commodity. There are several frontier models, they leapfrog each other every few months, and swapping the underlying engine is genuinely getting easier. If lock-in were about the model, I wouldn't be worried.
The lock-in is in the layer you built on top. It's the library of prompts your teams refined over a year of trial and error. It's the retrieval configuration, the chunking strategy, the tool definitions, the evaluation sets you use to know whether a change made things better or worse. And increasingly it's the memory — the per-user and per-account context the system has quietly accumulated, the fine-tunes, the embeddings, the feedback signals that taught it how your business actually talks. None of that is your training data in the raw. It's the derived asset, and it's where the value compounds. It's also the part the contract usually says nothing about.
Ask yourself the question I ask in every renewal: if I had to leave this vendor in ninety days, what could I actually walk out the door with? In a fintech serving more than 1,500 financial institutions, I don't get to answer that question with a shrug. Neither should you.
Treat it like a third-party-risk problem, because it is one
We already have a discipline for this. It's called third-party risk management, and the muscle is built — we just haven't pointed it at the right target in AI deals. When you onboard a critical vendor, you ask how you'd offboard them. You ask where the data lives, who can see it, and what happens to it on termination. Context portability belongs in exactly that conversation, with the same teeth.
So put it in writing. A few clauses I'd treat as non-negotiable on anything material:
- Export rights for derived context. Prompts, system instructions, retrieval configs, embeddings, fine-tunes, and stored memory are your assets, and you can export them in a documented, non-proprietary format on demand — not just at termination.
- A defined format and a tested path. "You can have your data" means nothing if it arrives as an opaque blob. Specify the schema, and actually run the export once during the relationship so you know it works before you need it.
- Deletion and survival on exit. Spell out what the vendor retains, for how long, and how derived artifacts built from your context are purged — the same way you'd handle a sub-processor offboarding.
- No silent re-use. Your accumulated context doesn't become training fuel for the model everyone else rents. That's a confidentiality and competitive issue, not just a privacy one.
This isn't exotic legal engineering. It's the data-egress conversation we already won, extended one layer up the stack to the artifacts that now carry the value.
This is an exit-strategy concern, not a paranoia tax
I want to be clear that I'm not arguing against committing to a vendor. Depth of integration is how you get leverage out of these tools, and you can't get that by hedging on everything. The point of an exit strategy was never that you plan to leave. It's that the ability to leave is what keeps the relationship honest — on price, on roadmap, on the support you get when something breaks at 2 a.m.
A vendor who knows you physically cannot extract a year of refined context has no reason to sharpen their pencil at renewal. A vendor who knows you can walk with your assets intact behaves differently, and that difference shows up in the terms long before you ever exercise the option. Portability is negotiating power you bank quietly and may never have to spend.
There's an architecture decision hiding in here too, and it's the one I'd actually push hardest. Wherever you can, own the context layer yourself. Keep your prompt library, your eval sets, and your retrieval store in systems you control, and treat the model as the interchangeable part it's becoming. Build the abstraction so that the engine swaps and the accumulated intelligence stays. That's not just procurement hygiene; it's how you keep the option to adopt whatever's best next quarter instead of whatever you're trapped with.
The takeaway
The cloud taught us that the cheapest thing to start is rarely the cheapest thing to leave, and that the bill you didn't read was the one that hurt. AI is running the same play, except the heavy, sticky asset this time isn't a petabyte of storage — it's the institutional knowledge you've been pouring into someone else's system, prompt by prompt, with no clause guaranteeing you can ever get it back.
So here's the challenge. Pull your most important AI contract and find the section on context, memory, and prompt portability. If it isn't there, you don't have an AI strategy yet — you have an AI dependency. Fix that before the renewal, not during it.
