CLOUD Act, ZDR und ZOA

Unternehmen, Behörden und andere Organisationen möchten generative KI nutzen, ohne dabei die Kontrolle über vertrauliche Informationen, personenbezogene Daten oder Geschäftsgeheimnisse zu verlieren. In diesem Zusammenhang fallen zunehmend Begriffe wie CLOUD Act, Zero Data Retention und Zero Operator Access.

Häufig werden diese Begriffe jedoch vermischt. Ein Rechenzentrum in Deutschland, eine Zusage zur Nicht-Speicherung und eine technisch abgeschottete KI-Umgebung betreffen drei unterschiedliche Ebenen:

die rechtliche Zugriffsmöglichkeit,
die Speicherung von Daten,
den technischen Zugriff durch den Betreiber.

Erst wenn alle drei Ebenen betrachtet werden, lässt sich beurteilen, wie souverän eine Cloud- oder KI-Lösung tatsächlich ist.

Was regelt der US CLOUD Act?

Der Clarifying Lawful Overseas Use of Data Act, kurz CLOUD Act, ist ein US-amerikanisches Gesetz aus dem Jahr 2018. Er stellt insbesondere klar, dass Anbieter elektronischer Kommunikations- oder Remote-Computing-Dienste unter bestimmten Voraussetzungen zur Herausgabe von Daten verpflichtet werden können, die sich in ihrem „possession, custody, or control“ befinden – also in ihrem Besitz, ihrer Verwahrung oder unter ihrer Kontrolle.

Dabei ist nach dem Wortlaut der maßgeblichen Regelung nicht entscheidend, ob die Daten innerhalb oder außerhalb der USA gespeichert sind.

Das führt zu einem wichtigen Grundsatz:

Der Speicherort allein entscheidet nicht darüber, welchem staatlichen Zugriffsrecht ein Cloud-Dienst unterliegen kann.

Ein Rechenzentrum in Frankfurt macht einen Dienst deshalb nicht automatisch unabhängig von US-amerikanischem Recht. Entscheidend sind unter anderem die gesellschaftsrechtliche Struktur des Anbieters, seine Niederlassungen, seine tatsächliche Kontrolle über die Daten und die konkrete technische Architektur.

Umgekehrt bedeutet die mögliche Anwendbarkeit des CLOUD Act nicht, dass US-Behörden jederzeit frei auf sämtliche Kundendaten zugreifen können. Eine Datenherausgabe setzt ein rechtliches Verfahren und eine entsprechende Anordnung voraus. Für eine Risikoanalyse ist dennoch relevant, ob ein Anbieter überhaupt technisch und rechtlich in der Lage wäre, die betreffenden Daten herauszugeben.

Auch die europäischen Datenschutzbehörden weisen darauf hin, dass sich beim CLOUD Act Konflikte mit dem europäischen Datenschutzrecht ergeben können und eine US-amerikanische Herausgabeanordnung nicht automatisch eine Rechtsgrundlage nach der DSGVO darstellt.

Was bedeutet Zero Data Retention?

Zero Data Retention, kurz ZDR, bedeutet im KI-Kontext, dass der Anbieter die übermittelten Prompts und die erzeugten Antworten nach Abschluss der Verarbeitung nicht dauerhaft speichert.

Der typische Ablauf sieht dann so aus:

Ein Benutzer übermittelt eine Anfrage.
Das KI-Modell verarbeitet die Anfrage.
Die Antwort wird zurückgegeben.
Prompt und Antwort werden anschließend nicht in den regulären Protokoll- oder Trainingssystemen des Anbieters gespeichert.

OpenAI beschreibt ZDR beispielsweise als eine Datenkontrolle, durch die Kundeninhalte unter anderem von bestimmten Missbrauchsüberwachungsprotokollen ausgeschlossen werden. Die genaue Wirkung hängt allerdings vom jeweiligen Dienst und Endpunkt ab.

ZDR kann Risiken deutlich reduzieren. Daten, die nicht mehr vorhanden sind, können später grundsätzlich weder von Mitarbeitern eingesehen noch aufgrund einer Behördenanfrage herausgegeben werden.

Allerdings ist „Zero“ nicht immer vollständig wörtlich zu verstehen. Vor einem Einsatz müssen deshalb die Ausnahmen geprüft werden. Relevant sind insbesondere:

technische Metadaten,
Abrechnungsdaten,
Sicherheitsprotokolle,
Fehlerprotokolle,
Caches,
Backups,
Anhänge und hochgeladene Dateien,
Daten in verbundenen Werkzeugen,
externe Modellanbieter,
Daten, die der Kunde selbst in einer Anwendung speichert.

ZDR ist deshalb keine allgemeine Eigenschaft eines Unternehmens, sondern eine konkrete Zusage für einen bestimmten Dienst, Vertrag, Endpunkt und Datenfluss.

Was bedeutet Zero Operator Access?

Zero Operator Access, kurz ZOA, geht an einer anderen Stelle an.

ZOA bedeutet, dass Administratoren oder andere Mitarbeiter des Cloud- beziehungsweise KI-Betreibers technisch keine Möglichkeit haben sollen, auf die im System verarbeiteten Kundendaten zuzugreifen.

Amazon beschreibt ZOA bei seiner Mantle-Architektur beispielsweise als ein Design, bei dem bewusst keine technischen Zugriffsmöglichkeiten für AWS-Mitarbeiter auf Kundendaten vorgesehen wurden.

Eine belastbare ZOA-Architektur kann unter anderem folgende Komponenten umfassen:

hardwaregestützte Isolation,
Confidential Computing,
abgeschottete Ausführungsumgebungen,
kryptografische Attestierung,
kundenseitig kontrollierte Schlüssel,
stark eingeschränkte Administrationsschnittstellen,
unveränderbare Zugriffsprotokolle,
automatisierte Wartungs- und Updateprozesse.

Der Unterschied zu einer reinen organisatorischen Regel ist wesentlich.

Die Aussage „Unsere Mitarbeiter dürfen nicht auf Kundendaten zugreifen“ beschreibt zunächst eine Richtlinie. ZOA soll dagegen bedeuten: „Unsere Mitarbeiter können technisch nicht auf Kundendaten zugreifen.“

Doch auch bei ZOA müssen die Grenzen betrachtet werden. Zu klären ist beispielsweise, ob die Zugriffssperre für alle Betriebszustände gilt oder ob es Ausnahmen bei Supportfällen, Störungen, forensischen Untersuchungen oder behördlichen Maßnahmen gibt.

ZDR und ZOA lösen unterschiedliche Probleme

ZDR und ZOA werden häufig gemeinsam genannt, sind aber nicht dasselbe.

ZDR beantwortet die Frage:

Welche Kundendaten bleiben nach der Verarbeitung gespeichert?

ZOA beantwortet die Frage:

Wer kann während der Verarbeitung technisch auf die Daten zugreifen?

Eine Lösung kann ZDR bieten, ohne ZOA zu gewährleisten. Dann werden Daten nach der Verarbeitung gelöscht, könnten während der Verarbeitung aber theoretisch von privilegierten Administratoren eingesehen werden.

Umgekehrt kann eine Plattform ZOA bieten, Daten aber langfristig verschlüsselt speichern. Mitarbeiter können dann möglicherweise nicht auf die Inhalte zugreifen, die Daten sind jedoch weiterhin vorhanden.

Für besonders schützenswerte Informationen ist daher die Kombination interessant:

keine dauerhafte Speicherung der Inhalte,
kein technischer Betreiberzugriff,
möglichst geringe rechtliche Zugriffsmöglichkeiten,
Kontrolle der Verschlüsselungsschlüssel durch den Kunden.

Warum ZDR und ZOA den CLOUD Act nicht automatisch ausschalten

ZDR und ZOA sind technische beziehungsweise organisatorische Schutzmaßnahmen. Der CLOUD Act ist eine rechtliche Regelung. Diese Ebenen dürfen nicht gleichgesetzt werden.

Eine ZDR-Zusage kann die Menge der herausgabefähigen Daten reduzieren. Eine konsequent umgesetzte ZOA-Architektur kann verhindern, dass ein Anbieter technisch auf Klartextdaten zugreifen kann. Beide Maßnahmen können damit das praktische Risiko eines Zugriffs deutlich senken.

Sie ändern jedoch nicht zwingend die rechtliche Einordnung des Anbieters.

Ein US-amerikanischer Anbieter kann weiterhin US-Recht unterliegen, auch wenn ein bestimmter Dienst mit ZDR oder ZOA betrieben wird. Entscheidend ist dann, ob die Daten tatsächlich außerhalb seiner technischen Kontrolle liegen und wie belastbar diese Eigenschaft vertraglich und technisch nachgewiesen wird.

