Model sovereignty: who decides which AI models your organisation runs

What does model sovereignty actually cover?

Model sovereignty is one of the seven kinds of sovereignty in the Sovereign Intelligence Platform. The brief for the category defines it through four verbs: selection, deployment, customisation and lifecycle. Each one is a decision someone in your organisation either owns or has quietly handed to a supplier.

• Selection. Which models are approved, for which purposes, and who can approve a new one.
• Deployment. Where a model runs: a provider's hosted API, a private cloud, your own data centre or a laptop. This is where model sovereignty meets infrastructure sovereignty.
• Customisation. How a model is tailored to your work, through prompts, retrieval, fine-tuning or adapters, and who owns the result.
• Lifecycle. How a model version is introduced, tested, pinned, monitored, replaced and finally retired.

The common failure is not choosing a hosted model. It is building so tightly around one model that replacing it becomes a project nobody can afford. Sovereignty here is about keeping the exit door usable, whether or not you ever walk through it. For the wider definition, see what sovereign intelligence is.

What are the four ways to run a model, and what does each cost you in control?

Most organisations end up using more than one of these at once. The point of the table is to make the trade-off explicit, not to rank the options. No row is wrong for every workload.

Open-weight models are not automatically sovereign, and hosted models are not automatically a loss of control. An open-weight model on a single rented GPU with no evaluation suite and no one who can upgrade it is a dependency on one engineer. A hosted model reached through a gateway you control that can swap it in an afternoon is a dependency you can manage. The deployment pattern matters less than the answer to the question: how hard is it to change?

For the cost side of self-hosting, read the economics of private AI and the open-source LLM cost guide. For how inference engines actually serve these models, the vLLM continuous batching deep dive is a good technical companion.

Which licences and terms should you read before approving a model?

A model is a set of weights plus a set of terms. The terms decide what you may do with it. Legal and procurement should read them, but engineers need to know which clauses to flag, because the clauses change the architecture.

• Permitted use. Some licences restrict commercial use, use above a certain scale, or specific sectors. Others restrict using model outputs to train a competing model.
• Redistribution and modification. Can you host it for subsidiaries, ship it inside a product, or publish a tailored derivative?
• Acceptable-use policies. Many licences include a policy that can be updated. Record which version you accepted and when.
• Provider terms for hosted models. Look for prompt and output retention, whether content may be used to improve the provider's models, sub-processors, where processing happens and what notice you get before a model is withdrawn.
• Training-data and provenance statements. These matter for downstream obligations. General-purpose AI model providers have had transparency obligations under the EU AI Act since 2 August 2025, as summarised by Usercentrics (opens in a new tab). Ask what documentation the provider can give you.

Summarise the outcome in one record per model. Swfte's model cards show the shape: what the model is for, what it is not for, and where it runs. Your own record should add the licence version, the approving owner and the data classes the model may touch.

How do you build a model approval list that people will actually use?

An approval list is the smallest piece of model governance that works. It answers three questions for every model: who approved it, for what purpose, and for which data. Without it, shadow AI fills the gap, because people use whatever model gets the job done.

1. Start from the data classes, not the models. Decide what each class of data may reach. A model is approved for a class, not in general.
2. Define an intake path that takes days, not quarters. If approval is slow, teams route around it. Publish what evidence a new model needs: licence review, evaluation results on your tasks, location and retention facts.
3. Record an owner per model. Someone accountable for its behaviour, its cost and its retirement.
4. Make the list machine-readable. A policy that lives in a document cannot stop a call. The approved list should be the configuration the gateway enforces, so that an unapproved model fails closed.
5. Review on a schedule. Models change, terms change and your needs change. A list nobody reviews is a list of past decisions.

This is the same principle as runtime governance: the list changes what the system can actually do, rather than describing what it should do.

How should routing policy follow data classification?

Routing is where model sovereignty becomes operational. Instead of every team choosing a model, a routing policy decides which model serves a request, based on the data in it, the task, the cost and the risk. The table below is an illustration of the structure, not a recommendation for any specific model.

Failover needs the same discipline. A fallback from a private model to a hosted one can silently move confidential data across a boundary. Fallback targets must be approved for the same data class as the primary, or the request should fail. Cost routing, covered in the model routing guide, works inside these limits and never above them.

Why are evaluations the gate for every model change?

Swapping a model without evaluation is changing production behaviour on faith. The way to make models replaceable is to make evaluation cheap, repeatable and owned by you. That means an evaluation set built from your own tasks, with expected outcomes agreed by the people who understand the work.

• Own the eval set. It is part of your intelligence sovereignty. A vendor's benchmark tells you how a model does on the vendor's tasks.
• Test what matters to the workflow. Accuracy on extraction, refusal behaviour, tool-calling reliability, latency and cost per task, not just general capability scores.
• Include safety and policy cases. Prompts designed to elicit disallowed behaviour, and cases where the right answer is to escalate to a person.
• Run the suite on every change. New model, new version, new prompt template, new retrieval index. A pass is the condition for promotion.
• Keep the results. Evaluation records are evidence. They show why a model was approved and what changed when it was replaced.

The guide covers this in practice in step 4, select and evaluate models.

Should you fine-tune a model or use retrieval?

Customisation is where teams most often over-invest. Start with the cheapest control that works and move up only when evaluation shows you need to.

The rule of thumb is that facts belong in retrieval and behaviour belongs in tuning. Facts in weights go stale and cannot be access-controlled per user. If you fine-tune, treat the adapter as an asset with an owner, a data lineage and a re-training plan.

How do you pin versions, retire models and plan an exit?

Lifecycle is the least glamorous and most underrated part of model sovereignty. Models are withdrawn, repriced and silently updated. An organisation that cannot answer which model version produced a given output cannot investigate an incident or reproduce a decision.

• Pin versions explicitly. Call a named version, not an alias that moves. Record the version in the audit trail next to each output.
• Schedule retirements. Every approved model gets a review date. Track provider deprecation notices as an input to that schedule.
• Keep a tested alternative warm. For each critical workflow, one qualified replacement that has passed your evaluation suite.
• Write the exit plan before you need it. What data, prompts, tuned adapters and integrations would move, how long it would take, and what you would lose. The model exit cost audit framework is a worked method.
• Watch the supply chain. Model, serving stack and hardware are dependencies too. See supply-chain sovereignty.

Where does Swfte fit?

Model sovereignty sits in Layer 03 of the platform, Intelligence and Models: turning data and knowledge into useful intelligence. Swfte's Connect is one API for 50+ model providers, with smart routing, failover and cost tracking, and BuildX provides the model gateway. They are designed so that the model is a configuration choice behind a policy, not a hard-coded dependency.

For workloads that must run on infrastructure you control, the platform is designed for private, dedicated and hybrid deployment through dedicated cloud, scoped with you and not self-serve. Where a deployment option is not generally available, the trust centre says so. Model approval and routing are enforced alongside identity, policy and audit, as part of the trust fabric that runs through all six layers.