EU-Datenresidenz für KI-APIs 2026: Anbieter-Guide

EU-Standortkontrollen für KI-APIs hängen vom Projekt, Endpoint, Deployment-Typ, Modell, Feature und der gesamten Verarbeitungskette ab. OpenAI dokumentiert regionale Speicherung und Verarbeitung für berechtigte europäische API-Projekte über eu.api.openai.com. Azure und AWS binden den Verarbeitungsort an Deployment-Typ oder Inferenzprofil. Mistral dokumentiert nun den eigenen Regional-Inference-Endpoint api.eu.mistral.ai. Self-Hosting kann direkte Infrastrukturkontrolle bieten, aber nur wenn jedes Modell, Gateway, Log, Backup, jeder Supportpfad und jeder Subprozessor innerhalb der vorgesehenen Grenze bleibt.

Das ist eine Engineering-Sicht, keine Rechtsberatung und kein Anbieter-Pitch. Die Aussagen wurden am 2. September 2026 erneut geprüft und haben eine kurze Haltbarkeit. Verifiziere vor Vertragsabschluss Speicherung, Verarbeitung, Retention, Training, Subprozessoren, Supportzugriff, Transfers und geltende Jurisdiktion als getrennte Vertragsfelder.

Zuerst die Begriffe klären

Die meiste Verwirrung in der EU-KI-Beschaffung entsteht durch das Verwechseln von Begriffen, die Unterschiedliches bedeuten. Kläre diese, bevor du irgendetwas vergleichst.

• Datenresidenz ist eine Standortaussage: wo Daten physisch liegen. Es ist eine Konvention, kein in der DSGVO definierter Begriff.
• Datensouveränität ist breiter als der physische Standort und kann geltendes Recht, Anbieterkontrolle, Zugriffswege, Schlüssel und operative Abhängigkeiten umfassen. Die Nationalität eines Anbieters beweist allein nicht, dass ein bestimmtes Offenlegungsgesetz auf bestimmte Daten anwendbar ist. Die rechtliche Analyse gehört in Vertrag, Transfer-Folgenabschätzung und Prüfung des anwendbaren Rechts, nicht in das Wort "Residenz".
• Speicherung im Ruhezustand ist der Ort, an dem deine Daten dauerhaft abgelegt werden. Verarbeitung oder Inferenz ist der Ort, an dem die GPU den Aufruf tatsächlich ausführt. Nach Art. 4 Abs. 2 DSGVO umfasst "Verarbeitung" ausdrücklich sowohl das Speichern als auch das Nutzen von Daten, sodass ein Inferenz-Aufruf in einer Nicht-EU-Region selbst ein Verarbeitungsvorgang ist, auch wenn die Speicherung in der EU bleibt.
• Zero Data Retention (ZDR) ist eine vom Anbieter definierte Kontrolle mit Endpoint- und Sicherheitsausnahmen, kein universelles Versprechen, dass nirgends zugehörige Daten existieren. "Kein Training mit deinen Daten" ist davon getrennt und sagt allein nichts über Missbrauchslogs, Anwendungszustand, Metadaten oder Supportdaten.

Der eine Satz, den du dir merken solltest: Das Label "EU-Residenz" eines Anbieters beweist für sich allein keine EU-only-Inferenz. Manche Produkte umfassen heute Speicherung und Verarbeitung, andere grenzen beides getrennt ab. Verifiziere den genauen Endpoint, Deployment-Typ, die berechtigten Services, den Retention-Modus und Ausnahmen.

Der Vergleich auf einen Blick

So vergleichen sich die Optionen über typische Beschaffungsdimensionen. Alle Angaben wurden am 2. September 2026 geprüft und müssen pro Anbieter, Endpoint, Modell und Feature erneut verifiziert werden.

Mistral und Hetzner haben ihren Hauptsitz in der EU, OpenAI, Microsoft und AWS in den USA. Das kann relevant sein, entscheidet eine Transfer- oder Behördenzugriffsanalyse aber nicht allein. Prüfe Vertragsparteien, Unternehmenskontrolle, Subprozessoren, Support, Fernzugriff, Schlüsselhoheit, aktivierte Features und geltendes Recht. Kundenseitig verwaltete Schlüssel können eine ergänzende Maßnahme sein, sind aber keine vollständige Antwort.