Die richtige Frage lautet deshalb nicht nur:

Unterliegt der Anbieter dem CLOUD Act?

Sondern auch:

Welche verwertbaren Daten befinden sich tatsächlich in seinem Besitz, seiner Verwahrung oder unter seiner Kontrolle?

Wie lassen sich Hetzner und STACKIT damit vergleichen?

Hetzner und STACKIT werden häufig als europäische Alternativen zu US-amerikanischen Hyperscalern genannt. Dabei muss zunächst berücksichtigt werden, dass beide Anbieter primär Cloud- und Infrastrukturleistungen bereitstellen.

Wer dort selbst ein KI-Modell betreibt, erhält nicht automatisch ZDR oder ZOA. Diese Eigenschaften müssen durch die Architektur der eigenen Anwendung hergestellt werden.

Hetzner

Hetzner ist ein deutscher Hostinganbieter. Das Unternehmen betreibt eigene Rechenzentrumsparks in Nürnberg, Falkenstein und Helsinki. Zusätzlich bietet Hetzner Cloud-Standorte außerhalb Europas an, darunter Ashburn in den USA; dort nutzt das Unternehmen Colocation-Kapazitäten.

Für eine souveränitätsorientierte Architektur müsste der Kunde daher bewusst einen europäischen Standort auswählen und sicherstellen, dass auch Backups, Snapshots, Supportprozesse und nachgelagerte Dienste innerhalb des gewünschten Rechtsraums verbleiben.

Hetzner weist darauf hin, dass bei Nicht-Cloud-Produkten Daten ausschließlich innerhalb der EU verarbeitet und gespeichert werden. Bei Cloud-Produkten hängt die Datenverarbeitung dagegen vom gewählten Standort und dem konkreten Produkt ab.

Ein typisches Szenario könnte so aussehen:

Ein Unternehmen mietet Server in Deutschland.
Es installiert ein quelloffenes Sprachmodell selbst.
Prompts werden nur im Arbeitsspeicher verarbeitet.
Anwendungslogs werden deaktiviert oder minimiert.
Datenbanken und Backups verbleiben in Deutschland.
Verschlüsselungsschlüssel werden separat kontrolliert.

In einem solchen Modell kann der Betreiber der KI-Anwendung ZDR weitgehend selbst umsetzen.

Echtes ZOA ist schwieriger. Bei klassischer Server- oder Cloud-Infrastruktur besitzt der Infrastrukturbetreiber regelmäßig privilegierte technische Möglichkeiten auf bestimmten Ebenen. Um einen Administratorzugriff auch technisch auszuschließen, wären zusätzliche Maßnahmen wie Confidential Computing, eigene Schlüsselverwaltung und überprüfbare Attestierung erforderlich.

STACKIT

STACKIT ist Teil von Schwarz Digits und positioniert sich ausdrücklich als europäische beziehungsweise souveräne Cloud. Nach Angaben des Unternehmens werden Daten ausschließlich in Europa gespeichert und verarbeitet. Die Rechenzentren befinden sich in Deutschland und Österreich.

STACKIT verweist außerdem auf Zertifizierungen, darunter ISO 27001 auf Basis des IT-Grundschutzes für definierte Infrastruktur- und Plattformdienste.

Im Vergleich zu einem klassischen Infrastrukturhoster liegt der Schwerpunkt stärker auf einer breiteren Cloud-Plattform mit Managed Services, Kubernetes, Speicher-, Identitäts- und Sicherheitsdiensten.

Für regulierte Organisationen kann das Vorteile haben:

europäische gesellschaftsrechtliche Struktur,
Datenhaltung in Deutschland und Österreich,
dokumentierte Compliance-Strukturen,
umfangreichere Managed Services,
Ausrichtung auf Unternehmen und öffentliche Verwaltung.

Aber auch bei STACKIT gilt: Der Einsatz eines europäischen Hosters erzeugt nicht automatisch ZDR oder ZOA für eine KI-Anwendung.

Wird beispielsweise ein Sprachmodell auf STACKIT betrieben, während die Anwendung sämtliche Prompts in einer Datenbank protokolliert, liegt keine Zero-Data-Retention-Architektur vor. Werden Administratorzugänge ohne zusätzliche technische Abschottung ermöglicht, liegt auch nicht zwingend Zero Operator Access vor.

