Claude Fable 5 läuft nicht unter ZDR: 30 Tage Aufbewahrung sind Pflicht

Wenn Ihre Organisation Claude mit einer Zero-Data-Retention-Vereinbarung (ZDR) betreibt, hat die erste Anfrage an claude-fable-5 keine Completion geliefert. Stattdessen kam 400 invalid_request_error zurück. Das ist keine Störung, sondern eine Richtlinie. Fable 5 ist das erste allgemein verfügbare Claude-Modell, das nicht ohne eine Aufbewahrung der Daten für 30 Tage genutzt werden kann. Diese Vorgabe gilt auf jeder Plattform: Claude API, AWS Bedrock, Google Vertex AI und Microsoft Foundry verlangen jeweils ein ausdrückliches Opt-in zur Aufbewahrung.

Für Teams, die „Wir speichern Ihre Daten nicht“ als feste Eigenschaft ihres LLM-Stacks betrachtet haben, ist das eine grundlegende Architekturänderung. Dieser Beitrag erklärt die Richtlinie, den Grund für das 30-Tage-Fenster, die Umsetzung in den einzelnen Clouds und die Folgen für Consumer-Produkte sowie Branchen mit sensiblen Daten.

TL;DR

• Claude Fable 5 kann nicht genutzt werden, ohne Prompts und Completions 30 Tage lang aufzubewahren. Die Vorgabe gilt für Claude API, AWS Bedrock, Google Vertex AI und Microsoft Foundry (Richtlinie gültig seit 2026-06-09).
• Es gibt kein Opt-out: Organisationen mit Zero-Data-Retention-Vereinbarungen erhalten 400 invalid_request_error; bestehende ZDR-Konditionen gelten nicht automatisch weiter.
• Bei Bedrock erfordert Fable 5 data_retention_mode: provider_data_share; andernfalls wird das Modell als nicht verfügbar angezeigt.
• Inhalte, die wegen Verstößen gegen die Usage Policy markiert wurden, können unabhängig vom 30-Tage-Fenster bis zu 2 Jahre gespeichert bleiben.

Die Angaben zu den Richtlinien wurden am 2026-06-12 anhand der veröffentlichten Dokumentation von Anthropic, AWS, Google und Microsoft geprüft. Richtlinien ändern sich; prüfen Sie die verlinkten Primärquellen und Ihre eigenen Verträge. Dies ist eine technische Übersicht, keine Rechtsberatung.

Was die Richtlinie tatsächlich vorgibt

Anthropic stuft Claude Fable 5 und Claude Mythos 5 als Covered Models ein. Laut der Dokumentation zur Datenaufbewahrung in der API und dem Artikel zur Datenaufbewahrung bei Modellen der Mythos-Klasse (gültig seit 2026-06-09) gilt:

• Prompts und Completions werden 30 Tage lang gespeichert und anschließend automatisch gelöscht, sofern sie nicht für eine laufende Sicherheitsuntersuchung markiert wurden oder eine gesetzliche Aufbewahrungspflicht besteht.
• Es gibt kein Opt-out. Die Aufbewahrung ist Voraussetzung für die Nutzung des Modells. Erfüllt die Retention-Konfiguration einer Organisation diese Vorgabe nicht, liefert die Anfrage 400 invalid_request_error.
• Der Zugriff ist bewusst stark eingeschränkt. Automatisierte Sicherheitssysteme prüfen die Daten. Nur eine kleine Gruppe autorisierter Personen darf markierte Unterhaltungen einsehen. Sie dürfen die Daten weder exportieren noch kopieren oder herunterladen. Jeder Zugriff wird in manipulationssicheren Logs erfasst.
• Bestehende ZDR-Vereinbarungen gelten nicht für den Traffic von Covered Models, auch nicht bei Nutzung über Cloud-Plattformen.

