Claude Fable 5's 30-tägige Datenspeicherung: ZDR, HIPAA, COPPA

Wenn Ihre Organisation Claude unter einem Zero-Data-Retention-Vertrag (ZDR) betreibt, hat Ihre erste Anfrage an claude-fable-5 keine Vervollständigung zurückgegeben. Sie hat 400 invalid_request_error zurückgegeben. Das ist kein Ausfall – das ist Richtlinie. Fable 5 ist das erste allgemein verfügbare Claude-Modell, das nicht ohne 30-tägige Datenspeicherung verwendet werden kann, und diese Anforderung gilt modellübergreifend auf jeder Plattform: die Claude API, AWS Bedrock, Google Vertex AI und Microsoft Foundry sperren den Zugang jeweils hinter einer expliziten Einwilligung zur Datenspeicherung.

Für Teams, die „Wir speichern Ihre Daten nicht” als feststehende Eigenschaft ihres LLM-Stacks betrachtet haben, ist dies ein architektonisches Ereignis. Dieser Beitrag erläutert, was die Richtlinie besagt, warum das Zeitfenster existiert, wie jede Cloud es umsetzt und was sich dadurch für Consumer-Produkte und datensensible Branchen ändert.

Die Richtliniendetails wurden am 2026-06-12 anhand der veröffentlichten Dokumentation von Anthropic, AWS, Google und Microsoft überprüft. Richtlinien ändern sich; überprüfen Sie die verlinkten primären Quellen und Ihre eigenen Verträge. Dies ist ein technischer Überblick, keine Rechtsberatung.

Was die Richtlinie tatsächlich besagt

Anthropic stuft Claude Fable 5 und Claude Mythos 5 als Covered Models ein. Gemäß der API-Datenspeicherungsdokumentation und dem Artikel zu den Datenspeicherungspraktiken für Mythos-Klasse-Modelle (gültig ab 2026-06-09):

• Prompts und Vervollständigungen werden 30 Tage lang gespeichert und anschließend automatisch gelöscht – es sei denn, sie wurden für eine aktive Sicherheitsuntersuchung markiert oder sind gesetzlich aufzubewahren.
• Es gibt keine Opt-out-Möglichkeit. Die Datenspeicherung ist eine Bedingung für die Nutzung des Modells. Eine Anfrage von einer Organisation, deren Datenspeicherungskonfiguration die Anforderung nicht erfüllt, gibt 400 invalid_request_error zurück.
• Der Zugang ist bewusst eingeschränkt. Automatisierte Sicherheitssysteme prüfen die Daten; nur eine kleine Gruppe genehmigter Mitarbeiter kann markierte Konversationen einsehen, diese nicht exportieren, kopieren oder herunterladen, und jeder Zugriff wird in manipulationssicheren Protokollen festgehalten.
• Bestehende ZDR-Vereinbarungen gelten nicht für den Datenverkehr von Covered Models – auch nicht über Cloud-Plattformen.

Consumer-Pläne (Claude Free/Pro/Max) sind nicht betroffen – sie unterliegen bereits ihren eigenen Datenspeicherungsbedingungen. Diese Richtlinie zielt auf die kommerzielle API-Oberfläche ab, genau dort, wo „Wir speichern niemals” Versprechen typischerweise zu finden sind.

Warum ein 30-Tage-Fenster existiert

Die Begründung im Covered-Models-Artikel ist konkret: Diese Modelle verfügen über erheblich fortgeschrittene Fähigkeiten in der Softwareentwicklung, agentischen Workflows und Cybersicherheit, und „einige Formen des Missbrauchs sind erst über viele Anfragen hinweg erkennbar.” Die genannten Beispiele – Best-of-N-Jailbreaking, staatlich geförderter Spionage – sind Angriffsmuster, bei denen jeder einzelne Prompt harmlos wirkt und erst die Abfolge diagnostisch ist. Eine gelöschte Sequenz lässt sich nicht erkennen.

Zwei Dinge, die das Fenster nicht ist:

• Kein Trainingsdatensatz. Anthropic erklärt, dass gespeicherte Daten ohne ausdrückliche Genehmigung niemals für das Training verwendet werden. Der Zweck ist ausschließlich die Missbrauchserkennung.
• Nicht neu in der Art – neu in der Verbindlichkeit. Ein ~30-tägiges Fenster zur Missbrauchsüberwachung ist seit Jahren der Branchenstandard: OpenAI speichert API-Missbrauchsprotokolle bis zu 30 Tage (ZDR nach Genehmigung); Azure OpenAI speichert Prompts bis zu 30 Tage, sofern keine Genehmigung für eine modifizierte Missbrauchsüberwachung vorliegt. Was sich geändert hat, ist, dass das Fenster für eine Modellklasse nicht mehr verhandelbar ist – bisher bot jeder Anbieter eine Zero-Retention-Ausweichmöglichkeit.

Ein bereits bestehender Vorbehalt, der viele überrascht: Selbst unter ZDR speichert Anthropic die Ergebnisse der Sicherheitsklassifikatoren, und Inhalte, die wegen Verstößen gegen die Nutzungsrichtlinien markiert wurden, können bis zu 2 Jahre aufbewahrt werden. Zero Data Retention hat nie bedeutet, dass keinerlei Daten gespeichert werden – es bedeutet, dass nicht markierte Inhalte im normalen Verarbeitungspfad nicht gespeichert werden.

Gleiche Anforderung, drei Clouds, drei Mechanismen

Die Aufbewahrungsfrist gilt überall dort, wo das Modell ausgeführt wird, doch jede Plattform gestaltet die Opt-in-Möglichkeit unterschiedlich — und diese Unterschiede entscheiden, wer Ihre Daten verarbeitet und wo Ihre Kontrollmöglichkeiten liegen.

AWS Bedrock ist am explizitesten. Data Retention ist ein konfigurierbarer Modus (default / provider_data_share / none), aufgelöst nach Projekt → Konto → Modellstandard. Fable 5 deklariert allowed_modes: ["provider_data_share"]: Prompts und Completions werden mit Anthropic geteilt und bis zu 30 Tage aufbewahrt. In jedem anderen Modus:

{
  "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 hat sich nichts geändert, und ein SCP auf dem Bedingungsschlüssel bedrock:DataRetentionMode kann Ihre Sicherheitslage organisationsweit durchsetzen — niemand stellt das Konto heimlich um, um das neue Modell auszuprobieren. Hinweis: Bei Cross-Region-Inferenz liegt die aufbewahrte Kopie in der Zielregion, was relevant ist, wenn Sie Residenzpflichten einhalten müssen.

Google Vertex AI sperrt das Modell hinter einer projektweiten Anthropic-Datenweitergabe-Einstellung (setPublisherModelConfig mit dataSharingEnabledProvider: "anthropic") sowie der Akzeptanz der Bedingungen im Model Garden, gemäß der Google-Dokumentation zu Fable 5. Die allgemeine Datenverarbeitung folgt der Vertex AI-Datenverwaltungsrichtlinie; für residenzsensible Workloads steuern die regionalen und Multi-Region-Endpunkte von Vertex, wo die Inferenz ausgeführt wird — was nun auch den Speicherort der aufbewahrten Kopie einschließt.

Microsoft Foundry ist strukturell anders. Microsofts Daten- und Datenschutzdokumentation stellt explizit klar, dass Claude-Modelle Drittanbieter-Marketplace-Dienste sind: Sie akzeptieren Anthropics Bedingungen beim Deployment, und Anthropic — nicht Microsoft — ist der Datenverarbeiter. Azures ZDR- und modifizierte Missbrauchsüberwachungsprogramme für Azure OpenAI erstrecken sich nicht auf Claude-Deployments. Organisationen mit ZDR-Sicherheitslage an anderer Stelle isolieren die Nutzung von Covered Models typischerweise in einem dedizierten Abonnement, wodurch die Aufbewahrungsgrenze strukturell statt verfahrenstechnisch wird.

Das Muster über alle drei Plattformen hinweg: Die Aufbewahrungsklasse wurde zu einem erstklassigen, maschinenlesbaren Modellattribut — einem Modus, einem Flag, einem Bedingungstor — anstatt einem Absatz in einem Vertrag. Ihre Infrastruktur kann Ihre Datensicherheitslage nun durchsetzen, und sie sollte es auch.

Was das für Enterprise-Deployments bedeutet

Ohne ZDR-Vereinbarung ändert sich mechanisch nichts — Sie befanden sich bereits in einer 30-tägigen Aufbewahrungslage, möglicherweise ohne es zu wissen. Die Arbeit besteht darin, dies in Ihrer Anbieterdokumentation explizit zu machen.

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

1. Covered Models überspringen. ZDR bleibt einheitlich; Sie verzichten auf das Modell. Sinnvoll, wenn Ihre Workloads es nicht benötigen — lesen Sie unsere gemessene Fable 5-Evaluierung, um zu sehen, was es kostet und wo es sich unterscheidet.
2. Aufteilen nach Workspace oder Projekt. Jede Plattform unterstützt ein bereichsbezogenes Opt-in: einen dedizierten Claude API-Workspace (Konsole → Einstellungen → Workspaces → Datenschutzeinstellungen), ein Bedrock-Projekt mit provider_data_share, ein separates Vertex-Projekt oder Azure-Abonnement. Leiten Sie nur aufbewahrungstolerante Workloads dorthin.
3. Aufbewahrung organisationsweit akzeptieren. Am einfachsten zu betreiben, aber es stuft die Garantie für jeden Workload stillschweigend herab — einschließlich derjenigen, deren Sensibilität ZDR gerechtfertigt hat. Das ist eine Entscheidung für Ihren Datenschutzverantwortlichen, keine Konfigurationsänderung.

Unabhängig vom Anbieter: Ihr eigenes Logging ist eine zweite Aufbewahrungsoberfläche. Wenn Ihr Gateway oder Ihr Observability-Stack vollständige Prompts protokolliert, betreiben Sie ein längeres Zeitfenster als Ihr Anbieter, unter Ihrem eigenen Dach. Anbietergarantien sind nur so aussagekräftig wie die Schicht davor — dieselbe Prüflogik, die wir auf Cache-Behauptungen angewendet haben, gilt auch hier.

Was das für verbraucherorientierte Produkte bedeutet

Wenn Sie Verbraucher bedienen und deren Inhalte über ein Covered Model leiten, wirkt sich die Änderung auf Ihre eigene rechtliche Risikooberfläche aus – unabhängig davon, ob ein ZDR-Vertrag besteht oder nicht. Drei konkrete Konsequenzen:

1. Ihre Datenschutzerklärung muss wahrscheinlich aktualisiert werden. Die meisten Rechtsordnungen verlangen die Offenlegung von Aufbewahrungsfristen, nicht nur der Erhebung: Artikel 13(2)(a) DSGVO verlangt die Angabe der Speicherdauer (oder der Kriterien dafür) zum Zeitpunkt der Erhebung; Californias CPRA verlangt, dass die Datenschutzerklärung bei der Erhebung die Aufbewahrungsdauer je Kategorie personenbezogener Daten angibt. Wenn Ihre Erklärung besagt – oder impliziert –, dass Gesprächsdaten nirgendwo gespeichert werden, macht eine 30-tägige Kopie beim Auftragsverarbeiter diese Aussage falsch. Aktualisieren Sie die Erklärung, die Verarbeitungsverzeichnisse und das DPA-Inventar.

2. Sie können Nutzern kein Opt-out anbieten, das Sie selbst nicht haben. Die Aufbewahrung kennt keinen Ausnahmemechanismus, daher gibt es keine Schaltfläche, die Sie bauen könnten, um die Prompts eines Nutzers auszunehmen – solange Sie dieses Modell weiterhin verwenden. Der Hebel, den Sie tatsächlich in der Hand haben, ist das Routing: Ein einwilligungsbewusstes Gateway leitet Nutzer, die der Datenweitergabe widersprechen, zu ZDR-fähigen Modellen und alle anderen zum Covered Model – eine rechtliche Anforderung wird so zu einer gewöhnlichen Routing-Regel. Das ist weitaus besser als ein Präferenz-Kontrollkästchen, das nichts bewirkt.

3. Löschanfragen brauchen eine saubere technische Umsetzung. Löschpflichten (DSGVO Art. 17, CPRA-Löschung und entsprechende Regelungen) erstrecken sich auf Auftragsverarbeiter. Ein begrenztes Zeitfenster mit automatischer Löschung innerhalb von 30 Tagen ist im Allgemeinen eine vertretbare Auftragsverarbeiter-Position – aber Ihr DSAR-Playbook sollte das festhalten, anstatt eine sofortige nachgelagerte Löschung zu versprechen, die Sie nicht umsetzen können.

Die globale Dimension verstärkt dies: Dieselbe Logik aus Offenlegung und Auftragsverarbeitung findet sich in der UK GDPR, Brasiliens LGPD und der wachsenden Familie von US-amerikanischen Datenschutzgesetzen auf Staatsebene. Für Nutzer in China kommen durch das PIPL zwei schärfere Anforderungen hinzu – die Weitergabe personenbezogener Daten an einen anderen Auftragsverarbeiter erfordert grundsätzlich eine gesonderte Einwilligung, und die Weiterleitung von Inhalten chinesischer Nutzer an einen ausländischen LLM-Endpunkt stellt eine grenzüberschreitende Übermittlung dar, die einen anerkannten Mechanismus erfordert (Sicherheitsbewertung, Standardvertrag oder Zertifizierung). Ein Modell-Upgrade, das verändert, wer was, wo und wie lange speichert, ist genau die Art von Änderung, für die diese Rechtsrahmen eine erneute vertragliche Absicherung erwarten.

Branchen mit sensiblen Daten: Wo die 30-Tage-Frist am härtesten trifft

Für die meisten Produkte ist das Anbieterfenster ein Dokumentationsproblem. Für Branchen, deren Daten selbst reguliert sind, ist es ein Architekturproblem: Die aufbewahrte Kopie ist reguliertes Ruhendaten bei einem Anbieter, und branchenspezifische Vorschriften regeln genau das.

Gesundheitswesen (HIPAA)

HIPAA schreibt keine Nullaufbewahrung vor – es verlangt, dass jeder Anbieter, der geschützte Gesundheitsinformationen hält, dies im Rahmen eines Business Associate Agreements (BAA) mit angemessenen Schutzmaßnahmen tut. Die 30-Tage-Kopie Ihrer Prompts ist PHI im Ruhezustand bei einem Business Associate; die Frage ist, ob Ihr BAA dies abdeckt. Die beiden großen API-Anbieter strukturieren dies unterschiedlich, und der Unterschied ist nun relevant: Anthropics HIPAA-fähiger API-Zugang erfordert ausdrücklich kein ZDR – er basiert auf Aufbewahrung mit Schutzmaßnahmen (Verschlüsselung, Zugriffskontrollen, Audit-Protokollierung, erzwungene Funktionseinschränkungen). OpenAIs API BAA deckt Endpunkte ab, die für Zero Data Retention geeignet sind – und ein BAA, das auf ZDR-Endpunkte beschränkt ist, kann strukturell kein Modell abdecken, das Aufbewahrung vorschreibt.

Die Aufbewahrungsklasse eines Modells ist nun eine Frage der BAA-Berechtigung. Bestätigen Sie schriftlich, dass Ihr BAA das spezifische Modell abdeckt, bevor Sie PHI dorthin routen – und denken Sie daran, dass sich die Kette in der Cloud verschiebt: Auf Bedrock ist die Plattform Ihr Business Associate; auf Foundry verarbeitet Anthropic die Daten direkt. Ein scharfer Punkt: PHI darf niemals in JSON-Schema-Definitionen für strukturierte Ausgaben erscheinen – gecachte Schemas erhalten nicht denselben Schutz wie Nachrichteninhalte.

Kinderprodukte (COPPA)

Das Timing ist ungünstig: Die geänderte COPPA-Regel der FTC trat am 23. Juni 2025 in Kraft, mit Compliance-Pflicht für die meisten Bestimmungen bis zum 22. April 2026 – das erste Modell mit obligatorischer anbieterseitiger Aufbewahrung kam genau dann, als Betreiber die neuen Aufbewahrungspflichten umsetzten. Zwei davon interagieren direkt mit dem 30-Tage-Fenster: Eine schriftliche, öffentliche Datenspeicherungsrichtlinie ist nun verpflichtend (§312.10) – welche Kinderdaten gesammelt werden, warum und wann sie gelöscht werden – und unbegrenzte Aufbewahrung ist verboten, wobei die Aufbewahrung auf das für den Erhebungszweck vernünftigerweise Notwendige beschränkt ist.

Ein begrenztes 30-Tage-Fenster mit automatischer Löschung hat die kompatible Form – aber der Anbieter behält für seinen Trust-and-Safety-Zweck, nicht für den Zweck, für den Sie die Kinderdaten erhoben haben, und Ihre Datenschutzhinweise müssen die Auftragsverarbeitungsbeziehung korrekt beschreiben. Für kindgerichtete Produkte, die ZDR speziell zur Minimierung des Datenpfads eingeführt haben, gilt die Routing-Antwort mit höherem Einsatz: Kinderverkehr bleibt auf ZDR-fähigen Modellen, oder das Covered-Model-Fenster fließt zuerst in Ihre §312.10-Richtlinie ein.

Dasselbe Muster in anderen Branchen

Sobald man die Struktur erkennt – regulierte Daten, aufbewahrte Kopie bei einem Anbieter, branchenspezifische Regel zur Aufbewahrung – wiederholt sie sich:

• Biometrie (Illinois BIPA): Betreiber benötigen einen schriftlichen, öffentlich zugänglichen Aufbewahrungsplan und Vernichtungsrichtlinien für biometrische Daten. Eine 30-Tage-Kopie von Prompts, die biometrische Identifikatoren enthalten, gehört in diesen Plan.
• Zahlungsverkehr (PCI DSS / GLBA): PCI DSS verbietet die Speicherung sensibler Authentifizierungsdaten nach der Autorisierung – überall. Kartendaten, die in einen Prompt eingefügt werden, werden zu Kartendaten, die 30 Tage lang bei einem Anbieter aufbewahrt werden. Die saubere Antwort ist vorgelagerte Schwärzung, nicht nachgelagerte Dokumentation.
• Bildung (FERPA): Anbieter, die Schülerakten im Rahmen der School-Official-Ausnahme verwalten, müssen unter der direkten Kontrolle der Schule bleiben. Eine Safety-Retention-Kopie, auf die die Schule nicht zugreifen oder die sie nicht vorzeitig löschen kann, steht in einem unbehaglichen Verhältnis zu diesem Standard – eine Frage für Rechtsberater, bevor EdTech-Verkehr ein Covered Model erreicht.
• Finanzdienstleistungen – die Umkehrung (SEC/FINRA): Broker-Dealer müssen Geschäftskommunikation gemäß den Bücher-und-Aufzeichnungen-Regeln aufbewahren. Für sie ist das Anbieterfenster nicht das Problem; das Erfassen einer eigenen konformen Kopie ist es. Dieselbe Aufbewahrungsfrage, umgekehrtes Vorzeichen.

Der gemeinsame Faden: Branchenregeln regulieren Aufbewahrung in beide Richtungen, und ein anbieterseitiges Fenster, das Sie nicht kontrollieren, muss in die Richtung eingeordnet werden, in die Ihre Branche zeigt.

Eine Entscheidungs-Checkliste

• ✅ Inventarisieren Sie, welche Modelle Ihr Traffic tatsächlich berührt. Die Aufbewahrungsklasse ist nun ein Attribut pro Modell, nicht pro Anbieter.
• ✅ Wenn Sie ZDR haben: Entscheiden Sie bewusst – überspringen Sie Covered Models, teilen Sie nach Workspace/Projekt/Abonnement auf, oder akzeptieren Sie Aufbewahrung organisationsweit. Lassen Sie es nicht implizit geschehen.
• ✅ Erzwingen Sie die Haltung in der Infrastruktur – Bedrock SCPs, Workspace-Datenschutzkontrollen, separate Cloud-Projekte – nicht auf einer Wiki-Seite.
• ✅ B2C: Aktualisieren Sie Datenschutzhinweise und DSAR-Playbooks; routen Sie nicht zustimmende Nutzer zu ZDR-fähigen Modellen, anstatt Opt-outs zu bauen, die nicht funktionieren können.
• ✅ Regulierte Daten: Bestätigen Sie die Abdeckung pro Modell, schriftlich – BAA für PHI, §312.10-Richtlinie für Kinderdaten, Aufbewahrungspläne für Biometrie – bevor Sie diese Daten an ein aufbewahrungspflichtiges Modell routen.
• ✅ Prüfen Sie Ihr eigenes Logging. Ein 30-Tage-Fenster eines Anbieters ist irrelevant, wenn Ihr Gateway Prompts unbegrenzt protokolliert.

Fazit

Das 30-Tage-Fenster, das an Fable 5 geknüpft ist, ist kein Datenhunger – es handelt sich um ein begrenztes, zweckgebundenes Missbrauchsmonitoring, das mit dem übereinstimmt, was die meisten Anbieter der Branche ohnehin standardmäßig tun, und das für eine Modellklasse verpflichtend gemacht wurde, weil die Erkennung von anforderungsübergreifendem Missbrauch bei gelöschten Daten nicht funktioniert. Für die meisten Teams ist der technische Aufwand gleich null, und die Governance-Auswirkung beschränkt sich auf einen Absatz in einer Anbieterprüfung.

Für Organisationen jedoch, deren Compliance-Position von einer Nullspeicherung ausging – ZDR-bezogene BAAs, Datenschutzhinweise, die keine Persistenz vorsehen, Kinderprodukte, die auf Datensparsamkeit aufgebaut sind – ist Fable 5 der Moment, in dem diese Annahme aufgehört hat, modellübergreifend einheitlich zu gelten. Die Lösung besteht nicht darin, das Modell zu meiden. Sie besteht darin, die Speicherklasse als expliziten, modellspezifischen Eingabeparameter in Routing-Entscheidungen zu integrieren – genauso wie Sie es bereits mit Preis und Kontextfenster handhaben.

FAQ

Kann ich Claude Fable 5 im Rahmen einer Zero-Data-Retention-Vereinbarung nutzen? Nein. Fable 5 und Mythos 5 sind Covered Models, die eine 30-tägige Speicherung erfordern; ZDR-Organisationen erhalten einen 400 invalid_request_error, sofern sie nicht die 30-tägige Speicherung für einen Workspace aktivieren und den Fable-5-Traffic darüber leiten.

Umgeht die Nutzung über AWS Bedrock, Vertex AI oder Microsoft Foundry die Anforderung? Nein. Jede Plattform sperrt das Modell hinter einem eigenen Retention-Opt-in: provider_data_share auf Bedrock, Anthropic-Datenweitergabe plus Model-Garden-Bedingungen auf Vertex, Anthropics Bedingungen bei der Bereitstellung auf Foundry (wo Anthropic, nicht Microsoft, der Datenverarbeiter ist). Bestehende ZDR-Vereinbarungen werden auf keiner dieser Plattformen übernommen.

Können meine Endnutzer der Speicherung widersprechen? Nein – es gibt keinen Opt-out-Mechanismus. Der Hebel, den Sie haben, ist das Routing: Leiten Sie Nutzer, die der Datenweitergabe nicht zustimmen, zu ZDR-fähigen Modellen. Liefern Sie keinen Präferenz-Toggle aus, der nichts ändert.

Werden die gespeicherten Daten zum Training von Modellen verwendet? Anthropic erklärt, dass gespeicherte Daten ohne ausdrückliche Genehmigung niemals für das Training verwendet werden. Der Zweck ist die Trust-and-Safety-Überprüfung: automatisiertes Screening, wobei markierte Konversationen nur von autorisiertem Personal eingesehen werden können, das die Daten nicht exportieren kann, unter manipulationssicheren Zugriffsprotokollen.

Ändert die 30-tägige Speicherung die Funktionsweise des Prompt-Cachings? Nein. Cache-Einträge folgen ihren eigenen kurzen TTLs (5 Minuten oder 1 Stunde), und der Caching-Vertrag für Fable 5 bleibt unverändert – siehe unsere gemessene Auswertung. Das 30-Tage-Fenster ist eine separate, parallele Speicherung für die Sicherheitsüberprüfung.

Quellen

• Anthropic — API and data retention
• Anthropic — Covered Models
• Anthropic — Data retention practices for Mythos-class models
• AWS — Amazon Bedrock data retention
• Google Cloud — Claude Fable 5 (partner models)
• Google Cloud — Vertex AI data governance
• Microsoft — Claude in Foundry: data, privacy, and security
• OpenAI — Enterprise privacy
• OpenAI — BAA for API services
• FTC — COPPA Rule amendments (press release)
• Federal Register — Children’s Online Privacy Protection Rule

Alle Quellen geprüft am 2026-06-12. Richtlinien können sich ändern – überprüfen Sie die aktuellen Dokumente und Ihre eigenen Verträge. Dies ist keine Rechtsberatung.

← Zurück zum Blog