Ein sinnvoller Vergleich

Hetzner, STACKIT und ein US-amerikanischer KI-Dienst lassen sich nicht allein anhand des Preises oder des Rechenzentrumsstandorts vergleichen. Sinnvoller ist ein mehrdimensionales Bewertungsmodell.

Kriterium	Externer US-KI-Dienst	KI auf Hetzner	KI auf STACKIT
Betreiber des Modells	Externer KI-Anbieter	In der Regel der Kunde	In der Regel der Kunde oder ein Partner
Rechtsraum des Anbieters	Häufig USA beziehungsweise international	Deutschland	Deutschland beziehungsweise EU
CLOUD-Act-Exposition	Je nach Konzernstruktur grundsätzlich relevant	Typischerweise geringer, aber im Einzelfall zu prüfen	Nach Anbieterpositionierung keine US-Konzernstruktur
Datenstandort	Vertrags- und produktabhängig	Vom gewählten Standort abhängig	Deutschland und Österreich
ZDR	Produkt- und vertragsabhängig	Durch den Kunden umsetzbar	Durch den Kunden beziehungsweise Lösungsanbieter umsetzbar
ZOA	Nur bei spezieller Architektur	Nicht automatisch enthalten	Nicht automatisch enthalten
Betriebsaufwand	Niedrig	Eher hoch	Mittel bis hoch
Funktionsumfang	Häufig sehr hoch	Abhängig vom eigenen Aufbau	Größeres Cloud-Service-Portfolio
Modellkontrolle	Begrenzt	Hoch	Hoch
Nachweisführung	Anbieterunterlagen erforderlich	Weitgehend eigene Verantwortung	Kombination aus Anbieter- und Eigennachweisen

Die Tabelle zeigt: Ein europäischer Hoster kann die rechtliche Ausgangslage verbessern, verlagert aber einen erheblichen Teil der Verantwortung auf den Kunden.

Bei einem vollständig gemanagten KI-Dienst kümmert sich der Anbieter um Modellbetrieb, Skalierung, Updates und Sicherheit. Beim Selbstbetrieb auf Hetzner oder STACKIT muss das Unternehmen diese Aufgaben selbst übernehmen oder einen spezialisierten Dienstleister beauftragen.

Hetzner oder STACKIT: Was passt zu wem?

Eine pauschale Aussage, welcher Anbieter „sicherer“ ist, wäre unseriös. Beide adressieren teilweise unterschiedliche Anforderungen.

Hetzner eignet sich häufig für:

technisch erfahrene Teams,
kostensensible Projekte,
dedizierte Server und flexible Infrastruktur,
selbst betriebene Open-Source-Modelle,
Architekturen mit hohem Eigenverantwortungsgrad,
Organisationen, die ihre Plattform weitgehend selbst verwalten.

STACKIT eignet sich häufig für:

größere Unternehmen,
öffentliche und regulierte Organisationen,
Projekte mit umfangreichen Compliance-Anforderungen,
Plattform- und Managed-Service-Architekturen,
Organisationen, die eine europäische Cloud-Alternative mit breiterem Serviceportfolio suchen,
Ausschreibungen, bei denen Zertifizierungen und dokumentierte Souveränitätsmerkmale eine zentrale Rolle spielen.

Die tatsächliche Entscheidung sollte nicht nur auf Marketingbegriffen beruhen. Sie sollte aus einem dokumentierten Schutzbedarf, einer Bedrohungsanalyse und einer klaren Zielarchitektur abgeleitet werden.

Die entscheidenden Fragen an einen KI- oder Cloud-Anbieter

Vor der Verarbeitung vertraulicher Daten sollten Unternehmen mindestens folgende Punkte prüfen:

Recht und Organisation

Welche juristische Person ist Vertragspartner?
In welchen Ländern bestehen Muttergesellschaften, Tochterunternehmen und Niederlassungen?
Welchen ausländischen Herausgabe- und Überwachungsgesetzen kann der Anbieter unterliegen?
Welche Unterauftragnehmer werden eingesetzt?
Existiert ein belastbarer Auftragsverarbeitungsvertrag?
Wie werden Behördenanfragen geprüft und dokumentiert?

Speicherung und ZDR

