Am 9. Juni hat AWS Claude Fable 5 auf Amazon Bedrock veröffentlicht und die eigentliche Enterprise-Story in einem Satz versteckt: Bevor du es aufrufen kannst, musst du provider_data_share aktivieren, und sobald du das tust, verlassen deine Daten die Daten- und Sicherheitsgrenze von AWS (AWS).
Das ist kein kleiner Konfigurationsschalter. Es verändert den Vertrag, den viele Teams zu kaufen glaubten, als sie sich für Bedrock entschieden haben.
Anthropic macht sein Angebot klar genug. Fable 5 ist die öffentliche, abgesicherte Version der neuen Mythos-Fähigkeitsklasse. Es kostet 10 $ pro Million Input-Tokens und 50 $ pro Million Output-Tokens, also das Doppelte des aktuellen Opus 4.8 API-Tarifs, und Anthropic sagt, das Modell sei für langlaufende Softwareentwicklung, Wissensarbeit, Vision und agentische Workflows gebaut (Anthropic, Claude pricing docs). Aber der Preis, der für ernsthafte Unternehmen am meisten zählt, ist nicht der Tokenpreis. Es ist der Governance-Preis.
Seit dem 17. Juni gibt es noch eine weitere Wendung: Anthropic sagt, der Zugriff auf Fable 5 und Mythos 5 sei am 12. Juni nach einer Exportkontrollanweisung der US-Regierung ausgesetzt worden, während alle anderen Claude-Modelle davon unberührt bleiben (Anthropic). Diese Aussetzung mag vorübergehend sein, das Governance-Muster ist es nicht. So sieht der Zugang zu Frontier-Modellen jetzt aus: mehr Fähigkeit, mehr Überwachung, weniger einfache Datenschutzversprechen.
Das Kleingedruckte, das die Architektur verändert
AWS’ Launch-Beitrag sagt, Claude Fable 5 sei in Bedrock in US East, Northern Virginia, und Europa, Stockholm, verfügbar. Er sagt auch, dass es zum Start keine Konsolen-UI für die neue Einstellung zur Datenaufbewahrung gibt. Du musst die Data Retention API aufrufen, bevor du das Modell aufrufst.
Der Launch-Beitrag zeigt die Form des Schalters:
curl -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \
-H "Authorization: Bearer <your_bearer_token>" \
-H "Content-Type: application/json" \
-d '{ "mode": "provider_data_share" }'AWS buchstabiert dann aus, was dieser Modus bedeutet: Bedrock kann Inferenzdaten gemäß den Anforderungen der Modellanbieter aufbewahren und mit ihnen teilen; bei Anthropic Fable 5 gehören zu diesen Anforderungen 30 Tage Aufbewahrung von Eingaben und Ausgaben plus mögliche menschliche Prüfung (AWS).
Das bricht das mentale Modell, das viele Plattformteams hatten:
| Route | Standarderwartung | Realität bei Fable 5 |
|---|---|---|
| Bedrock mit den meisten Modellen | Eingaben/Ausgaben werden standardmäßig nicht gespeichert | Reicht für Fable 5 nicht |
| Bedrock Fable 5 | Von AWS gehosteter Zugriff auf Anthropic-Modell | Opt-in zum Datenaustausch mit dem Anbieter erforderlich |
| Claude API mit ZDR | Keine Prompt-/Output-Aufbewahrung für berechtigte APIs | Fable 5 und Mythos 5 sind nicht ZDR-berechtigt |
| Ältere Claude-Modelle | Bestehende Aufbewahrungseinstellungen gelten weiter | Nicht von Covered-Model-Richtlinie betroffen |
AWS’ eigene Bedrock-Dokumentation zur Missbrauchserkennung sagt weiterhin, Bedrock nutze standardmäßig zero operator access und zero data retention. Dann listen sie Ausnahmen auf. Für Claude Fable 5 werden Eingaben und Ausgaben bis zu 30 Tage aufbewahrt, und die Nutzung setzt voraus, dass man dem Teilen des aufbewahrten Traffics mit Anthropic zur Missbrauchserkennung und möglichen menschlichen Prüfung zustimmt (AWS docs).
Diese „Ausnahme“ ist das Produkt.
Warum Anthropic die Daten will
Anthropics Argument ist nicht unsinnig. Das Unternehmen sagt, Mythos-Modelle überschreiten Fähigkeitsschwellen, bei denen Missbrauch erst über viele Anfragen hinweg sichtbar wird. Ein einzelner Prompt kann harmlos aussehen. Ein Muster von Prompts kann nach Jailbreak-Suche, Distillation, staatlich unterstützter Aktivität oder Datenerpressung aussehen. Anthropic nennt ausdrücklich Angriffe über mehrere Anfragen wie Best-of-N-Jailbreaking und sagt, vorübergehende Aufbewahrung lasse seine Schutzmechanismen über einzelne Requests hinaus „herauszoomen“ (Anthropic support).
Das Unternehmen sagt außerdem, aufbewahrte Daten würden nicht zum Trainieren neuer Claude-Modelle genutzt, und menschlicher Zugriff sei auf markierte Fälle mit ernsthaftem Schadenspotenzial oder schriftliche Kundenanfragen begrenzt. Prüfer verwenden laut Anthropic Werkzeuge, die Export, Kopieren oder Herunterladen verhindern; der Zugriff wird in manipulationssicheren Logs aufgezeichnet. Nach 30 Tagen werden Daten gelöscht, sofern sie nicht mit einer Sicherheitsuntersuchung oder rechtlichen Anforderung verbunden sind (Anthropic support).
Das ist ein schlüssiges Sicherheitsdesign. Es ist aber auch eine schwächere Enterprise-Grenze als „eure Prompts und Outputs werden nicht aufbewahrt“.
Beides kann wahr sein. Entwickler reden darüber oft so, als müsse eine Seite lügen. Das ist der falsche Rahmen. Der bessere Rahmen ist: Anthropics Sicherheitssystem braucht Beobachtbarkeit, und Enterprise-Governance behandelt Beobachtbarkeit über sensible Prompts oft als neuen Auftragsverarbeiter, neuen Aufbewahrungsspeicher und neue Prüffläche.
Wenn du einen Coding Agent über eine regulierte Codebasis laufen lässt, ist dein „Prompt“ keine Chatnachricht. Er kann Quelldateien, Stacktraces, versehentlich in Logs ausgegebene Secrets, in Fixtures eingebettete Kundendatensätze, Schwachstellenberichte, Datenbankschemata, interne URLs, IAM-Policy-Fragmente und Tool-Ausgaben von MCP-Servern enthalten. Ein 30 Tage aufbewahrtes Transkript ist nicht abstrakt. Es ist eine temporäre Kopie deiner Engineering-Umgebung.
Die Reaktion der Community war vorhersehbar und größtenteils richtig
Der Hacker-News-Thread kam direkt zum Punkt. Die Einreichung hob AWS’ Aussage hervor, dass Daten beim Opt-in zur Aufbewahrung die AWS-Grenze verlassen, und bekam innerhalb weniger Tage 426 Punkte und 254 Kommentare (Hacker News). Die Debatte lautete nicht: „Ist Fable smart?“ Sie lautete: „Wofür war Bedrock da, wenn nicht für diese Grenze?“
Ein HN-Kommentator brachte den zentralen Enterprise-Schmerz auf den Punkt: Diese Modelle werden in Umgebungen unbrauchbar, in denen Verträge einschränken, wer Kundendaten erhalten darf. Ein anderer sagte, es gebe wenig Grund, Bedrock zu nutzen, wenn einem Datenaustausch-Grenzen nicht wichtig sind. Das ist etwas überzogen, Bedrock bietet auch IAM-Integration, Abrechnung, Service Controls und AWS-native Operations, aber es trifft das Kaufmotiv vieler AI-Plattformteams.
Dasselbe Thema tauchte in r/aws auf, wo der Beitragstitel unverblümt war: „AWS Bedrock to require sharing data with Anthropic for Mythos and future models.“ Ein Kommentator sagte, Daten innerhalb der Sicherheitsgrenze zu halten, sei für seine Organisation „der Hauptpunkt“ von Bedrock gewesen; ein anderer nannte die Modelle für sich unbrauchbar (Reddit r/aws).
Es gab auch einen zweiten, misstrauischeren Strang: Wenn Anbieter Prompts 30 Tage lang aufbewahren, was hindert sie daran, darauf zu trainieren? Die faktische Antwort ist, dass Anthropic sagt, diese Daten nicht zum Trainieren neuer Claude-Modelle oder für Nicht-Sicherheitszwecke zu verwenden (Anthropic). Die praktische Antwort ist, dass regulierte Unternehmen ihre Kontrollen nicht auf Vendor-Vibes bauen. Sie bauen auf durchsetzbare Bedingungen, Audit-Rechte, Datenflussdiagramme, Aufbewahrungspläne und Incident-Prozesse.
Das ist das fehlende Stück in vielen Forendebatten. „Sie sagen, kein Training“ ist relevant. Es reicht nicht.
Bedrocks altes Versprechen ist nicht verschwunden, es wurde modellspezifisch
Der größte Fehler, den ein Enterprise-Team jetzt machen kann, ist, „Bedrock“ als eine einzige Datenschutzposition zu behandeln.
Für ältere Modelle und viele Bedrock-Routen existiert die alte Haltung weiterhin. AWS sagt, Bedrock speichere Modelleingaben oder -ausgaben standardmäßig nicht und nutze standardmäßig zero operator access (AWS docs). Anthropic sagt, andere Claude-Modelle liefen weiterhin unter bestehenden Vereinbarungen und konfigurierten Aufbewahrungseinstellungen (Anthropic support).
Fable 5 verschiebt die Governance-Einheit von „Anbieter“ oder „Plattform“ zu „Modellklasse“.
Das bedeutet, dein AI-Gateway muss Modell-IDs als Policy-Objekte verstehen. global.anthropic.claude-fable-5 sollte nicht im selben Allowlist-Eimer liegen wie Sonnet, Haiku oder Opus. Es braucht ein eigenes Risikolabel, eigene Routing-Regeln, eigenes Logging und wahrscheinlich einen eigenen Freigabepfad.
Eine vernünftige Enterprise-Policy sieht jetzt so aus:
- Entwickler standardmäßig auf Nicht-Covered-Models für normale Coding- und Support-Aufgaben lenken.
- Modelle der Fable/Mythos-Klasse hinter ausdrückliche Projektfreigabe stellen.
- Prompts blockieren, die regulierte Daten, Secrets, Kundenkennungen, unveröffentlichte Finanzdaten oder exportkontrolliertes Material enthalten.
- Ein Clean-Room-Repo oder synthetisches Fixture-Set für Fable-Coding-Agent-Läufe verlangen.
- Jeden Aufruf mit Modell-ID, Aufbewahrungsmodus, Datenklassifizierung, Business Owner und Ticket loggen.
- Einen Kill Switch einbauen, der Covered Models organisationsweit deaktivieren kann, ohne darauf zu warten, dass jedes Team Code aktualisiert.
Das ist langweilige Governance-Arbeit. Sie ist aber auch das, was Unternehmen erlaubt, mächtige Modelle zu nutzen, ohne so zu tun, als sei ein aufbewahrtes Coding-Transkript harmlos.
Der echte Tradeoff: Fähigkeit jetzt, saubere Grenzen später
Meine Position: AWS und Anthropic haben richtig gehandelt, indem sie den Aufbewahrungs-Tradeoff explizit gemacht haben, aber Fable 5 sollte in ernsthaften Engineering-Umgebungen nicht standardmäßig aktiviert sein.
Die Transparenz ist gut. Der Product Fit ist enger, als der Launch-Hype nahelegt.
Wenn du einen Prototyp baust, eine Open-Source-Codebasis migrierst, öffentliche Dokumente analysierst oder eine vom Red Team freigegebene Sandbox betreibst, kann Fable 5s Tradeoff vernünftig sein, sobald der Zugriff zurückkehrt. Das Modell ist teuer, aber die relevante Frage ist, ob es eine lange Aufgabe mit weniger menschlichen Zyklen abschließt. Anthropic behauptet, Fable 5 liege bei längerer, komplexerer Arbeit stärker vorn, und frühe Kundenanekdoten verweisen auf ambitionierte Migrationen und agentische Coding-Läufe (Anthropic).
Wenn du am Transaktionssystem einer Bank arbeitest, an einer Pipeline für medizinische Akten, an einem Repository eines Regierungsauftragnehmers, an unveröffentlichtem Chipdesign, an Kundensupport-Exporten oder an einem Produktionsincident mit Secrets, sollte die Standardantwort nein sein. Nicht „für immer nein“. Nein, bis Legal, Security und der Dateneigentümer den neuen Auftragsverarbeiter und Aufbewahrungspfad akzeptieren.
Hier müssen Teams aufhören, ihr Urteil an Cloud-Markenvertrauen auszulagern. Bedrock ist kein magischer Datenschutzumschlag. Es ist eine Plattform mit modellspezifischen Ausnahmen. Die Ausnahme hängt jetzt an dem Frontier-Modell, das alle ausprobieren wollen.
Anthropics Aussetzung vom 12. Juni macht das noch klarer. Dasselbe Modell, das 30 Tage Sicherheitsaufbewahrung verlangte, wurde zurückgezogen, weil die US-Regierung nationale Sicherheitsbedenken wegen eines möglichen Jailbreaks geltend machte, eine Behauptung, der Anthropic widerspricht (Anthropic). Diese Abfolge sollte jedes Roadmap-Meeting nüchtern machen. Frontier-Modelle sind nicht mehr nur Dependencies. Sie sind volatile Policy-Oberflächen.
Was Entwicklerteams diese Woche tun sollten
Fangt mit Inventarisierung an. Durchsucht euren Code, eure Notebooks, Terraform und internen Docs nach Fable- und Mythos-Modell-IDs. Erzwingt die Policy dann auf Gateway-Ebene, statt jeder SDK-Callsite zu vertrauen.
Wenn ihr Bedrock nutzt, prüft, ob provider_data_share aktiviert wurde und wer diese Einstellung ändern kann. Behandelt sie wie eine Produktionskontrolle für Datenabfluss, nicht wie eine Modellpräferenz. Wenn eure Organisation vertragliche ZDR-Zusagen hat, geht davon aus, dass Fable 5 außerhalb des genehmigten Pfads liegt, bis Counsel etwas anderes sagt.
Für Coding Agents: Erstellt einen „frontier-sicheren“ Workspace: keine Secrets, keine Kundendaten, keine privaten Incident-Logs, keine proprietären Datensätze, sofern nicht ausdrücklich genehmigt. Gebt dem Modell ein schmales Aufgabenpaket, nicht euer ganzes Monorepo plus Slack-Export plus Datenbankkonsole.
Für Procurement: Aktualisiert den Fragebogen. Stellt Modellanbietern und Cloud-Plattformen diese Fragen pro Modellklasse:
- Werden Prompts und Outputs aufbewahrt? Wie lange?
- Wer speichert sie, der Cloud-Anbieter oder der Modellanbieter?
- Können Menschen sie prüfen? Unter welchen Auslösern?
- Werden sie für Training, Safety Tuning, Klassifikator-Evaluation oder Missbrauchserkennung genutzt?
- Welche Audit-Logs kann der Kunde sehen?
- Was passiert bei Legal Hold, Sicherheitsuntersuchung oder behördlicher Anordnung?
- Kann der Kunde das Modell organisationsweit deaktivieren?
Der Launch von Fable 5 hat Bedrock nicht schlecht gemacht. Er hat faule Bedrock-Governance überflüssig gemacht.
Das ist die nützliche Lektion. Die Zukunft wird mehr Modelle wie dieses bringen: sehr fähig, teuer, überwacht und in Sonderbedingungen verpackt. Gewinnen werden nicht die Teams, die alle verbieten oder alle blind aktivieren. Gewinnen werden die Teams, die Arbeit nach Sensibilität routen, belegen können, wohin Daten geflossen sind, und Frontier-Fähigkeit für Aufgaben reservieren, die den Governance-Preis wert sind.
Leser, die Claude Fable 5 selbst ausprobieren möchten, können es über Claude Fable 5 on OneHop nutzen, einen Drop-in-Endpoint, der etwa 30 % unter Listenpreis liegt. Neue Accounts können mit 10 $ gratis starten, keine Karte erforderlich.
Weiterlesen: Erste Schritte mit Claude Fable 5.
