19 Tage Fable-Ban, ein Reinstate, und die nächste Verfügung wartet schon

Am 12. Juni hat das US Department of Commerce eine Direktive an Anthropic geschickt, die innerhalb von Stunden zur weltweiten Abschaltung von Fable 5 und Mythos 5 führte. 19 Tage später — heute — ist der Zugang wieder offen. Für alle. Ohne Nationalitäts-Filter, ohne ID-Gate.

Wer den Fable-Ban-Artikel vom 29. Juni gelesen hat, kennt die Struktur des Vorfalls. Was in der Kommentar-Schleife rund um den Reinstate jetzt untergeht: die Rückkehr der Modelle ist die kurzfristig gute Nachricht — die langfristig interessante Frage lautet, was der Vorfall über die nächsten 12 Monate lehrt. Und die Antwort ist unbequem.

Was heute wirklich zurückkommt

Anthropic hat gestern Abend das offizielle Statement veröffentlicht: „Fable 5 returns globally July 1." Beide Modelle sind seit heute morgen wieder in der API und in Claude verfügbar. Der ursprünglich diskutierte Nationalitäts-Filter, der zwischenzeitlich als Workaround im Gespräch war, ist nicht Bestandteil des Reinstates. Anthropic hat sich hier — offenbar erfolgreich — in Washington durchgesetzt.

Auf der technischen Seite: keine wesentlichen Änderungen an den Modellen selbst. Die 135-tägige CVE-Klausel aus dem „Project Glasswing"-Pilot bleibt bestehen — das ist aber ein Backend-Detail, das euch als Nutzer wenig betrifft. In der Konsole sieht alles aus wie vor dem 12. Juni.

Für Kunden, die zwischenzeitlich auf Sonnet 4.6 oder auf Alternativ-Anbieter umgestellt haben, stellt sich jetzt die Frage: zurück auf Fable, oder auf den ausgewichenen Setup bleiben? Wir empfehlen: erstmal auf dem stabileren Setup bleiben, den Fable-Reinstate 2-3 Wochen beobachten, dann bewusst entscheiden. Der Reflex „schnell zurück zum Gewohnten" ist in dieser Lage der Falsche.

Drei Lager nach 19 Tagen

Wir haben in den vergangenen zweieinhalb Wochen mit ungefähr zwanzig Mittelständlern gesprochen, die produktiv KI einsetzen. Grob sortieren sich die Reaktionen in drei Lager — und diese Sortierung ist der interessanteste Datenpunkt aus der ganzen Episode.

Lager 1 — „Wir haben es nicht gemerkt." Wer bereits einen Routing-Layer und mindestens zwei aktive Provider im Setup hatte, hat den Ban nicht als Ausfall wahrgenommen. Bei einem unserer Kunden lief eine automatische Umschaltung auf Sonnet 4.6 innerhalb von 90 Sekunden nach Auftreten der ersten Fehler-Responses. Der Kunde hat den Vorfall erst zwei Tage später durch unser Wochenreporting mitbekommen.

Lager 2 — „Wir haben zwei Tage geblutet." Wer keine automatische Failover-Logik hatte, aber technisch versiert war, hat innerhalb von 6-24 Stunden manuell umgestellt. Das kostet Nerven und Fokus, aber es funktioniert. Der Preis: 2-3 Tage schlechtere Output-Qualität, verunsicherte Kunden, Ad-hoc-Entscheidungen unter Zeitdruck.

Lager 3 — „Wir haben angerufen und gefragt was zu tun ist." Wer keine Infrastruktur, kein Backup, kein Ansprechpartner hatte, hat die 19 Tage nicht produktiv arbeiten können. Bei einem Kunden aus dem Handel führte das zu einer 10-tägigen Verzögerung in einem Kundenprojekt, weil der Bot, der Angebote generiert, drei Wochen lang schlicht nicht funktioniert hat.

Der Ban war ein Realitäts-Check. Nicht für die Anbieter — sondern für die Anwender.

Was der Ban gezeigt hat, das wichtiger ist als der Reinstate

Drei strukturelle Lektionen, die auch nach der Rückkehr der Modelle gelten:

Erstens: „Verfügbar heute" ist keine Verfügbarkeitsgarantie für morgen. Das gilt für jeden US-Anbieter, es gilt zunehmend auch für europäische Anbieter, die in geopolitischen Kreuzungen stehen. Wer heute einen Workflow auf ein Modell hardcodet, baut auf Voraussetzungen, die morgen politisch neu verhandelt werden können.

Zweitens: Der Unterschied zwischen „ich könnte umstellen" und „ich habe schon einmal umgestellt" ist nicht akademisch. Lager 2 hatte „theoretisch" einen Alternativplan. Lager 1 hatte ihn schon einmal in Produktion getestet. Der Wechsel unter Realzeit-Druck ist kein Refactor — er ist eine Config-Änderung, weil die andere Schiene schon läuft.

