LLM-Datenspeicherung und ZDR: Wer Ihre Prompts lesen kann

Ihr Prompt geht nicht einfach an „das KI-Unternehmen“. In einem Agent-Stack durchläuft er mehrere Stationen, die ihn alle im Klartext verarbeiten. Welche das sind, hängt vom Stack ab: Telemetrie des Agent-Frameworks, eine Tracing-Plattform, ein Memory Store, ein Analytics-Tool, ein AI-Gateway und eine von drei Arten von Inference-Providern. Für jede Station gelten eigene Regeln zu Aufbewahrung, Speicherregion und Training. Am längsten liegen Ihre Prompts meist auf Ihrer Seite der API. Modellanbieter löschen Standard-Logs nach rund 30 Tagen, während Tracing- oder Memory-Systeme sie standardmäßig behalten, bis Sie sie selbst löschen. Zero Data Retention (ZDR) ist eine echte und sinnvolle Vereinbarung, regelt aber nur eine Station und dort auch nur eine von drei Dimensionen. Dieser Artikel bildet die gesamte Kette ab: Wer speichert welche Daten wie lange, und was deckt ZDR ab oder nicht?

TL;DR

• Jede Station mit Klartextzugriff kann Daten erfassen. Tracing und Memory Stores auf Agent-Seite behalten Prompts deutlich länger als Modellanbieter.
• Provider regeln die Aufbewahrung pro Feature: Bei der Claude API ist Caching ZDR-fähig, Batch-Jobs bleiben 29 Tage gespeichert, Fable 5 verlangt 30 Tage.
• Der Speicherort folgt dem Server: DeepSeeks offizielle API speichert Daten ausschließlich in der Volksrepublik China.
• Kostenlose Endpoints bergen das größte Risiko: Trainingsrechte sind meist der Preis für kostenlose Kapazität.
• ZDR hielt vor Gericht stand: Von der Sicherungsanordnung der NYT-Klage waren nur API-Kunden mit Zero Retention ausgenommen.

Wer kann Ihren Prompt in einem Agent-Stack lesen?

Jede Station auf dem Weg. Und dieser Weg ist länger, als er in den meisten Architekturdiagrammen dargestellt wird:

Gehen wir die Kette von links nach rechts durch. Der Agent-Layer gehört Ihnen, besteht aber selten nur aus Ihrer eigenen Infrastruktur. Frameworks senden Telemetrie. Tracing- und Observability-Plattformen sind ausdrücklich dafür da, vollständige Prompts und Antworten zu speichern. Memory-Features schreiben Gesprächsinhalte in Vektorspeicher, die nicht von selbst ablaufen. Ein Session-Replay-Snippet für Analytics im Web-UI kann den Prompt bereits während der Eingabe erfassen, bevor Ihr Backend ihn überhaupt sieht. Das Gateway ist bei Eigenbetrieb eine Partei, als SaaS kommen zwei Parteien ins Spiel. SaaS-Gateways gibt es in zwei Varianten. Die erste ist der Multi-Provider-Aggregator: Eine API verteilt Requests auf die dahinterliegenden Provider. Die Datenschutzlage ergibt sich deshalb immer aus zwei Richtlinien, der des Aggregators und der des Hosts, bei dem der jeweilige Request gelandet ist. Die zweite Variante stammt von Security-Anbietern: Gateways für Data Loss Prevention (DLP) und Guardrails untersuchen Payloads, schwärzen Inhalte und setzen Richtlinien durch. Jeden Prompt zu lesen ist hier Teil des Produkts. Auffällige Prompts werden in der Regel bewusst als Security Events gespeichert.

Hinter dem Gateway stehen drei Arten von Inference-Providern: die API des Modellanbieters selbst, ein Cloud-Provider, der das Modell innerhalb Ihrer Cloud-Tenancy betreibt, und GPU-Hosts, die Open Weights nach ihren eigenen Logging-Regeln bereitstellen. Nur beim Bypass, also selbst gehosteter Inference in einer dedizierten Tenancy oder auf eigenen GPUs, verarbeitet kein Dritter den Klartext. Dabei gibt es allerdings einen Haken, auf den wir später zurückkommen.

Für alles Weitere gilt eine zentrale Regel: Sehen und Speichern sind zwei verschiedene Fragen. Jede Station kann technisch Daten erfassen. Ob sie das tut, hängt von Defaults, Einstellungen und Verträgen ab. Diese Defaults unterscheiden sich entlang der Kette erheblich.

Wer speichert Ihre Prompts tatsächlich?

Meist ist es Ihr eigenes Tooling, und zwar länger als jede andere Station. Die Aufbewahrungsfristen der Provider, die Security-Fragebögen dominieren, werden in Tagen gemessen. Die Agent-seitigen Speicher, nach denen niemand fragt, laufen dagegen unbegrenzt weiter.

Der Agent-Layer speichert Daten absichtlich. Das Produkt einer Tracing-Plattform ist eine Datenbank mit Ihren Prompts und Outputs. Die Aufbewahrungsdauer ist dort eine Projekteinstellung und kein Versehen in der Policy. Die Defaults unterscheiden sich je nach Tool und sollten bekannt sein: Die OpenTelemetry-Integration von GitHub Copilot exportiert Span-Struktur, Timing und Token-Anzahlen, aber keine Prompt-Inhalte, solange Sie die Inhaltserfassung nicht ausdrücklich aktivieren. Dieses datensparsame Muster sollten mehr Agent-Tools übernehmen. Der Privacy Mode von Cursor existiert, weil im Standardmodus Codedaten geteilt werden. Was der Modellanbieter nach 30 Tagen löscht, liegt am Tag 300 immer noch in Ihrem Trace Store.

Das Gateway speichert, was Sie dort konfigurieren. Usage Records lassen sich nicht vollständig vermeiden, denn für die Abrechnung müssen Token-Anzahlen, Modelle und Zeitstempel pro Request bekannt sein. Payloads müssen dagegen nicht gespeichert werden: Prompt- und Response-Bodys können ausschließlich den Arbeitsspeicher durchlaufen, ohne jemals persistent geschrieben zu werden. Zwei beliebte Gateway-Features überschreiten diese Grenze jedoch oft unbemerkt. Eine Konsole zur Request-Inspektion oder Observability speichert per Definition Payloads, genau wie eine Tracing-SaaS eine Station zuvor. Auch Gateway-seitiges Caching legt Prompt-Inhalte am Gateway ab: Ein Semantic Cache speichert ein Embedding des Prompts und die vollständige gecachte Antwort. Ein Response Cache speichert beide Seiten unverändert auf dem Datenträger, auf dem das Gateway läuft. Bei der Bewertung eines Gateways, ob als SaaS oder selbst gehostet, sollten Sie dieselben drei Fragen getrennt stellen: Was steht im Request Record, was speichert die Observability-Ansicht dauerhaft, und was schreibt der Cache?

Provider regeln die Aufbewahrung pro Feature, nicht pauschal für das gesamte Unternehmen. Ein brauchbares Modell liefert direkt Anthropics Dokumentation zur Aufbewahrung von API-Daten. Dort wird die ZDR-Eignung für jedes Feature einzeln ausgewiesen: Prompt Caching ist ZDR-fähig, weil der Cache-Zustand nur im Arbeitsspeicher liegt. Batch Processing speichert Jobs 29 Tage, weil asynchrone Jobs persistenten Speicher benötigen. Code-Execution-Container bleiben bis zu 30 Tage bestehen, hochgeladene Dateien bis zu ihrer Löschung. Ein Satz auf dieser Seite bringt es auf den Punkt: Wer ein zustandsbehaftetes Feature nutzt, entscheidet sich für die betreffenden Daten „gegen die eigene ZDR-Vereinbarung“. Bei OpenAI listet die Dokumentation zu Data Controls die ZDR-fähigen Endpoints auf. Abuse-Monitoring-Logs werden standardmäßig bis zu 30 Tage aufbewahrt. Gecachte Prompts liegen als verschlüsselte Key-Value-Tensoren auf lokalem GPU-Speicher mit begrenzter TTL. Für die Claude API gilt im kommerziellen Standardbetrieb eine Löschfrist von bis zu 30 Tagen.

Wo liegen die Daten physisch?

