Sovereignty is an architecture decision, not a hosting choice

A company decides it wants control over its data. The project gets a budget, a supplier is chosen, and eighteen months later the systems run in a data centre inside the country, on contract terms the legal team is happy with. The board is told the company is now sovereign.

Then somebody asks a practical question. If the vendor raised its prices sharply next year, how long would it take to leave? Nobody can answer. The data model belongs to the vendor’s product. The approval chains are configured in the vendor’s admin screens. The encryption keys sit in the vendor’s key service, and the language model that drafts customer replies is called through the vendor’s account. The servers moved. The dependency did not.

The cause is that sovereignty was treated as a question of where, when it is a question of who can do what without asking. Location matters: it decides which law applies and who can be compelled to hand data over. But it is one property among several, and it is the only one you can buy off the shelf. The others have to be designed in.

Where “sovereign” quietly fails

Keys held elsewhere. If the encryption keys live in a service the provider controls, the provider can read the data, and so can anyone able to compel the provider. Data stored in your country and encrypted with a key you do not hold is located, not controlled.

A model of the business you cannot take with you. Every system offers an export. Few export the relations, the rules and the history in a form another system can load. A set of tables without the meaning of their columns is a backup, not an exit.

Logic living in configuration. Approval limits, pricing rules, routing: when these are clicks in a proprietary screen, they cannot be read, reviewed or moved. The way the company works is held in a format only one product understands.

One model, one provider. If every piece of language work goes through a single external model under a single account, the company’s ability to operate now depends on that provider’s prices, availability and terms of use. That is a supply-chain risk, and it rarely appears on a risk register.

An exit nobody has rehearsed. An exit plan that has never been run is a hope. The first time anyone tests whether the company can move is usually the moment it has to.

What to design instead

Treat sovereignty as a set of properties of the architecture, each of which can be checked by someone who does not have to take the vendor’s word for it.

The keys are yours. Encryption keys are generated and held on infrastructure the company controls, and whoever operates the platform cannot use them without the company’s involvement.

The model of the company travels with the data. Objects, relations and rules are described in an open, readable form and versioned, so that what the business means by an order or a customer can leave with the records. That is the job of an ontology: the meaning lives beside the data, not inside one vendor’s product.

Logic is something you can read. Rules and processes are stored as reviewable artefacts with a history, not as the state of a configuration screen. If an agent changed a rule, the change has an author, a reason and an approval.

Models are replaceable. Language work is routed per task, so sensitive work can go to a model on your own hardware and general work to a frontier model, and either can be swapped without rewriting the processes that use them. Where a small model on your own hardware is good enough, the architecture should let you use it.

The stack is open source where it matters. Open source does not guarantee sovereignty, but it removes the one dependency you can never negotiate away: permission to run the software at all.

This is the design Hurukan is being built to. Its Security and Sovereignty layer enforces permissions on the server, audits every change as made by a person, an agent or the system, runs on infrastructure the company chooses and writes the exit down at the start. It is in build, not deployed, so what is described here is the design, not a track record.

A test you can run this week

Take one process that matters. Invoicing is a good candidate, because it touches customers, prices, payments and the law. Answer five questions in writing:

1. Where are the encryption keys for this data, and who is able to use them?
2. If you exported everything today, could another system reproduce what an invoice means here: its states, its approval rules, its links to orders and payments?
3. Where do the rules for this process live, and can a person read them without logging in to the vendor’s tool?
4. Which external models touch this data, under whose account, and what happens to the process if that model is unavailable for a week?
5. When did anyone last move this process, or a copy of it, to different infrastructure?

Any question that takes more than a day to answer marks a dependency nobody designed. The answers also show which data deserves the most care, which is the subject of a separate piece on deciding what must never leave the building.

Sovereignty bought as a hosting contract lasts until the first hard negotiation. Sovereignty designed into the keys, the model, the logic and the exit is still there when the negotiation gets difficult. The Hurukan overview shows how the layers fit together.