Werden Prompts und Antworten gespeichert?
Gilt ZDR für sämtliche Modelle und API-Endpunkte?
Sind Sicherheits- und Missbrauchsprotokolle ausgenommen?
Werden Metadaten, Dateien oder Embeddings gespeichert?
Wie lange verbleiben Daten in Caches und Backups?
Nutzen Unterauftragnehmer dieselben Löschregeln?

Zugriff und ZOA

Können Administratoren Klartextdaten einsehen?
Bestehen technische oder nur organisatorische Zugriffsbeschränkungen?
Gibt es privilegierte Notfallzugänge?
Werden Zugriffe revisionssicher protokolliert?
Unterstützt die Plattform Confidential Computing?
Wer kontrolliert die Verschlüsselungsschlüssel?
Ist die technische Abschottung durch Attestierung oder externe Audits nachweisbar?

Eigene Anwendung

Protokolliert die eigene Software Prompts?
Speichert ein Chat-Frontend Gesprächsverläufe?
Werden Daten an Monitoring-, Analyse- oder Ticketsysteme übertragen?
Können Benutzer unbeabsichtigt besonders sensible Daten eingeben?
Existieren Rollen-, Lösch- und Berechtigungskonzepte?
Werden Modelle, Container und Abhängigkeiten regelmäßig aktualisiert?

Ein praktisches Zielbild für souveräne Unternehmens-KI

Eine belastbare europäische KI-Architektur könnte beispielsweise aus folgenden Komponenten bestehen:

Ein europäischer Cloud- oder Hostinganbieter ohne beherrschende US-Muttergesellschaft.
Ein ausdrücklich gewählter Rechenzentrumsstandort in Deutschland oder der EU.
Ein selbst betriebenes oder vertraglich kontrolliertes KI-Modell.
Keine dauerhafte Speicherung von Prompts und Antworten.
Strikte Minimierung technischer Metadaten.
Verschlüsselte Kommunikation und verschlüsselte Datenträger.
Kundenseitig kontrollierte Schlüssel für besonders sensible Daten.
Technische Isolation der KI-Workloads.
Revisionssichere, aber inhaltsarme Sicherheitsprotokolle.
Vertraglich definierte Lösch-, Support- und Behördenprozesse.

Bei besonders hohem Schutzbedarf können zusätzlich Confidential Computing, separate Hardware, private Netzwerke und eine lokale Vorverarbeitung personenbezogener Daten eingesetzt werden.

Fazit: Souveränität ist mehr als ein Serverstandort

Der CLOUD Act betrifft die rechtliche Ebene. ZDR betrifft den Lebenszyklus der Daten. ZOA betrifft die technischen Zugriffsmöglichkeiten des Betreibers.

Keiner dieser Begriffe kann die anderen ersetzen.

Ein US-amerikanischer KI-Anbieter mit ZDR und einer belastbaren ZOA-Architektur kann technisch sehr gut abgesichert sein, bleibt aber möglicherweise Teil eines US-amerikanischen Rechts- und Konzernraums.

Ein deutscher oder europäischer Hoster wie Hetzner oder STACKIT kann die rechtliche Abhängigkeit von US-Anbietern reduzieren. Der europäische Standort allein garantiert jedoch weder Zero Data Retention noch Zero Operator Access.

Die zentrale Erkenntnis lautet daher:

Digitale Souveränität entsteht nicht durch ein einzelnes Zertifikat, einen Serverstandort oder ein Datenschutzversprechen. Sie entsteht aus dem Zusammenspiel von Rechtsraum, Unternehmenskontrolle, technischer Architektur, Datenminimierung und überprüfbaren Verträgen.

Für weniger sensible Anwendungen kann ein vertraglich abgesicherter, gemanagter KI-Dienst ausreichen. Bei Geschäftsgeheimnissen, Gesundheitsdaten, Verwaltungsinformationen oder kritischer Infrastruktur spricht dagegen vieles für eine kontrollierte europäische Architektur – gegebenenfalls mit einem selbst betriebenen Modell auf Infrastruktur von Hetzner, STACKIT oder einem vergleichbaren europäischen Anbieter.

Entscheidend ist nicht, welcher Anbieter auf seiner Website am häufigsten das Wort „souverän“ verwendet. Entscheidend ist, wer technisch und rechtlich tatsächlich Kontrolle über die Daten besitzt.

Wie souverän ist eine KI wirklich?