Dort, wo die Infrastruktur für den Request läuft. Je nach Provider-Typ fällt die Antwort unterschiedlich aus. Bei einem in der Cloud gehosteten Modell ist die Lage am klarsten: Auf Amazon Bedrock ist der Cloud-Provider der Auftragsverarbeiter, und die Inference bleibt in der ausgewählten Region. Deshalb wählen regulierte Unternehmen bevorzugt diesen Weg. Die API eines Modellanbieters läuft dagegen dort, wo der Anbieter seine Infrastruktur betreibt. OpenAI bietet für die meisten Endpoints regionale Verarbeitung in den USA und der EU. Kleinere Anbieter veröffentlichen dazu häufig keine Angaben. Das eindeutigste Gegenbeispiel ist DeepSeek. Laut eigener Datenschutzerklärung werden personenbezogene Daten in der Volksrepublik China erhoben, verarbeitet und gespeichert. Für die offizielle API gibt es keine Option für die USA oder die EU. Werden dieselben Open Weights von einem US-amerikanischen GPU-Host bereitgestellt, gilt diese geografische Zuordnung nicht. Das zeigt deutlich: Wohin die Daten eines Modells fließen, hängt vom Betreiber ab, nicht vom Modell.

Zusätzlich zur primären Kopie gibt es zwei weitere Speicherorte. Caches und Batch-Dateien liegen für ihre jeweilige Lebensdauer in der Serving-Region, unabhängig vom Request Log. Außerdem setzt jeder Provider Unterauftragsverarbeiter, also eigene nachgelagerte Anbieter, und Backups ein. Löschzusagen beziehen sich deshalb meist auf aktive Systeme. Für Backups gelten zusätzliche Fristen zur Übernahme der Löschung. Wenn Ihr Datenflussdiagramm beim Logo des API-Anbieters endet, fehlen mindestens diese beiden Stationen.

Wer verlangt die Speicherung, und wer trainiert mit Ihren Prompts?

Drei verschiedene Faktoren können Daten über die Standardfristen hinaus am Leben halten. Nur einer davon taucht im Marketing des Providers auf.

Vorgaben aus Policies. Bei einigen Modellen ist eine bestimmte Aufbewahrungsdauer aus Sicherheitsgründen Pflicht. Claude Fable 5 und Mythos 5 verlangen selbst für ZDR-Kunden eine Aufbewahrung von 30 Tagen. Die Durchsetzung erfolgt explizit: Erfüllt die Aufbewahrungskonfiguration einer Organisation diese Anforderung nicht, wird der Request mit einem 400-Fehler abgelehnt, statt ihn stillschweigend anzunehmen. Eine weitere Ausnahme entsteht bei Abuse-Eskalationen. Inhalte, die wegen Verstößen gegen Nutzungsrichtlinien markiert wurden, folgen einer völlig anderen Frist. Anthropics Consumer-Policy nennt bis zu 2 Jahre für markierte Inputs und Outputs sowie bis zu 7 Jahre für Classifier Scores.

Legal Holds. Das Verfahren NYT gegen OpenAI lieferte den deutlichsten Praxistest für Löschzusagen. Eine Sicherungsanordnung vom Mai 2025 verpflichtete OpenAI, Output-Logs aufzubewahren, die andernfalls gelöscht worden wären. Das betraf in den Consumer-Tarifen auch Chats, die Nutzer gelöscht hatten. Die Anordnung wurde im September eingeschränkt. Später ordnete ein Gericht im Rahmen der Discovery die Herausgabe von 20 Millionen Chat-Logs an. Für API-Käufer ist ein Detail entscheidend: Enterprise-Kunden und Kunden mit Zero Data Retention waren ausgenommen, weil keine gespeicherten Daten vorlagen, die hätten gesichert werden können. Eine Löschrichtlinie kann durch einen Litigation Hold außer Kraft gesetzt werden. Eine Architektur, die Daten nie gespeichert hat, kann das nicht.

Intermediäre als Datensammler. Es gibt dokumentierte Fälle, in denen Klartextdaten innerhalb der Kette monetarisiert wurden. Der größte bekannte Fall saß direkt beim Nutzer. Im Dezember 2025 dokumentierten Sicherheitsforscher, dass eine als „Privacy“-Produkt beworbene VPN-Browser-Erweiterung mit Millionen Installationen Skripte in AI-Chatseiten einschleuste. Sie fing sämtliche Prompts und Antworten aus ChatGPT, Claude, Gemini und fünf weiteren Assistenten ab und übermittelte die Gespräche an ein verbundenes Datenbroker-Unternehmen. Die Erfassung lief unabhängig davon, ob das VPN aktiviert war, und betraf rund 8 Millionen Nutzer aus der gesamten Extension-Familie des Anbieters. Dabei handelte es sich um einen clientseitigen Interceptor und nicht um ein API-Gateway. Die Schlussfolgerung gilt trotzdem für jede Station im Diagramm: Jeder Intermediär mit Klartextzugriff kann zur Sammelstelle werden. Sein wirtschaftlicher Anreiz ist die Monetarisierung, und die Erfassung bleibt für beide Enden unsichtbar. Vertrauen in einen Intermediär ist eine Aussage über sein Geschäftsmodell, nicht über seine Feature-Liste.

