Cloud Act und DSGVO: Wo Ihre KI-Daten liegen sollten

Cloud Act und DSGVO stehen bei KI-Projekten selten im selben Satz, obwohl sie denselben Datensatz betreffen können, sobald ein Sprachmodell in einer amerikanischen Cloud läuft. Der US CLOUD Act erlaubt US-Behörden unter bestimmten Bedingungen Zugriff auf Daten von US-Anbietern, selbst wenn die Server in der EU stehen. Wer KI-Anwendungen mit personenbezogenen oder betrieblich sensiblen Daten plant, muss beide Rechtsrahmen von Anfang an gemeinsam denken, nicht erst, wenn die Rechtsabteilung nach dem Produktivstart Fragen stellt.

Cloud Act und DSGVO: der rechtliche Rahmen für KI-Daten

Der US CLOUD Act von 2018 verpflichtet US-Anbieter, Daten auf behördliche Anordnung herauszugeben, auch wenn diese Daten technisch auf Servern in der EU liegen. An der eigentlichen DSGVO-Pflicht ändert das nichts. Ein Cloud-Anbieter braucht in jedem Fall einen Auftragsverarbeitungsvertrag, der festlegt, wie personenbezogene Daten verarbeitet werden dürfen und wer als Unterauftragsverarbeiter beteiligt ist.

Schrems II erklärte 2020 das EU-US Privacy Shield für ungültig, weil der Europäische Gerichtshof den Zugriff US-amerikanischer Behörden auf europäische Daten als unverhältnismäßig einstufte. Das EU-US Data Privacy Framework ist der Nachfolger dieser Regelung, steht aber laut einer Einschätzung von noyb aus dem Juni 2026 erneut unter Druck. Anlass sind Entscheidungen zur Unabhängigkeit der amerikanischen Aufsichtsbehörde FTC, die nach dieser Einschätzung die Grundlage des Abkommens schwächen.

Datenklassen und Routing-Regel

In der Praxis hilft eine einfache Einteilung mehr als eine juristische Fallunterscheidung für jeden Einzelfall. Personenbezogene und wettbewerbskritische Daten, etwa Konstruktionsdaten oder unveröffentlichte Finanzzahlen, gehören in eine eigene Klasse mit einer klaren Regel, welche Systeme sie verarbeiten dürfen. Allgemeine, öffentlich ohnehin zugängliche Daten können nach dieser Regel in eine internationale Cloud-API gehen, sensible Daten bleiben auf einem europäischen Anbieter oder einer selbst betriebenen Umgebung. Wie sich ein Sprachmodell für genau diese sensiblen Daten vollständig selbst betreiben lässt, beschreibt der Beitrag Private KI-Modelle: On-Premise-LLMs für sensible Daten.

Nach einer Auswertung von gosign aus dem Februar 2026 verarbeiten Unternehmen in einer typischen Aufteilung 60 bis 70 Prozent ihrer KI-Anfragen über internationale Cloud-Anbieter, 25 bis 35 Prozent über deutsches IaaS und 5 bis 10 Prozent On-Premises. Diese Aufteilung folgt in der Regel der Datenklasse, nicht der technischen Bequemlichkeit des jeweiligen Teams.

Wie sich die Routing-Regel technisch umsetzen lässt

In den meisten Architekturen sitzt die Regel an einer einzigen Stelle, einem Gateway oder einer kleinen Middleware, durch die jede Anfrage an ein Sprachmodell läuft. Dort entscheidet ein Tag am Datensatz, etwa „öffentlich“ oder „vertraulich“, welcher Anbieter die Anfrage bekommt. Anwendungsteams müssen die Unterscheidung dadurch nicht selbst treffen, sie wählen nur die Datenklasse beim Anlegen eines neuen Anwendungsfalls.

Diese Stelle eignet sich auch für die Protokollierung. Wer später nachweisen muss, welche Anfrage welchen Anbieter erreicht hat, findet die Antwort in einem einzigen Log statt in mehreren verstreuten Anwendungen.

Der Auftragsverarbeitungsvertrag als Prüfpunkt

