OpenAI baut Zero Data Retention aus: Was das für Unternehmens-KI bedeutet

Bei vielen KI-Projekten ist heute nicht mehr die Qualität des Modells der größte Stolperstein.

Die eigentliche Frage lautet zunehmend:

Was passiert mit unseren Daten, wenn wir sie an ein KI-Modell senden?

Gerade sobald interne Dokumente, Kundeninformationen, Vertragsinhalte oder andere sensible Daten verarbeitet werden sollen, reicht ein „Das Modell ist ziemlich gut“ als Entscheidungsgrundlage nicht mehr aus.

Am 19. August 2026 hat OpenAI deshalb ein bemerkenswertes Update veröffentlicht. Das Unternehmen bekräftigt darin, Zero Data Retention – kurz ZDR – auch für leistungsfähige Frontier-Modelle anbieten zu wollen. Gleichzeitig kündigt OpenAI mit „Private Safety Processing“ einen neuen Ansatz an, der Sicherheitsmechanismen ermöglichen soll, ohne OpenAI-Mitarbeitern Zugriff auf die zugrunde liegenden Kundeninhalte zu geben.

Das klingt zunächst nach einem sehr technischen Infrastrukturthema.

Für Unternehmen könnte es allerdings eine der wichtigeren Entwicklungen bei der produktiven Einführung von KI sein.

Was bedeutet Zero Data Retention überhaupt?

Zero Data Retention bedeutet vereinfacht gesagt, dass über die entsprechenden API-Aufrufe übermittelte Prompts und Modellantworten nach der Verarbeitung nicht von OpenAI gespeichert werden.

OpenAI beschreibt das für berechtigte API-Kunden so: Kundeninhalte werden nach der Anfrage nicht aufbewahrt und stehen Mitarbeitern des Unternehmens nicht zur manuellen Prüfung zur Verfügung. Unternehmensdaten werden außerdem grundsätzlich nicht für das Training der Modelle verwendet, solange ein Kunde dies nicht ausdrücklich aktiviert.

Das ist ein wichtiger Unterschied zur Frage, ob ein Anbieter grundsätzlich Daten „zum Training verwendet“.

Denn aus Unternehmenssicht sind eigentlich mehrere Fragen voneinander zu trennen:

Werden meine Daten für Modelltraining verwendet?

Wie lange werden Ein- und Ausgaben gespeichert?

Wo werden sie verarbeitet?

Wer kann darauf zugreifen?

Welche Metadaten entstehen trotzdem?

Und welche externen Systeme werden innerhalb meines eigenen KI-Prozesses zusätzlich eingebunden?

Genau diese Unterscheidung ist wichtig, weil „unsere Daten werden nicht zum Training verwendet“ keineswegs automatisch bedeutet, dass überhaupt keine Speicherung erfolgt.

OpenAI weist beispielsweise für die normale API-Nutzung darauf hin, dass Eingaben und Ausgaben außerhalb bestimmter Konfigurationen und Funktionen für einen begrenzten Zeitraum zur Bereitstellung der Dienste und Missbrauchserkennung aufbewahrt werden können. Für berechtigte Organisationen stehen dagegen zusätzliche Retention Controls bis hin zu Zero Data Retention zur Verfügung.

Warum OpenAI jetzt überhaupt über ZDR spricht

Das Interessante an der aktuellen Meldung ist nicht, dass Zero Data Retention grundsätzlich neu wäre.

Das ist es nicht.

Spannend ist vielmehr, warum OpenAI das Thema jetzt erneut hervorhebt.

KI-Systeme erledigen inzwischen zunehmend längere und komplexere Aufgaben. Ein klassischer API-Aufruf bestand vielleicht aus einer Frage und einer Antwort.

Ein moderner KI-Agent kann dagegen über längere Zeit arbeiten, mehrere Werkzeuge verwenden, Informationen zusammensuchen und verschiedene Aktionen nacheinander ausführen.

Damit verändern sich auch die Sicherheitsanforderungen.

OpenAI argumentiert, dass manche gefährlichen oder missbräuchlichen Nutzungsmuster erst sichtbar werden, wenn mehrere Interaktionen gemeinsam betrachtet werden. Genau das ist bei einem klassischen ZDR-Modell schwierig: Wenn Inhalte nicht gespeichert werden, können sie auch nicht später von einem Sicherheitsteam zusammengesetzt und untersucht werden.

Die bisher naheliegende Antwort wäre:

Dann muss der Anbieter die Inhalte eben speichern.

Für viele Unternehmen wäre genau das jedoch problematisch.

OpenAI versucht deshalb, mit Private Safety Processing beide Ziele miteinander zu verbinden.

Was ist Private Safety Processing?

Das Konzept befindet sich aktuell noch in einer frühen Phase.