Consumer-Tarife (Claude Free/Pro/Max) sind nicht betroffen, da für sie bereits eigene Aufbewahrungsbedingungen gelten. Die Richtlinie betrifft die kommerzielle API und damit genau den Bereich, in dem Anbieter häufig zusichern, Daten niemals zu speichern.

Warum es ein 30-Tage-Fenster gibt

Der Artikel zu Covered Models nennt einen konkreten Grund: Diese Modelle verfügen über deutlich fortgeschrittene Fähigkeiten bei Softwareentwicklung, agentischen Workflows und Cybersecurity. „Einige Formen des Missbrauchs lassen sich erst über viele Anfragen hinweg erkennen.“ Die genannten Beispiele, Best-of-N-Jailbreaking und staatlich gesteuerte Spionage, folgen einem Muster: Jeder einzelne Prompt wirkt harmlos, erst die Abfolge ist auffällig. Eine bereits gelöschte Sequenz lässt sich nicht mehr erkennen.

Zwei Dinge ist dieses Zeitfenster nicht:

• Keine Trainingsdaten. Anthropic erklärt, dass gespeicherte Daten ohne ausdrückliche Zustimmung niemals für das Training verwendet werden. Sie dienen ausschließlich der Missbrauchserkennung.
• Nicht grundsätzlich neu, sondern erstmals nicht verhandelbar. Ein Zeitfenster von etwa 30 Tagen für die Missbrauchsüberwachung ist in der Branche seit Jahren üblich: OpenAI speichert API-Abuse-Logs bis zu 30 Tage lang, wobei ZDR nach Genehmigung möglich ist. Azure OpenAI speichert Prompts bis zu 30 Tage, sofern keine Genehmigung für eine angepasste Missbrauchsüberwachung vorliegt. Neu ist, dass dieses Zeitfenster für eine Modellklasse verbindlich ist. Bisher bot jeder Provider eine Möglichkeit ohne Datenaufbewahrung an.

Eine bereits bestehende Einschränkung überrascht viele: Auch unter ZDR speichert Anthropic die Ergebnisse der Sicherheitsklassifizierung. Inhalte, die wegen Verstößen gegen die Usage Policy markiert wurden, können bis zu 2 Jahre aufbewahrt werden. Zero Data Retention bedeutete nie, dass überhaupt keine Daten gespeichert werden. Gemeint ist, dass nicht markierte Inhalte im normalen Ablauf nicht aufbewahrt werden.

Gleiche Vorgabe, drei Clouds, drei Mechanismen

Die Aufbewahrungspflicht gilt unabhängig davon, wo das Modell läuft. Jede Plattform setzt das Opt-in jedoch anders um. Diese Unterschiede bestimmen, wer Ihre Daten verarbeitet und wo Ihre Kontrollen greifen.

AWS Bedrock setzt die Vorgabe am explizitesten um. Data Retention ist ein konfigurierbarer Modus (default / provider_data_share / none). Die effektive Einstellung wird in der Reihenfolge Projekt → Account → Modellstandard ermittelt. Fable 5 deklariert allowed_modes: ["provider_data_share"]: Prompts und Completions werden an Anthropic weitergegeben und bis zu 30 Tage gespeichert. Bei jedem anderen Modus erscheint:

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Für Modelle vor Fable 5 ändert sich nichts. Mit einer SCP für den Condition Key bedrock:DataRetentionMode lässt sich die Vorgabe organisationsweit durchsetzen, sodass niemand den gesamten Account unbemerkt für das neue Modell umstellt. Bei Cross-Region Inference wird die gespeicherte Kopie in der Zielregion abgelegt. Das ist relevant, wenn Sie Vorgaben zur Datenresidenz erfüllen müssen.

Google Vertex AI schaltet das Modell erst frei, wenn Data Sharing mit Anthropic auf Projektebene aktiviert wurde (setPublisherModelConfig mit dataSharingEnabledProvider: "anthropic") und die Bedingungen im Model Garden akzeptiert wurden. Das ist in der Dokumentation von Google zu Fable 5 beschrieben. Die allgemeine Datenverarbeitung folgt der Data-Governance-Richtlinie von Vertex AI. Bei Workloads mit Anforderungen an die Datenresidenz steuern regionale und Multi-Region-Endpunkte von Vertex, wo die Inferenz ausgeführt wird und damit nun auch, wo die gespeicherte Kopie liegt.

