Software sovereignty: keep the data, keys and choice
Sovereignty does not mean hosting everything yourself. It means retaining the practical ability to explain, export, replace and operate critical product components without asking a provider for permission.
Define what must not become captive
Start with an inventory of critical assets: user data, decision history, business rules, identities, keys, prompts, evaluations and export formats. They do not all require the same level of control.
For each one, ask: if this provider disappears or changes terms tomorrow, can we still serve the user? The answer determines where portability, local-first processing or self-hosting deserves investment.
Process data as close to the need as possible
Local-first matters when latency, confidentiality, offline work or data ownership are decisive. It does not eliminate cloud services; it prevents the cloud from becoming the only place where the product and its data can exist.
Minimization is still the first control. Not collecting data reduces more risk than wrapping unnecessary collection in layers of protection. Document purpose, retention and deletion before integrating a model.
Build a boundary around providers
Model, storage and delivery calls should pass through stable internal contracts. Keep business formats in your system and translate them at the provider boundary. This stops an external schema from becoming your architecture.
Portability does not require maintaining five providers in parallel. It requires a tested exit scenario: complete export, key replacement, migration of a small sample and an inventory of features that would be lost.
Keep the ability to operate and reverse
Secrets stay outside code, with minimum permissions and a rotation path. Critical actions need a record, an owner and, where possible, compensation or rollback.
Keep a useful degraded mode. When a remote model is unavailable, the product can sometimes fall back to search, a rule, local processing or a queue. Sovereignty is also measured on the day a dependency fails.
The sovereignty test
- 01
Critical data exports to a documented format
- 02
Business rules do not live only inside a provider
- 03
Secrets are separate, scoped and rotatable
- 04
Changing models does not rewrite the whole product
- 05
Deletion and retention can be operated
- 06
A provider exit scenario has been tested
- 07
A degraded mode keeps real utility