OpenAI API

OpenAIs Europa-Region umfasst EWR und Schweiz und dokumentiert regionale Speicherung und Verarbeitung für unterstützte API-Endpoints. Erstelle ein berechtigtes Projekt in dieser Region und sende Traffic an https://eu.api.openai.com. Für Nicht-US-Regionen verlangt OpenAI derzeit eine Genehmigung der Missbrauchsüberwachungs-Kontrollen und einen Zero-Data-Retention-Zusatz. Unterstützte Endpoints, Modelle, Tools und Snapshots unterscheiden sich; Systemdaten, Drittanbieterdienste, Extended Caching, Background Mode, Tracing und weitere Features haben eigene Ausnahmen. Nutze die aktuelle Kontrolltabelle, statt einen regionalen Schalter als universell zu behandeln. API-Daten werden standardmäßig nicht zum Training genutzt, sofern der Kunde sich nicht dafür entscheidet.

Azure OpenAI

Bei Azure-gehosteten Modellen bestimmt der Deployment-Typ die Inferenzgeografie. Global-Deployments können dort verarbeiten, wo das Modell bereitgestellt ist. Data-Zone-Deployments bleiben in der angegebenen Zone; Microsofts EU Data Zone folgt der Azure EU Data Boundary und kann EFTA-Standorte wie Norwegen und die Schweiz umfassen. Unterstützte Single-Region-Deployments binden die Verarbeitung enger. Der Anwendungszustand bleibt in der Ressourcengeografie, Modell- und Feature-Verfügbarkeit unterscheiden sich jedoch. Batch gibt es als Global- und Data-Zone-Variante, leite seinen Pfad daher nicht aus dem Ressourcennamen ab. Prüfe die aktuelle Deployment-Matrix und Produktbedingungen für Modell und Service.

Mistral

Mistral hat seinen Hauptsitz in der EU und dokumentiert nun drei Inferenzpfade: einen globalen Endpoint ohne bestimmte Zusage zum Inferenzstandort, api.eu.mistral.ai über mehrere EU- und EFTA-Rechenzentren und einen US-Endpoint. Regionale Inferenz und Zero Retention sind getrennte Kontrollen; der regionale Endpoint macht nicht jede Control Plane oder optionale Funktion regional. Laut aktueller API-Dokumentation werden API-Aufrufe nicht zum Modelltraining genutzt, doch Labs- oder Preview-Modelle, Feedback, Produktmodi und konfigurierte Opt-ins haben abweichende Regeln. Self-Hosted- und Cloud-Marketplace-Deployments folgen ihrer vollständigen Architektur und den Bedingungen des Providers, nicht dem Endpoint-Versprechen der Managed API.

Hetzner und Self-Hosting

Hetzner ist allgemeine Infrastruktur, keine verwaltete LLM-API. Du wählst Standort, Hardware, Modell, Serving-Stack, Gateways, Speicher, Logs, Backups und Supportpfad. Ein EU-Server hält nicht automatisch das vollständige System in der EU und entfernt nicht jeden Dritten. Hardware-SKUs und Kapazität ändern sich, deshalb solltest du nach aktuellen Spezifikationen und gemessener Last dimensionieren statt nach festen GPU-Beispielen. Self-Hosting macht dich außerdem für Zugriffskontrolle, Patching, Secrets, Isolation, Missbrauchsbehandlung, Backups, Observability, Verfügbarkeit und sichere Modellupdates verantwortlich.

Prüfe bei selbst gehosteten Open Weights die genaue Modellkarte und Lizenzversion. Mistral, Llama, Qwen und andere Familien nutzen je nach Release unterschiedliche Lizenzen; aus einem Modell lässt sich kein familienweites kommerzielles Nutzungsrecht ableiten. Self-Hosting kann die Kontrolle verbessern, Kosten und Qualität hängen aber von Auslastung, Hardware, Betrieb, Workload und gewähltem Modell ab.

