The sovereignty conversation has matured. Two or three years ago it was a procurement question — which region is the data centre in? — and most enterprises have since discovered that the answer on the invoice and the answer in the architecture are different things. Surveys through 2025 and 2026 show a measurable shift of AI inference toward private infrastructure, and a large majority of executives now say they factor a vendor's country of origin and data handling into buying decisions. The direction is clear. The definition is still blurry.
Here is the definition we work with: sovereignty is a property of your context, not of your hardware. And context is a more demanding thing to protect than data.
Context is the asset nobody put on the balance sheet
A record is a fact: an invoice number, an amount, a date. Context is what makes the fact answer a question — which customer it belongs to, how that customer relates to three other entities, what happened last time, which definition of "revenue" your board agreed, and what the person asking is allowed to see. Context is the accumulated, organised memory of how your organisation actually works.
When an AI system answers a question about your organisation, the quality of the answer is mostly the quality of the context it was assembled from. The model is interchangeable; the context is not. Whoever holds your context holds the thing that makes every future answer possible — and if that context lives inside a vendor's system, assembled in their format, improving their product, you have rebuilt the lock-in the industry just spent a decade escaping, one layer up the stack.
This is why we say: own your context, rent your intelligence. Models are a market. Context is an asset.
What leaving the building actually looks like
The naive picture — someone emailing a database to a model provider — is not how context leaks. It leaks politely, a request at a time.
A support agent that sends the whole ticket, the customer record and the account history to an external API with every question is exporting context. A retrieval system whose index lives on someone else's infrastructure is exporting context. An analytics copilot that learns your definitions, your thresholds and your naming conventions inside a vendor's cloud is exporting the most valuable layer of all — and you will discover exactly how valuable on the day you try to leave.
The fix is not to refuse external models. It is to draw the boundary correctly and be precise about what crosses it.
The technical detail
A well-drawn boundary has three properties.
First, records never cross. Questions are resolved against an ontology over live records inside your perimeter; what goes out, if anything goes out, is a task-shaped question stripped of the records it came from.
Second, inference is a choice, not a default. A model running inside your boundary — on your hardware or in your tenancy — means nothing crosses at all. An external model means a contracted, audited, minimal crossing. Both are ordinary configurations of the same codebase; the difference is a setting, not a rebuild. That last property matters more than it sounds, because it is what stops sovereignty being a diminished edition you apologise for.
Third, evidence stays home. The record of what was asked, what was answered, on what basis and under whose authority is append-only and yours. A vendor can rent you intelligence. They should never end up owning your audit trail.
The Monday question
Ask your AI vendor one question: if we leave, what do we take?
If the answer is your raw data and a farewell email, the context — the joined, governed, definition-carrying asset your answers were built from — was never yours. If the answer is the ontology, the definitions, the evaluation sets, the records of every decision and the means to run the same queries elsewhere, you own your context.
Everything else is a detail.