Nach Angaben von OpenAI soll das System zusammenhängende Interaktionen automatisiert auf problematische Muster untersuchen können, ohne dass OpenAI-Mitarbeiter die eigentlichen Kundeninhalte sehen.

Bei klassischen ZDR-Deployments verbleiben die Kundeninhalte laut OpenAI auf Infrastruktur, die der Kunde kontrolliert. Zusätzlich arbeitet das Unternehmen an einer Variante, bei der Inhalte auf OpenAI-Infrastruktur gespeichert, aber mit Schlüsseln verschlüsselt werden, die der Kunde kontrolliert. OpenAI selbst soll keine Kopie dieser Schlüssel besitzen.

Falls das automatisierte Sicherheitssystem ein Problem erkennt, soll OpenAI lediglich ein begrenztes Sicherheitssignal erhalten und nicht automatisch den dazugehörigen Prompt oder die Antwort.

Private Safety Processing wird aktuell mit ersten Kunden getestet. OpenAI plant nach eigenen Angaben, im September 2026 weitere technische Informationen beziehungsweise ein Whitepaper zu veröffentlichen.

Für Unternehmen ist das deshalb interessant, weil hier ein grundsätzliches Spannungsfeld sichtbar wird:

Je leistungsfähiger KI-Agenten werden, desto mehr Sicherheitskontrollen brauchen sie.

Gleichzeitig möchten Unternehmen gerade bei sensiblen Prozessen immer weniger Daten unnötig an externe Anbieter abgeben.

ZDR ist nicht dasselbe wie EU-Datenresidenz

Ein Punkt wird bei solchen Diskussionen häufig durcheinandergebracht.

Zero Data Retention und Datenresidenz sind zwei unterschiedliche Dinge.

ZDR beantwortet primär die Frage, ob beziehungsweise wie lange die Inhalte eines API-Aufrufs gespeichert werden.

Datenresidenz beschäftigt sich dagegen damit, in welcher Region Daten gespeichert oder verarbeitet werden.

OpenAI bietet für berechtigte API-Kunden unter anderem europäische Datenresidenz an. Für entsprechend konfigurierte europäische API-Projekte können berechtigte Endpunkte in Europa verarbeitet werden; OpenAI hat diese Option bereits als Kombination mit Zero Data Retention angeboten.

Für ein europäisches Unternehmen sind deshalb je nach Projekt mehrere Architekturentscheidungen relevant.

Vielleicht benötigt ein Prozess keinerlei Speicherung beim Modellanbieter.

Vielleicht ist zusätzlich Verarbeitung innerhalb Europas erforderlich.

Vielleicht müssen bestimmte Informationen bereits vor dem API-Aufruf pseudonymisiert werden.

Und vielleicht sollte ein Teil der sensiblen Daten überhaupt nie das eigene Backend verlassen.

Ein guter KI-Stack beantwortet diese Fragen gezielt.

Warum das für den Mittelstand wichtiger wird

Man könnte das Thema als Enterprise-Sonderfall abtun.

Das wäre ein Fehler.

Denn mittelständische KI-Projekte bewegen sich inzwischen sehr schnell von allgemeinen Textassistenten hin zu echten Geschäftsprozessen.

Eine KI soll beispielsweise:

eingehende Kundenanfragen verstehen,

Dokumente analysieren,

CRM-Daten heranziehen,

Angebote vorbereiten,

Supportfälle bearbeiten,

Informationen aus internen Systemen zusammentragen,

oder Aktionen über APIs auslösen.

Spätestens dann werden reale Unternehmensdaten verarbeitet.

Und plötzlich ist die Frage nach Datenflüssen kein theoretisches Compliance-Thema mehr.

Angenommen, ein KI-Assistent verarbeitet eine eingehende Kundenmail.

Der eigentliche LLM-Aufruf dauert vielleicht zwei Sekunden.

Doch davor und danach können Daten durch mehrere Systeme laufen:

E-Mail-Provider → Automatisierungsplattform → eigenes Backend → KI-Anbieter → CRM → Logging-System.

Nur auf den Datenschutz des KI-Modells zu schauen, greift deshalb viel zu kurz.

Der größere Trend: Datenschutz wird Teil der KI-Architektur

Das ist wahrscheinlich die wichtigere Entwicklung hinter OpenAIs Ankündigung.

Datenschutz wird zunehmend zu einer technischen Architekturentscheidung.

Früher konnte man Datenschutz teilweise noch nachträglich über Verträge, Richtlinien und Dokumentation abbilden.

Bei modernen KI-Systemen entsteht Datenschutz dagegen direkt in der Softwarearchitektur.

Beispielsweise durch:

• möglichst geringe Datenweitergabe,
• Pseudonymisierung vor Modellaufrufen,
• getrennte Verarbeitungsschritte,
• EU-Datenresidenz,
• Zero Data Retention,
• rollenbasierte Berechtigungen,
• eigene Logging-Strategien,
• begrenzte Tool-Zugriffe,
• und klare Löschkonzepte.

Das ist auch ein Grund, warum wir bei Welp-IT KI-Projekte nicht einfach als „API an ChatGPT anschließen“ betrachten.

Die Modellwahl ist nur ein Bestandteil.

Mindestens genauso wichtig ist die Frage, welche Daten das Modell überhaupt sehen muss.

Weniger Daten können sogar bessere Architektur bedeuten

Interessanterweise führt Datenschutz häufig nicht zu schlechterer, sondern zu besserer Software.

Ein Beispiel:

Ein Unternehmen möchte eingehende Supportanfragen automatisch kategorisieren.

Muss das Sprachmodell dafür wirklich den vollständigen Kundendatensatz kennen?

Wahrscheinlich nicht.

Vielleicht reichen Betreff und Nachrichtentext.

Für die spätere Zuordnung zum Kunden kann anschließend ein klassischer Backend-Prozess sorgen.

Oder eine KI soll feststellen, welche Art von Termin ein Kunde benötigt.

Braucht sie dafür Name, Adresse, Telefonnummer und komplette Kundenhistorie?

Nicht zwangsläufig.

Je genauer ein System in kleine Aufgaben zerlegt wird, desto weniger Informationen benötigt häufig jeder einzelne Verarbeitungsschritt.

Das reduziert nicht nur Datenschutzrisiken.

Es macht Fehler leichter nachvollziehbar und Schnittstellen einfacher zu kontrollieren.

Aber macht ZDR eine KI-Anwendung automatisch DSGVO-konform?

Nein.

Und genau das sollte bei aller Begeisterung über neue Datenschutzfunktionen klar bleiben.

Zero Data Retention ist ein technischer Baustein.

Keine universelle Compliance-Freigabe.

Ein Unternehmen muss weiterhin prüfen, auf welcher rechtlichen Grundlage personenbezogene Daten verarbeitet werden, welche Anbieter beteiligt sind, welche Verträge notwendig sind, wo Daten verarbeitet werden und ob der konkrete Anwendungsfall besondere Anforderungen mit sich bringt.

Auch die eigene Anwendung kann Daten speichern, selbst wenn der Modellanbieter dies nicht tut.

Ein n8n-Workflow mit ausführlichem Execution Log kann beispielsweise sensible Inhalte speichern, obwohl der eigentliche LLM-Aufruf Zero Data Retention verwendet.

Das Gleiche gilt für Fehlertracking, Datenbanken oder externe APIs.

Datenschutz muss deshalb entlang der gesamten Verarbeitungskette betrachtet werden.

Was Unternehmen jetzt daraus mitnehmen sollten

Die Meldung vom 19. August ist weniger ein Grund, sofort bestehende KI-Systeme umzubauen.

Sie zeigt vielmehr, wohin sich professionelle KI-Infrastruktur entwickelt.

Die Diskussion verschiebt sich von:

„Darf ich Unternehmensdaten überhaupt in ein LLM schicken?“

hin zu:

„Unter welchen technischen Bedingungen kann ich genau diesen Prozess sicher betreiben?“

Das ist ein großer Unterschied.

Leistungsfähige Modelle, Datenresidenz, kontrollierte Speicherung und immer ausgefeiltere Sicherheitsmechanismen ermöglichen inzwischen Architekturen, die vor wenigen Jahren noch schwer umzusetzen waren.

Aber diese Möglichkeiten müssen bewusst eingesetzt werden.

Ein Häkchen für Zero Data Retention ersetzt keine saubere Systemarchitektur.

Fazit: Das Modell ist nur ein Teil der Datenschutzfrage

OpenAIs aktuelles ZDR-Update ist vor allem deshalb relevant, weil es einen größeren Wandel sichtbar macht.

KI wird zunehmend Teil echter Geschäftsprozesse.

Und sobald das passiert, werden Datenschutz, Berechtigungen und Datenflüsse genauso wichtig wie Modellqualität und Prompt Engineering.

Unternehmen, die heute neue KI-Systeme entwickeln, sollten deshalb nicht erst am Ende fragen:

„Wie machen wir das jetzt datenschutzfreundlich?“

Die bessere Frage steht ganz am Anfang:

Welche Daten muss dieses System wirklich kennen und welche nicht?

Genau daraus entsteht am Ende nicht nur eine bessere Datenschutzstrategie, sondern meistens auch eine bessere KI-Anwendung.

Wir von Welp-IT helfen Unternehmen und Institutionen mit allem rund um Künstliche Intelligenz. Von der KI Strategie Beratung über KI-Automatisierung bis hin zur eigenen individuellen KI-Entwicklung.

Hinweis: Dieser Artikel stellt keine Rechtsberatung dar.