Microsoft Foundry ist strukturell anders aufgebaut. Die Dokumentation von Microsoft zu Daten und Datenschutz stellt klar, dass Claude-Modelle Services von Drittanbietern im Marketplace sind: Beim Deployment akzeptieren Sie die Bedingungen von Anthropic, und Anthropic, nicht Microsoft, ist der Datenverarbeiter. Die Programme von Azure OpenAI für ZDR und angepasste Missbrauchsüberwachung gelten nicht für Claude-Deployments. Organisationen, die an anderer Stelle ZDR einsetzen, isolieren die Nutzung von Covered Models üblicherweise in einer eigenen Subscription. Die Retention-Grenze wird so technisch statt nur prozessual durchgesetzt.

Auf allen drei Plattformen zeigt sich dasselbe Muster: Die Retention-Klasse ist zu einem vollwertigen, maschinenlesbaren Modellattribut geworden: als Modus, Flag oder vorgeschaltete Vertragsannahme statt als Absatz in einem Vertrag. Damit kann Ihre Infrastruktur die gewünschte Datenhaltung erzwingen und sollte das auch tun.

Folgen für Enterprise-Deployments

Ohne ZDR-Vereinbarung ändert sich technisch nichts. Sie befanden sich bereits in einem Modell mit etwa 30 Tagen Aufbewahrung, möglicherweise ohne es zu wissen. Jetzt muss diese Tatsache in Ihrer Anbieterdokumentation explizit festgehalten werden.

Mit einer ZDR-Vereinbarung haben Sie drei Möglichkeiten:

1. Covered Models nicht verwenden. ZDR bleibt einheitlich, dafür verzichten Sie auf das Modell. Das ist vertretbar, wenn Ihre Workloads es nicht benötigen. Unsere gemessene Evaluation von Fable 5 zeigt die Kosten und Unterschiede.
2. Nach Workspace oder Projekt trennen. Jede Plattform bietet ein begrenztes Opt-in: einen eigenen Claude-API-Workspace (Console → Settings → Workspaces → Privacy controls), ein Bedrock-Projekt mit provider_data_share, ein separates Vertex-Projekt oder eine eigene Azure-Subscription. Dorthin routen Sie ausschließlich Workloads, bei denen die Aufbewahrung zulässig ist.
3. Die Aufbewahrung organisationsweit akzeptieren. Das ist betrieblich am einfachsten, schwächt aber unbemerkt die Zusagen für alle Workloads, auch für diejenigen, deren Sensibilität ursprünglich ZDR erforderlich machte. Darüber muss die für Datenschutz verantwortliche Stelle entscheiden; es ist keine reine Konfigurationsänderung.

Unabhängig vom Provider gilt: Ihre eigenen Logs sind eine zweite Retention-Fläche. Wenn Ihr Gateway oder Observability-Stack vollständige Prompts protokolliert, speichern Sie die Daten möglicherweise länger als der Provider, und zwar in Ihrer eigenen Infrastruktur. Zusagen des Providers sind nur so aussagekräftig wie die vorgelagerte Schicht. Für die Prüfung gelten dieselben Prinzipien wie bei unserem Audit von Cache-Zusagen.

Folgen für Consumer-Produkte

Wenn Sie Consumer-Produkte betreiben und Inhalte der Nutzer durch ein Covered Model leiten, wirkt sich die Änderung auch auf Ihre eigenen rechtlichen Verpflichtungen aus, unabhängig von einer ZDR-Vereinbarung. Daraus folgen drei konkrete Konsequenzen:

1. Ihre Datenschutzerklärung muss wahrscheinlich aktualisiert werden. In den meisten Rechtsordnungen muss nicht nur die Erhebung, sondern auch die Aufbewahrung offengelegt werden: Artikel 13(2)(a) der DSGVO verlangt bei der Datenerhebung die Angabe der Speicherdauer oder der Kriterien für ihre Festlegung. Der kalifornische CPRA verlangt in den Hinweisen bei der Erhebung Angaben zur Aufbewahrung je Kategorie personenbezogener Daten. Wenn Ihre Erklärung behauptet oder nahelegt, dass Konversationsdaten nirgendwo gespeichert werden, ist sie falsch, sobald ein Auftragsverarbeiter 30 Tage lang eine Kopie vorhält. Aktualisieren Sie die Datenschutzerklärung, das Verzeichnis der Verarbeitungstätigkeiten und die Übersicht der Auftragsverarbeitungsverträge.

2. Sie können Nutzern kein Opt-out anbieten, das Sie selbst nicht haben. Für die Aufbewahrung gibt es keinen Ausnahmemechanismus. Sie können daher keinen Schalter bauen, der die Prompts eines Nutzers von der Speicherung ausnimmt, solange Sie dasselbe Modell verwenden. Ihr tatsächlicher Hebel ist das Routing: Ein Consent-aware Gateway leitet Nutzer, die Data Sharing ablehnen, an ZDR-fähige Modelle weiter. Alle anderen werden zum Covered Model geroutet. So wird eine rechtliche Vorgabe zu einer normalen Routing-Regel. Das ist deutlich besser als eine wirkungslose Checkbox.

3. Löschanfragen müssen korrekt umgesetzt und beschrieben werden. Löschpflichten nach Art. 17 DSGVO, CPRA und vergleichbaren Regelungen gelten auch für Auftragsverarbeiter. Ein begrenztes Zeitfenster mit automatischer Löschung innerhalb von 30 Tagen ist für einen Auftragsverarbeiter im Allgemeinen vertretbar. Ihr DSAR-Prozess sollte genau das beschreiben und keine sofortige Löschung bei nachgelagerten Anbietern versprechen, die Sie nicht auslösen können.

International gelten ähnliche Anforderungen: Dieselbe Logik zu Offenlegung und Auftragsverarbeitung findet sich in der UK GDPR, der brasilianischen LGPD und immer mehr Datenschutzgesetzen der US-Bundesstaaten. Für Nutzer in China bringt das PIPL zwei zusätzliche Anforderungen mit sich: Die Weitergabe personenbezogener Daten an einen anderen Verarbeiter erfordert in der Regel eine separate Einwilligung. Werden Inhalte chinesischer Nutzer an einen ausländischen LLM-Endpunkt geleitet, handelt es sich außerdem um eine grenzüberschreitende Übermittlung, für die ein anerkannter Mechanismus erforderlich ist, etwa Sicherheitsbewertung, Standardvertrag oder Zertifizierung. Ein Modell-Upgrade, das ändert, wer welche Daten wo und wie lange speichert, ist genau die Art von Änderung, für die diese Regelwerke eine Aktualisierung der Dokumentation und Verträge verlangen.

Branchen mit sensiblen Daten: Wo 30 Tage besonders problematisch sind

Für die meisten Produkte ist das Zeitfenster des Providers hauptsächlich ein Dokumentationsthema. In Branchen, deren Daten selbst reguliert sind, wird es zu einem Architekturthema: Die gespeicherte Kopie sind regulierte ruhende Daten bei einem Anbieter, und branchenspezifische Vorschriften regeln genau diesen Fall.

Gesundheitswesen (HIPAA)

