Sovereignty as a product, or sovereignty as property
Published on · LINAGORA
The thesis
The word sovereignty covers two incompatible realities. One is bought as a contract and a service level, it is real for as long as the contract runs, and it disappears the day that contract changes hands. The other is owned, audited and transferred. Confusing the two at the moment of purchase is the most expensive mistake in the current market.
Two definitions that do not overlap
Sovereignty as a product is a contractual promise: a supplier commits on where processing happens, on service levels and on confidentiality clauses. It is a legal guarantee, backed by the supplier's solidity and by the duration of its commitment.
Sovereignty as property is a technical property: you hold the components, you can audit them, run them elsewhere and hand them to a third party. It depends on no promise, because it rests on none.
The two can coexist, and the best arrangement combines them. But they do not substitute for one another. A buyer who believes they are acquiring the second while signing for the first discovers the gap at the worst possible moment: the one where they want to leave.
What a regional endpoint does not guarantee
The most common argument is that the service is reachable from a European region. That is information about where a server sits. It is not information about the real path your data takes.
As soon as the system calls external tools, runs searches, or involves second-tier subcontractors, the effective route of the data stops being described by the main contract. Execution logs and backups often follow a policy distinct from production data, and that is where location is lost most quietly.
The useful question is therefore not where the servers are, but whether you can obtain an up-to-date flow diagram, including outbound calls, the named list of subcontractors and the legal regime of each. A supplier who cannot produce that diagram is not necessarily lying: they do not know.
The supplier who becomes a reseller
There is a mechanism, independent of any brand, that a buyer should learn to recognise. A supplier builds its position on the fact that it produces its own technology. Then, under the pressure of the pace of innovation or of training costs, it starts distributing third-party models under its own contractual envelope.
Commercially, this is rational: the catalogue widens without investment. From the client's point of view, something decisive has changed. The guarantee they were buying rested on their supplier's control of the technology. It now rests on a contract between two third parties, to which they are not a party and whose terms they do not know.
This is not a scandal, it is a shift in business model. But it should trigger a rereading of the contract, because it moves the risk without the price changing.
The commitment with no way out
A multi-year commitment is not a problem in itself. It becomes one when no exit is provided, neither technically nor contractually, and when that absence is publicly presented as a strength of the relationship.
Such a commitment is not sovereignty. It is dependency, simply better located than the previous one. The data is in Europe, the decision is not: it belongs to whoever holds the only possible execution path.
The test is simple and requires no technical skill. Ask to see the exit procedure. Not the clause: the procedure. How long, in what format, which data recovered, which data lost, at what cost. If nobody can produce it, it does not exist.
Eight criteria to apply before signing
We use this grid in our audits. It fits in eight lines, it requires no technical expertise, and it separates the two definitions without argument.
Nature of the commitment: a contract and a service level, or an asset owned and transferable. Model weights: reachable through an interface and not redistributable, or open, downloadable and retrainable. Data path: guaranteed by clause and opaque on external calls, or verifiable on your own infrastructure. Commitment period: multi-year and often non-terminable, or none, because reversibility is structural.
Exit cost: loss of the integration investment, or a technical migration with the data preserved. Change of supplier: renegotiation or breach, or replacement of a component. Auditability: on declaration, or on the code and the weights. What is left at the end: a billing history, or a system, weights and skills.
None of these criteria is ideological. Each can be checked against evidence.
What this means for your organisation
Real reversibility requires three conditions at once, and two out of three will not do. Open building blocks first: without accessible code and weights, leaving means starting from scratch. Hosting outside extraterritorial law next: without it, your data remains reachable by a jurisdiction you did not choose, however good the contract. Documented integration last: an open but unreadable system cannot be handed to anyone.
These three conditions describe exactly the arrangement we build and operate. It is not the simplest path in the short term, nor the cheapest in year one. It is the only one that holds over ten years.
Before your next signature, apply the eight-criteria grid to the offer you are about to choose, and to the one you already have. The comparison is often more instructive than the audit itself.
The related advisory module
Know what you signed, and what leaving would cost
The dependency and reversibility audit applies this grid to your contracts and your real data flows, and puts a figure on the exit plan.