Suche

Wonach suchen Sie?

Durchsuchen Sie Leistungen, Anwendungsfälle und unser Praxiswissen.

Mindestens 2 Zeichen eingeben

Beliebte Einstiege

Daten & Governance

Was bedeutet Zero Data Retention (ZDR) – und was garantiert es nicht?

Zero Data Retention klingt nach einer einfachen Zusage: Daten werden nicht gespeichert. In der Praxis ist ZDR jedoch eine anbieter- und produktspezifische Regel mit einem genau definierten Geltungsbereich, technischen Voraussetzungen und möglichen Ausnahmen.

Die kurze Antwort

Zero Data Retention bezeichnet eine vertragliche oder technische Regel, nach der erfasste Kundeninhalte bei den abgedeckten Funktionen nach der Verarbeitung nicht dauerhaft gespeichert werden. Die Inhalte werden trotzdem verarbeitet, und ZDR sagt allein noch nichts über Training, Metadaten, Datenstandort, Drittanbieter oder nicht abgedeckte Funktionen aus.

Kurz zusammengefasst

  • ZDR ist kein einheitlicher Rechts- oder Industriestandard; die genaue Definition steht beim jeweiligen Anbieter.
  • Die Zusage gilt häufig nur für bestimmte Konten, Projekte, Modelle, APIs und Funktionen.
  • Keine dauerhafte Speicherung bedeutet nicht keine Verarbeitung, keine Metadaten und keine Drittanbieter.
  • Vertrag, Funktionsmatrix, aktive Konfiguration und tatsächliche Datenflüsse müssen zusammenpassen.

ZDR ist eine Aufbewahrungsregel, kein Datenschutzsiegel

Damit ein Modell eine Antwort erzeugt, muss es Eingaben technisch verarbeiten. ZDR betrifft in der Regel die Frage, ob definierte Kundeninhalte nach dieser Verarbeitung beim Anbieter gespeichert bleiben. Welche Inhalte erfasst sind und welche Ausnahmen gelten, unterscheidet sich jedoch deutlich.

  • Die Verarbeitung der aktuellen Anfrage findet weiterhin statt.
  • Ein- und Ausgaben können für abgedeckte Funktionen ohne dauerhafte Speicherung verarbeitet werden.
  • Betriebs- oder Abrechnungsmetadaten können ausserhalb der Zusage liegen.
  • Gesetzlich notwendige oder sicherheitsbezogene Ausnahmen können vorgesehen sein.
  • Eigene Speicherungen des Kunden werden durch ZDR nicht verhindert.

Sechs Zusagen, die nicht verwechselt werden sollten

Anbieter verwenden mehrere ähnlich klingende Aussagen. Für eine belastbare Entscheidung muss jede davon separat beantwortet werden.

Sechs Zusagen, die nicht verwechselt werden sollten
ZusageWas sie tatsächlich beantwortetWas offenbleibtWelcher Nachweis zählt
Kein TrainingDefinierte Kundendaten werden nicht zur Verbesserung oder zum Training von Modellen verwendet.Speicherung, Supportzugriff, Missbrauchserkennung und eigene Logs.Vertrag, Produkteinstellung und dokumentierter Geltungsbereich.
Zero Data RetentionAbgedeckte Inhalte werden nach der Verarbeitung beim Anbieter nicht dauerhaft aufbewahrt.Verarbeitung, Metadaten, Drittanbieter, nicht abgedeckte Funktionen und eigene Speicherungen.ZDR-Vereinbarung, Endpunkt- und Funktionsmatrix sowie aktive Kontokonfiguration.
Kein AnwendungszustandGespräche, Dateien oder Assistentenzustände werden nicht für die spätere Nutzung erhalten.Sicherheits- und Abrechnungsprotokolle sowie externe Integrationen.Produktdokumentation plus Test, ob Verlauf, Dateien und Zustand wirklich fehlen.
DatenresidenzBestimmte Daten werden in einer ausgewählten Region gespeichert und allenfalls verarbeitet.Supportzugriffe, globale Metadaten, Unterauftragnehmer und Modelltraining.Vertragliche Regionszusage und Liste der ausgenommenen Datenarten und Dienste.
Keine menschliche EinsichtInhalte werden nicht regulär von Support- oder Sicherheitsteams angesehen.Automatisierte Verarbeitung und ausdrücklich geregelte Ausnahmefälle.Vertragsklausel mit Rollen, Anlässen, Genehmigung und Protokollierung von Zugriffen.
LöschbarkeitBereits gespeicherte Daten können innerhalb definierter Fristen entfernt werden.Backups, abgeleitete Daten, gesetzliche Aufbewahrung und Daten in Folgesystemen.Getesteter Löschprozess mit Fristen, Umfang und Löschbestätigung.

