Dataflow and IONOS announced a partnership to provide sovereign data pipelines for the European market. The key phrase in the announcement was not "GDPR compliant" or "EU data residency." It was "architected to remain outside U.S. CLOUD Act jurisdiction."
That framing is precise, and the precision is intentional. GDPR compliance is a legal standard. EU data residency is a geography. Outside U.S. CLOUD Act jurisdiction is an architecture requirement — one that determines which infrastructure choices are acceptable and which are not, regardless of where the servers are physically located.
Most teams I talk to treat the CLOUD Act as a legal department concern. It is an engineering concern.
What the CLOUD Act Actually Says
The Clarifying Lawful Overseas Use of Data Act, passed in 2018, gives U.S. law enforcement the authority to compel U.S. companies to produce data stored on their servers — even if those servers are located outside the United States. The key word is "companies." If your cloud provider is incorporated in the United States, the CLOUD Act can reach data they store for you, regardless of the data center's physical location.
This means that storing data with AWS, Azure, or Google Cloud in a Frankfurt data center does not put that data outside CLOUD Act reach. AWS is a U.S. company. The Frankfurt servers are operated by a U.S. company. A lawful U.S. government order can compel AWS to produce the data on those servers.
For traditional data — customer records, financial transactions, operational logs — CLOUD Act exposure has been a known and managed risk for years. Legal teams understand it. DPAs address the European side. Most organizations have accepted the residual risk.
For AI-derived intelligence, the risk profile is different. And most organizations have not caught up to that difference.
Why AI Changes the CLOUD Act Calculus
Your raw data may be anonymized, encrypted at rest, and subject to a comprehensive data processing agreement with your cloud provider. Even so, if you are running AI workloads on that infrastructure, you are generating derived intelligence that may not have the same protections as the underlying data — and that derived intelligence may be more revealing than the data it came from.
Vector embeddings are derived intelligence. When you run your proprietary documents, customer interactions, or operational data through an embedding model to build a RAG corpus, you are creating mathematical representations of that information. Those embeddings encode the semantic content of your data in a form that an AI system can retrieve and reason over. If those embeddings are stored on CLOUD Act-reachable infrastructure, a lawful order can compel their production.
More importantly, sophisticated reconstruction attacks on embedding models have improved significantly. The embeddings are not perfectly reversible, but they are not opaque either. Compelled production of your RAG corpus is effectively compelled production of a significant portion of the business intelligence that corpus represents.
Fine-tuned model weights are derived intelligence. If you fine-tune a base model on your proprietary data — your customer service interactions, your engineering documentation, your sales playbooks — the resulting weights encode that knowledge. Those weights, stored on a U.S. cloud provider, are reachable by the CLOUD Act regardless of what the underlying data's protections were.
Inference logs are derived intelligence. Every prompt sent to a cloud-hosted model and every response generated creates a record. Those records reveal what problems your organization is trying to solve, what information your systems are looking for, and what decisions your AI is supporting. If inference happens on U.S. cloud infrastructure, those logs exist there.
How European Teams Are Responding
The Dataflow/IONOS partnership is one example of a pattern that is accelerating across the European market. The architectural response to CLOUD Act exposure has three main forms, and serious teams are combining all three.
EU-domiciled infrastructure with EU-based legal entities. IONOS is a German company incorporated and operating under German law. Data processed on IONOS infrastructure by IONOS employees is not automatically reachable by the U.S. CLOUD Act. This is the legal entity answer to the jurisdiction question. It requires using providers that are genuinely non-U.S. companies — not European subsidiaries of U.S. parents, which inherit the parent's CLOUD Act exposure.
Air-gapped on-premise inference. The most complete answer to the CLOUD Act question is running inference on hardware you own or lease in a facility you control. Inference that never touches U.S. cloud infrastructure has no CLOUD Act surface. This is the path I have been documenting with the Sovereign Stack — AMD hardware, Kubernetes orchestration, Lemonade Server for inference, no dependency on U.S. cloud providers for the critical inference path.
Hybrid architecture: sovereign inference, EU-compliant storage. For organizations that cannot fully air-gap their AI workloads, a hybrid approach separates the inference layer (on-premise or EU-domiciled) from the storage layer (EU-compliant cloud). This does not eliminate CLOUD Act exposure entirely, but it moves the most sensitive derived intelligence — the inference logs, the fine-tuned weights — off U.S. infrastructure.
What This Means for Non-European Organizations
The CLOUD Act runs in both directions. European customers are asking U.S. vendors about their CLOUD Act exposure when evaluating AI products that will handle European data. If your AI pipeline runs on AWS, Azure, or GCP — even with a comprehensive DPA — your European customers have a legitimate question about the jurisdiction of their data.
For U.S.-based organizations selling into regulated European markets — financial services, healthcare, government — the CLOUD Act question is becoming a procurement filter. Not everywhere, and not yet for every deal. But the direction is clear.
The organizations that are getting ahead of this are not doing so out of regulatory anxiety. They are doing so because the architecture question — "where does our derived intelligence live, and who can compel access to it?" — has a clean answer for sovereign infrastructure and an ambiguous answer for U.S. cloud infrastructure. Clean answers win procurement conversations.
The Architecture Question to Ask
Before your next AI infrastructure decision, ask: if a U.S. government agency issued a lawful order to your cloud provider tomorrow, what AI-derived intelligence about your business or your customers would be disclosed?
If you cannot answer that question precisely — if you don't know which embeddings live where, which inference logs exist on which infrastructure, which fine-tuned weights are stored in which cloud — you have an architecture gap. Not a compliance gap. An architecture gap.
The Dataflow/IONOS partnership is one team's answer to that question. The answer you need may be different. But knowing the question is the beginning of building the right system.