Trainingsklauseln. Die Business-APIs der großen Anbieter trainieren standardmäßig nicht mit Ihren Daten. Consumer-Produkte tun es zunehmend, sofern Sie nicht widersprechen. Schon deshalb gehört Agent-Traffic auf API-Keys und nicht auf Consumer-Accounts. Immer mehr Produkte verstecken die Trainingsfreigabe hinter einem Schalter, den Sie selbst finden müssen: Consumer-Tarife mit standardmäßig aktiviertem Training und einer tief in den Einstellungen vergrabenen Opt-out-Option, Developer-Tools, bei denen Telemetrie oder Code-Sharing zugleich als Einwilligung zum Training gilt, Anbieterprogramme, die Datenfreigaben mit Rabatten oder kostenlosem Kontingent belohnen, sowie Aggregator-Dashboards mit getrennten Trainingsschaltern für bezahlte und kostenlose Tiers. Jeder Schalter gilt pro Account, teilweise pro Workspace. Mit einer Aktualisierung der Nutzungsbedingungen kann sich auch der Default ändern. Eine einmalige Prüfung reicht deshalb nicht. Diese Einstellungen gehören ebenso auf eine wiederkehrende Checkliste wie die Rotation von Keys.

Kostenlose Modelle verdienen besondere Aufmerksamkeit. Alle genannten Risiken konzentrieren sich im Free Tier. Der Launch eines kostenlosen Modells wird meist von der Partei subventioniert, die vom Traffic profitiert, in der Regel vom Modellanbieter selbst. Prompts an die kostenlose Variante fließen deshalb nach dessen Policy an diesen Anbieter. Trainingsrechte sind häufig Teil der Gegenleistung. Verarbeitet werden die Daten dort, wo dieser Anbieter arbeitet, bei chinesischen Anbietern also in China. Aggregator-Gateways veröffentlichen für einzelne Endpoints eigene Datenrichtlinien und bieten einen Schalter zum Ausschluss von Providern mit Training an, weil genau bei kostenlosen Routen solche Klauseln üblich sind. Die Faustregel ist eindeutig: Behandeln Sie einen kostenlosen Endpoint als Datenübermittlung, nicht als API-Aufruf. Kostenlose Inference wird immer irgendwie bezahlt, meist mit Ihren Prompts.

Was bedeutet ZDR tatsächlich?

ZDR legt für genau eine Station der Kette eine von drei Dimensionen fest, und das nur für geeignete Features. Das ist keine Kritik, sondern die Definition. Wer die Grenzen kennt, kann ZDR sinnvoll einsetzen.

• Die drei Dimensionen. Trainingsnutzung, Aufbewahrungsdauer und menschlicher Zugriff sind voneinander unabhängig. Business-APIs trainieren bereits nicht mit Ihren Daten. ZDR setzt die Aufbewahrung von Payloads auf null. Der menschliche Zugriff wird separat über Abuse-Prozesse geregelt. Wer diese Dimensionen vermischt, verkauft ZDR als umfassender, als es tatsächlich ist.
• Was unter ZDR bestehen bleibt. Usage-Metadaten und Abrechnungsdaten, Outputs von Safety Classifiers sowie der Zustand aller zustandsbehafteten Features, die Sie aktivieren. Beide großen Anbieter umgehen die Ausnahme für Abuse Monitoring inzwischen technisch, statt Payloads darunter zu speichern: auf der einen Seite Safety-Signale ohne Payload, auf der anderen ausschließlich gespeicherte Classifier-Ergebnisse.
• Was ZDR nicht erreicht. Alles links vom Provider: Ihr Trace Store, Ihre Gateway-Logs und Ihr Vector Memory. Die häufigste und zugleich widersprüchlichste Konfiguration ist eine ZDR-Vereinbarung mit dem Modellanbieter, während eine Tracing-SaaS jeden Prompt unbegrenzt speichert.
• Der Haken beim Self-Hosting. Open Weights auf eigenen GPUs entfernen alle Drittanbieter aus dem Datenpfad. Dafür erbt die eigene Infrastruktur das gesamte Problem: Request-Logging des Inference-Servers, Access Logs und Trace-Dateien. Self-Hosting verschiebt die Aufbewahrungsfläche nur. Kleiner wird sie erst durch konsequente Log-Hygiene.

