I spend a lot of time in rooms with enterprise technology leaders who are deeply invested in AI. They’ve deployed copilots, run RAG pipelines against internal document stores, and some have fine-tuned foundation models on proprietary data. By most measures, they’re ahead of their peers. Yet, if their primary model provider changed its terms, got acquired, or decided their use case no longer met its acceptable use policy, everything they’ve built could be switched off overnight.
What enterprises have built they do not own
Almost three quarters (72%) of organisations have now adopted generative AI in at least one business function. The dominant deployment pattern involves feeding proprietary data into a third-party model via retrieval-augmented generation (RAG) or fine-tuning. Both approaches are useful. Neither constitutes durable ownership.
RAG gives a model access to documents at query time. The underlying model weights don’t change. It reads internal data the way a contractor reads a brief, without accumulating institutional knowledge. Fine-tuning encodes domain context at a point in time, then freezes. As business conditions shift, that snapshot drifts from operational reality, and the cost and complexity of fine-tuning means most organisations rely on periodic cycles rather than continuous adaptation.
What neither approach produces is a model that has internalised the business over time. The patterns, anomalies and judgment calls that accumulate through operational experience never make it into the model.
The answer is to separate the two. The base model (whoever provides it) should be treated as a commodity layer. What is important to own is the learning layer. The infrastructure that continuously trains on operational data and encodes the resulting domain expertise back into model weights the organisation governs. That layer is both the training mechanism and the accumulated intelligence it produces.
Model deprecation is already a recurring operational event
Vendor control over the model layer isn’t theoretical. OpenAI has deprecated multiple model versions in rapid succession, with organisations given windows of three to six months to migrate dependent workflows. During the introduction of GPT-5 in 2025, OpenAI removed multiple older models simultaneously from ChatGPT causing widespread workflow disruption, before partially reversing the decision following user backlash
For individual developers, these transitions are an inconvenience. For enterprises with critical workflows built on specific model versions, they represent unplanned operational risk with a timeline set by the provider.
Policy risk compounds infrastructure risk
Beyond deprecation, providers also retain the right to change their acceptable use terms, and those changes can affect use cases regardless of the operational investment made.
The clearest recent example involves the U.S. Department of Defence. In March 2026, the Department of War formally notified Anthropic that it had been designated a supply chain risk, the first such designation ever applied to an American company. The designation followed a breakdown in negotiations over how Anthropic’s model could be used on classified government networks.
The conflict centred on Anthropic’s refusal to remove restrictions on mass domestic surveillance and fully autonomous weapons systems from its acceptable use terms. This structural dynamic is directly relevant to any enterprise. A provider made a policy decision and the customer (in this case the Pentagon) had no recourse other than to absorb the disruption and migrate.
Apply that to a commercial context. Any organisation that has spent two years building critical workflows on top of a third-party model faces the same exposure. Provider terms change, models get deprecated, acquisitions alter product roadmaps. None of these events require consent so operational dependency doesn’t factor into the provider’s decision.
The structural fix is the same as for deprecation risk. It is to bring the training infrastructure inside the organisation’s environment. When the system that continuously learns from operational data and writes the resulting domain expertise into model weights is self-hosted, the base model becomes interchangeable.
A provider policy change that makes a specific model untenable simply becomes a substitution decision. The business retains the training pipeline, the accumulated intelligence it has produced, and can swap the foundation it runs on. That is what model sovereignty looks like in practice, and it is an architecture decision, not a procurement one.
The architecture question organisations aren’t asking yet
Enterprise leaders prefer hosting AI models on their own infrastructure, citing data privacy, reduced vendor breach risk, and customised security protocols as primary motivations. That preference is sound, but infrastructure hosting alone doesn’t resolve the dependency problem if the learning layer (the component that accumulates domain expertise over time and trains your model) still belongs to the provider.
Gartner identifies open GenAI models as reshaping the enterprise landscape. They do this by offering greater flexibility and freedom from vendor lock-in, with the ability to customise, fine-tune, and deploy on an organisation’s own terms. But switching to an open model doesn’t by itself create ownership.
It changes the infrastructure while leaving the same gap in the learning layer. The domain expertise an organisation builds through AI deployment needs to be encoded in the infrastructure it governs, not in a relationship with a provider it can’t control.
The real question is whether the institutional knowledge the AI systems accumulate over time and are trained on sits inside the organisation’s environment or inside someone else’s.
What governance frameworks need to account for
Most organisations recognise vendor dependency as a risk. Far fewer have taken concrete steps to address it at the architecture level. That gap is widest precisely where it matters most. The decisions made in year one of an AI deployment compound into entrenched dependencies by year three.
The practical questions for any executive team reviewing AI governance are:
- What workflows are now critically dependent on a specific third-party model version?
- What is the migration cost and timeline if that version is deprecated or the provider’s terms change?
- Where does the domain expertise accumulated through our AI deployments actually reside, and does the business own it?
These are standard vendor risk questions. The reason they haven’t been applied to AI is that the field moved quickly enough that most organisations prioritised getting deployments working over assessing what they were becoming dependent on. That window is narrowing.
Only about one-third of organisations currently report scaling AI across the enterprise according to McKinsey. This means the majority still have time to make architectural decisions before operational dependency becomes too embedded to change.
The organisations that use that window to ask ownership questions, not just capability questions, will be in a materially different position when the next provider policy change or model deprecation cycle arrives.
