Trust-Seiten von KI-Anbietern prüfen fast immer DSGVO und §203 – fast nie den US Cloud Act
Wenn ich für ein Audit die Infrastruktur eines Kunden durchgehe, gehört es mittlerweile zur Routine, auch die „Trust & Compliance“-Seite der KI- und Automatisierungs-Tools zu lesen, die im Einsatz sind. Diese Seiten sind in den letzten Jahren deutlich besser geworden: Auftragsverarbeiter-Rolle, Sub-Auftragnehmer-Übersicht, technisch-organisatorische Maßnahmen, oft sogar eine eigene Aufschlüsselung nach §203 StGB für Kanzleien und andere Berufsgeheimnisträger.
Ein Muster fällt mir dabei immer wieder auf: Die DSGVO-Seite ist gründlich. Die §203-Seite ist gründlich. Der US Cloud Act taucht so gut wie nie auf.
Was auf diesen Seiten normalerweise steht – und was fehlt
Eine typische, gut gemachte Trust-Seite eines KI- oder Automatisierungs-Anbieters deckt ab:
- Datenstandort: Persistente Speicherung in Deutschland oder der EU.
- Auftragsverarbeitung: AVV nach Art. 28 DSGVO, dokumentierte Rollen und Pflichten.
- §203 StGB (falls relevant): Schriftliche Vertraulichkeitsverpflichtung der Mitarbeitenden, dokumentierte Weisungen – die Standard-Konstruktion, die seit der Reform 2017 den Einsatz externer IT-Dienstleister für Berufsgeheimnisträger überhaupt erst sauber ermöglicht.
- Sub-Auftragnehmer-Liste: Wer die Infrastruktur betreibt, mit Standort.
Das ist ordentliche Arbeit, und rechtlich ist daran meistens nichts auszusetzen. Was in dieser Liste fast immer fehlt: eine Einordnung, was es bedeutet, wenn einer dieser Sub-Auftragnehmer ein US-Konzern ist – selbst wenn dessen Rechenzentrum in Frankfurt steht.
Warum „Rechenzentrum in Frankfurt“ nicht automatisch heißt „kein US-Zugriff“
Der US Cloud Act (2018) verpflichtet US-Unternehmen, auf Anordnung US-amerikanischer Behörden Daten herauszugeben – unabhängig davon, wo auf der Welt diese Daten physisch gespeichert sind. Das betrifft AWS, Microsoft Azure und Google Cloud unabhängig von der gewählten Region, weil die Mutterkonzerne US-Unternehmen sind. Die Frankfurt-Region reduziert Latenz und erfüllt Datenstandort-Anforderungen. Sie löst den Cloud-Act-Zugriff auf Konzernebene nicht auf.
Die formale Antwort darauf ist seit 2023 das EU-US Data Privacy Framework – eine Angemessenheitsentscheidung der EU-Kommission, auf die sich Unternehmen für den transatlantischen Datentransfer berufen können. Das ist keine Randnotiz, sondern die aktuell gültige Rechtsgrundlage, und ich will das nicht kleinreden.
Die ehrliche Einordnung: Die beiden Vorgänger dieses Mechanismus – Safe Harbor und Privacy Shield – wurden vom Europäischen Gerichtshof bereits einmal gekippt (Schrems I, 2015) und ein zweites Mal (Schrems II, 2020), jeweils mit genau dieser Cloud-Act-Problematik als Kernargument. Ob das aktuelle Framework denselben Weg geht, ist unter Datenschützern und Juristen umstritten, aber nicht abschließend geklärt. Wer sich ausschließlich auf diese eine Rechtsgrundlage verlässt, baut auf einem Fundament, das historisch zweimal nachgegeben hat.
Ist das jetzt ein Rechtsverstoß?
Nein – und das würde ich niemandem unterstellen, der eine saubere AVV-Konstruktion mit EU-Hosting vorweisen kann. Das ist rechtlich sauber aufgesetzt, so wie es aktuell für die meisten Anbieter Standard ist.
Was es ist: eine offene, unentschiedene Risikofrage, die auf den meisten Trust-Seiten schlicht nicht vorkommt – weder als „das prüfen wir“ noch als „das ist uns bewusst, hier ist unsere Einschätzung“. Genau diese Lücke sehe ich in Audits regelmäßig, wenn ich mir anschaue, welche Tools und Sub-Dienstleister in einer bestehenden n8n- oder Make-Pipeline tatsächlich eingebunden sind.
Was das für dein eigenes Setup bedeutet
Wenn du KI-Tools oder Automatisierungs-Plattformen einsetzt, die selbst wieder auf AWS, Azure oder Google Cloud aufsetzen, lohnt sich eine kurze Prüfung:
1. Wer sind die Sub-Auftragnehmer deines Tools, nicht nur wo stehen deren Server? Die Trust-Seite nennt in der Regel beides – die zweite Frage wird nur selten selbst beantwortet. 2. Fließen personenbezogene Daten unverschlüsselt an diese Sub-Auftragnehmer? Wenn ja, hängt deine Absicherung vollständig an der einen, umstrittenen Rechtsgrundlage. 3. Gibt es eine technische Ebene, die nicht von dieser Rechtsfrage abhängt? Lokales Maskieren personenbezogener Daten, bevor sie überhaupt einen US-Anbieter erreichen, ist die einzige Absicherung, die unabhängig davon funktioniert, wie sich die Rechtslage um das Data Privacy Framework in den nächsten Jahren entwickelt.
Der dritte Punkt ist der eigentliche Unterschied zwischen „wir haben einen AVV“ und „wir sind technisch unabhängig von der Frage, ob der AVV in fünf Jahren noch trägt“.
Warum ich darauf so genau schaue
Bei einem KI-Compliance-Audit gehört diese Prüfung mittlerweile standardmäßig dazu: nicht nur, ob die eigene Pipeline eine PII-Maskierung hat, sondern auch, welche Drittanbieter in dieser Pipeline stecken und wie deren eigene Risikokette aussieht. Ein Tool kann selbst technisch sauber integriert sein und trotzdem ein Sub-Auftragnehmer-Risiko mitbringen, das im eigenen Audit sonst unsichtbar bleibt.
Wenn du wissen willst, wo genau in deiner eigenen n8n- oder Make-Infrastruktur solche Abhängigkeiten stecken:
