EU-Hosting für KI: was dir niemand sagt

Zehn Minuten auf einer SaaS-Website reichen: Alle behaupten 'EU hosted'. Manchmal 'EU Data Residency'. Vereinzelt 'EU Sovereignty'. Es sieht gleich aus, ist es aber ganz und gar nicht. Und für KI-Anwendungen, wo du mit LLMs arbeitest, die in den USA auf Daten aus der ganzen Welt trainiert wurden, ist der Unterschied zwischen diesen Begriffen der Unterschied zwischen DSGVO-konform und einer potenziellen Datenpanne.

Die drei Stufen, in aufsteigender Strenge

Stufe 1: EU-Server

Die schwächste Aussage. Bedeutet: Die physische Maschine steht in einem EU-Rechenzentrum. Aber sie sagt nichts darüber, wo die Daten zwischendurch herkommen oder hingehen. Der Load-Balancer kann in den USA stehen, die Logs können nach Australien gehen, die Backups können in Singapur liegen. 'EU-Server' ist eine Postleitzahl, keine Garantie.

Stufe 2: EU-Data-Residency

Strenger. Bedeutet: Alle persistenten Daten (Datenbank, File-Storage, Backups) bleiben innerhalb der EU-Grenzen. Aber 'persistent' ist der Trick: Temporäre Verarbeitung, ein API-Call, eine Log-Zeile, eine Queue-Nachricht, kann trotzdem eine EU-Grenze überschreiten. Für LLM-KI ist das ein großes Leck, denn jede Nutzerinteraktion läuft durch ein Modell, das irgendwo läuft.

Stufe 3: EU-only Processing

Der richtige Maßstab. Bedeutet: In KEINER Phase, weder bei der Speicherung noch bei der Verarbeitung noch beim temporären Caching, verlassen Daten die EU. Inklusive des Inference-Calls an das Sprachmodell. Das erfordert, dass dein LLM-Anbieter ebenfalls einen EU-Endpoint hat und dass du diesen Endpoint ausdrücklich nutzt.

Wo es bei KI-Tools schiefgeht

Die meisten KI-Helpdesk-Tools behaupten 'EU Data Residency', nutzen aber eine amerikanische LLM-API ohne EU-Routing. Das heißt, jede Nutzerfrage, inklusive des gesamten Kontexts (Kundenname, Bestellnummer, eventuell Zahlungsdaten), läuft über Server außerhalb der EU, bevor sie beantwortet wird. Die Frage selbst wird nicht 'gespeichert' im strengen Sinn, aber verarbeitet. Und Verarbeitung fällt unter die DSGVO.

Was das Gesetz sagt

DSGVO Art. 44-46 verbietet die Übermittlung personenbezogener Daten in Länder außerhalb der EU/EWR ohne gültige Rechtsgrundlage. Die gültigen Grundlagen sind begrenzt und an Bedingungen geknüpft: ein Angemessenheitsbeschluss (wie das EU-US Data Privacy Framework, das rechtlich unter Druck steht), Standardvertragsklauseln (SCCs, erfordern eine zusätzliche Risikoanalyse) oder verbindliche interne Datenschutzvorschriften (BCRs).

Für KI-Kundensupport lautet die praktische Schlussfolgerung: Wenn dein Anbieter Daten in den USA verarbeiten lässt, stütze das immer auf das EU-US DPF, und wisse, dass du innerhalb von 90 Tagen eine Alternative brauchst, falls es wegfällt. Viele CIOs und DSBs verlangen deshalb 'EU-only Processing' ohne Übermittlung als Baseline.

Welche Stufe brauchst du?

• B2C-Webshop mit allgemeinen Support-Fragen → Stufe 2 ist in der Praxis akzeptabel.
• B2B mit Enterprise-Kunden, bei denen der Einkauf einen AVV verlangt → Stufe 3.
• Gesundheitswesen, Finanzen, öffentlicher Sektor, Hochschulen → Stufe 3 ist faktisch Pflicht.
• Unternehmen mit DPF-Allergie (oft deutsche Kunden, oft Rechtsabteilungen) → Stufe 3 + europäischer LLM-Anbieter (Mistral, Aleph Alpha).

Wie Conveya das löst

Unsere Datenbank, Queue, File-Storage und API-Server laufen in EU-Central (Amsterdam). Unsere Standard-LLM-Route läuft über OpenAI; Merchants, die striktes EU-only Processing verlangen, können über CHAT_PROVIDER zu einem europäischen Anbieter routen (Mistral Large ist die am besten erprobte EU-Route). Bei jedem Merchant-Onboarding dokumentieren wir, welche Route genutzt wird und welche Sub-Prozessoren aktiv sind, siehe /privacy für die aktuelle Sub-Prozessor-Liste.