Building a Sovereign AI Stack, Layer by Layer

You build a sovereign AI stack from the bottom up in six layers: infrastructure, data and context, models, agents, workflows and solutions. Governance is not a seventh layer. It is a fabric you attach at every layer as you go. At each layer there are a few decisions that are expensive to reverse and many that are cheap, and the skill is knowing which are which. This post walks the stack in order, names the decisions, and says what you can safely postpone.

It is the short companion to the full guide to building a Sovereign Intelligence Platform, which has the complete checklist for each stage. For the category itself, start with sovereign intelligence explained.

Where do you start before touching any layer?

Start with requirements, not tools. Write down, in a page, what sovereignty means for your organisation. The seven kinds of control (data, infrastructure, model, intelligence, operational, governance and supply chain) give you a checklist. For each one, answer: what must we control, what can we delegate, and who says so?

Two outputs matter. The first is a data classification that maps classes to permitted locations and permitted models. The second is a list of the regulations and contracts that attach conditions to your AI use. This is step one of the guide, define sovereignty requirements. Everything below inherits it.

Be wary of one trap. Teams often turn "sovereignty" into a single number, such as a country name, and stop. The EU Cloud Sovereignty Framework is a useful corrective. It scores cloud services against eight objectives (strategic, legal and jurisdictional, data and AI, operational, supply chain, technology, security and compliance, and environmental) and uses five assurance levels from 0 to 4. You do not have to adopt it, but it shows how many separate dimensions sit behind the word.

Layer 1: How do you choose infrastructure?

Layer 1, sovereign infrastructure, is control over where and how AI runs. The decisions that are expensive to reverse:

• Deployment model. Public cloud region, private cloud, on-premise or hybrid. The honest answer is often hybrid: sensitive workloads in a boundary you control, bursty or low-risk ones elsewhere.
• Jurisdiction of the operator. Data location is not the same as legal exposure. Under the US CLOUD Act, US-based providers can be compelled to disclose data in their possession, custody or control wherever it sits (CSIS). Decide how much that matters for each data class.
• Key custody. Who holds the encryption keys. Customer-managed keys are designed for on dedicated deployments, not generally available today.
• Inference serving. Whether you run models yourself. Serving open-weight models efficiently depends on memory management of the key-value cache. The PagedAttention paper behind vLLM is the standard reference, and our vLLM deep dive explains continuous batching. Whether you need this depends on volume and sensitivity. The economics are covered in private AI economics for enterprises.

What you can postpone: exact GPU model choices, multi-region failover design and fine-tuned capacity planning. They matter, but they follow from the workload, and early commitments there age quickly.

Portability is worth designing in now. The EU Data Act's cloud switching rules have applied since 12 September 2025 and prohibit switching charges from 12 January 2027 (eprecisio). Even where that does not apply to you, an architecture that can move is a stronger negotiating position. See infrastructure sovereignty.

For Swfte, private, dedicated and hybrid deployment is designed for and scoped per engagement through dedicated cloud, not self-serve. The GPU reference covers the hardware used to serve models. Customer data is stored in AWS eu-west-1 (Ireland) today.

Layer 2: How do you prepare data and context?

Layer 2, data and context, gives AI the context to understand the organisation. This is where most projects spend most of their time, and rightly.

Decisions that are expensive to reverse:

• Permission model for retrieval. Retrieval must honour the permissions of each source system. If a document is restricted to finance, an agent answering for an engineer must not see it. Test this with two accounts, one that should see a document and one that should not.
• Where the index lives. The vector store holds derived representations of your data. It inherits the sensitivity of the source and belongs inside the same boundary.
• Lineage. Every answer should be traceable to the sources that informed it. Without lineage you cannot do traceability later.
• Memory. What an agent may remember across sessions, for how long, and who can inspect or delete it.

What you can postpone: knowledge graphs. They are valuable where relationships matter, such as supplier networks or product hierarchies, but start with well-governed retrieval over documents and add structure where the questions demand it. The RAG architecture and implementation guide gives the build detail, and intelligence sovereignty explains why the knowledge and memory you build here are assets you should own and be able to move. Cortex is the Swfte entry point for answers from your own files.

Layer 3: How do you select and evaluate models?

Layer 3, intelligence and models, turns data and knowledge into useful intelligence.

Decisions that are expensive to reverse:

• The approved model list. Which models may touch which classes of data. This is policy, not preference.
• Open-weight, hosted or tailored. Open-weight models you host give control and cost predictability, and ask for operational skill. Hosted models give frontier capability and ask for trust in the provider. Many organisations run both and route by data class and task.
• Evaluation harness. You need your own evaluations on your own tasks. Public leaderboards do not know your documents. Build the harness before you commit to a model, because it is what lets you switch.
• Exit path. What happens when a model is withdrawn or repriced. The model exit cost audit framework is a practical template.

