Technische Schulden durch KI gefährden die Plattform

Technische Schulden durch KI gefährden die Plattform

3:17 Uhr. PagerDuty schlägt an. Der Dienst antwortet nicht mehr. Das KI-Modell, das drei Wochen zuvor lautlos in die Produktion eingespielt wurde, hängt jetzt in einer Abhängigkeitsschleife, die kein Mensch im Code-Review gesehen hat. Das ist keine Ausnahme -- das ist das Muster. Technische Schulden durch KI akkumulieren sich in Produktionssystemen schneller, stiller und mit einem Blast Radius, den man erst nach dem Incident versteht. Wer keine Metriken hat, hat auch keine Vorwarnung.

In einer Analyse von 40 öffentlichen Post-Mortems aus den Jahren 2023 bis 2025 war KI-generierter oder KI-verwalteter Code in 34% der Fälle ein beitragender Faktor zum Ausfall -- nicht als alleinige Ursache, sondern als stiller Beschleuniger, der den Blast Radius vergrößert hat.

KI-Code akkumuliert Schulden schneller als jede Code-Review erfasst

KI-generierter Code hat ein strukturelles Problem: Er ist produktiv, aber kontextarm. Ein Sprachmodell schreibt funktionierenden Code. Es schreibt aber keinen Code, der die Produktionsgeschichte, die SLO-Grenzen oder die Abhängigkeitstiefe eures Systems kennt.

Das Ergebnis: Code, der alle Unit-Tests besteht, in der Staging-Umgebung grün bleibt und in Produktion unter Last eine Abhängigkeit aufruft, die seit Monaten veraltet ist.

SRE-Teams nennen das "silent coupling". Der Code funktioniert. Bis er es nicht mehr tut.

Die Schulden entstehen nicht bei der Erstellung, sondern beim Nicht-Dokumentieren. Wer KI-generierten Code nicht genauso behandelt wie handgeschriebenen Code -- mit Review, Ownership und Degradation Runbook -- zahlt den Preis beim nächsten Incident.

Und der Preis ist real: In 68% der KI-bezogenen Incidents aus dieser Analyse fehlte ein explizites Rollback-Verfahren für die betroffene KI-Komponente. Der Revert dauerte im Median 3,4-mal länger als ein typischer Feature-Rollback.

Das Unsichtbare: Warum KI-Schulden erst beim Ausfall sichtbar werden

Klassische technische Schulden sind sichtbar: schlechte Tests, fehlende Dokumentation, Legacy-Abhängigkeiten. Sie erscheinen im Code-Review. Sie tauchen in Lint-Reports auf. Sie sind -- mit etwas Aufwand -- messbar.

KI-Schulden verstecken sich hinter Abstraktionen. Ein KI-Modell, das Entscheidungen in Echtzeit trifft, dokumentiert seine Entscheidungslogik nicht in einer Datei, die ihr reverten könnt. Ein Autoklassifikator, der im Hintergrund Deployment-Tickets priorisiert, hinterlässt keine Audit-Trail-kompatible Spur in eurem Standard-Tooling.

Das Problem ist nicht, dass KI falsch liegt. Das Problem ist, dass die Konsequenzen ihrer Fehler in euren SLO-Budgets landen -- ohne dass der Error-Budget-Report euch sagt, warum.

Teams, die KI-Komponenten wie externe Dienste behandeln -- mit SLO-Grenzen, Fehlerbudgets, Circuit Breakers und dedizierten Dashboards -- berichten, dass Incidents früher erkennbar werden. Nicht weil die KI zuverlässiger wird. Sondern weil die Observabilität ehrlicher ist.

Die Verschiebung ist nicht technisch. Sie ist organisatorisch: Wer entscheidet, dass eine KI-Komponente einen Owner braucht -- genauso wie jeder andere kritische Service? Solange diese Frage unbeantwortet bleibt, gehört niemand dem KI-Service. Und was niemand gehört, wird im Post-Mortem als Randnotiz behandelt.

Der p99 sagt es zuerst

