ragsovereigntyeu-ai-actgdprarchitecture

Souveränität ist ein Datenpfad, kein Rechenzentrum

Juni 2026 · 7 Min. Lesezeit

Eine EU-Region zu wählen fühlt sich an wie die Souveränitätsentscheidung. Es ist die beruhigendste Zeile in der Architektur und die, die am wenigsten schützt. Für ein RAG-System, das regulierte Daten verarbeitet — öffentlicher Sektor, Gesundheit, Finanzen — ist die harte Frage nicht, wo die Daten gespeichert sind. Sie ist, wer gezwungen werden kann, sie herauszugeben. Und die Antwort hängt von einem Pfad ab, nicht von einem Ort: der Route, die eine einzelne Anfrage durch das System nimmt, und wer jede Station auf dem Weg betreibt. Das ist ein Gang diesen Pfad entlang, Schicht für Schicht, und was es braucht, all das innerhalb europäischer Jurisdiktion zu halten.

Die Region ist die Box, die beruhigt und nicht schützt

Der US CLOUD Act verpflichtet US-Unternehmen, Daten auf rechtmäßige Anforderung herauszugeben, unabhängig davon, wo auf der Welt diese Daten physisch liegen. Was bindet, ist die Jurisdiktion des Betreibers, nicht der Standort des Servers. Ein Rechenzentrum in Frankfurt, betrieben von einem US-Konzern, ist weiterhin in Reichweite — die EU-Region ist die Box, die beruhigt, ohne zu schützen.

Souveränität ist also keine Eigenschaft eines Speicherorts. Sie ist eine Eigenschaft des gesamten Datenpfads. Man muss der Route folgen, die eine Anfrage nimmt, und an jeder Station eine Frage stellen: wer betreibt das, und welchem Recht unterliegt er? Ein RAG-System ist nur so souverän wie seine am stärksten exponierte Schicht.

Follow one query: every stop — query, embedding, retrieval, generation — stays inside the EU self-hosted zone. Swap generation for a managed US API and the protected context leaves that zone on every single call, whatever region the servers sit in.

Ein RAG-System leckt an jeder Schicht, die ihm nicht gehört

Man gehe den Pfad ab, den eine Anfrage nimmt. Das Embedding-Modell verwandelt jeden Chunk in einen Vektor, und es sieht jedes Stück Inhalt — einmal zur Indexierungszeit und erneut bei jeder Anfrage. Die Vektordatenbank hält eine durchsuchbare Kopie des gesamten Korpus, oft inklusive des Quelltexts als Metadaten. Und das Sprachmodell erhält den abgerufenen Kontext zusammen mit der Frage bei jedem einzelnen Aufruf.

Das Letzte ist das schärfste. Generierung ist, wo der sensible Kontext kontinuierlich landet, im Normalbetrieb — nicht einmalig beim Setup. Ein gemanagtes Sprachmodell eines US-Anbieters sieht also den geschützten Inhalt jedes Mal, wenn das System genutzt wird. Die Region, in der die Server stehen, spielt dabei keine Rolle.

Self-Hosting verändert die Frage

Hier ist der Punkt, an dem viele stolpern: Was zählt, ist nicht, wer das Modell trainiert hat, sondern wer es betreibt. Ein Open-Weight-Modell, dessen Gewichte man herunterlädt und auf der eigenen europäischen Infrastruktur betreibt, sendet nichts an seinen Hersteller zurück. Ob diese Gewichte in den USA oder anderswo entstanden, ist für die CLOUD-Act-Frage irrelevant, sobald das Modell unter eigener Kontrolle läuft.

Die Exponierung kommt von der gemanagten API, nicht von der Herkunft der Gewichte. Das ist es, was einen souveränen Stack praktikabel macht: Es braucht kein europäisch gebautes Modell, sondern ein europäisch betriebenes.

Die souveränen Bausteine

Jede Schicht hat heute eine reife, europäisch betreibbare Option. Für sensible Daten ist die Regel an jeder dieselbe: selbst hosten, oder einen Anbieter unter europäischer Jurisdiktion nutzen — nie einen gemanagten US-Dienst.

— Infrastruktur — Hetzner, IONOS, StackIT, Open Telekom Cloud, OVHcloud oder Scaleway, oder on-prem. Nicht AWS, Azure oder GCP für die sensiblen Abschnitte.
— Embedding — bge-m3, multilingual-e5 oder jina-embeddings-v3, selbst gehostet. Keine gemanagte US-Embedding-API.
— Vektordatenbank — Qdrant, Weaviate oder pgvector auf Postgres, selbst gehostet. Kein gemanagter US-Dienst.
— Sprachmodell — Mistral, Llama, Qwen oder Teuken selbst gehostet via vLLM; oder ein europäischer gemanagter Anbieter wie Mistral oder Aleph Alpha, wenn man keine GPUs betreiben will.

Was Souveränität kostet

Sie ist nicht umsonst, und etwas anderes zu behaupten ist unehrlich. Man übernimmt Betriebslast — GPU-Server betreiben, skalieren, Updates — die ein gemanagter Anbieter sonst abnähme. Die besten Open-Weight-Modelle sind sehr gut und mehr als genug für die meiste Retrieval-Arbeit, aber die äußerste Front wird noch von den großen US-Modellen gehalten, und diese Lücke schließt sich eher, als dass sie geschlossen ist. GPU-Infrastruktur kann bei geringem Volumen auch mehr kosten als eine nutzungsbasierte API.

Die Rechnung kippt mit den Daten. Für öffentliche Inhalte ist ein souveräner Stack Over-Engineering. Für personenbezogene, öffentliche oder Gesundheitsdaten — genau dort, wo DSGVO und EU AI Act ohnehin verlangen, den Fluss zu kontrollieren — ist es weniger eine Kostenfrage als eine Bedingung dafür, das System überhaupt betreiben zu dürfen.

For public content a managed stack is fine — the sovereign path is for personal, public-sector, or health data, where you either self-host or stay with a provider under European jurisdiction.

Das Fazit: einer Anfrage folgen

Hier ist eine Übung, kürzer als jedes Compliance-Audit. Man nehme eine sensible Anfrage und verfolge sie durch den Stack — Query, Embedding, Retrieval, Generierung — und markiere jede Station, die ein US-Unternehmen kontrolliert. Jede Markierung ist ein Punkt, den der CLOUD Act erreichen kann, was auch immer das Regions-Dropdown sagt.

Und ein konkreter Startpunkt, der heute produktionsreif ist: GPU-Infrastruktur bei einem deutschen Anbieter; bge-m3 für Embeddings via Text Embeddings Inference; Qdrant für den Vector-Store; ein Mistral-Modell via vLLM für die Generierung, oder Mistral und Aleph Alpha gemanagt, wenn man auf Self-Hosting verzichtet; Orchestrierung im eigenen Code auf EU-Infrastruktur. Stehen alle fünf Schichten unter europäischer Kontrolle, ist kein souveränitäts-nahes System entstanden. Sondern ein souveränes.