Der Entscheidungsbaum

Wähle den ersten Zweig, der zu deiner harten Anforderung passt, nicht zu deiner Vorliebe.

1. Deine Richtlinie beschränkt bestimmte Jurisdiktionen oder Fernzugriffswege. Übersetze das in Kriterien für Vertragspartei, Unternehmenskontrolle, Subprozessoren, Support, Schlüsselmanagement, Netzwerk, Logging und Offenlegungsrecht. Ein EU-Host oder Open-Weight-Modell allein kann das Gesamtergebnis nicht beweisen.
2. Du brauchst EU-Speicherung und -Verarbeitung bei geringem Betriebsaufwand, und ein US-Anbieter ist mit den nötigen Transfersicherungen akzeptabel. Vergleiche Azure OpenAIs EU Data Zone mit einem berechtigten OpenAI-Europa-Projekt über eu.api.openai.com. Bestätige Modell, Endpoint, Retention-Modus, Supportzugriff und Ausnahmen.
3. Du willst eine verwaltete API mit EU-Hauptsitz. Bewerte Mistrals EU-Regional-Endpoint, Modellabdeckung, Preise, Zero-Retention-Berechtigung, Control-Plane-Umfang, Subprozessoren und optionale Features.
4. Du bist bereits in AWS zuhause und willst EU-eingeschlossene Inferenz. Bedrock mit EU-übergreifenden Inferenz-Profilen, plus Zero Data Retention, falls du es brauchst.
5. Du hast einen begründeten Self-Hosting-Fall und die nötige Betriebskompetenz. Vergleiche einen vollständigen EU-gehosteten Stack anhand gemessener Last, Lizenzierung, Sicherheit, Verfügbarkeit, Personal und Lebenszykluskosten mit Managed-Alternativen.

"Beschaffe kein EU-Label. Beschaffe einen benannten Endpoint, Deployment-Typ, Verarbeitungsbereich, Retention-Modus, eine Subprozessorliste und Ausnahmeregeln. Das sind die Nachweise, die eine Architekturprüfung testen kann."

Wo Residenz ins größere Bild passt

Residenz ist ein Baustein eines belastbaren EU-KI-Systems, nicht die ganze Antwort. Die schwierigeren Probleme sind meist Retrieval-Qualität, nutzerbezogene Berechtigungen, Evals und Kosten, die wir in unserer RAG-Produktionsreife-Checkliste für die EU behandeln. Und Residenz sitzt innerhalb eines größeren Compliance-Stacks aus RAG-Datenflüssen, DSGVO und dem AI Act, den wir in wie DSGVO und der AI Act für ein DACH-SaaS zusammenspielen entwirren. Bring das Residenz-Modell früh in Ordnung, denn den Datenstandort nach dem Launch nachzurüsten gehört zu den teuersten Dingen, die du tun kannst.

Residenz minimiert auch nicht das Payload. Die PII-Redaction-Pipeline für LLM-Prompts vergleicht lokales Presidio und Privacy Filter mit Cloud-DLP und zeigt, wie unnötige Identifikatoren gar nicht erst in die Modellanforderung gelangen.

Eine gekaufte Pseudonymisierungsplattform ist die verpackte Fassung dieser Datenminimierung, und sie wirft eine eigene Rechtsfrage auf: Nimmt ein Pseudonymisierungs-Gateway den Prompt aus dem DSGVO-Bereich? Kurz gesagt kann es den Status des Modellanbieters verändern, deinen nie, und nur gemessen an den EDSA-Bedingungen für eine Drittlandsübermittlung.

Den Datenfluss abzubilden, bevor irgendetwas platziert wird, ist der erste Schritt in KI-Softwareentwicklung in Österreich, und die Retrieval-, Berechtigungs- und Eval-Schichten drumherum übernimmt unser KI Setup Service. Twinsoft AI zeigt konkret, wie ein Produktionssystem aussieht, das genau von diesen Randbedingungen geformt wurde.