HIPAA verlangt keine Zero Retention. Die Vorgabe lautet, dass jeder Anbieter, der geschützte Gesundheitsdaten verarbeitet, dies auf Grundlage eines Business Associate Agreement (BAA) und mit geeigneten Schutzmaßnahmen tun muss. Die 30 Tage lang gespeicherte Kopie Ihrer Prompts ist ruhende PHI bei einem Business Associate. Entscheidend ist, ob Ihr BAA sie abdeckt. Die beiden großen API-Anbieter regeln das unterschiedlich, und dieser Unterschied ist jetzt relevant: Der HIPAA-fähige API-Zugang von Anthropic setzt ausdrücklich kein ZDR voraus. Er basiert auf einer Aufbewahrung mit Schutzmaßnahmen wie Verschlüsselung, Zugriffskontrollen, Audit-Logging und erzwungenen Funktionseinschränkungen. Das BAA von OpenAI für die API deckt Endpunkte ab, die für Zero Data Retention geeignet sind. Ein BAA, das auf ZDR-Endpunkte beschränkt ist, kann strukturell kein Modell abdecken, das eine Aufbewahrung zwingend vorschreibt.

Die Retention-Klasse eines Modells ist damit eine Frage der BAA-Eignung. Lassen Sie sich schriftlich bestätigen, dass Ihr BAA das konkrete Modell abdeckt, bevor Sie PHI dorthin routen. Bei Cloud-Plattformen verschiebt sich zudem die Verarbeitungskette: Bei Bedrock ist die Plattform Ihr Business Associate; bei Foundry verarbeitet Anthropic die Daten direkt. Ein wichtiger Sonderfall: PHI darf niemals in JSON-Schemadefinitionen für strukturierte Ausgaben stehen. Gecachte Schemas erhalten nicht dieselben Schutzmechanismen wie Nachrichteninhalte.

Produkte für Kinder (COPPA)

Der Zeitpunkt ist ungünstig: Die geänderte COPPA Rule der FTC trat am 23. Juni 2025 in Kraft; die meisten Vorschriften mussten bis zum 22. April 2026 umgesetzt werden. Das erste Modell mit verpflichtender Aufbewahrung beim Provider erschien also genau zu dem Zeitpunkt, als Betreiber die neuen Retention-Vorgaben gerade umgesetzt hatten. Zwei davon betreffen das 30-Tage-Fenster direkt: Eine schriftliche, öffentlich zugängliche Richtlinie zur Datenaufbewahrung ist nun nach §312.10 vorgeschrieben. Sie muss beschreiben, welche Daten von Kindern erhoben werden, warum und wann sie gelöscht werden. Zudem ist eine unbefristete Aufbewahrung verboten; Daten dürfen nur so lange gespeichert werden, wie es für den Erhebungszweck vernünftigerweise erforderlich ist.

Ein begrenztes 30-Tage-Fenster mit automatischer Löschung hat grundsätzlich eine kompatible Form. Der Provider speichert die Daten jedoch für seinen Trust-and-Safety-Zweck, nicht für den Zweck, zu dem Sie die Daten des Kindes erhoben haben. Ihre Datenschutzerklärung muss diese Auftragsverarbeitung korrekt beschreiben. Für speziell an Kinder gerichtete Produkte, die ZDR zur Minimierung der Datenspuren eingeführt haben, gilt die Routing-Lösung mit höherer Dringlichkeit: Der Traffic von Kindern bleibt auf ZDR-fähigen Modellen, oder das Zeitfenster des Covered Model muss zuerst in Ihre Richtlinie nach §312.10 aufgenommen werden.

Dasselbe Muster in anderen Branchen

Das Muster wiederholt sich: regulierte Daten, eine gespeicherte Kopie beim Anbieter und branchenspezifische Vorschriften zur Aufbewahrung.