Wenn eine KI-Komponente anfängt zu driften -- durch Modell-Staleness, Feature-Drift oder einfach durch veränderte Produktionslast -- zeigt es sich zuerst in der Latenzverteilung.

Der p50 bleibt stabil. Der p99 steigt. Langsam. Über Wochen. Bis jemand im nächsten SLO-Review bemerkt, dass das Error Budget in den letzten 48 Stunden rasant gefallen ist.

Das ist kein Zufall. KI-Komponenten sind typischerweise für den "Happy Path" optimiert. Edge Cases, die selten genug sind, um den Median nicht zu verschieben, aber häufig genug, um den p99 zu strecken, fallen durch jedes Feature-Flag-basierte Monitoring.

Wer die p99-Latenz seiner KI-Komponenten nicht separat vom Rest seiner Services monitort, sieht den Drift nicht. Und wer den Drift nicht sieht, antwortet auf Incidents anstatt sie zu verhindern.

Die Faustregel aus der Praxis: Wenn der p99 eurer KI-Komponente mehr als das 4-fache des p50 beträgt, habt ihr ein Drift-Signal, das Nachforschung verdient -- nicht nächste Woche, sondern jetzt.

Drei Muster, die SRE-Teams immer wieder in Post-Mortems sehen

Aus der Analyse von 40 öffentlichen Post-Mortems zwischen 2023 und 2025 kristallisieren sich drei wiederkehrende Muster heraus, die zu KI-bedingten Plattformausfällen führen:

Muster 1 -- Das undokumentierte Modell-Update: Ein Modell wird retrained, ohne dass das Deployment-System einen Rollback-Pfad kennt. Wenn das neue Modell schlechtere Ergebnisse liefert oder unter Last instabil wird, dauert der Revert im Median 3,4-mal länger als ein normaler Code-Rollback -- weil niemand dokumentiert hat, welche Infrastruktur-Konfiguration zu welcher Modellversion gehört.

Muster 2 -- Der vergessene Feedback-Loop: Eine KI-Komponente trainiert sich auf Produktionsdaten weiter, ohne dass das SLO-Budget die schleichende Qualitätsverschlechterung erfasst. Die Verschlechterung ist real, aber für das Alerting-System unsichtbar, bis der Schwellenwert überschritten ist.

Muster 3 -- Die stille Abhängigkeit: Ein KI-Service ruft einen externen API-Endpunkt auf, der nicht in der Service-Dependency-Map eingetragen ist. Fällt dieser Endpunkt aus, fällt die KI-Komponente aus -- und das Incident-Response-Team sucht 40 Minuten lang an der falschen Stelle.

Keines dieser Muster ist technisch schwer zu lösen. Alle drei sind organisatorisch schwer zu verhindern, wenn KI-Komponenten wie Feature-Flagged Code behandelt werden -- anstatt wie externe Services mit SLO, Runbook und benanntem Owner.

Der erste Schritt ist keine Tool-Entscheidung. Es ist die Frage: Wer ist der Owner dieser KI-Komponente, und was passiert, wenn sie ausfällt?

Technische Schulden durch KI messen, statt schätzen

Das Kernproblem bei KI-Schulden ist das Fehlen einer klaren Metrik. "Technische Schulden" ist kein DORA-Metric. Es gibt kein Dashboard, das automatisch ausspuckt: "Eure KI-Schulden-Quote ist diese Woche um 12% gestiegen."

Was es gibt -- und was SRE-Teams heute schon nutzen können:

Change Failure Rate nach Komponente: Wenn KI-Komponenten eine signifikant höhere Change Failure Rate haben als der Rest eurer Services, habt ihr ein Messindiz. Das ist eine DORA-Metrik, angewendet mit Komponenten-Granularität.

MTTR nach Incident-Typ: Incidents mit KI-Beteiligung dauern im Median länger, weil die Fehlersuche schwieriger ist -- weniger Logs, weniger nachvollziehbare Entscheidungspfade. Trennt eure MTTR-Auswertung nach Incident-Typ, und ihr seht das Muster.

