EU-First AI Stack Architecture: Six Layers, One Trust Fabric
A reference architecture for an EU-first AI stack: six layers, one trust fabric and the EU data boundary.
"EU-first" is easy to say and hard to draw. This post is a reference architecture: what an EU-first, sovereign-by-design AI stack looks like layer by layer, where the EU data boundary has to sit, and how each regulatory requirement maps to a control and a piece of evidence. We use Swfte's six layers and Trust and Governance Fabric, but the structure works for any stack.
Last verified 2026-10-06. Legal references link to EUR-Lex or Commission pages; commentary-only items are marked as such.
Start with the definitions
EU-first here means the architecture starts from European requirements (the AI Act, GDPR, NIS2, DORA and the Data Act) and works outward, rather than bolting a region selector onto an existing design.
Sovereign by design means the organization keeps meaningful control over its AI estate: data, infrastructure, models, operations, governance and supply chain, not just where a server sits.
Audit-ready means the evidence a regulator or customer will ask for is a by-product of operation. Evidence on demand is the same idea from the auditor's side: you can retrieve who did what, with which data and model, under which policy.
The six layers
| # | Layer | Purpose | Boundary question it answers |
|---|---|---|---|
| 01 | Sovereign Infrastructure | Control over where and how AI runs | Which jurisdiction and which operator hold the compute? |
| 02 | Data and Context | Give AI the context to understand the organization | Where do retrieval indexes and connectors live, and who can read them? |
| 03 | Intelligence and Models | Turn data and knowledge into useful intelligence | Which models are approved, where are they served, and can you swap them? |
| 04 | Governed Agents | Act without uncontrolled authority | What may each agent do, and what needs a human? |
| 05 | Governed Workflows | Embed AI in how the organization operates | Where are the approval points and the escalation paths? |
| 06 | AI Solutions | Measurable business outcomes | Which risk class and which regulatory role does each solution carry? |
In Swfte these map to dedicated cloud and GPU inference, Cortex and Connect, the BuildX model gateway (50+ models), Studio and Nexus, Studio workflows, and Solutions. Each layer has its own boundary decision: a stack that is EU-hosted at layer 01 but sends retrieval context to a third-country embedding API at layer 02 is not EU-first.
Layer 01: Sovereign infrastructure
Compute, hosting and deployment dependencies. The questions are jurisdiction (which legal system can compel access), operator (who administers the machines) and dependency (what does this layer call that you did not choose). For NIS2, supply-chain security and continuity under Art 21(2) start here.
Layer 02: Data and context
Knowledge bases, vector indexes, connectors. Most personal data enters here, so this layer carries the GDPR weight: lawful basis, minimization, retention and the DPIA trigger. Retrieval indexes are copies of your data and must sit inside the same boundary as the source.
Layer 03: Intelligence and models
A model gateway gives you one place to enforce which models are approved for which data classification, and one place to change your mind, which matters for DORA exit planning and Data Act switching. See the model exit-cost audit framework and avoiding AI vendor lock-in.
Layers 04 and 05: Governed agents and workflows
Agents act; workflows embed them in operations. Both need identity, a permitted-actions list and human approval points. Swfte describes five controlled-autonomy levels, from L1 Assist (AI recommends) to L5 Adaptive (improves within controlled boundaries), so autonomy rises deliberately. For AI Act Art 14 human oversight and Art 26 deployer duties, these layers are where oversight is implemented.
Layer 06: AI solutions
Finished applications, where you answer the role question: provider, deployer or high-risk Annex III case? Use the classification flowchart and checklist.
One trust fabric, not a seventh layer
The Trust and Governance Fabric runs through all six layers and has thirteen facets:
- Identity, Access, Data controls, Policy
- Security, Privacy, Compliance, Risk
- Human oversight, Auditability, Traceability, Evidence, Monitoring
Traceability is the chain from data to model to agent to decision to action to outcome. Guardrails answer "should this be blocked?" Governance asks who is acting, allowed to do what, under which policy, with which data and model, at what risk, with what oversight, and can we prove it? The verbs are Allow, Deny, Warn, Filter, Escalate and Require human approval.
The anchor is the Trust Profile attached to each AI system: identity, owner, risk level, approved models, data classification, data residency, permitted systems, allowed actions, restricted actions, human approval rule, retention, audit and policy set.
Where the EU data boundary sits
The EU data boundary is the line inside which an AI system's data and compute stay, and across which nothing moves unless you decided it should. In-region inference is a narrow claim by itself. A defensible definition covers six things, plus a question about people:
| Element | What must sit inside the boundary | Common leak |
|---|---|---|
| Prompts | Prompt and response payloads in transit and at rest | A model API endpoint outside the region |
| Retrieval indexes | Embeddings, vector stores, document chunks | A hosted embedding or rerank service elsewhere |
| Weights and inference | Model weights and the GPUs that run them | Fallback routing to another region on overload |
| Logs | Traces, prompts captured for debugging, audit logs | A log or observability SaaS with its own region |
| Backups | Snapshots, replicas, disaster-recovery copies | A DR region chosen for cost |
| Admin access | Who can administer all of the above, from where | Support staff or vendors with out-of-region access |
The last row is the one most diagrams miss: data stored in the EU but administered from outside it carries a different risk profile. See what in-region must mean and data sovereignty for enterprise AI.
Transfers outside the boundary fall under GDPR Chapter V (adequacy, SCCs, derogations). The EU-US Data Privacy Framework (adequacy decision of 10 July 2023) faces a pending appeal, C-703/25 P, according to a policy tracker.
Deployment options
The same architecture is designed to let you run in four modes, scoped through a dedicated deployment engagement, not self-serve:
- EU region. Today the trust page states that customer data is stored in AWS eu-west-1 (Ireland).
- In-country. Designed to let you pin hosting to a single country for national data-residency requirements.
- Dedicated. Single-tenant infrastructure for one organization.
- On-prem or hybrid. Designed to let you keep inference and data on your own premises, or split workloads. See on-prem economics and the air-gapped deployment checklist.
The boundary table above looks different in each mode.
Requirement, control, evidence
Controls are what a stack like this implements; evidence is what you should be able to produce.
| Regime | Requirement | Architectural control | Evidence on demand |
|---|---|---|---|
| AI Act | Human oversight (Art 14); deployer oversight and logs kept at least six months (Art 26) | Approval rules per Trust Profile; Require-human-approval verb; autonomy levels | Approval records, retained logs |
| AI Act | Risk management, documentation, logging (Arts 9, 11, 12) | Traceability chain; per-system risk level | Data-to-outcome trace; documentation |
| AI Act | Transparency (Art 50, applies since 2 Aug 2026) | AI disclosure in interfaces; output marking where generative | Screenshots, configuration, marking tests |
| GDPR | Processor terms, security, DPIA (Arts 28, 32, 35) | Data classification; encryption; retention rules | DPA, DPIA, records of processing |
| GDPR | Transfer rules (Chapter V) | EU data boundary; approved-model list by region | Region configuration, transfer assessments |
| NIS2 | Art 21(2) measures; 24-hour early warning, 72-hour notification (Art 23) | Access control, MFA, incident routing, supply-chain review | Incident timeline, access reviews |
| DORA | ICT third-party risk, exit strategies, concentration (Arts 28 to 30) | Model gateway for substitutability; dependency inventory | Register of information, exit plan |
| Data Act | Cloud switching (Chapter VI); switching charges end 12 Jan 2027 | Portable data and configuration; no proprietary-only formats | Export test, contract terms |
For the pages behind each row, see GDPR for AI, NIS2 for AI, DORA for AI, Data Act and AI and the AI Act timeline. The evidence column is the subject of building an AI Act evidence pack. Data Act dates come from the Commission fact page.
Why no one can certify "sovereign" yet
No sovereignty certificate exists in law today.
- The EU cloud certification scheme (EUCS) has not been adopted. The Commission's 20 January 2026 proposal to revise the Cybersecurity Act, according to Clifford Chance, sets a new procedure but excludes sovereignty requirements from certification.
- The Cloud and AI Development Act (CADA) is a Commission proposal published on 3 June 2026, not law. According to law-firm commentary, it contemplates four Union Assurance Levels (EU location, third-country independence, EU ownership and control, full supply-chain control), mainly applied through public procurement, with adoption targeted around 2027.
Practical consequence: "sovereign" is a design property you can describe and evidence, not a label someone can issue. Write your own definition into procurement. We make no claim that Swfte meets any CADA level. The banks and public-sector companion is the EU sovereign AI stack.
How Swfte supports this
Swfte is a Sovereign Intelligence Platform built for Europe, and its six layers and 13-facet Trust and Governance Fabric are designed to let you apply this architecture with EU-first defaults: EU region hosting today, with in-country, dedicated and on-prem or hybrid deployment designed to be scoped through a dedicated deployment engagement. Swfte provides the technical controls, governance mechanisms and evidence to support deployment within applicable requirements; the exact posture depends on use case, jurisdiction, deployment and configuration. See /eu, /platform/governance, /platform/sovereignty, /platform/trust-profile and /trust for what is in place and what is still in progress.
This is not legal advice. Verify the current text and your national rules with counsel before you rely on any mapping above.
Related: Swfte Connect lets you restrict routing to approved providers and keep sensitive traffic on models you host; see EU-first routing with Connect.