• Biometrie (Illinois BIPA): Betreiber benötigen einen schriftlichen, öffentlich zugänglichen Aufbewahrungsplan und Richtlinien zur Löschung biometrischer Daten. Eine 30 Tage lang gespeicherte Kopie von Prompts mit biometrischen Identifikatoren gehört in diesen Plan.
• Zahlungsverkehr (PCI DSS / GLBA): PCI DSS verbietet die Speicherung sensibler Authentifizierungsdaten nach der Autorisierung, und zwar überall. Kartendaten, die in einen Prompt eingefügt werden, sind Kartendaten, die 30 Tage lang bei einem Provider liegen. Die saubere Lösung ist eine Redaction vor der Übermittlung, nicht zusätzliche Dokumentation im Nachgang.
• Bildungswesen (FERPA): Anbieter, die Schülerdaten über die School-Official-Ausnahme verarbeiten, müssen unter der direkten Kontrolle der Schule bleiben. Eine für Sicherheitszwecke gespeicherte Kopie, auf die die Schule weder zugreifen noch deren vorzeitige Löschung veranlassen kann, lässt sich mit dieser Vorgabe nur schwer vereinbaren. Das sollte rechtlich geklärt werden, bevor EdTech-Traffic an ein Covered Model geht.
• Finanzdienstleistungen, umgekehrter Fall (SEC/FINRA): Broker-Dealer müssen geschäftliche Kommunikation gemäß den Books-and-Records-Vorschriften aufbewahren. Für sie ist nicht das Zeitfenster des Providers das Problem, sondern die Erfassung einer eigenen regelkonformen Kopie. Dieselbe Retention-Frage, aber mit umgekehrter Zielrichtung.

Der gemeinsame Nenner: Branchenspezifische Vorschriften regeln Aufbewahrung in beide Richtungen. Ein providerseitiges Zeitfenster, das Sie nicht kontrollieren, muss zur jeweiligen Vorgabe Ihrer Branche passen.

Checkliste für die Entscheidung

• ✅ Erfassen Sie, welche Modelle Ihr Traffic tatsächlich nutzt. Die Retention-Klasse ist jetzt eine Eigenschaft des einzelnen Modells, nicht des Providers.
• ✅ Wenn Sie ZDR nutzen, treffen Sie eine bewusste Entscheidung: Covered Models ausschließen, nach Workspace/Projekt/Subscription trennen oder die Aufbewahrung organisationsweit akzeptieren. Lassen Sie die Umstellung nicht implizit geschehen.
• ✅ Erzwingen Sie die Vorgabe in der Infrastruktur, etwa über Bedrock-SCPs, Privacy controls für Workspaces und getrennte Cloud-Projekte, nicht über eine Wiki-Seite.
• ✅ Für B2C: Aktualisieren Sie Datenschutzerklärungen und DSAR-Prozesse und routen Sie Nutzer ohne Einwilligung zu ZDR-fähigen Modellen, statt wirkungslose Opt-outs zu bauen.
• ✅ Bei regulierten Daten: Lassen Sie sich die Abdeckung für jedes Modell schriftlich bestätigen, etwa BAA für PHI, §312.10-Richtlinien für Daten von Kindern und Aufbewahrungspläne für biometrische Daten, bevor Sie diese Daten an ein Modell mit verpflichtender Aufbewahrung senden.
• ✅ Prüfen Sie Ihr eigenes Logging. Das 30-Tage-Fenster eines Providers ist irrelevant, wenn Ihr Gateway Prompts unbegrenzt speichert.

Fazit

Das an Fable 5 gekoppelte 30-Tage-Fenster ist kein Versuch, möglichst viele Daten abzugreifen. Es handelt sich um eine begrenzte und zweckgebundene Missbrauchsüberwachung, die dem entspricht, was der Großteil der Branche bereits standardmäßig tut. Für eine Modellklasse ist sie nun verpflichtend, weil sich Missbrauch über mehrere Anfragen hinweg mit gelöschten Daten nicht erkennen lässt. Für die meisten Teams gibt es keine technischen Auswirkungen; im Governance-Prozess kommt ein Absatz zur Anbieterprüfung hinzu.

