What SEAL-3 Means for Your AI API
In October 2025, the EU published its Cloud Sovereignty Framework, introducing the SEAL classification system. It gives organizations a way to measure how much control they actually have over their cloud infrastructure, from "none" to "complete." If you're running AI workloads that touch EU personal data, understanding SEAL levels is no longer optional.
The SEAL levels, explained
SEAL stands for Sovereignty Evaluation and Assessment Levels. It ranges from 0 to 4, with each level adding a layer of control over where your data lives, who can access it, and under what legal authority.
| Level | Name | What it means | Real example |
|---|---|---|---|
| SEAL-0 | No controls | Data processed anywhere, no sovereignty measures | A startup using OpenAI's API with default settings |
| SEAL-1 | Jurisdictional | Subject to EU law, but non-EU operational parent | AWS eu-central-1 with default CloudWatch logging |
| SEAL-2 | Data sovereignty | Data and processing under EU control, customer-managed encryption | OVHcloud with customer-managed keys |
| SEAL-3 | Operational control | EU-domiciled provider, EU operational control, digital resilience | EU-native provider + EU monitoring + documented exit plan |
| SEAL-4 | Full sovereignty | Complete EU control, no non-EU critical dependencies, hardware isolation | Confidential computing on EU hardware with HSM-backed keys |
The framework was published alongside EUR 180 million in EU Commission procurement budgets that now require SEAL-2 or higher. Financial sector RFPs are increasingly referencing SEAL-3 as a baseline. This is not theoretical.
Why SEAL-1 is not enough
Most companies using AI APIs today operate at SEAL-0 or SEAL-1. They send prompts to a US provider, maybe in an EU data center region, and assume that counts as compliant. It does not.
Here is what happens when you use a US-based AI provider with an EU region:
Your data is under US jurisdiction. The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) allows US authorities to compel any US-incorporated company to produce data, regardless of where that data is stored. Having your data in Frankfurt does not protect it from a US subpoena. The Schrems II ruling in July 2020 invalidated the EU-US Privacy Shield precisely because of this conflict.
Your subprocessor chain is invisible. EDPB Opinion 22/2024 requires controllers to maintain real-time visibility into every processor and subprocessor touching their data. No exceptions by risk level. When you use a US AI provider, your prompts may pass through monitoring tools (Datadog, CloudWatch), logging pipelines, and abuse detection systems that you have never been told about and have no contractual control over.
Standard Contractual Clauses are not a fix. After Schrems II, the EDPB explicitly stated that SCCs alone are insufficient for US transfers. You need "supplementary measures," and the only technical measure the EDPB has identified as adequate is customer-controlled encryption with EU-held keys. That is hard to implement when the AI provider needs to read your prompts to run inference.
What SEAL-3 actually requires
SEAL-3 is where most regulated workloads should aim. It requires:
- EU-domiciled provider: the company operating your infrastructure is incorporated in the EU and subject to EU law, not just hosting in an EU data center
- EU operational control: no non-EU entity can access your data through legal or technical means
- Automated processor chain tracking: quarterly verification at minimum, continuous monitoring preferred
- Documented exit strategy: a 12-month runbook for migrating away from the provider, as required by the ECB Guide on Cloud Outsourcing (July 2025)
- DPIA completed before processing: the EDPB found that 63% of public sector cloud deployments had no DPIA before processing began. That is no longer acceptable.
The key insight is that SEAL-3 is not about where your servers are. It is about who controls them and under what legal framework. An EU data center run by a US company is SEAL-1 at best.
How this applies to AI inference
AI inference has a unique problem compared to other cloud workloads: the data you send in prompts is often the most sensitive data you have. Customer names, financial records, medical histories, legal documents. And unlike storage or compute, you cannot encrypt data at rest and call it done. The provider needs to read your prompts in plaintext to run the model.
This means the provider's jurisdiction and data handling practices matter more for AI inference than for almost any other cloud workload. If your provider retains prompts (even temporarily for abuse monitoring), those prompts are data at risk.
How ozeye delivers SEAL-3 for AI workloads
ozeye routes every API request through EU-native providers exclusively:
| Provider | Incorporation | Data center | Data retention |
|---|---|---|---|
| Mistral AI | France | Paris, FR | Zero (ZDR enabled) |
| Scaleway | France | Paris, FR | Zero (ZDR by default) |
| OVHcloud | France | Gravelines, FR | Billing metadata only |
Every provider is an EU-incorporated company, operating EU data centers, under EU jurisdiction. No US parent companies. No CLOUD Act exposure. No subprocessors outside the EU in the inference path.
Combined with Zero Data Retention across all providers, the attack surface for data access requests is minimal. There is nothing stored to hand over.
Multi-provider routing eliminates concentration risk. DORA (in force since January 2025) requires financial institutions to manage ICT concentration risk. ozeye automatically routes requests across multiple providers with fallback, so no single provider failure takes you offline. This is not just good engineering; it is a regulatory requirement for financial services.
The subprocessor chain is transparent. ozeye publishes its full subprocessor list. You know exactly which companies handle your data and where. This directly satisfies EDPB Opinion 22/2024's requirement for processor chain visibility.
Who should care about SEAL-3
Financial services are the most immediate use case. DORA applies to banks, insurers, payment processors, and their critical ICT providers. In November 2025, the EU designated AWS, Azure, and GCP as critical ICT service providers under DORA, requiring them to establish EU subsidiaries. If you are in financial services and using AI for credit decisions, KYC, fraud detection, or claims processing, your inference provider is an ICT service under DORA.
Healthcare organizations processing patient data under GDPR need explicit subprocessor control and data minimization. Zero Data Retention directly addresses this.
Public sector procurement is increasingly gated on SEAL-2+, driven by the EUR 180 million EU Commission procurement baseline published alongside the framework.
Any EU company processing personal data through AI prompts has, at minimum, a GDPR Article 28 obligation to understand and control their processor chain. That is most companies building AI-powered features today.
Getting started
Switching from a US AI provider to ozeye requires changing two lines of code:
from openai import OpenAI
client = OpenAI(
base_url="https://ozeye.ai/v1",
api_key="oz_your_api_key"
)
response = client.chat.completions.create(
model="mistral-small-latest",
messages=[{"role": "user", "content": "Hello"}]
)
Same OpenAI SDK. Same API format. SEAL-3 compliance from the first request.