What you can postpone: fine-tuning. Prompting plus good retrieval gets you a long way, and fine-tuning is easier to justify once evaluations show a specific gap. See model sovereignty and AI model routing and cost optimisation. Connect provides one API for 50+ model providers with routing, failover and cost tracking.

Layer 4: How do you build governed agents?

Layer 4, governed agents, is about acting without uncontrolled authority. An agent is a model plus tools plus a goal plus authority. The authority is the part to design carefully.

Decisions that are expensive to reverse:

• Agent identity. Give each agent its own identity rather than borrowing a person's. It is the foundation for scoped permissions and for attribution in the record.
• Tool permissions. Define what each tool can do, with narrow scopes. A tool that creates draft purchase orders is a different risk from one that issues payments.
• Approval rules. Which actions need a human, and who that human is.
• Trust Profile. The record of identity, owner, risk level, approved models, data classification, data residency, permitted systems, allowed actions, restricted actions, human approval rule, retention, audit and policy set. Write it before the agent ships. See Trust Profile.

Protocols help but do not replace policy. MCP, which Anthropic donated to the Agentic AI Foundation in December 2025 (MCP blog), standardises how agents reach tools. Our posts on the MCP standard and hybrid integration with an MCP layer cover it. The standard tells you how to connect, not whether the connection is allowed.

What you can postpone: multi-agent orchestration. Get one agent right first. When you do get there, multi-agent systems in the enterprise describes the patterns. See operational sovereignty. Studio and Nexus are the Swfte entry points for building agents and for policy and traceability.

Layer 5: How do you design governed workflows?

Layer 5, governed workflows, embeds AI in how the organisation operates. A workflow chains steps, some performed by people, some by software and some by agents.

Decisions that are expensive to reverse:

• Where human steps sit. Put approvals at the points of consequence, not at every step. Approval fatigue turns oversight into decoration.
• Failure behaviour. What happens when a policy denies a step, a model is unavailable or a tool times out. Decide whether the workflow fails closed, escalates or retries.
• Idempotency and rollback. Actions that change records need a way back.
• Ownership. Every workflow has a named owner who is accountable for its outcomes.

What you can postpone: advanced branching, parallelism and long-running orchestration. A simple, well-instrumented flow beats a clever one you cannot trace.

Layer 6: How do you deliver solutions and measure outcomes?

Layer 6, AI solutions, is measurable business outcomes. This is the layer the business sees, and the one that feeds the loop. Choose outcomes before you build: cycle time, resolution rate, error rate, cost per task, or whatever your owner already tracks. Measure the baseline first, otherwise you cannot show improvement.

Evidence from outcomes flows back into layer 2. That is the closed loop, described in the closed intelligence loop: control, intelligence, agency, execution, outcomes, and back into data and context. The organisation gets smarter through AI, inside a boundary it controls.

What you can postpone: broad rollout. Prove one solution against its baseline, then replicate. The use-case template keeps each one in the same order: problem, AI capability, data, agent, workflow, governance, outcome.

How does the trust fabric attach at each layer?

You do not wait until layer six to add governance. Attach the relevant facets as you build.

All thirteen facets (identity, access, data controls, policy, security, privacy, compliance, risk, human oversight, auditability, traceability, evidence and monitoring) are described on the governance page. The architecture reference and sovereign AI reference architecture post show where they sit in the diagram. Traceability, the chain from data to model to agent to decision to action to outcome, is the one that most often gets skipped, and the hardest to add later.

Telemetry deserves a note. OpenTelemetry's GenAI semantic conventions, including agent spans such as invoke_agent and execute_tool, are still at Development status and not Stable, per the project's agent span documentation. Use them, but expect attribute names to change and wrap them behind your own schema.

On compliance: a stack cannot make an organisation compliant by itself. Swfte provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. Check the trust centre for what is true today.

What is a sensible order of work?

You can follow the layers in order, but you do not have to finish one before starting the next. A thin slice through all six, with one use case, teaches more than a perfect layer one.

1. Write requirements and the classification-to-model table.
2. Stand up the minimum infrastructure boundary and identity.
3. Connect one data source with correct permissions.
4. Approve two models and build a small evaluation set.
5. Build one agent with a Trust Profile at L1 or L2.
6. Wrap it in a simple workflow with a named owner.
7. Measure one outcome against a baseline.
8. Feed the evidence back, then expand.

That mirrors the land-and-expand ladder: API, inference, model, private AI, enterprise data, agent, workflow, business solution, dedicated infrastructure, and an enterprise-wide sovereign AI environment. The staged path is spelled out in from AI pilot to governed AI operations.

Where to go next

Work through the full guide for the checklists, or see how ready you are with the Sovereign AI Readiness self-assessment, which runs in your browser and sends nothing anywhere. For a conversation about your own stack, talk to our team.