Chapter 4The Lock-In You Did Not Sign

Lock-in used to be something you could see coming. A proprietary database, a closed file format, a licensing scheme that punished migration. CIOs learned to spot it and negotiate around it. AI platforms introduce four new kinds, and three of them are invisible on a contract because they are not contractual at all. They are consequences of how the system was built, and they bind the institution whether or not anyone agreed to them.

Model lock-in

The most obvious and the least discussed. A platform that calls one provider's models, through that provider's proprietary API, with prompts tuned to that provider's quirks, cannot change providers without re-engineering. The institution is exposed to that provider's pricing, its outages, its policy changes, and its decisions about which models to retire. When a better or cheaper model appears elsewhere, and in this market one appears every few months, the institution cannot take advantage of it.

The engineering fix is well understood and widely ignored: every model behind one interface, every prompt written against that interface, and the specific provider a configuration value. Most of the industry has converged on a common request format, so a platform that speaks it can address dozens of providers and any open-weight model served by any of the standard inference engines. If your platform does this, switching models is a change to a settings page. If it does not, ask why.

The subtler form of model lock-in is capability drift. A platform that has quietly come to depend on one provider's particular strengths, its long context, its tool-calling style, its image handling, will work worse on any other model even if the interface is standard. The defence is to test. A platform that routinely runs its evaluation suite against several models, and publishes the results to its administrators, is one whose model independence is real rather than nominal.

Identity lock-in

Every AI product has to know who the user is. The hosted ones solve this by becoming an identity provider: users get accounts in the vendor's system, and the institution's directory is synchronized into it. Over time, roles, groups, permissions and sharing settings accumulate in the vendor's identity store. The agents people have built, the conversations they have had, the memory the system holds about them, are all keyed to identities the vendor owns.

Leaving means re-establishing all of that somewhere else. In practice institutions do not leave, and the vendor knows it.

The sovereign alternative is an identity layer the institution runs, which every application consumes. Users sign in once, through the institution's own single sign-on if it has one, and receive tokens scoped to themselves and their organization. Applications, whether built by the vendor, by the institution, or by an agent in an afternoon, trust that layer and hold no identity of their own. Chapter 14 describes how this is engineered so that applications never touch a secret. The point here is that identity is the layer that makes everything else portable, and it must be the first one the institution owns.

Connector lock-in

Connecting an AI system to an institution's data is expensive. Someone has to understand the student information system's data model, or the ERP's, or the clinical system's, write the integration, handle authentication, map the fields, and keep it working through upgrades. Vendors know this, and a growing number offer their connectors as the product's main attraction.

The trap is that connectors built inside a vendor's platform belong to the vendor's platform. They encode months of institutional knowledge about the institution's own systems in a form that cannot be taken anywhere else. The second AI product the institution adopts starts the integration work from zero.

The engineering escape is a connector standard. The Model Context Protocol, introduced by Anthropic in late 2024, adopted by the other major model providers through 2025 and since placed under the Linux Foundation's stewardship, defines how an agent discovers and calls tools, including tools that read and write institutional systems. A connector written to the protocol works with any agent platform that speaks it. The institution's investment in understanding its own systems becomes portable. Part III is about building on this foundation and, crucially, about the broker that sits between the agents and the connectors so that credentials and policy never live in the agent itself.

Format and memory lock-in

Two quieter forms deserve a paragraph each.

Conversations, documents, agent configurations and evaluation results accumulate in whatever format the platform chose. If that format is proprietary, exporting it yields something that is technically complete and practically useless. The sovereign requirement is that every artefact the platform holds is available in a documented, open format: agent definitions as readable files, conversations as structured records, evaluations as data a spreadsheet can open.

Memory is the newest form and potentially the stickiest. As agents remember what each person has told them, which preferences they hold, which problems they are working on, the memory store becomes the thing that makes the system feel personal. A vendor that holds the memory holds the relationship. A sovereign platform keeps memory in the institution's own database, in rows an administrator can read, correct and delete, scoped per person and per agent, and exportable like everything else.

Writing the exit into the architecture

A good contract has an exit clause: notice periods, data return, transition assistance. These are worth negotiating. But a clause is a promise about future behaviour, enforced by lawyers after the relationship has already soured. The sovereign approach is to make the exit a fact about the present, verifiable at any time, by building it into the architecture.

Concretely: the institution runs the platform, or could tomorrow, because it has the code and the deployment definitions. The identity layer is the institution's. The connectors are written to a standard and the broker that governs them is the institution's. The models are configuration. The data was never copied. Memory lives in the institution's database.

An institution built this way can end a vendor relationship by, at most, replacing the people who help run the platform. Nothing else has to change. That is the only exit clause that cannot be litigated, because there is nothing to litigate. The system simply keeps running.

The following parts of this book are about each layer in turn, because each of the four kinds of lock-in is defeated by a specific engineering decision at a specific layer, and a CIO who knows which decision to look for can tell in a meeting whether a vendor has made it.