Drittens: Der billige Zusatz-Aufwand vor einem Vorfall ist immer günstiger als die teure Notreaktion währenddessen. Ein Routing-Layer kostet einen Entwickler ein bis zwei Tage. Ein Failover-Test unter Realbetrieb kostet eine Kalender-Woche. Der Ausfall einer Kundenpipeline für 10 Tage kostet euch einen sechsstelligen Betrag an Umsatz plus Vertrauen, das ihr nicht so schnell zurückbekommt.

Wer diese drei Punkte nach den 19 Tagen nicht in eine To-do-Liste übersetzt hat, verpasst die Lektion des Vorfalls und wird die gleiche Erfahrung beim nächsten Anlauf erneut machen. Und der nächste Anlauf steht kurz bevor.

Der nächste Vorfall ist schon terminiert: Biometric-ID am 8. Juli

Während der Fable-Reinstate heute die Schlagzeilen dominiert, läuft eine andere Anthropic-Änderung mit deutlich unmittelbarerem Kosten- und Prozess-Impact auf den Rollout: der Persona-basierte Biometric-ID-Check startet am 8. Juli. In sieben Tagen. Und die Trigger-Kriterien sind so formuliert, dass er die meisten produktiv arbeitenden Mittelstands-Setups direkt trifft.

Anthropic hat gestern die Trigger-Konfiguration präzisiert. Persona-Verifikation wird verlangt bei: (a) Plan-Upgrade, (b) „unusual activity flag", (c) Feature-Access-Requests wie Model-Preview-Access, (d) Underage-Verdacht. Der zweite Punkt — „unusual activity flag" — ist der kritische. Wer mehrere Agenten parallel auf einem Max-Plan laufen lässt, oder wer 24/7-Traffic mit hohem Volumen fährt, wird mit hoher Wahrscheinlichkeit als „unusual" markiert und in den Persona-Verifikations-Flow geschickt.

Persona ist ein US-basiertes Identitäts-Verifikations-Unternehmen, das Government-IDs plus Live-Selfie plus 269 Zusatz-Checks fordert, darunter Terror-Watchlist-Abgleich und FinCEN-SAR-Fähigkeit. Discord hat die Zusammenarbeit mit Persona vor einigen Wochen beendet — das ist im Kontext der DSGVO ein Signal, das man nicht ignorieren sollte. Für europäische Kunden gibt es in der Anthropic-Policy bisher keine Ausnahme.

Praktisch heißt das: In sieben Tagen werden möglicherweise eure Agenten auf einen Login-Loop laufen, in dem Anthropic euch nach einem Ausweis-Upload fragt, den ihr datenschutz-rechtlich nicht mal eben liefern könnt. Das ist keine hypothetische Zukunft — das ist eine terminierte Änderung.

Was wir konkret empfehlen — in dieser Reihenfolge

Die Zeit-Priorität ist eng. Für die nächsten sieben Tage:

1. API-Key-Workspace-Backup einrichten. Wenn ihr heute über Subscription-Pläne (Pro, Max) arbeitet: legt parallel einen API-Zugang mit eigenem Billing-Konto an. Das ist die Grundvoraussetzung, um Persona-Trigger ausweichen zu können — API-Keys unterliegen der Verifikation nur in Ausnahmefällen.
2. Account-Split für hohe Volumina. Wenn ihr fünf Agenten auf einem Max-Plan fährt, ist die Wahrscheinlichkeit hoch, dass ihr am 8. Juli als „unusual activity" markiert werdet. Splittet die Agenten auf mehrere Sub-Accounts — das reduziert das Trigger-Risiko deutlich.
3. Routing-Layer, falls noch nicht vorhanden. Wer aus dem Fable-Ban nicht mitgenommen hat, dass eine Abstraction-Schicht zwischen Anwendung und Anbieter existieren muss, sollte diese Woche eine ansetzen. Mindest-Setup: Umgebungsvariable, die zwischen Provider A und B umschaltet, ohne Code-Änderung.
4. Zweiten Provider produktiv testen. Nicht nur „theoretisch verfügbar" — sondern täglich einen kleinen Prozentsatz eurer Workloads durch Mistral, Sonnet 4.6, oder ein lokales Modell laufen lassen. Der Failover ist keine Strategie, wenn ihr ihn nie geübt habt.
5. Compliance-Dokumentation aktualisieren. Wenn ihr mit DSGVO-Verantwortlichen arbeitet, informiert diese jetzt über die kommende Persona-Verifikation und die Alternativen. Vor dem 8. Juli, nicht danach.

Das ist eine kompakte Woche. Aber es sind fünf Aktionen, die den Unterschied machen werden zwischen „wir haben es nicht gemerkt" und „wir haben zwei Tage geblutet" beim nächsten Vorfall — und dieser Vorfall ist nicht mehr hypothetisch, sondern kalendarisch.