Infrastructure Sovereignty for AI: Compute, Hosting, Deployment and Dependencies

What does infrastructure sovereignty cover?

It is layer 01 of the platform, Sovereign Infrastructure: control over where and how AI runs. Four controls define it.

• Compute. Which accelerators and servers run training and inference, who owns or leases them, and how capacity is reserved.
• Hosting. The facility, the operator and the jurisdiction they answer to.
• Deployment. How software reaches that hardware: containers, orchestration, release control, and whether you can run it in an environment of your choosing.
• Dependencies. Everything the runtime needs that you do not control: provider APIs, control planes, licence servers, package registries, update channels.

Dependencies is the one most often skipped. A system can be hosted exactly where you want and still stop working because a remote licence check, model download or management plane in another jurisdiction is unreachable. List those dependencies the way you would list sub-processors. The wider treatment is in supply-chain sovereignty.

Cloud, private cloud, on-premises or hybrid?

There is no single correct answer. The aim is to be able to choose per workload and change your mind. The trade-offs are mostly about who carries operational responsibility.

Hybrid is the realistic destination for most organisations, and it makes a single policy and audit plane more important, not less. If policy differs by environment, the weakest environment sets your real posture. Swfte's dedicated cloud describes isolated VPC or bare-metal deployment in a public cloud or your own data centre. Private, dedicated and hybrid deployment are designed for and scoped with you through a dedicated deployment engagement; they are not self-serve. The older economics question is examined in private AI on-premises economics.

What do GPUs and inference serving have to do with it?

If you host models yourself, you inherit the engineering of serving them. Two facts shape the infrastructure decision. First, large language model serving is limited by memory as much as by raw compute, because every active request holds a key-value cache that grows with context length. Second, how well the serving software manages that memory changes how many requests a given GPU can handle.

The PagedAttention paper (opens in a new tab) (Kwon et al., SOSP 2023) described managing the KV cache in non-contiguous blocks, in the way an operating system pages memory, which reduced waste and underpins the vLLM serving engine. Continuous batching is a related but separate scheduler technique: the scheduler can add and remove requests at each step rather than waiting for a whole batch to finish. Our deep dive on vLLM continuous batching covers it in practical terms.

For sovereignty, the point is not the technique. It is that serving choices are infrastructure choices you can make for yourself on hardware you control, and that the capacity you reserve defines what you can run without a third party. For GPU reference material, see the GPU guide. When you size capacity, plan for peak concurrency and long contexts rather than average load, keep a hosted fallback for overflow if your policy allows it, and make sure the policy classes in data sovereignty decide what may spill over.

How do portability and exit work?

Sovereignty you cannot exercise is decoration. The test of infrastructure sovereignty is whether you can leave. Regulation now helps here for cloud services in the EU. The Data Act (Regulation (EU) 2023/2854) became applicable on 12 September 2025, and its Chapter VI obliges cloud providers to remove barriers to switching, including to on-premises solutions, with notice and transition periods set in the Act. Switching charges are capped at cost until 12 January 2027, after which they are prohibited under Article 29. See the summaries at eprecisio (opens in a new tab) and Atomity (opens in a new tab), and verify against the text before relying on them.

The regulation removes some contractual barriers. It does not remove architectural lock-in. Practical exit readiness means:

• Workloads packaged as containers with declared dependencies, deployable to another environment.
• Models and adapters stored in formats you hold, not only inside a provider's console.
• Data, indexes and logs exportable on request, with a tested restore elsewhere.
• A model gateway or abstraction between applications and model providers, so a provider can be swapped without application rewrites. See Connect and model exit costs.
• An exit plan with owners, a rehearsal and a cost estimate, reviewed on a schedule.

How does the EU Cloud Sovereignty Framework apply?

The European Commission's Cloud Sovereignty Framework (opens in a new tab) is a method for assessing how sovereign a cloud service is. It scores services against eight sovereignty objectives, SOV-1 to SOV-8: strategic, legal and jurisdictional, data and AI, operational, supply chain, technology, security and compliance, and environmental. Each is rated on a five-level scale called SEAL, from 0 to 4. It is used in public procurement, where a tender can set a minimum level per objective.

Even if you are not a public buyer, it is a useful checklist. Its objectives map onto the seven sovereignties here: legal and jurisdictional and data and AI onto data sovereignty, operational onto operational sovereignty, supply chain onto supply-chain sovereignty, technology (openness, interoperability and lock-in) onto the portability points above. Swfte does not claim an assessment against this framework. Treat it as vocabulary for your own requirements. The mapping to the full platform is in the architecture reference.

What does Swfte offer here?

Swfte treats infrastructure as one layer of one platform, not as the identity of the company. The platform is designed to let you run on infrastructure you control, from cloud to private cloud, on-premises and hybrid, and to enter at that layer or to arrive at it later.

• Today. Customer data is stored in AWS eu-west-1 (Ireland). On-device mode runs prompts through a local model on a Mac. See the trust centre for exactly what is true today and what is in progress.
• Designed for. Dedicated cloud deployments, in an isolated VPC or bare metal, with data residency agreed per engagement, and GPU and inference capacity for hosting models, alongside the GPU reference. Scoped with you; not self-serve.
• Across the platform. The same policy and audit approach applies whichever environment a workload runs in, through Nexus and the governance fabric.

Specific commitments, such as hardware, regions or capacity for a dedicated deployment, are agreed in the engagement. Public detail on hardware, regions and capacity: <capacity and region details - founder to fill>.

An infrastructure sovereignty checklist

1. Inventory where every AI workload runs, who operates the environment and which jurisdiction they answer to.
2. List runtime dependencies that live outside your control: control planes, licence checks, model downloads, update channels.
3. Choose a deployment option per workload and state the reason, tied to data class.
4. Reserve or plan GPU capacity for peak concurrency and long contexts, with a defined overflow rule.
5. Run one policy and audit plane across all environments.
6. Package workloads so they can move, and rehearse a move at least once.
7. Keep a written exit plan with owners, a rehearsal date and a cost estimate.
8. Re-review against the cloud-switching terms in your contracts before the 12 January 2027 change to switching charges.

Use this alongside step 2 of the build guide. The CTO checklist turns it into questions for vendors.