Mein Agent fiel über Nacht aus, weil ein Modell abgeschaltet wurde. Was ich in Teil 1 dieser Reihe noch nicht gesagt habe: Dieser Ausfall war nicht einmal das schlimmste Risiko.
Es gibt drei Wege, wie ein KI-Modell aus Ihrem Prozess verschwindet. Nur einer davon ist der laute, sichtbare Ausfall.
Reihe „Modell-Souveränität“ · Teil 2 von 7
← Teil 1: Über Nacht abgeschaltet ·
Teil 3 folgt
Modelle sind die neue Lieferkette
Wenn Sie aus der IT-Sicherheit kommen, kennen Sie das Muster. SolarWinds, Log4Shell, der CrowdStrike-Vorfall, Kaseya: Jedes Mal lag das Problem nicht im eigenen Haus, sondern in einem Baustein der Lieferkette, auf den man sich verlassen hatte. Sicherheitsverantwortliche denken längst in Lieferketten. KI-Modelle sind die neue Lieferkette, und sie hat ihre eigenen Ausfallarten.
Der Unterschied: Bei klassischer Software denken wir inzwischen selbstverständlich über Lieferkettenrisiken nach. Bei KI-Modellen tun wir das noch nicht. Unter Modell-Risiken verstehe ich Risiken, die nicht aus Ihrer Anwendung oder Infrastruktur entstehen, sondern aus dem KI-Modell selbst und seinen Nutzungsbedingungen. Davon gibt es drei.
Risiko 1: Verfügbarkeit
Das Modell ist schlicht weg. Nicht wegen eines technischen Defekts, sondern weil eine Regelung, eine Anordnung oder eine Geschäftsentscheidung des Anbieters es entzieht. Genau das ist am 12. Juni 2026 passiert, als der Zugang zu Claude Fable 5 per Exportkontroll-Anweisung über Nacht gesperrt wurde. (Quelle: Anthropic, 12.06.2026.)
Risiko 2: Nutzbarkeit
Subtiler, aber ebenso kritisch: Das Modell verschwindet nicht, seine Fähigkeiten verschwinden. Es existiert weiter, aber genau die Funktion, wegen der Sie es ausgewählt haben, steht plötzlich nicht mehr zur Verfügung. Schutzmechanismen, Verhalten und Routing ändern sich.
Ein Beispiel: Fable 5 leitet Anfragen, die nach Cybersecurity, Biologie oder Chemie aussehen, automatisch an das schwächere Modell Opus 4.8 weiter. Anthropic gibt an, dass das in weniger als fünf Prozent der Sitzungen geschieht, räumt aber ein, dass die Schutzmechanismen bewusst breit eingestellt sind und auch harmlose Arbeit treffen können. (Quelle: Anthropic.)
Für einen Security-Workflow heißt das: Das Modell ist da, aber für genau Ihre Aufgabe womöglich nicht mehr zu gebrauchen. Ein eingespielter Prüfprozess liefert dann über Nacht schwächere Ergebnisse, ohne dass eine einzige Fehlermeldung erscheint.
Risiko 3: Datenhaltung
Das Modell darf genutzt werden, aber nicht für bestimmte Daten. Für die Mythos-Klasse, zu der Fable gehört, gibt es keine Zero-Data-Retention. Anfragen und Antworten werden 30 Tage gespeichert, und Organisationen mit einer Zero-Data-Retention-Pflicht bekommen bei der Nutzung schlicht einen Fehler zurück. (Quelle: Anthropic-Support.)
Daraus folgt: Das beste Modell und das complianteste Modell sind nicht zwingend dasselbe Modell.
Für Unternehmen mit strengen Vertraulichkeitsanforderungen kann diese Speicherpflicht bereits ausreichen, um das Modell auszuschließen.
Wofür klassische Notfallpläne nicht gemacht sind
Business-Continuity-Pläne kennen Cloud-Ausfälle, Ransomware und Rechenzentrumsbrände. Diese drei Modell-Risiken passen in keine dieser Schubladen.
Der Anbieter existiert, der Vertrag gilt, die API antwortet. Und trotzdem steht Ihr Prozess.
Weil das Modell weg ist, sich verändert hat oder Ihre Daten nicht anfassen darf.
Die naheliegende Antwort lautet: Dann regeln wir das eben vertraglich. Warum genau das nicht ausreicht, ist Thema von Teil 3.
Kernaussagen dieses Beitrags
- KI-Modelle sind eine Lieferkette mit eigenen Ausfallarten.
- Risiko 1, Verfügbarkeit: das Modell wird entzogen.
- Risiko 2, Nutzbarkeit: das Modell ist da, tut aber nicht mehr, was Sie brauchen.
- Risiko 3, Datenhaltung: das Modell darf nicht für bestimmte Daten genutzt werden.
- Das beste Modell und das complianteste Modell sind nicht zwingend dasselbe.
Welches dieser drei Risiken ist in Ihrem Unternehmen heute am wenigsten abgedeckt?
Move fast and secure things.