So handhabt Synthorai die Daten

Die Gateway-Station gehört uns, deshalb können wir konkrete Zusagen machen. Im Zero-Retention-Modus durchlaufen Request- und Response-Bodys ausschließlich den Arbeitsspeicher und werden nicht persistent geschrieben. Gespeichert wird nur der für die Abrechnung erforderliche Usage Record: Zeitstempel, Modell, Token-Anzahlen und ein Content Hash. Damit lässt sich ein Request im Streitfall zuordnen, ohne seinen Inhalt zu speichern. Für das Upstream-Routing wird die Provider-Liste bereits vor dem Routing gefiltert: Synthorai nimmt ausschließlich Provider auf, die sich für unseren Traffic zu Zero Data Retention verpflichten. Es gibt eine dokumentierte Ausnahme, Claude Fable 5. Dessen Aufbewahrungsfrist von 30 Tagen ist vom Modellanbieter vorgeschrieben und lässt sich vertraglich nicht ausschließen. Die Provider-Auswahl bestimmt damit auch die Aufbewahrung. Das Gateway muss diese Eigenschaft pro Route offen ausweisen, statt sie in einem Policy-PDF zu verstecken. Eine Route zu Fable 5 enthält die Aufbewahrungsvorgabe deshalb als dokumentierte Metadaten und nicht als Überraschung.

FAQ

Trainieren LLM-Provider standardmäßig mit API-Daten?

Nein. Die Business-APIs der großen Anbieter trainieren standardmäßig nicht mit Kundendaten. Diese Zusage findet sich jeweils in der Dokumentation zu den Data Controls. Ausnahmen treten vor allem bei kleineren Anbietern auf: Consumer-Produkte mit Opt-out statt Opt-in, einige GPU-Hosts für Open Weights und kostenlose Endpoints, bei denen Trainingsrechte Teil des Preises sind.

Bedeutet ZDR, dass der Provider überhaupt nichts speichert?

Nein. ZDR bedeutet, dass Prompt- und Response-Payloads bei geeigneten Features nicht aufbewahrt werden. Usage-Metadaten, Abrechnungsdaten und Outputs von Safety Classifiers bleiben bestehen. Zustandsbehaftete Features wie Batch-Jobs oder File Uploads speichern naturgemäß Daten und liegen damit außerhalb des ZDR-Rahmens. Entscheidend ist die Tabelle zur Feature-Eignung, nicht die Überschrift.

Kann ich Produktionsdaten sicher an kostenlose Modelle senden?

Behandeln Sie einen kostenlosen Endpoint als Datenübermittlung, nicht als API-Aufruf. Die kostenlose Kapazität wird von einer Partei subventioniert, die vom Traffic profitiert. Trainingsrechte gehören häufig zur Vereinbarung, und die Verarbeitung findet dort statt, wo der Sponsor tätig ist. Für kurzlebige Experimente kann dieser Tausch akzeptabel sein. Bei Kundendaten, Code oder Zugangsdaten ist er es meist nicht.

Ist Self-Hosting automatisch die datenschutzfreundlichste Option?

Self-Hosting entfernt sämtliche Drittanbieter aus dem Klartextpfad. Das ist ein echter Vorteil. Die Aufbewahrung verschwindet dadurch jedoch nicht. Inference-Server, Reverse Proxies und Tracing schreiben standardmäßig Logs. Ein selbst gehosteter Stack mit Standard-Logging kann deshalb mehr Prompt-Daten aufbewahren als eine API-Konfiguration mit ZDR. Entscheidend ist die Logging-Konfiguration, nicht das Hosting-Modell.

Quellen geprüft am 2026-08-29: Jede Aussage zu einem Provider ist oben mit dessen eigener Dokumentation oder primären Gerichtsunterlagen verlinkt. Die Richtlinien in diesem Bereich wurden allein im Monat vor der Veröffentlichung zweimal geändert. Die Links sind deshalb als aktuelle Referenz maßgeblich. Dies ist eine technische Einordnung, keine Rechtsberatung.

Verwandte Artikel: Die 30-tägige Aufbewahrungspflicht von Fable 5, so funktioniert Prompt Caching, Vergleich der Provider-Caches.

← Zurück zum Blog