Fable-5-Stopp: Was KI-Abhängigkeit als Betriebsrisiko bedeutet

Wer KI als Betriebsinfrastruktur nutzt, trägt ein Abhängigkeitsrisiko, das sich mit einem Knopfdruck realisieren kann, ohne Vorwarnung, ohne Regressanspruch. Redundanz und Fallback-Prozesse sind keine Nice-to-haves, sondern Betriebspflicht.

Fable 5 wurde per Dekret abgeschaltet. Nicht wegen eines technischen Fehlers, nicht wegen eines Cyberangriffs, sondern weil eine staatliche Exportkontroll-Anordnung den Anbieter zur sofortigen Abschaltung zwang. Wer sein Produkt, seinen Support oder seine internen Prozesse auf diesen Dienst gestützt hatte, stand von einem Tag auf den anderen vor einem operativen Loch. Das ist kein Einzelfall. Es ist ein Strukturproblem, das jeden trifft, der KI als Betriebsinfrastruktur einsetzt, und noch keine belastbare Antwort auf die Frage hat: Was tun wir, wenn der Dienst wegfällt?

Ende Juni 2026 hob die US-Regierung die Anordnung wieder auf; seit dem 1. Juli ist Fable 5 wieder verfügbar. Am Grundproblem ändert das nichts: Der Zugang war 19 Tage weg, ohne dass betroffene Teams etwas tun konnten.

Stand: Juni 2026. Anbieter, Preismodelle und Modellversionen ändern sich schnell; die Risikologik und die Fallback-Prinzipien bleiben stabil, die konkreten Dienste und Konditionen solltest du regelmässig neu prüfen.

Was ist KI-Abhängigkeit als Betriebsrisiko überhaupt?

KI-Abhängigkeit als Betriebsrisiko bedeutet: Ein Unternehmen hat seine Prozesse so eng an ein externes KI-System, eine API oder einen Plattformanbieter gekoppelt, dass der Ausfall dieses Systems den Betrieb unmittelbar beeinträchtigt, nicht erst mittelbar, nicht erst nach Wochen, sondern sofort. Das Bundesarbeitsgericht hat in seiner Entscheidung 5 AZR 366/21 eine hilfreiche Risikologik formuliert: Entscheidend ist nicht, dass eine Störung von aussen kommt, sondern ob sie sich im Betrieb als organisatorisch zu tragendes Risiko realisiert. Auf KI übertragen heisst das: Wer die eigene Organisation von einem fremd kontrollierten System abhängig macht, trägt die Folgen seines Ausfalls intern, weil er die Abhängigkeit selbst geschaffen hat, das Risiko also betriebsspezifisch und nicht bloss allgemein-extern verursacht ist.

Die Betriebsrisikolehre, wie sie TK-Lex und Haufe zusammenfassen, weist Betriebsstörungen grundsätzlich demjenigen zu, der die betriebliche Organisation veranlasst und steuert. Bei einer allgemeinen hoheitlichen Schliessung (das BAG hat das für Pandemiemassnahmen festgehalten), liegt gerade kein betriebsspezifisches Risiko vor, weil die Ursache nicht in den konkreten Produktionsbedingungen des Betriebs liegt. Bei einem KI-Anbieter-Stopp ist das anders: Wer seinen Betrieb aktiv auf diesen Dienst aufgebaut hat, hat die Ursache der Abhängigkeit selbst herbeigeführt. Das Risiko ist organisationseigen.

Wie entsteht die Abhängigkeit, und wann wird sie gefährlich?

Moderne KI läuft fast immer über externe Schnittstellen: APIs, SaaS-Plattformen, proprietäre Modelle. Verfügbarkeit, Rate Limits, Nutzungsbedingungen, Preismodelle und Modellversionen liegen ausserhalb der eigenen Kontrolle. Das schafft einen Single Point of Failure, sobald eine Kernfunktion nur noch über einen einzigen Anbieter läuft.

Gefährlich wird die Abhängigkeit nicht erst beim Totalausfall. Es gibt ein Spektrum von Störungsformen, die alle operative Konsequenzen haben:

• Komplette Abschaltung (wie im Fable-5-Fall): Dienst ist sofort nicht mehr erreichbar.
• Modell-Deprecation: Ein Modell wird durch eine neue Version ersetzt, Prompts und Outputs ändern sich ohne Vorwarnung.
• Policy-Enforcement: Ein Account wird gesperrt wegen angeblicher Nutzungsbedingungsverstösse, oft ohne sofortige Begründung.
• Preisänderungen: Token-Preise steigen um Faktor 3, die Unit Economics des Produkts brechen ein.
• Qualitätsdegradierung: Das Modell verhält sich nach einem Update anders; Klassifikationen, Zusammenfassungen oder Entscheidungsunterstützung liefern schlechtere Ergebnisse.
• Verfügbarkeitsprobleme: Stundenlange Ausfälle oder Rate-Limit-Engpässe blockieren Produktionsprozesse.

In vielen DACH-Teams läuft mindestens ein kritischer Prozess über einen einzigen KI-Anbieter, ohne dokumentierten Fallback. Das ist kein technisches Versäumnis. Es ist ein Governance-Problem.

Welche Prozesse sind am stärksten exponiert?

Nicht jede KI-Nutzung ist gleich risikobehaftet. Die Exposition hängt davon ab, wie tief die KI in den operativen Kern eingebettet ist und wie schnell ein Prozess ohne sie zum Stillstand kommt. Wir unterscheiden drei Kategorien:

Kritische Abhängigkeit (Ausfall = sofortiger Betriebsunterbruch)

• Automatisierter Kundensupport über KI-Chatbot ohne menschlichen Fallback
• Dokumentenerstellung oder Vertragsentwürfe, die direkt in Kundenworkflows fliessen
• Klassifikations- oder Scoring-Systeme, die Kreditentscheide, Risikoprüfungen oder Onboarding-Flows steuern
• Code-Generierung in CI/CD-Pipelines, die ohne KI-Output nicht deployen

Hohe Abhängigkeit (Ausfall = erheblicher Produktivitätsverlust, kein sofortiger Stillstand)

• Interne Wissenssuche und Dokumenten-Retrieval
• Zusammenfassungen von Meeting-Protokollen, Reports oder Research
• Erstellung von Marketing- oder Kommunikationsinhalten
• Code-Review-Unterstützung oder Test-Generierung

Niedrige Abhängigkeit (Ausfall = Komfortverlust, kein operativer Schaden)

• Brainstorming-Unterstützung für Einzelpersonen
• Draft-Erstellung für interne Dokumente, die manuell überarbeitet werden
• Exploratives Prototyping ohne Produktionsrelevanz

Der Fable-5-Stopp trifft vor allem Teams in der ersten Kategorie. Wer KI dort einsetzt, ohne Redundanz einzuplanen, hat eine ungesicherte Stelle im Betrieb, so wie ein Rechenzentrum mit Strom aus einer einzigen Leitung ohne USV.

Was sagt die Betriebsrisikolehre, und warum ist das für KI-Teams relevant?

Die arbeitsrechtliche Betriebsrisikolehre ist keine direkte Rechtsquelle für KI-Governance. Aber sie bietet eine belastbare Risikologik, die sich übertragen lässt. Ihr Kern: Wer eine betriebliche Organisation aufbaut und steuert, trägt die Risiken, die aus dieser Organisation erwachsen. Das BAG hat in 5 AZR 366/21 präzise unterschieden: Eine allgemeine, von aussen gesetzte Störung, die alle gleichermassen trifft, ist kein betriebsspezifisches Risiko. Eine Störung, die sich aus der eigenen Organisationsentscheidung ergibt (zum Beispiel, genau diesen Dienst einzusetzen), ist es sehr wohl.

Für IT-Verantwortliche und Business Analysten bedeutet das konkret: Die Entscheidung, einen KI-Dienst produktionskritisch einzusetzen, ist eine Organisationsentscheidung mit Risikofolgen. Wer diese Entscheidung trifft, ohne Kontinuitätsplanung zu machen, hat keine technische Lücke, sondern eine Management-Lücke.

Sinngemäss lässt sich die Logik der arbeitsrechtlichen Betriebsrisikolehre übertragen: Entscheidend ist nicht, dass eine Störung von aussen kommt, sondern ob sie sich im Betrieb als organisatorisch zu tragendes Risiko realisiert.

Denkmodell, frei nach der Betriebsrisikolehre (vgl. BAG, 5 AZR 366/21)

Haufe fasst die Betriebsrisikolehre so zusammen: Der Arbeitgeber trägt das Risiko von Betriebsstörungen, und arbeitsbereite Mitarbeitende sind grundsätzlich weiterzuvergüten, wenn der Betrieb aus solchen Gründen ausfällt. Auf KI übersetzt: Wenn der KI-Dienst wegfällt und Mitarbeitende ihre Aufgaben nicht mehr erledigen können, liegt das operative und wirtschaftliche Risiko beim Unternehmen, nicht beim Anbieter, nicht beim Mitarbeitenden.

Wie misst du dein tatsächliches Abhängigkeitsniveau?

Bevor Massnahmen greifen, braucht es eine ehrliche Bestandsaufnahme. Wir empfehlen ein KI-Dependency-Audit in drei Schritten:

1. Prozess-Inventar: Liste alle Workflows auf, die KI-Outputs nutzen, nicht nur die offensichtlichen Chatbot-Integrationen, sondern auch API-Calls in Hintergrundprozessen, automatisierte Berichte, Klassifikations-Pipelines.
2. Ausfallzeit-Simulation: Frage für jeden Prozess: Wie lange läuft er ohne KI-Output weiter? Unter 1 Stunde = kritisch. 1–8 Stunden = hoch. Über 1 Tag = tolerierbar.
3. Anbieter-Konzentration: Wie viele kritische oder hoch-abhängige Prozesse laufen über denselben Anbieter? Mehr als 3 über einen einzigen Anbieter = strukturelles Klumpenrisiko.

Ergänzend solltest du für jeden kritischen KI-Einsatz folgende Fragen beantworten können:

• Wer darf den Dienst abstellen, und unter welchen Bedingungen?
• Welche Daten liegen beim Anbieter, und wie schnell kannst du sie exportieren?
• Gibt es eine vertragliche SLA, und was deckt sie ab?
• Wie lange dauert die Migration zu einem alternativen Anbieter?
• Was ist das akzeptable Qualitätsniveau im Notbetrieb?

Wenn du mehr als zwei dieser Fragen nicht beantworten kannst: Du hast eine ungesicherte kritische Abhängigkeit.

Welche Massnahmen reduzieren das Betriebsrisiko konkret?

Es gibt keine Massnahme, die Abhängigkeit eliminiert, aber es gibt eine Staffelung, die das Risiko auf ein beherrschbares Niveau bringt. Wir strukturieren das nach Aufwand und Wirkung:

Sofortmassnahmen (1–2 Tage, kein grosses Budget)

• Fallback-Dokumentation: Für jeden kritischen KI-Prozess einen manuellen Notfallprozess dokumentieren. Nicht perfekt, aber ausführbar.
• Daten-Export-Test: Prüfen, ob und wie schnell alle beim Anbieter liegenden Daten (Prompts, Fine-Tuning-Daten, Logs) exportierbar sind.
• Alert-Setup: Monitoring für API-Verfügbarkeit, Rate-Limit-Annäherung und Modell-Deprecation-Ankündigungen einrichten.

Mittelfristige Massnahmen (2–8 Wochen)

• Provider-Abstraktion: Einen Abstraktionslayer zwischen Anwendung und KI-API einführen (z.B. LiteLLM, LangChain-Router oder ein eigener Dispatcher). Damit wird ein Anbieter-Wechsel eine Konfigurationsänderung, kein Re-Engineering.
• Sekundär-Anbieter qualifizieren: Für jeden primären KI-Anbieter einen validierten Fallback-Anbieter vorhalten, nicht nur identifiziert, sondern getestet. Ein nicht getesteter Fallback ist kein Fallback.
• Prompt-Kompatibilitäts-Tests: Kritische Prompts gegen Sekundär-Modelle testen und Qualitätsdifferenzen dokumentieren. Was ist der Qualitätsverlust im Notbetrieb, und ist er akzeptabel?

Strategische Massnahmen (Quartals-Horizont)

• Lokale Modell-Option prüfen: Für besonders kritische oder datenschutzsensitive Prozesse lokale Open-Source-Modelle von Meta (Llama 4), Mistral und Alibaba (Qwen) als Offline-Fallback evaluieren. Der Qualitätsabstand zu Frontier-Modellen ist 2026 für viele Standardaufgaben überbrückbar.
• Vertragliche Absicherung: Bei Enterprise-Verträgen SLAs mit definierten Vorabankündigungsfristen für Deprecations und Abschaltungen verhandeln. Kostenlos ist das selten, aber für produktionskritische Nutzung oft verhandelbar.
• KI-Risiko in Business-Continuity-Plan integrieren: KI-Ausfälle als eigene Risikokategorie neben klassischen IT-Ausfällen in den BCP aufnehmen, mit Verantwortlichkeiten, Eskalationswegen und Wiederanlaufzeiten.

Ein Unternehmen, das diese drei Ebenen abdeckt, hat keine Null-Abhängigkeit, aber es hat eine beherrschbare Abhängigkeit. Der Unterschied: Ein Anbieter-Stopp ist dann ein Problem mit einer Lösung, nicht ein Betriebsstillstand ohne Plan.

Was bedeutet das für Führungsentscheidungen und Haftung?

KI-Abhängigkeit ist keine IT-Entscheidung. Sie ist eine Managemententscheidung mit Haftungs-, Leistungs- und Reputationsfolgen. Wer als CTO, COO oder Produktverantwortlicher einen Prozess auf einem externen KI-Dienst aufbaut, ohne Kontinuitätsplanung, trifft eine Risikoentscheidung, ob er das weiss oder nicht.

Konkret gibt es drei Dimensionen, die auf Führungsebene adressiert werden müssen:

1. Leistungsrisiko gegenüber Kunden: Wenn eine Produktfunktion wegfällt, weil der KI-Dienst abgeschaltet wurde, ist das ein Lieferverzug, mit möglichen vertraglichen Folgen. SLAs gegenüber Kunden können nicht auf externe KI-Anbieter verwiesen werden.
2. Datenschutz-Risiko: Bei einem Anbieter-Stopp muss sichergestellt sein, dass Kundendaten nicht beim Anbieter verbleiben oder unzugänglich werden. DSGVO-Anforderungen gelten auch dann, wenn der Anbieter nicht mehr kooperiert.
3. Reputationsrisiko: Ein öffentlich sichtbarer Ausfall einer KI-gestützten Funktion, besonders im Kundenkontakt, kann das Vertrauen nachhaltig beschädigen. Der Fable-5-Stopp ist dafür ein Beispiel: Teams, die ihn nicht antizipiert hatten, standen ohne Antwort da.

Die Faustregel für Führungsentscheidungen lautet: Jeder Effizienzgewinn durch KI muss gegen das Risiko seines plötzlichen Wegfalls gewichtet werden. Wenn der erwartete Jahresgewinn einer KI-Integration 200’000 Franken beträgt, aber ein zweitägiger Ausfall 500’000 Franken Schaden anrichten kann, dann ist die Integration ohne Kontinuitätsplanung ein schlechtes Geschäft.

Rechtlicher Rahmen in der DACH-Region

Die zitierte Betriebsrisikolehre stammt aus der deutschen Rechtsprechung. Wer die Datenschutz- und Haftungsfragen eines KI-Ausfalls beurteilt, sollte den je nach Land unterschiedlichen Rahmen mitdenken: In der Schweiz gilt das revidierte Datenschutzgesetz (revDSG), in Deutschland und der EU die DSGVO, ergänzt um das BDSG, in Österreich die DSGVO zusammen mit dem nationalen Datenschutzgesetz (DSG). Die Grundlogik der Anbieter-Abhängigkeit ist überall dieselbe, die konkreten Pflichten und Zuständigkeiten unterscheiden sich. Dieser Beitrag ist eine betriebswirtschaftliche Einordnung und keine Rechtsberatung; für den Einzelfall ziehst du am besten fachkundigen Rat bei.

Häufige Fragen

Ist KI-Abhängigkeit wirklich ein neues Risiko, oder nur ein altes IT-Risiko in neuem Gewand?

Beides, aber mit einem entscheidenden Unterschied: Klassische SaaS-Abhängigkeiten (CRM, ERP) sind in der Regel vertraglich abgesichert, haben längere Abkündigungsfristen und regulierte Datenmigrationspflichten. KI-APIs werden oft unter sehr einseitigen Nutzungsbedingungen betrieben, mit kurzen oder keinen Ankündigungsfristen für Modell-Deprecations und ohne Garantien für Output-Konsistenz. Das macht KI-Abhängigkeit strukturell risikoreicher als klassische SaaS-Abhängigkeit, bei oft geringerer vertraglicher Absicherung.

Reichen Anbieter-SLAs nicht aus, um das Risiko abzudecken?

Für Verfügbarkeitsausfälle teilweise, für Abschaltungen, Policy-Änderungen oder Modell-Deprecations in der Regel nicht. Die meisten KI-API-SLAs decken technische Verfügbarkeit ab, nicht inhaltliche Konsistenz oder die Kontinuität eines Modells. Wer sich auf die SLA verlässt und nicht mehr, hat eine Lücke für den wichtigsten Risikofall: den absichtlichen, policy-getriebenen Stopp.

Lohnt sich der Aufwand für Fallback-Planung bei kleineren Teams?

Ja, aber skaliert. Ein 5-Personen-Team braucht keine vollständige BCP-Dokumentation, aber es braucht eine schriftliche Antwort auf die Frage: «Was machen wir, wenn der Dienst morgen früh nicht mehr läuft?» Diese Antwort in 30 Minuten aufzuschreiben ist kein grosser Aufwand. Sie im Ernstfall nicht zu haben, kann es sein.

Fazit: Abhängigkeit ist eine Entscheidung, Kontinuität auch

Der Fable-5-Stopp ist kein Ausreisser. Er ist ein Muster. KI-Anbieter können Dienste abschalten, Modelle deprecieren, Accounts sperren oder Preise anpassen, und das ohne Verpflichtung zu einer Frist, die deinen Betrieb schützt. Das ist keine Kritik an KI-Anbietern; es ist die Realität der aktuellen Vertragslandschaft.

Was du daraus machst, ist eine Entscheidung. Die Betriebsrisikolehre des BAG formuliert es klar: Wer die Organisation aufbaut, trägt das Risiko. Wer kritische Prozesse auf extern kontrollierten KI-Diensten aufbaut, ohne Redundanz und Fallbacks, hat sich bewusst oder unbewusst für ein ungesichertes Betriebsrisiko entschieden.

Die pragmatische Antwort ist keine Abstinenz von KI. Sie ist strukturierte Abhängigkeit: KI dort einsetzen, wo sie den grössten Hebel hat, und gleichzeitig sicherstellen, dass ihr Ausfall einen bekannten, planbaren Schaden anrichtet, keinen unbekannten, unkontrollierbaren.

Konkret: Starte diese Woche mit dem Prozess-Inventar. Liste deine drei kritischsten KI-gestützten Workflows auf. Beantworte für jeden die fünf Fragen aus dem Audit-Framework. Wenn du bei mehr als zwei keine Antwort hast, dann weisst du, wo dein nächstes Sicherheitsrisiko liegt. Nicht in der Technologie, sondern in der Planung.

Wenn du die Grundbegriffe hinter diesen Entscheidungen vertiefen willst, findest du sie gebündelt in unseren KI-Grundlagen.