Walk the floor at Web Summit in Lisbon this year and you will see many booths promising “sovereign AI.” Model builders, US hyperscalers, European cloud providers, and hardware vendors all use the same phrase. Yet if you ask three of them what happens when a foreign court orders the disclosure of prompt logs, or what happens to a hospital’s workflow if an external API key is revoked, you will get three incompatible answers.
The problem for European IT leaders is that “sovereign” is currently used as a marketing adjective rather than an engineering specification. That ambiguity is expensive. When a Chief Information Officer or a Chief Information Security Officer signs off on an AI deployment, they are taking responsibility for where company data travels, which jurisdiction governs the software stack, and whether the system will keep running when a vendor changes its terms. Under the EU AI Act (Regulation (EU) 2024/1689) and the General Data Protection Regulation (GDPR), those obligations stay with the enterprise.
If the market does not share a definition of AI sovereignty, buyers cannot compare offers or match an architecture to the sensitivity of a workload. To give enterprise teams a practical way to evaluate what they are buying, we propose a five-level scale, modelled on the autonomy levels used in the automotive industry. It runs from Level 0, where the enterprise has no technical control at all, to Level 4, where the complete AI stack operates locally under the enterprise’s own authority.
The five levels of AI sovereignty
A working scale for European CIOs
Level | Category | Architectural definition | Where inference and memory live | Residual risk and exposure |
L0 | Uncontrolled commercial AI | Consumer or public SaaS AI tools used directly by employees through browser interfaces or public APIs. | Multi-tenant public servers outside the enterprise’s governance perimeter. | Extreme. Prompts, documents, and business logic leave the company immediately; high exposure to data leakage, possible model training reuse, and compliance breaches. |
L1 | Contractual sovereignty (the enterprise cloud) | Enterprise SaaS or API subscriptions where the vendor promises by contract not to train on customer data and to delete logs. | Provider-controlled cloud infrastructure; legal protection relies on terms of service rather than technical isolation. | High. A contract stops commercial reuse, but it does not override extraterritorial laws such as the US CLOUD Act if the parent provider falls under non-EU jurisdiction. |
L2 | Tenant isolation (“EU sovereign cloud” enclaves) | Dedicated regional cloud zones or partner-operated enclaves located inside the European Union. | EU-based data centres, often still running proprietary hypervisors, models, or control planes owned by non-EU vendors. | Moderate to high. It depends on who owns and operates the enclave. Residency is solved; dependency on the foreign technology provider for software updates remains. |
L3 | Hybrid and architectural sovereignty (local data, cloud LLM) | RAG, vector databases, and orchestration stay on-premises, while calls go out to an external cloud LLM. | Databases stay inside the corporate network; context windows and prompts still travel to an external inference endpoint. | Moderate to high. Calls to the external model send out the most relevant passages of internal documents. They may also expose the organisation’s process knowledge: the sequence and context of tasks show the provider how the business works and makes its decisions. |
L4 | Full autonomous sovereignty | Air-gapped or fully local hosting of the complete stack: hardware, AI gateway, models, RAG, orchestration, and evaluation tools. | Entirely inside the customer’s own premises or private infrastructure, with zero external calls required to operate. | Minimal external exposure. No data or process knowledge leaves the organisation, and inference runs on a European solution. Security, updates and model choice become the organisation’s own responsibility. |
Why geography and contracts are not enough
Most of the confusion in the current market happens between Levels 1, 2, and 3. Vendors frequently present these intermediate setups as full sovereignty because they solve one part of the problem while leaving two others untouched.
1. Data residency is not legal immunity (the Level 1 and Level 2 gap)
A server bolted to a rack in Frankfurt or Dublin gives you data residency. It does not automatically give you legal sovereignty. Under the US Clarifying Lawful Overseas Use of Data (CLOUD) Act, a service provider subject to US jurisdiction can be compelled to preserve or disclose data in its possession, custody, or control, regardless of whether that data is stored inside or outside the United States. Recent reports that US technology companies shared European regulators’ correspondence with US lawmakers show how quickly jurisdiction can override geography.
Both the European Commission’s tech sovereignty strategy and the European Parliament’s recent resolution on technological sovereignty and digital infrastructure point out the structural risk of relying on non-EU cloud infrastructure subject to extraterritorial laws. When an enterprise buys a Level 1 enterprise licence or a Level 2 regional enclave managed by a foreign hyperscaler, it gets a contractual promise and a European postcode. It does not get immunity from foreign legal reach, nor does it control the underlying hypervisor.
2. Local databases still leak context if the model is remote (the Level 3 trap)
Many IT departments have tried to solve this by keeping their documents and vector databases on their own servers while calling a frontier model in the cloud for reasoning. On an architecture diagram, this looks safe because the system of record never moves.
In practice, an AI agent only works if you feed it context. Every time a user asks a question about a procurement contract, a patient file, or a source-code repository, the local RAG pipeline retrieves the relevant paragraphs and sends them to the external LLM inside the prompt. Even if the cloud vendor deletes that prompt after thirty seconds, the enterprise has still transmitted confidential text outside its perimeter, exposed its business processes through metadata, and tied its daily operations to an external API whose price and availability it does not control.
3. True sovereignty includes operational continuity (why Level 4 exists)
The test of Level 4 sovereignty is straightforward: if you unplug the external internet connection at the firewall, does your AI still work?
In a Level 4 architecture, the answer is yes. The compute hardware, the locally hosted language models, the Model Context Protocol (MCP) connectors, the RAG pipeline, the AI gateway, and the evaluation guardrails all run inside the enterprise’s own environment. Nothing is sent out for inference, and no external control plane can throttle throughput, deprecate a model version overnight, or alter per-token pricing once a workflow reaches production scale.
Matching the level to the workload
Defining these five levels is not an argument that every task in a company needs Level 4. If a marketing team is drafting public social media posts from already published press releases, Level 1 is perfectly adequate.
The point of having a strict scale is to stop enterprises from accidentally running Level 4 workloads on Level 1 or Level 2 infrastructure. When an organisation builds agents that read board minutes, adjudicate insurance claims, assist with clinical diagnostics, or inspect proprietary manufacturing designs, the risk profile changes completely. For those processes, a contractual clause or a local database feeding a public API leaves the company exposed.
Before signing an AI infrastructure contract, European IT leaders should ask three questions of every vendor:
- Which jurisdiction governs the parent company that controls the update and management plane?
- Where does the prompt context live during the millisecond of inference?
- What happens to our production agents if we disconnect the external network tomorrow morning?
Until the industry uses the word “sovereignty” with engineering precision, those three questions—and the five levels above—are the clearest way to separate a sales pitch from an architecture.
That is precisely why Austriacard built GaiaB™, a sovereign enterprise AI platform: to give European enterprises a turnkey path to Level 4, full autonomous sovereignty.
GaiaB was engineered from the ground up so that IT departments and system integrators can deploy a complete, industrialised Level 4 architecture behind their own firewall in days rather than months:
- 100% local inference and zero external exposure: In its on-premise deployment, GaiaB combines dedicated, enterprise-grade hardware with pre-configured open-weight models (up to ~300B parameters). Your raw data, vector embeddings, RAG pipelines, and multi-agent reasoning loops never leave your internal network perimeter—even during the millisecond of inference.
- Complete agentic middleware in one platform: Rather than shipping bare hardware, GaiaB integrates the full agentic software stack locally, including an internal Model Context Protocol (MCP) engine to connect safely to your ERP, CRM, and databases, a local AI Gateway with role-based access control and audit logs, an advanced Agentic Framework, and a deterministic local evaluation framework.
- Total operational and financial predictability: Because GaiaB runs entirely inside your perimeter, with no data held by a third-party provider, it keeps your data out of reach of foreign extraterritorial laws (such as the US CLOUD Act), keeps running through WAN outages or third-party kill-switches, and is free from volatile per-token cloud billing.