AWS Frankfurt schützt nicht: Warum dein KI-System trotz „deutschem Rechenzentrum“ DSGVO und US CLOUD Act verletzt
Ich spreche regelmäßig mit Gründern, CTOs und Abteilungsleitern, die mir stolz erklären: „Wir sind compliant. Wir nutzen AWS Frankfurt.“
Und dann erkläre ich ihnen, dass sie es nicht sind.
Das ist kein Angriff. Das ist eine der häufigsten und teuersten Fehlannahmen in der deutschen Unternehmenslandschaft. Und sie hat nichts mit einer fernen Gesetzesfrist zu tun: Die DSGVO gilt jetzt, nicht erst ab einem Stichtag im EU AI Act. Datenschutzbehörden können schon heute aktiv prüfen.
Dieser Artikel erklärt, warum „Serverstandort Deutschland bei US-Anbieter“ keine rechtliche Absicherung ist, was der US CLOUD Act wirklich bedeutet, wie die Haftungskette für dich als Geschäftsführer oder Entscheider aussieht – und welche Architektur tatsächlich schützt.
Was ist der US CLOUD Act? (Die Definition, die du dir merken solltest)
Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) verpflichtet US-amerikanische Unternehmen dazu, auf Anforderung von US-Behörden Zugang zu Daten zu gewähren, die sie kontrollieren – unabhängig davon, auf welchem Server in welchem Land diese Daten physisch gespeichert sind.
Übersetzt: Wenn du AWS, Microsoft Azure, Google Cloud oder einen anderen US-Konzern als Hosting-Anbieter nutzt, kann das US-Justizministerium (DoJ) ein Auskunfts- oder Herausgabeersuchen stellen – und der Anbieter ist gesetzlich verpflichtet, dem nachzukommen. Ohne dass du darüber informiert wirst. Ohne dass ein deutsches oder europäisches Gericht zustimmen müsste.
AWS Frankfurt ist eine Tochtergesellschaft der Amazon.com, Inc., headquartered in Seattle, Washington. Azure Berlin ist eine Infrastruktur der Microsoft Corporation, Redmond, Washington. Google Cloud Frankfurt gehört der Alphabet Inc., Mountain View, California.
Die physische Adresse des Servers ist irrelevant. Was zählt, ist die Nationalität des Unternehmens, das ihn kontrolliert.
Der DSGVO-Konflikt: Zwei Gesetze, ein unmöglicher Kompromiss
Hier entsteht das Problem, das sich seitdem wie ein offener Konflikt durch den transatlantischen Datentransfer zieht.
Die DSGVO (Art. 44 ff.) verbietet grundsätzlich die Übermittlung personenbezogener Daten in Drittstaaten – also Länder außerhalb der EU – ohne angemessenes Schutzniveau oder explizite Einwilligung des Betroffenen.
Der US CLOUD Act zwingt US-Unternehmen gleichzeitig dazu, Behörden Zugang zu gewähren.
Ein US-Anbieter, der einem US-Behördenersuchen folgt, verletzt potenziell die DSGVO. Ein US-Anbieter, der dem Ersuchen nicht folgt, verletzt US-Recht. Es gibt keinen Weg, der beide Gesetze gleichzeitig erfüllt.
Für dich als Nutzer dieser Infrastruktur bedeutet das: Du kannst für deine Kunden keine vollständige DSGVO-Konformität nach Art. 5 Abs. 1 lit. f (Integrität und Vertraulichkeit) garantieren, wenn du US-Infrastruktur für die Verarbeitung personenbezogener Daten einsetzt.
Das ist kein theoretisches Risiko. Der Europäische Gerichtshof hat AWS, Microsoft und Google bereits im Kontext des Schrems-II-Urteils (2020) als problematisch eingestuft. EU-Datenschutzbehörden verhängen aktiv Bußgelder.
Der typische n8n-Workflow: Wo es gerade schiefgeht
Lass mich das an einem konkreten Beispiel zeigen, das ich regelmäßig in Unternehmen antreffe.
Du hast einen n8n-Workflow, der eingehende Support-Tickets aus Zoho Desk nimmt, über einen HTTP-Node an die OpenAI API sendet und die Antwort als KI-generierte Notiz zurückschreibt. Läuft seit sechs Monaten wunderbar.
Hier ist, was in diesem Workflow gerade passiert:
[Zoho Desk] → [n8n auf AWS Frankfurt] → [OpenAI API (USA)] → [Antwort]
│
└── Ticket-Inhalt enthält:
- kunde-a@unternehmens-domain.de
- Max Mustermann, Vertriebsleiter
- IBAN DE89 3704 0044 0532 0130 00
- Adresse des EndkundenZwei Probleme auf einen Blick:
1. n8n läuft auf AWS Frankfurt → US CLOUD Act greift, Daten sind potenziell zugänglich 2. OpenAI API empfängt ungemaskierte PII → Drittstaatentransfer ohne DSGVO-Rechtsgrundlage
Und jetzt kommt der Punkt, bei dem viele nicken, weil sie ihn kennen: Es sind nicht nur saubere API-Datenströme, die durch solche Systeme fließen. Im deutschen Mittelstand kommen täglich strukturierte und unstrukturierte Daten an – digitalisierte Lieferscheine, eingescannte Verträge, und ja, immer noch: der OCR-verarbeitete Fax-Eingang vom Zulieferer aus dem Schwarzwald, der keine E-Mail-Adresse hat. Alles landet im gleichen Webhook. Alles geht an die KI.
Wenn dein n8n-Workflow diesen Fax-Scan mit Kundennamen, Bestellnummern und internen Notizen an OpenAI sendet, verlässt unverschlüsseltes PII deiner Kunden das EU-Territorium. Ohne ihre Einwilligung.
Wo der EU AI Act zusätzlich greift – und wo nicht
Ein reiner Support-Automatisierungs-Workflow wie oben ist für sich genommen noch kein Hochrisiko-System nach Annex III. Die Transparenzpflichten aus Art. 50 (Offenlegung gegenüber Betroffenen) greifen nur bei bestimmten Systemtypen – etwa Chatbots, Emotionserkennung oder Deepfakes – und gelten unverändert ab August 2026. Ein Logging- oder Audit-Trail-Zwang, wie ihn viele hier vermuten, ist dagegen Teil der Hochrisiko-Pflichten (Art. 12, Art. 14) und betrifft nur Systeme, die tatsächlich unter Annex III fallen – zum Beispiel, wenn dieselbe KI auch automatisiert über Personalentscheidungen oder Kreditwürdigkeit mitentscheidet. Diese Pflichten gelten ab Dezember 2027, verschoben vom ursprünglich geplanten August 2026 (Digital Omnibus on AI).
Der Punkt, den viele übersehen: Ob dein System als Hochrisiko-KI eingestuft wird, ist im Zweifel eine Einzelfallprüfung. Der DSGVO-Verstoß aus dem Beispiel oben ist das nicht – der ist unabhängig von jeder Einstufung schon heute real, sobald unmaskierte Kundendaten das EU-Territorium verlassen.
| Verstoß | Bußgeld | Rechtsgrundlage |
|---|---|---|
| Verbotene KI-Praktiken | bis 35 Mio. EUR / 7 % Umsatz | Art. 5 + 99 EU AI Act |
| Fehlende Transparenz (nur bei Chatbots, Deepfakes etc.) | bis 15 Mio. EUR / 3 % Umsatz | Art. 50 + 99 EU AI Act |
| Fehlende Hochrisiko-Dokumentation (nur bei Annex-III-Systemen, ab Dez. 2027) | bis 15 Mio. EUR / 3 % Umsatz | Art. 12/14 + 99 EU AI Act |
| DSGVO-Verletzung (unabhängig von KI-Einstufung) | bis 20 Mio. EUR / 4 % Umsatz | Art. 83 DSGVO |
Diese Bußgelder können kumulativ verhängt werden, wenn mehrere Tatbestände gleichzeitig zutreffen.
Die Haftungskette: Warum du persönlich haftest
Das ist der Punkt, an dem Gespräche oft ernst werden.
Wenn eine Datenpanne nachgewiesen wird – z.B. durch eine Beschwerde eines deiner Kunden bei der Datenschutzbehörde – prüfen die Behörden, ob die Verantwortlichen von der Problematik wissen konnten oder mussten.
Die Rechtsprechung dazu ist eindeutig: Geschäftsführer und Vorstände haften persönlich für Datenschutzverstöße, wenn sie:
- keine angemessene Due Diligence bei der Infrastrukturwahl vorgenommen haben
- bekannte Risiken (US CLOUD Act war 2018 öffentlich) toleriert haben
- keine geeigneten technischen Maßnahmen nach Art. 32 DSGVO umgesetzt haben
Es reicht nicht, zu sagen „das hat meine IT entschieden.“ Als GF bist du verantwortlich.
Was wirklich schützt: Der richtige Stack
Der Schlüssel liegt nicht darin, den Serverstandort eines US-Konzerns zu wählen. Der Schlüssel liegt im Betreiber.
Hetzner Online GmbH ist ein deutsches Unternehmen mit Sitz in Gunzenhausen, Bayern. Es gibt keine US-Muttergesellschaft. Der US CLOUD Act greift strukturell nicht.
Das ist der Unterschied:
| Kriterium | AWS Frankfurt | Hetzner Deutschland |
|---|---|---|
| Unternehmens-Sitz | Seattle, USA | Gunzenhausen, Deutschland |
| US CLOUD Act | ✗ greift | ✓ greift nicht |
| DSGVO-Konformität | ⚠ eingeschränkt | ✓ vollständig möglich |
| Preis (Vergleich) | höher | deutlich niedriger |
| Bare-Metal-Option | begrenzt | ✓ verfügbar |
| LUKS-Verschlüsselung | nicht nativ | ✓ möglich |
Aber der Betreiberwechsel allein löst das OpenAI-Problem nicht. Die PII verlässt immer noch die EU, wenn du ungemaskierte Daten an externe LLM-APIs sendest.
Die Lösung heißt lokales PII-Masking vor dem LLM-Aufruf.
Lokales PII-Masking: So funktioniert es technisch
Der Ansatz ist eigentlich ganz einfach: Vor dem Aufruf einer externen KI-API werden alle personenbezogenen Daten lokal tokenisiert. Das bedeutet, du ersetzt Namen, E-Mails, IBANs und Adressen durch eindeutige, reversible Platzhalter. Das externe LLM bekommt nur die tokenisierten Daten zu sehen – nie die echten.
# Vereinfachtes Beispiel: Lokales PII-Masking mit Microsoft Presidio
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()
# Eingehender Support-Ticket-Text (Beispieldaten, frei erfunden)
raw_text = """
Hallo, ich bin max.mustermann@beispiel-firma.de und habe ein Problem mit
meiner Bestellung. Die Lieferadresse ist Musterstraße 1, 12345 Musterstadt.
Bitte buchen Sie die Rückerstattung auf IBAN DE89 3704 0044 0532 0130 00.
"""
# Schritt 1: PII erkennen (läuft vollständig lokal – kein Cloud-Aufruf)
results = analyzer.analyze(text=raw_text, language="de")
# Schritt 2: PII ersetzen durch Platzhalter
anonymized = anonymizer.anonymize(text=raw_text, analyzer_results=results)
# Was jetzt an das externe LLM geht:
# "Hallo, ich bin <EMAIL_ADDRESS_1> und habe ein Problem mit meiner
# Bestellung. Die Lieferadresse ist <LOCATION_1>. Bitte buchen Sie
# die Rückerstattung auf <IBAN_1>."
print(anonymized.text)Das LLM sieht niemals echte Kundendaten. Es sieht nur die Struktur und den Kontext. Die Zuordnung zwischen `EMAIL_ADDRESS_1` und `max.mustermann@beispiel-firma.de` bleibt lokal auf deinem Server, in einem verschlüsselten Identity Vault.
Nach dem LLM-Aufruf wird de-tokenisiert: Der generierte Text wird mit den Original-Werten zusammengeführt, bevor er zurück ins CRM geschrieben wird.
Performance in der Praxis: Presidio analysiert und maskiert 5 typische Ticket-Entitäten in ~290ms auf einem Standard-CPU-Server. Das ist für asynchrone Verarbeitung problemlos.
Vorher / Nachher: Die sichere Architektur
Unsicherer Status quo:
[CRM Webhook] → [n8n / AWS Frankfurt] → [OpenAI API / USA]
│
Echte PII fließt
in US-InfrastrukturDSGVO-konforme Architektur:
[CRM Webhook] → [FastAPI / Hetzner DE] → [Presidio PII-Masking]
│
Tokenisierte Daten
│
[LLM API oder lokales Modell]
│
[De-Tokenisierung]
│
[CRM Write-Back]Der gesamte Prozess läuft auf europäischer Infrastruktur. Der Audit-Trail wird dokumentiert. Human-in-the-Loop ist implementierbar. EU AI Act: erfüllt.
Zusammenfassung: Was du jetzt konkret tun kannst
- Sofort: Inventarisiere alle KI-Workflows in deinem Unternehmen (n8n, Make, Python-Skripte, API-Anbindungen)
- Diese Woche: Prüfe, welche davon personenbezogene Daten an externe LLM-APIs senden
- Diesen Monat: Führe für jeden problematischen Workflow eine Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO durch
- Vor Dezember 2027: Falls eines deiner Systeme unter Annex III fällt (z. B. Personalentscheidungen, Kreditwürdigkeit), sorge für dokumentiertes Logging und Human Oversight
Und sei dabei ehrlich mit dir: Die meisten Unternehmen haben 3–10 solche Workflows. Nicht weil sie fahrlässig sind, sondern weil n8n und Make die Hürde so niedrig gemacht haben, dass man schnell baut – und die Compliance-Implikationen erst nachher kommen.
Bin ich überhaupt betroffen?
Nicht jedes Unternehmen ist gleich stark exponiert. Wer nur einen Chatbot auf der Webseite betreibt, ist anders betroffen als wer Zoho-Tickets automatisiert an OpenAI schickt. Wenn du dir nicht sicher bist, an welcher Stelle du stehst, hilft dieser kostenlose Schnellcheck: In 8 Fragen siehst du, ob und wo konkreter Handlungsbedarf besteht.
→ Kostenloser KI-Compliance Schnellcheck auf brain-maze.de
Du willst Gewissheit statt Vermutungen?
Wenn du wissen möchtest, an welchen konkreten Stellen deine aktuellen KI-Automatisierungen heute gegen DSGVO oder EU AI Act verstoßen, biete ich eine strukturierte technische Analyse an.
Das Ergebnis ist kein schwammiges Beratungsgutachten, sondern eine Risiko- und Maßnahmenanalyse (PDF) mit priorisierten, direkt umsetzbaren Handlungspunkten – für dich, für deine Rechtsabteilung und für deinen Datenschutzbeauftragten.
Festpreis statt Stundensatz. Scope und Konditionen anfragen.
→ Zum KI-Compliance Audit auf brain-maze.de
Oder wenn du schon weiter bist und eine fertige, DSGVO-konforme KI-Infrastruktur für dein CRM suchst, schau dir Sentio Systems an – unsere managed Context Intelligence Platform auf 100% deutschen Servern mit lokalem PII-Masking:
