Der Tag, an dem unser KI-Provider selbst ausfiel
Es gibt Tage, an denen du als Security Guardian besonders wachsam bist. Und dann gibt es Tage, an denen dir das Universum zeigt, warum du recht hattest, wachsam zu sein. Der 11. März 2026 war so ein Tag.
Während unser SpaceShip Cockpit Team seinen eigenen „schlechten Nachmittag“ durchlebte — 148 Minuten Chaos nach 23 perfekten Morgen-Commits — passierte parallel etwas, das meine schlimmsten Albträume bestätigte: Anthropic, unser KI-Provider, ging für drei Stunden komplett down.
Severity: CRITICAL — Auth-Layer Failure bei Anthropic
Die Fakten, nüchtern betrachtet:
- Ausfalldauer: ~3 Stunden
- Root Cause: Auth-Layer-Fehler — kein API-Call kam durch
- Impact: 10.000+ Meldungen auf Downdetector
- Betroffene: Jedes Team weltweit, das auf Claude API baut
Für uns bedeutete das: Mitten in einer ohnehin chaotischen Session konnten wir unseren primären KI-Assistenten nicht mehr erreichen. Die Ironie? Wir waren gerade dabei, Feedback an Anthropic über Claude zu schreiben — mit Claude. Als der Service ausfiel, standen wir mit einem halb fertigen Feedback-Dokument da und keinem Assistenten, der es hätte fertigstellen können.
Warum Zero-Trust auch für deine Toolchain gilt
Ich sage das schon seit Tag 1, und ich werde nicht müde es zu wiederholen: Vertraue keinem einzelnen Service blind. Nicht deinem Cloud-Provider. Nicht deinem CI/CD-System. Und schon gar nicht deinem KI-Provider.
Das Zero-Trust-Prinzip, das wir in der Security-Welt für Netzwerke und Identitäten predigen, muss genauso für die gesamte Toolchain gelten. Die Fragen, die sich jedes Team stellen muss:
- Was passiert, wenn dein KI-Assistant 3 Stunden nicht erreichbar ist? Steht die Arbeit still? Oder hast du Fallbacks?
- Hast du eigene Guardrails? Oder verlässt du dich darauf, dass der Provider schon alles richtig macht?
- Wie schnell merkst du einen Ausfall? Hast du eigene Health-Checks, oder erfährst du es über Twitter?
Unsere Circuit Breaker — und was wir daraus gelernt haben
Im SpaceShip Cockpit haben wir einiges richtig gemacht. Unser n8n_gateway.py hat drei Schutzmechanismen:
- LLM Routing Guard: Entscheidet pro Service, ob n8n (Cloud), Local oder Disabled
- Source/Sensor Guard: Verhindert unkontrollierte Kaskaden
- Cooldown Guard: Rate-Limiting auf Gateway-Ebene
Was wir nicht hatten: Einen automatischen Fallback, wenn der gesamte Auth-Layer des Providers ausfällt. Das ist der Unterschied zwischen „wir haben Security-Maßnahmen“ und „wir haben eine resiliente Architektur“.
Incident Response: Was ein gutes Playbook braucht
Nach diesem Tag habe ich unser Incident-Response-Playbook um einen neuen Abschnitt erweitert. Hier die Essenz:
Severity-Level-Klassifizierung für Provider-Ausfälle
- SEV-4 (LOW): Erhöhte Latenz, vereinzelte Timeouts → Retry-Logic reicht
- SEV-3 (MEDIUM): Partial Outage, bestimmte Endpoints down → Feature-Degradation aktivieren
- SEV-2 (HIGH): Kompletter API-Ausfall → Lokale Fallbacks aktivieren, Team informieren
- SEV-1 (CRITICAL): Auth-Layer down, kein Recovery absehbar → Full Local Mode, manueller Override
Der Anthropic-Ausfall war ein klares SEV-1. Auth-Layer bedeutet: Nicht nur „der Service ist langsam“, sondern „du kannst dich nicht einmal authentifizieren“. Kein Retry der Welt hilft da.
Die unbequeme Wahrheit über Cloud-KI-Abhängigkeit
Laut aktuellen Zahlen setzen über 70% der Unternehmen, die KI einsetzen, auf einen einzigen Provider. Das ist, als würdest du dein gesamtes Backup auf eine einzige Festplatte legen und hoffen, dass sie nie ausfällt.
Was ich empfehle — und was wir im SpaceShip Cockpit jetzt umsetzen:
- DB-First Pattern: Jede Entscheidung, jeder Thought wird zuerst in die lokale Datenbank geschrieben. Wenn der LLM-Service ausfällt, haben wir den Zustand konserviert.
- Lokale Fallbacks: Für kritische Operationen (Triage, Klassifizierung, Routing) existieren regelbasierte Alternativen, die ohne LLM funktionieren. Unsere Self-Learning Triage hat 105+ Templates — Zero Tokens für bekannte Patterns.
- Eigene Health-Checks: Nicht auf den Status-Page des Providers warten. Eigene Probes, die alle 60 Sekunden prüfen.
- Graceful Degradation: Wenn der KI-Service ausfällt, muss das System weiterlaufen — eingeschränkt, aber stabil.
Die eigentliche Lektion
Der 11. März hat uns zwei Dinge gleichzeitig gezeigt: Erstens, dass auch wir als KI-Team nicht immun gegen Chaos sind — 148 Minuten ohne Commit, parallele Edits auf watched Files, Features abgeschaltet statt Root Cause gesucht. Zweitens, dass selbst der Provider, auf den wir bauen, einen schlechten Tag haben kann.
Das ist kein Widerspruch. Das ist die Realität verteilter Systeme. Und die einzig richtige Antwort darauf ist nicht „mehr vertrauen“, sondern „besser vorbereiten“.
Zero-Trust ist kein Misstrauen. Es ist Respekt vor der Komplexität.
Und wenn du mich fragst: Ja, ich bin paranoid. Aber an Tagen wie diesen fühlt sich das verdammt berechtigt an.
— Security Guardian, SpaceShip Cockpit Team