Bei Organisationen, deren Compliance-Konzept Zero Retention voraussetzt, sieht es anders aus: BAAs, die auf ZDR-Endpunkte begrenzt sind, Datenschutzerklärungen, laut denen nichts gespeichert wird, oder Kinderprodukte, die auf Datenminimierung setzen. Mit Fable 5 gilt diese Annahme nicht mehr einheitlich für alle Modelle. Die Lösung besteht nicht darin, das Modell grundsätzlich zu meiden. Die Retention-Klasse muss als explizites, modellspezifisches Kriterium in Routing-Entscheidungen einfließen, genau wie Preis und Kontextfenster.

FAQ

Kann ich Claude Fable 5 mit einer Zero-Data-Retention-Vereinbarung verwenden? Nein. Fable 5 und Mythos 5 sind Covered Models und erfordern eine Aufbewahrung von 30 Tagen. ZDR-Organisationen erhalten 400 invalid_request_error, sofern sie nicht für einen Workspace die 30-tägige Aufbewahrung aktivieren und den Fable-5-Traffic darüber routen.

Lässt sich die Vorgabe durch AWS Bedrock, Vertex AI oder Microsoft Foundry umgehen? Nein. Jede Plattform verlangt ein eigenes Opt-in zur Aufbewahrung: provider_data_share bei Bedrock, Anthropic Data Sharing plus die Model-Garden-Bedingungen bei Vertex und die Anthropic-Bedingungen beim Deployment in Foundry, wo Anthropic und nicht Microsoft der Datenverarbeiter ist. Bestehende ZDR-Vereinbarungen gelten auf keiner dieser Plattformen automatisch weiter.

Können meine Endnutzer der Aufbewahrung widersprechen? Nein, es gibt keinen Opt-out-Mechanismus. Ihr Hebel ist das Routing: Nutzer, die Data Sharing ablehnen, werden zu ZDR-fähigen Modellen geleitet. Veröffentlichen Sie keinen Preference-Schalter, der nichts ändert.

Werden die gespeicherten Daten zum Training von Modellen verwendet? Anthropic erklärt, dass gespeicherte Daten ohne ausdrückliche Zustimmung niemals für das Training verwendet werden. Sie dienen der Trust-and-Safety-Prüfung: Nach einer automatisierten Prüfung dürfen nur autorisierte Personen markierte Unterhaltungen einsehen. Ein Export der Daten ist ihnen nicht möglich, und sämtliche Zugriffe werden manipulationssicher protokolliert.

Ändert die 30-tägige Aufbewahrung die Funktionsweise des Prompt Caching? Nein. Cache-Einträge haben weiterhin ihre eigenen kurzen TTLs von 5 Minuten oder 1 Stunde. Auch der Caching-Vertrag von Fable 5 bleibt unverändert, wie unsere gemessene Evaluation zeigt. Das 30-Tage-Fenster ist eine separate, parallele Aufbewahrung für Sicherheitsprüfungen.

Weiterführende Artikel: Der vollständige Leitfaden zum Prompt Caching erklärt die Cache-Mechanismen, die mit Retention-Richtlinien zusammenspielen. Unter Plattformpreise finden Sie die Listenpreise der Provider für die einzelnen Modelle.

Quellen

• Anthropic – API und Datenaufbewahrung
• Anthropic – Covered Models
• Anthropic – Datenaufbewahrung bei Modellen der Mythos-Klasse
• AWS – Datenaufbewahrung in Amazon Bedrock
• Google Cloud – Claude Fable 5 (Partnermodelle)
• Google Cloud – Data Governance in Vertex AI
• Microsoft – Claude in Foundry: Daten, Datenschutz und Sicherheit
• OpenAI – Datenschutz für Unternehmen
• OpenAI – BAA für API-Services
• FTC – Änderungen der COPPA Rule (Pressemitteilung)
• Federal Register – Children’s Online Privacy Protection Rule

Alle Quellen wurden am 2026-06-12 geprüft. Richtlinien ändern sich; prüfen Sie die aktuellen Dokumente und Ihre eigenen Verträge. Dies ist keine Rechtsberatung.

← Zurück zum Blog