Der Geltungsbereich endet oft an einer Funktionsgrenze

Eine ZDR-Freigabe für eine API bedeutet nicht automatisch, dass jede Funktion desselben Anbieters abgedeckt ist. Gerade komfortable Funktionen benötigen häufig Zustand oder Speicher.

  • Ist ZDR für Organisation, Projekt oder einzelnen Vertrag aktiviert?
  • Welche Modelle und API-Endpunkte sind abgedeckt?
  • Speichern Datei-Uploads, Batch-Verarbeitung, Gesprächsverlauf oder Prompt-Caching Daten?
  • Gelten andere Regeln für Beta- und Vorschaufunktionen?
  • Speichern Websuche, Codeausführung, Connectors oder andere Drittanbieter eigene Daten?
  • Welche Sicherheits-, Missbrauchs- oder gesetzlichen Ausnahmen bestehen?

So lässt sich eine ZDR-Zusage prüfen

Eine Marketingseite genügt nicht. Die Zusage muss dem konkret eingesetzten Produkt und der technischen Konfiguration zugeordnet werden können.

  1. Schritt 1

    Vertrag lesen

    Definieren lassen, welche Daten, Produkte, Ausnahmen und Löschfristen umfasst sind.

  2. Schritt 2

    Funktionsmatrix prüfen

    Für jeden Endpunkt und jedes Werkzeug festhalten, ob Anwendungszustand entsteht.

  3. Schritt 3

    Aktivierung belegen

    Organisation, Projekt und Schlüssel auf die zugesagte Einstellung kontrollieren.

  4. Schritt 4

    Gesamtsystem prüfen

    Eigene Logs, Datenbanken, Observability-Dienste und Connectors in die Analyse einbeziehen.

  5. Schritt 5

    Änderungen überwachen

    Neue Modelle, Funktionen und Anbieterbedingungen vor der Nutzung erneut freigeben.

Wann ZDR hilfreich ist – und wann es nicht genügt

ZDR kann einen unnötigen Speicherort beseitigen und damit das Risiko bei kurzlebigen Modellanfragen reduzieren. Es ersetzt jedoch keine Datenklassifikation, Rechtsgrundlage, Zugriffskontrolle oder sichere Anwendungsarchitektur.

  • Hilfreich bei klar begrenzten, zustandslosen Anfragen mit vertraulichen Inhalten
  • Unzureichend, wenn die eigene Anwendung vollständige Prompts dauerhaft protokolliert
  • Unzureichend, wenn ein Connector Dokumente an einen nicht abgedeckten Drittdienst sendet
  • Unzureichend, wenn zu viele Mitarbeitende oder Systeme auf die Ausgangsdaten zugreifen können
  • Unzureichend, wenn Zweck, Zulässigkeit oder Informationspflichten ungeklärt sind
  • Unzureichend ohne Export-, Lösch-, Vorfalls- und Anbieterwechselkonzept
Beispiel aus dem Unternehmensalltag

Beispiel: Vertrauliche Vertragsanalyse über eine API

Eine Rechtsabteilung möchte einzelne Klauseln zusammenfassen lassen. Der verwendete Text-Endpunkt ist laut Vertrag und Kontoeinstellung ZDR-fähig. Die geplante Dateiablage des Anbieters wäre dagegen nicht abgedeckt. Deshalb liest die eigene Anwendung das Dokument ein, sendet nur die relevanten Klauseln zustandslos an den freigegebenen Endpunkt und speichert das geprüfte Ergebnis im eigenen Dokumentensystem. Inhaltshaltige Debug-Logs sind deaktiviert; Kontokonfiguration und Endpunkt werden dokumentiert.

Was Sie mitnehmen sollten

Fragen Sie nicht nur „Hat der Anbieter ZDR?“, sondern „Welche konkreten Daten werden bei unserem Endpunkt, unseren Funktionen und unserer Konfiguration wo und wie lange gespeichert?“ Erst diese Antwort ist für eine Architekturentscheidung brauchbar.

Quellen und Vertiefung

Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.

Inhaltlich geprüft

Fachliche Einordnung auf Basis offizieller Anbieter- und Behördenquellen. Keine Rechtsberatung; Produktbedingungen und ZDR-Umfang können sich ändern und sind für die konkrete Konfiguration zu prüfen.

Sie möchten das auf Ihre Situation übertragen?

Wir klären gemeinsam, was für Ihren Prozess, Ihre Daten und Ihre Systeme sinnvoll ist – verständlich und ohne unnötige Komplexität.

Projekt besprechen