Wenn KI-gestützter Code einen Incident im Produktivbetrieb auslöst, ist die Reaktion nichts Besonderes. Die Vorbereitung schon.
Ein ausfallender Bezahlvorgang verhält sich nicht anders, nur weil ein Modell die Regression geschrieben hat. Ihr Bereitschaftsteam wird alarmiert, priorisiert, begrenzt den Schaden und stellt den Betrieb wieder her, wie immer. Was sich ändert, ist das Gespräch danach. Und die leisen Fragen, die schon mitten im Vorfall aufkommen: Hat diesen Code überhaupt jemand verstanden? Wer ist dafür verantwortlich? Und würden wir bei einem Blick darauf überhaupt erkennen, dass er mit KI entstanden ist?
Wir arbeiten mit Entwicklungsteams in Hamburg und der weiteren EU, die KI-Tools schneller eingeführt haben, als sie ihre Incident-Praxis nachgezogen haben. Das Ergebnis ist eine absehbare Lücke: Das Tool ist weiter, die Disziplin in der Reaktion nicht. Dieser Artikel schließt sie.
Kernaussagen
- Ein Incident ist ein Incident: erkennen, priorisieren, eindämmen, wiederherstellen, lernen, ganz gleich, wer oder was den Code geschrieben hat.
- KI-generierter Code verkompliziert genau zwei Dinge: Verständnislücken und unklare Verantwortung. Beide löst man vor dem Merge, nicht während des Vorfalls.
- Machen Sie KI-Beteiligung erkennbar: über eine Konvention im Pull Request, über Review-Notizen und über ein Audit-Protokoll der Agenten. So kann das Postmortem Muster aufdecken.
- Prävention liegt weiter vorne: Review, das Verständnis voraussetzt, Leitplanken für Agenten, klare Verantwortung beim Merge und dieselbe Messlatte für KI-Ausgaben wie für alles andere.
Worauf es zuerst ankommt: Der Incident ist der Incident
Ein häufiger Fehler ist, einen KI-verursachten Incident zum Grundsatzurteil über KI zu machen. Das ist er nicht. Während des Vorfalls spielt es so gut wie keine Rolle, woher der Code stammt. Ihre Aufgabe ist dieselbe wie immer: den Dienst wiederherstellen, Kundschaft und Daten schützen, ehrlich kommunizieren.
Das gewohnte Muster der Reaktion bleibt unverändert.
| Phase | Welche Frage sie beantwortet | Was sich bei KI-Code nicht ändert |
|---|---|---|
| Erkennen | Stimmt etwas nicht, und wie schlimm? | Alarme und SLOs schlagen genauso an |
| Triage | Wie groß sind Auswirkung und Schweregrad? | Gemessen wird an der Wirkung, nicht an der Urheberschaft |
| Eindämmen | Wie stoppen wir den Schaden jetzt? | Rollback, Feature-Flag aus, Failover |
| Wiederherstellen | Wie kehren wir sicher zum Normalbetrieb zurück? | Prüfen, beobachten, bestätigen |
| Lernen | Warum ist das passiert, und was verhindert eine Wiederholung? | Hier wird die KI-Herkunft endlich relevant |
Erst in der letzten Phase wird die Herkunft des Codes zu einer erstrangigen Frage. Sie mitten im Vorfall ausfechten zu wollen, bremst die Reaktion und hilft niemandem.
Wo KI-generierter Code die Reaktion tatsächlich erschwert
Das Muster der Reaktion bleibt gleich. Trotzdem tauchen zwei echte Reibungspunkte auf, und sich auf sie vorzubereiten ist der eigentliche Punkt.
Verständnislücken. Wenn ein Mensch Code schreibt, hat ihn zum Zeitpunkt des Schreibens mindestens eine Person verstanden. Bei stark KI-gestütztem Code ist das nicht mehr garantiert. Hat die Autorin eine große Änderung schnell übernommen, sieht die Person, die sie nun unter Druck debuggt, sie womöglich zum ersten Mal. Die Gegenmaßnahme setzt früher an: eine Review-Disziplin, die sicherstellt, dass ein Mensch die Änderung vor dem Merge verstanden hat. Die Incident Response steht am Ende dieser Kette, nicht am Anfang. Sie kann nur so gut sein wie die Qualität des Reviews davor.
Unklare Verantwortung. Code, der von einem Agenten oder einem schnellen „Alles annehmen“-Workflow stammt, kann ohne klaren Verantwortlichen im Repository landen. Um 3 Uhr nachts kommt diese Unklarheit teuer zu stehen. Die Lösung: sicherstellen, dass jede Änderung, egal, wie sie entstanden ist, beim Merge ein zuständiges Team zugewiesen bekommt.
Beide Probleme löst man vor dem Vorfall, nicht währenddessen. Das ist der rote Faden: Die Vorbereitung auf Incidents mit KI-Code ist im Kern Review- und Verantwortungsdisziplin, die man vorab leistet.
KI-Beteiligung sichtbar machen
Aus dem, was Sie nicht sehen, können Sie nicht lernen. Wenn Ihr Postmortem nicht feststellen kann, ob KI-Unterstützung im Spiel war, wird Ihre Prävention zum Ratespiel.
Wir empfehlen nicht, jede von KI berührte Zeile zu kennzeichnen. Das ist unpraktisch und erzeugt nur Rauschen. Wir empfehlen ein leichteres Signal, das bis ins Review erhalten bleibt:
- eine Konvention im Pull Request, die nennenswerte KI-Unterstützung festhält
- Review-Notizen, die festhalten, was der Mensch geprüft hat, nicht nur, dass er zugestimmt hat
- bei Agenten ein Audit-Protokoll darüber, was geändert wurde und auf wessen Anweisung
Es geht nicht um Schuldzuweisung, sondern um Signal. Wenn sich eine Häufung von Incidents auf ein bestimmtes Tool, einen Workflow oder die Gewohnheit zurückführen lässt, Änderungen ohne Verständnis durchzuwinken, wollen Sie das klar genug erkennen, um zu handeln.
Das Postmortem, angepasst für KI
Ein Postmortem ohne Schuldzuweisung fragt ohnehin, wie das System (nicht die einzelne Person) den Fehler zugelassen hat. Bei KI-gestützten Incidents kommt eine kurze, gezielte Fragenreihe hinzu.
| Frage | Was sie offenlegt |
|---|---|
| War KI-Unterstützung bei der fehlgeschlagenen Änderung wesentlich? | Ob hier überhaupt ein KI-typisches Muster vorliegt |
| Hat ein Mensch die Änderung vor dem Ausliefern verstanden? | Eine Lücke in der Review-Qualität, kein Modellproblem |
| Bewegte sich die Änderung im freigegebenen Workflow und Rahmen? | Eine Lücke in der Steuerung, falls nicht |
| Hätte unser Review das bei von Hand geschriebenem Code erwischt? | Ob die Messlatte für KI-Ausgaben gesunken ist |
| War vor dem Vorfall jemand für die Änderung zuständig? | Eine Verantwortungslücke, die zu schließen ist |
Beachten Sie: Die meisten dieser Fragen führen auf Ihre eigenen Kontrollen zurück, nicht auf das Modell. Das ist Absicht. Das Modell ist nur ein Tool. Die Kontrollen liegen bei Ihnen.
Prävention gehört nach vorne, nicht ins Runbook
Die deutlichste Lehre aus wiederholten KI-gestützten Incidents lautet: Die Lösung steckt fast nie im Ablauf der Reaktion. Sie steckt vor dem Merge.
- Review, das Verständnis voraussetzt. Eine Freigabe sollte heißen, dass ein Mensch die Änderung erklären kann, nicht, dass er einen großen Diff überflogen und auf „Freigeben“ geklickt hat.
- Rahmen und Leitplanken für Agenten. Autonome Änderungen brauchen eine klar gezogene Grenze und einen menschlichen Kontrollpunkt dort, wo sich Risiko bündelt, damit unbeaufsichtigter Code nicht ungeprüft in die Produktion gelangt.
- Verantwortung beim Merge. Jede Änderung bekommt ein namentlich benanntes, zuständiges Team, unabhängig davon, wie sie entstanden ist.
- Dieselbe Messlatte für KI-Ausgaben. Der Review-Standard für KI-gestützten Code ist der Standard für jeden Code. Ihn zu senken, weil das Modell so selbstsicher wirkt, ist genau der Weg, auf dem überzeugend aussehende Fehler in die Produktion gelangen.
Bekommen Sie das hin, schrumpft der KI-spezifische Anteil Ihrer Incidents auf fast null, weil die gefährlichen Änderungen erst gar nicht ausgeliefert werden.
Eine Checkliste für die Einsatzbereitschaft
Wenn wir eine Entwicklungsorganisation darauf vorbereiten würden, KI-gestützte Incidents gut zu bewältigen, hätten wir das hier vor dem nächsten Vorfall gern bereit.
| Kontrolle | Konkrete Ausprägung |
|---|---|
| Standard-Incident-Prozess | Erkennen, Triage, Eindämmen, Wiederherstellen, Lernen, für jeden Code |
| Funktionierender Rollback | Getestet, schnell, unabhängig von der Urheberschaft des Codes |
| Signal für KI-Unterstützung | Eine leichte Konvention, die bis in Review und Audit erhalten bleibt |
| Review auf Verständnis | Freigabe heißt: Ein Mensch hat die Änderung verstanden |
| Verantwortung beim Merge | Jede Änderung hat ein namentlich benanntes, zuständiges Team |
| Postmortem ohne Schuldzuweisung, mit KI-Frage | Fragen nach dem Vorfall, die KI-Muster sichtbar machen |
Sie ist bewusst kurz gehalten. Die Vorbereitung auf KI-Code ist keine neue Disziplin, die man obendrauf setzt. Sie ist Ihre bestehende Disziplin, erweitert um einen neuen Weg, auf dem Code bei Ihnen ankommt.
Unsere Sicht
KI ändert nicht, was ein Incident ist. Sie ändert, wie leicht Code in die Produktion gelangen kann, ohne dass ihn jemand verstanden oder verantwortet hat. Teams, die KI-gestützte Incidents gut bewältigen, sind nicht die mit einem speziellen KI-Runbook. Es sind die, deren Review und Verantwortung stark genug waren, dass der Vorfall selten blieb, nachvollziehbar war und sich schnell auswerten ließ.
Behandeln Sie den Incident als Incident. Behandeln Sie die Prävention als eine Frage von Review und Verantwortung. Und machen Sie KI-Beteiligung sichtbar genug, dass Ihnen das Postmortem die Wahrheit erzählen kann.
Quellen
- Google / DORA,
Accelerate State of DevOps, Forschung zu Change-Failure-Rate und Wiederherstellung, abgerufen am 2026-06-10 - NIST,
AI Risk Management Framework (AI RMF 1.0), abgerufen am 2026-06-10 - EUR-Lex, Verordnung (EU) 2024/1689 (EU AI Act), Artikel 14 zur menschlichen Aufsicht, abgerufen am 2026-06-10
Häufige Fragen
- Braucht KI-generierter Code einen anderen Incident-Response-Prozess?
- Nein. Die Form der Reaktion ist dieselbe: erkennen, triagieren, mitigieren, wiederherstellen, lernen. Während des Vorfalls ist der Ursprung des Codes nahezu irrelevant – Sie stellen den Dienst wieder her, schützen Kundinnen und Daten und kommunizieren ehrlich. Die Urheberschaft wird erst in der Lernphase danach zu einer erstrangigen Frage.
- Warum erschwert KI-generierter Code die Incident Response?
- Auf zweierlei Weise. Verständnislücken: Bei stark KI-gestütztem Code liest die Person, die unter Druck debuggt, ihn vielleicht zum ersten Mal, falls ihn beim Merge niemand verstanden hat. Verantwortungslücken: Agenten- oder Alles-Annehmen-Änderungen können ohne klaren Verantwortlichen landen. Beides wird vorgelagert durch Review- und Verantwortungsdisziplin gelöst, nicht während des Vorfalls.
- Wie stellt man fest, ob KI-Unterstützung einen Vorfall verursacht hat?
- Machen Sie KI-Beteiligung sichtbar, ohne jede Zeile zu markieren. Nutzen Sie eine Pull-Request-Konvention, die nennenswerte KI-Unterstützung festhält, Review-Notizen, die festhalten, was ein Mensch geprüft hat, und für Agenten ein Prüfprotokoll, das festhält, was geändert wurde und auf wessen Anweisung. Ziel ist ein Signal für die Prävention, nicht Schuld.
- Wie verhindert man Vorfälle durch KI-generierten Code?
- Prävention liegt vor dem Merge, nicht im Notfallhandbuch: Review, das verlangt, dass ein Mensch die Änderung versteht, definierter Geltungsbereich und Freigaben für Agenten, beim Merge zugewiesene Verantwortung und dieselbe Review-Messlatte für KI-Ausgabe wie für jeden Code. Die Latte zu senken, weil das Modell selbstsicher wirkt, ist der Weg, auf dem überzeugend wirkende Defekte in die Produktion gelangen.