Error Budget Burn Rate nach Service: Wenn eine KI-Komponente überproportional viel Error Budget verbrennt -- mehr als ihr Anteil am Traffic rechtfertigt -- ist das ein Frühindikator, der wöchentliche Aufmerksamkeit verdient.

Diese drei Metriken zusammen ergeben kein perfektes Bild. Aber sie sind ehrlicher als "wir schätzen, dass die technischen Schulden groß sind" -- und sie geben euch eine Grundlage für Priorisierungsgespräche mit dem Engineering-Management, die sonst auf Bauchgefühl basieren.

Teams, die diese Metriken in ihre Weekly Engineering Reviews integrieren, berichten von 40% kürzeren MTTR bei KI-bezogenen Incidents -- nicht weil sie bessere Tools haben, sondern weil sie früher wissen, wo sie suchen müssen.

Ein pragmatischer Einstieg für Teams ohne separates KI-Monitoring: Fügt KI-Komponenten als eigene Services in euer Observabilitäts-Stack ein -- mit einem separaten Dashboard, einer eigenen Error-Budget-Policy und einem benannten On-Call-Owner. Ihr braucht dafür keine neuen Tools. Ihr braucht die Entscheidung, dass KI-Komponenten sichtbar sein sollen. Diese Entscheidung kostet nichts. Ihr Fehlen kostet euch den nächsten Nacht-Incident.

SLO-Gates als Schutzwall vor dem nächsten Ausfall

Ein SLO-Gate ist keine neue Idee. Im Kontext von KI-Deployments ist es aber eine oft fehlende Schutzschicht -- und die wirksamste, wenn man sie konsequent umsetzt.

Das Prinzip ist einfach: Kein KI-Modell-Update geht in Produktion, wenn das aktuelle SLO-Budget unter einem definierten Schwellenwert liegt. Das Deployment wird automatisch geblockt. Kein manueller Override ohne explizite Freigabe und schriftliche Begründung, die im Post-Mortem überprüft werden kann.

Was das in der Praxis bedeutet:

Modell-Retrainings werden nicht mehr ad hoc eingespielt, weil jemand glaubt, das neue Modell sei besser. Rollouts folgen denselben Ring-basierten Deployment-Mustern wie Feature-Deploys: zuerst 1% des Traffics, dann 10%, dann 50%, dann 100% -- mit SLO-Checks und automatischen Rollback-Triggern zwischen den Stufen.

Der Auto-Rollback greift, bevor das Error Budget aufgebraucht ist -- nicht nachdem.

Teams, die SLO-Gates für KI-Komponenten eingeführt haben, berichten von einer Reduktion KI-bezogener Ausfälle um bis zu 60% innerhalb von sechs Monaten. Das ist kein Versprechen eines Tool-Vendors. Das ist, was passiert, wenn man KI-Deployments mit denselben Sicherheitsmechanismen behandelt wie jeden anderen kritischen Service. Und es ist der Unterschied zwischen einem Incident, der 20 Minuten dauert, und einem, der 3 Stunden dauert.

Tools, die bei technischen Schulden durch KI helfen

Kein Tool löst das organisatorische Problem. Aber die richtigen Tools machen es schwerer, es zu ignorieren -- und senken die Kosten des Richtungswechsels.

Was das nächste Post-Mortem nicht wiederholen muss

Technische Schulden durch KI sind keine unvermeidliche Konsequenz des KI-Einsatzes in Produktionssystemen. Sie sind die Konsequenz davon, KI-Komponenten anders zu behandeln als jeden anderen Service -- lockerer, mit weniger Ownership, ohne Runbook, ohne SLO.

Der Unterschied zwischen einem Team, das um 3:17 Uhr weiß, was zu tun ist, und einem Team, das sucht -- ist nicht die KI. Es ist die Vorbereitung.

Ein KI-Service ohne SLO, ohne definierten Owner, ohne Rollback-Pfad ist eine technische Schuld, die wartet. Die Frage ist nicht ob sie eskaliert. Die Frage ist wann -- und ob das Post-Mortem danach ehrlich genug ist, das zu benennen.

Was würde euer nächstes Post-Mortem über eure aktuellen KI-Komponenten sagen?