Ein Auftragsverarbeitungsvertrag ist nach Artikel 28 DSGVO in jedem Fall Pflicht, unabhängig davon, wo der Anbieter sitzt. Wichtig ist bei einem US-Anbieter, welche Unterauftragsverarbeiter im Vertrag gelistet sind und ob darunter Gesellschaften fallen, die selbst dem US CLOUD Act unterliegen. Ein europäischer Vertragspartner mit einer amerikanischen Muttergesellschaft schützt vor diesem Zugriff meist nicht. Auch ein zweiter oder dritter Unterauftragsverarbeiter in der Kette zählt, etwa ein Betreiber von Rechenzentren oder ein Support-Dienstleister mit Zugriff auf Produktivdaten.

In eigenen Projekten prüfen wir diese Kette grundsätzlich vor der Systemauswahl, nicht danach. Ein Wechsel des Unterauftragsverarbeiters mitten im Projekt kostet in der Praxis mehr Zeit als eine gründliche Prüfung am Anfang, gerade wenn bereits Trainingsdaten oder Embeddings auf dem betroffenen System liegen.

Von der Datenklasse zur Architektur

Eine klare Datenklasse ist die Grundlage für die technische Architektur, die danach folgt. Unser Beitrag zu hybrider KI-Architektur zeigt, wie sich Cloud- und lokale Verarbeitung in der Praxis kombinieren lassen, ohne für jede einzelne Anfrage eine neue Entscheidung zu treffen. Wer die eigene Datenlage rechtlich und technisch gemeinsam einordnen will, bekommt dafür in einem Erstgespräch zur KI-Beratung einen strukturierten Einstieg.

Häufige Fragen

Reicht ein EU-Rechenzentrum?

Ein EU-Rechenzentrum erfüllt die DSGVO-Anforderung an den Verarbeitungsort, verhindert aber nicht automatisch den Zugriff über den US CLOUD Act. Wichtig ist die Nationalität und Konzernstruktur des Anbieters, nicht allein der Serverstandort. Ein US-Unternehmen mit einem Rechenzentrum in Frankfurt bleibt dem US CLOUD Act unterworfen, auch wenn die Daten die EU nie verlassen.

Welche Daten dürfen nie in die Cloud-API?

Eine pauschale Antwort gibt es nicht, aber die höchste Vorsicht gilt für unveröffentlichte Patente, Konstruktionsdaten mit Wettbewerbsrelevanz und besonders sensible personenbezogene Daten nach Artikel 9 DSGVO, etwa Gesundheitsdaten. Für diese Kategorien lohnt sich eine lokale oder europäische Verarbeitung unabhängig vom technischen Mehraufwand. Im Zweifel hilft die Überlegung, ob ein Verlust dieser Daten dem Unternehmen ernsthaft schaden würde. Bei einer solchen Kategorie zählt die höchste Schutzklasse mehr als der Komfort des Entwicklungsteams.

Was ändert sich, wenn das Framework fällt?

Fällt das EU-US Data Privacy Framework wie zuvor das Privacy Shield, verlieren Unternehmen die einfachste Rechtsgrundlage für Datentransfers in die USA und müssen auf Standardvertragsklauseln mit zusätzlichen Garantien ausweichen. Wer schon jetzt nach Datenklassen trennt, muss dann nur die Routing-Regel für eine Klasse anpassen, nicht die gesamte Architektur neu bauen. Genau dafür lohnt sich die Vorarbeit, auch wenn sie im laufenden Projekt zunächst wie zusätzlicher Aufwand wirkt.

Warum torck

torck entwickelt und betreibt KI-Systeme mit eigenen Teams in Maxhütte-Haidhof, Wien und Rabat und legt die Datenklasse für jedes Projekt fest, bevor die erste Zeile Code entsteht. Vertragspartner ist die deutsche torck GmbH, ein Vertrag statt einer Subunternehmerkette, was die Prüfung der Unterauftragsverarbeiter aus diesem Beitrag deutlich verkürzt. Diese Reihenfolge erspart teure Umbauten, wenn sich die Rechtslage rund um transatlantische Datentransfers ändert. Wer die eigene Architektur rechtlich und technisch absichern will, kann das in einem Erstgespräch zur KI-Beratung besprechen.

Gespräch vereinbaren