Netzwerk-Incident-Report automatisieren

Das echte Ausmaß des Problems

Post-Mortem-Berichte nach Netzwerkausfällen gelten in der Branche seit Jahrzehnten als Best Practice. Tatsächlich sind sie oft ein Engpass: Das NOC-Team, das gerade einen mehrstündigen Ausfall gemeistert hat, soll im Anschluss — oft in der Nacht oder am frühen Morgen — denselben Vorfall schriftlich rekonstruieren.

Die Herausforderung ist nicht Fachwissen. Die Herausforderung ist Datenaggregation und Formatierung: Alarmdaten liegen im Monitoring-System, Ticket-Zeitstempel in ServiceNow oder Jira, Kommunikationsverläufe in Slack oder Teams, Change-Einträge im CMDB, Kundenmeldungen im CRM. Ein vollständiger Post-Mortem-Bericht verlangt, alle diese Quellen chronologisch zusammenzuführen und in das interne Dokumentationsformat zu übersetzen.

Laut einer Analyse von incident.io aus dem Jahr 2025 kostet allein die „Documentation Archaeology” — das Rekonstruieren des Incident-Verlaufs aus verteilten Quellen — im Median 75 Minuten pro Incident. Der eigentliche Schreibaufwand kommt oben drauf. Für Major Incidents mit mehreren beteiligten Teams und Systemen berichten NOC-Leads regelmäßig von vier bis acht Stunden Gesamtaufwand pro Bericht.

Für einen Kabelnetzbetreiber mit 20–30 dokumentationspflichtigen Incidents pro Jahr summiert das zu 80–240 Ingenieurstunden, die ein Netzwerkexperte mit Senior-Stundensatz nicht mit Netzwerkbetrieb, sondern mit Textproduktion verbringt.

Hinzu kommt ein Qualitätsproblem: Je länger der Abstand zwischen Incident und Bericht, desto lückenhafter die Erinnerungen. Details zu Alarmen, die innerhalb von Minuten quittiert und vergessen wurden, gehen verloren. Hypothesen, die während des Incidents verworfen wurden, landen manchmal doch im Bericht, weil niemand mehr genau weiß, was letztlich zutraf. Und wenn dasselbe NOC-Team vier Wochen später denselben Fehlertyp sieht, ist das Wissen aus dem vorherigen Post-Mortem kaum abrufbar — weil es in einem Word-Dokument im SharePoint liegt, das niemand gesucht hat.

Mit vs. ohne KI — ein ehrlicher Vergleich

Zeitwerte basieren auf Erfahrungsberichten und der Analyse von incident.io (2025). Individuelle Ergebnisse hängen stark von der Qualität der verfügbaren Rohdaten ab.

Einschätzung auf einen Blick

Zeitersparnis — sehr hoch (5/5) Post-Mortem-Berichte sind im Kern strukturierte Textproduktion — genau das, was ein LLM besser und schneller kann als ein Mensch unter Zeitdruck nach einem nächtlichen Ausfall. Der Sprung von fünf bis sieben Stunden manueller Arbeit auf dreißig bis sechzig Minuten Überarbeitung eines KI-Entwurfs ist der stärkste Zeitersparnis-Hebel in dieser Kategorie. Höhere Zeitersparnis hat in dieser Branche kaum ein anderer Anwendungsfall.

Kosteneinsparung — mittel (3/5) Die Einsparung ist real, aber zweistufig: direkte Ingenieurstunden (quantifizierbar) und indirekte Effekte wie schnellere Kundenkommunikation nach einem Ausfall, die SLA-Strafzahlungen reduzieren kann. Letztere ist schwer zu isolieren — Vertragsklauseln, Eskalationswege und Kulanzentscheidungen spielen immer mit. Im direkten Vergleich mit Anwendungsfällen wie der Rechnungsreklamation oder dem SLA-Tracking ist der Kostenhebel hier moderat.

Schnelle Umsetzung — mittel (3/5) Der erste funktionierende Prototyp — Alarmlog in eine Textdatei kopieren, in ChatGPT einfügen, Prompt für Post-Mortem-Format ausführen — ist an einem Nachmittag machbar. Die produktive Integration mit Alarmmanagementsystemen, Ticketing-APIs und automatischer Berichtsformatierung dauert jedoch realistisch acht bis zwölf Wochen. Kein Sprintstart, aber kein mehrjähriges Projekt. Einstieg vergleichbar mit dem Kundenzufriedenheits-Monitoring.

ROI-Sicherheit — mittel (3/5) Die Zeitersparnis ist messbar: vor der Einführung die durchschnittliche Post-Mortem-Zeit erfassen, danach vergleichen. Der Qualitätseffekt — vollständigere Berichte, bessere Muster-Erkennung — ist real, aber schwer in Euro zu fassen. Teams, die diesen Schritt überspringen und keinen Vorher-Nachher-Vergleich einplanen, können den ROI im Nachhinein nicht belegen.

Skalierbarkeit — mittel (3/5) Das System skaliert mit der Incident-Häufigkeit, nicht mit dem Unternehmenswachstum. Ein ISP, der von tausend auf fünftausend Kunden wächst, profitiert nicht automatisch mehr — erst wenn auch die Incident-Anzahl steigt. Für NOC-Teams mit hoher Incident-Frequenz (>50 pro Jahr) ist die Skalierbarkeit sehr gut; für stabile Netze mit wenigen Ausfällen bleibt der Nutzen absolut moderat.

Richtwerte — stark abhängig von Incident-Häufigkeit, Qualität der verfügbaren Rohdaten und Integrationstiefe mit bestehenden Systemen.

Was der KI-Assistent konkret macht

Der technische Ansatz ist einfacher als er klingt: Ein Prompt beschreibt das gewünschte Berichtsformat — Titel, Zusammenfassung, Zeitleiste, Ursachenanalyse (RCA), Auswirkungen, Korrekturmaßnahmen, präventive Schritte. Die Rohdaten werden als Input mitgeliefert: exportierte Alarmlogs, Ticket-Kommentare, Change-Management-Einträge, optionale Slack-Transkripte. Das LLM produziert daraus einen strukturierten Entwurf.

Was das System tut:

• Zeitleiste rekonstruieren: Aus einem Alarm-Export mit hundert Einträgen wird eine chronologische Erzählung mit den kritischen Ereignispunkten
• Korrelationen erkennen: „Alarm X trat auf, 3 Minuten später eskalierte Alarm Y, 12 Minuten nach der ersten Meldung kamen Kundenbeschwerden” — das schreibt das System aus den Rohdaten
• Berichtsformat anwenden: Jeder Bericht folgt denselben Abschnitten, derselben Sprache, demselben Detailgrad — unabhängig davon, wer die Übernacht-Schicht hatte
• Vorläufige Ursachenanalyse formulieren: Basierend auf den Change-Management-Einträgen und dem zeitlichen Zusammenhang schlägt das System eine Ursachenhypothese vor — zur menschlichen Prüfung, nicht als Tatsache

Was das System nicht tut: Es bewertet nicht eigenständig, ob die Ursache stimmt. Es unterschreibt keine Berichte. Es entscheidet nicht, ob ein Incident meldepflichtig ist. Diese Verantwortung bleibt beim zuständigen Ingenieur.

Der Ablauf in der Praxis

1. Incident wird im Ticketing-System geschlossen
2. KI-Assistent erhält (manuell oder automatisch via API) die Rohdaten: Alarm-Export, Ticket-Zeitstempel, Change-Log-Auszug
3. LLM generiert Post-Mortem-Entwurf nach vorgegebenem Template in drei bis fünf Minuten
4. Zuständiger Ingenieur prüft den Entwurf, korrigiert fehlerhafte Kausalketten, ergänzt nicht dokumentierte Handlungen, bestätigt die Ursache
5. Bericht wird freigegeben und archiviert

Der Überarbeitungsaufwand liegt typisch bei dreißig bis sechzig Minuten — gegen vier bis acht Stunden vorher.

Datenquellen und Integration — was das System wirklich braucht

Das ist der Teil, über den Anbieter-Demos meistens hinweggehen: Der LLM-Assistent ist der einfache Teil. Die Arbeit liegt in den Datenquellen.

Für einen vollständigen Post-Mortem-Bericht braucht der Assistent Zugriff auf:

Alarmdaten aus dem Network Management System (NMS) Zeitgestempelte Alarme mit Schweregrad, betroffenen Geräten und Alarm-IDs. In den meisten Telekommunikationsumgebungen gibt es dafür SNMP-Traps, Syslog-Streams oder proprietäre NMS-Exporte (Netcracker, Comarch, NetCracker, Nokia NetAct, ZTE ZXOPS). Viele dieser Systeme bieten CSV- oder API-Export — wenn nicht, müssen Logs manuell vorbereitet werden.

Incident-Ticket-Historie aus dem ITSM-System Zeitgestempelte Kommentare, Status-Änderungen, Eskalationen aus ServiceNow, Jira oder dem hauseigenen System. Die meisten ITSM-Systeme haben REST-APIs für strukturierten Export.

Change-Management-Einträge Welche Konfigurationsänderungen wurden in den 24 Stunden vor dem Incident durchgeführt? Change-Management-Daten sind oft der Schlüssel zur Ursachenanalyse und werden von ITSM-Systemen mitgeführt.

Optionale Quellen Slack- oder Teams-Transcript aus dem Incident-Channel, Kundenmeldungszeitpunkte aus dem CRM, Messungen von Network-Performance-Monitoring-Tools.

In der Praxis gibt es drei Integrationsszenarien:

• Manuell (Pilot, 0–2 Wochen): Ingenieur exportiert Daten, fügt sie in ein Chat-Interface ein, erhält den Entwurf. Kein Technologieprojekt, aber manueller Aufwand bleibt.
• Halbautomatisch (3–8 Wochen): Ein Skript oder ein No-Code-Tool (z. B. n8n) aggregiert automatisch Daten aus ITSM-API und NMS-Export, übergibt sie an die LLM-API, gibt den Entwurf zurück.
• Vollautomatisch (8–16 Wochen): Integration in das Incident-Management-Workflow — sobald ein Incident den Status „gelöst” erreicht, startet die Berichtsgenerierung automatisch.

Akkuratheit als Pflicht — was bei falschen Berichten auf dem Spiel steht

Post-Mortem-Berichte in Telekommunikationsnetzen sind keine internen Notizen. Sie sind Grundlage für:

• SLA-Gutschriften und Vertragsdiskussionen mit Unternehmenskunden
• Meldungen an die Bundesnetzagentur nach §§ 168 ff. TKG für signifikante Ausfälle
• Interne Eskalationen, bei denen falsche Ursachenzuschreibung zu falschen Investitionsentscheidungen führt
• Beweisdokumente in Schadensersatzstreitigkeiten

Ein LLM, das halluziniert oder Kausalzusammenhänge auf Basis oberflächlicher Textmuster konstruiert, ist in diesem Kontext kein Komfortproblem — es ist ein Haftungsrisiko.

Zalando hat in seinem Engineering Blog (September 2025) nach zwei Jahren KI-gestützter Post-Mortem-Analyse ehrlich berichtet: Auch mit fortgeschrittenen Modellen wie Claude Sonnet 4 traten noch circa 10 % Attributionsfehler auf — das Modell verknüpfte Technologien mit Incidents aufgrund von Erwähnungen im Text, nicht aufgrund tatsächlicher Kausalität. Frühere Modelle zeigten in Teilen der Pipeline bis zu 40 % Halluzinationswahrscheinlichkeit. Für numerische Daten (Ausfalldauer, Anzahl betroffener Kunden) war “verlässliche Genauigkeit nicht zu erreichen” — menschliche Überprüfung war immer nötig.

Daraus folgt eine unverhandelbare Praxis:

1. Der KI-Entwurf ist immer ein Entwurf — nie ein fertiger Bericht
2. Jede Kausalaussage wird menschlich gegen die Rohdaten geprüft
3. Jede numerische Angabe (Ausfalldauer, betroffene Kunden, Wiederherstellungszeit) wird manuell verifiziert
4. Die Quelldaten werden im Bericht dokumentiert — so kann jede Aussage rückverfolgt werden
5. Für regulatorisch meldepflichtige Incidents gilt erhöhte Sorgfalt: Kein Bericht geht an die Bundesnetzagentur, ohne dass mindestens eine zweite Person den KI-Entwurf geprüft hat

Dieser Prozess ist der Unterschied zwischen einem nützlichen Werkzeug und einem Haftungsrisiko.

Dieser Abschnitt ist eine fachliche Orientierung, keine Rechtsberatung. Für die konkrete Auslegung von TKG-Meldepflichten, SLA-Klauseln und Schadensersatzfragen ziehe deine Rechtsabteilung oder spezialisierte Telekommunikationsjuristinnen hinzu.

Konkrete Werkzeuge — was wann passt

Für den Sofortstart (ohne Integration)

ChatGPT oder Claude mit einem guten Prompt und manuell eingefügten Rohdaten. ChatGPT ist die bekannteste Option für Teams ohne API-Erfahrung; Claude hat ein besonders großes Kontextfenster (bis zu 200.000 Token), das lange Alarm-Logs und Ticket-Historien auch bei komplexen Incidents ohne Datenverlust verarbeitet. Beide Ansätze erfordern kein technisches Setup — sie zeigen aber manuellen Datenpflegeaufwand, solange keine Integration besteht.

Für spezialisierte Incident-Post-Mortem-Automatisierung

incident.io ist die stärkste spezialisierte Lösung: Die KI-Funktion „Scribe” transkribiert Incidents in Echtzeit, erfasst Slack-Timelines automatisch und generiert laut eigenem Bericht ein 80 % fertiges Post-Mortem. Für Teams, die bereits mit Slack arbeiten und Datadog oder PagerDuty für Monitoring nutzen, ist incident.io der Weg des geringsten Widerstands. Kosten: ab ca. 31 USD/Nutzer/Monat (Pro-Plan, jährlich); EU-Datenhaltung verfügbar. Einschränkung: Optimales Ergebnis setzt voraus, dass das Team während des Incidents aktiv im Slack-Channel kommuniziert — stille Incidents werden schlechter dokumentiert.

PagerDuty hat mit seinem AIOps-Add-on und dem PagerDuty Copilot (seit Q3 2024 allgemein verfügbar) Post-Mortem-Generierung direkt in der Plattform integriert: Copilot erstellt einen Berichtsentwurf auf Knopfdruck, basierend auf der automatisch erfassten Incident-Timeline. Preis: PagerDuty AIOps ab 699 USD/Monat als Add-on (Stand 2025); für Teams, die PagerDuty ohnehin für On-Call-Management nutzen, ist das eine naheliegende Erweiterung.

Für Enterprise-Umgebungen mit ServiceNow

ServiceNow Now Assist for ITOM bringt KI-gestützte Post-Mortem-Generierung direkt in den bestehenden ServiceNow-Workflow — Entwürfe entstehen, wenn ein Incident-Ticket geschlossen wird, ohne Tool-Wechsel. Sinnvoll ausschließlich für Betreiber, die ServiceNow bereits als ITSM-Plattform einsetzen. Einstieg im fünfstelligen Jahresbereich.

Für Monitoring-Integration

Datadog enthält seit 2024 KI-Features für automatische Incident-Zusammenfassungen und kann als Datenquelle für externe LLM-Pipelines dienen. Für Betreiber, die Datadog bereits für Monitoring einsetzen, lässt sich die Alarm-Timeline direkt exportieren und als Grundlage für den KI-Prompt nutzen.

Zusammenfassung: Wann welcher Ansatz

• Kein Budget, schneller Proof of Concept → ChatGPT oder Claude mit manuellem Datenpfad
• Slack-zentrierter Workflow, Datadog/PagerDuty-Integration → incident.io Scribe
• PagerDuty bereits im Einsatz, AIOps-Budget vorhanden → PagerDuty Copilot
• ServiceNow als ITSM-Basis → ServiceNow Now Assist for ITOM
• Eigene Pipeline mit vollem Kontrollanspruch → LLM-API (ChatGPT oder Claude) + n8n für Datenaggregation

Datenschutz und Datenhaltung

Post-Mortem-Berichte enthalten typischerweise Daten, die datenschutzrechtlich und vertraglich sensibel sind:

• Namen und Kontaktdaten von On-Call-Ingenieuren (personenbezogene Daten nach DSGVO)
• Kundenbezogene Ausfallzeiten und betroffene Kundenzahlen (vertrauliche Geschäftsdaten)
• Netzwerkarchitekturdetails (sicherheitsrelevante Infrastrukturinformation)
• Konfigurationsdetails betroffener Systeme (potenziell sicherheitskritisch)

Das bedeutet:

AVV ist Pflicht. Wer Incident-Daten an einen Cloud-LLM-Anbieter übergibt, muss einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO abschließen. ChatGPT (OpenAI), Claude (Anthropic) und incident.io stellen AVV bereit — diese müssen aktiv angefordert und abgeschlossen werden, bevor Produktionsdaten verarbeitet werden.

EU-Hosting prüfen. incident.io bietet EU-Datenhaltung. Claude kann über AWS Bedrock (Frankfurt) oder Google Vertex AI (Europe West) DSGVO-konform betrieben werden. ChatGPT wird über US-Server verarbeitet; für Betreiber mit strikten Datenschutzanforderungen oder behördlichen Kunden empfiehlt sich ein EU-konformer Pfad.

Datensparsamkeit praktizieren. Bevor Alarm-Logs und Ticket-Daten an eine LLM-API übermittelt werden, sollten Kundennamen, IP-Adressen und interne Netzwerktopologiedetails pseudonymisiert oder entfernt werden — soweit das für die Post-Mortem-Qualität unschädlich ist. Viele Betreiber führen interne Anonymisierungsregeln für externe Berichte ohnehin — dieser Schritt kann in die Datenvorbereitung für den LLM-Prompt integriert werden.

ServiceNow Now Assist ist für Betreiber mit strikten Hosting-Anforderungen die datenschutzfreundlichste Variante — sofern die ServiceNow-Instanz in einem deutschen oder EU-Rechenzentrum betrieben wird. Das erfordert explizite Vertragsgestaltung; Standardinstanzen liegen nicht automatisch in der EU.

Was es kostet — realistisch gerechnet

Einstieg (Proof of Concept, ohne Integration) Praktisch kostenfrei: ChatGPT Plus (20 USD/Monat) oder Claude Pro (20 USD/Monat) reichen für den ersten Prototypen. Zeitinvestition: ein halber Tag für Prompt-Entwicklung und erste Tests.

Produktiver Einsatz mit Halbautomatisierung

• LLM-API-Kosten: 50–200 EUR/Monat je nach Volumen und Modell
• Integrationsaufwand (n8n oder eigenes Skript): 3–6 Entwicklertage intern, einmalig
• Gesamteinrichtung: ca. 2.000–5.000 EUR einmalig (externe Unterstützung) oder Eigenleistung

Spezialisierte Plattformen

• incident.io Pro: ca. 31 USD/Nutzer/Monat — für ein 5-köpfiges NOC-Team ca. 1.860 USD/Jahr
• PagerDuty AIOps-Add-on: ab 699 USD/Monat — sinnvoll, wenn PagerDuty ohnehin im Einsatz ist und das AIOps-Budget vertretbar ist
• ServiceNow Now Assist for ITOM: Fünfstelliger Jahresbereich — nur für Betreiber mit bestehender ServiceNow-Lizenz

Was du dagegenrechnest Ein NOC-Ingenieur mit Senior-Profil kostet ca. 45–65 EUR Bruttostundensatz (Schätzwert basierend auf Destatis-Verdienstdaten für IT-Berufe, 2024). Bei fünf bis sieben Stunden Post-Mortem-Aufwand je Incident und zwanzig Incidents pro Jahr: 4.500–9.100 EUR jährlich allein für die Dokumentationsarbeit dieses einen Prozessschritts — von einer Person.

Ein Team mit drei Senior-Engineers und dreißig Incidents pro Jahr kommt auf 13.500–27.300 EUR jährlich für Post-Mortem-Schreibarbeit.

Selbst ein konservatives Szenario (50 % Zeitersparnis, nur zwei Engineers) amortisiert eine solche Einrichtung in weniger als sechs Monaten.

Typische Einstiegsfehler

1. Mit dem komplexen Integrationsprojekt beginnen statt mit dem Proof of Concept. Der häufigste Fehler: Das Team wartet auf eine vollständige Integration mit NMS-API, ServiceNow-Webhook und automatischem Auslöser — und beginnt gar nicht. Der nützlichste erste Schritt ist brutaler Minimalismus: Den nächsten Alarm-Log-Export und die letzten Ticket-Kommentare in eine Textdatei kopieren und mit einem guten Prompt in ChatGPT einen Berichtsentwurf erstellen. Das klärt innerhalb eines echten Incidents, ob das Konzept für die eigene Umgebung funktioniert.

2. Den KI-Entwurf ungeprüft als fertigen Bericht verwenden. Das ist der gefährlichste Fehler — und er passiert, wenn das Werkzeug gut genug klingt, um Misstrauen einzuschläfern. Zalando hat nach zwei Jahren Erfahrung mit KI-Post-Mortems dokumentiert, dass selbst fortgeschrittene Modelle in rund 10 % der Fälle Technologien kausal mit Incidents verknüpfen, die nur erwähnt, nicht ursächlich waren. Für numerische Angaben wie Ausfalldauer oder Kundenzahl gilt: Immer manuell gegen die Rohdaten prüfen, nie aus dem KI-Entwurf übernehmen ohne Kontrolle.

3. Die Datenqualität ignorieren und trotzdem produktive Ergebnisse erwarten. Wenn Alarmlogs lückenhaft sind, Ticket-Kommentare auf Englisch, Deutsch und Abkürzungen gemischt sind, und Change-Management-Einträge in einem anderen System ohne Export-API liegen — dann gibt das LLM einen lückenhaften Entwurf zurück. Die Qualität des Outputs ist direkt abhängig von der Qualität des Inputs. Wer das ignoriert, wird nach zwei enttäuschenden Post-Mortems das Werkzeug wieder abschalten. Lösung: Vor dem Start den Datenpfad prüfen. Welche Daten liegen wo? In welchem Format? Wie vollständig?

4. Das Berichtsformat nicht fest definieren. Ein LLM ohne klare Strukturvorgabe produziert jedes Mal ein anderes Format — einmal mit fünf Abschnitten, einmal mit acht, einmal auf Englisch, einmal auf Deutsch. Für einen Betreiber, der Berichte konsistent archivieren und auswerten will, ist das unbrauchbar. Der Prompt muss das Zielformat exakt beschreiben: Pflichtabschnitte, Reihenfolge, Sprache, erlaubter Detailgrad. Einmal sauber definiert, hält das LLM das Format zuverlässig ein.

5. Die Wartung nicht einplanen — Prompts degradieren. Ein Prompt, der heute gut funktioniert, kann nach einem NMS-Update, einer Änderung des Ticket-Formats oder einem Modellupdate des LLM-Anbieters schlechtere Ergebnisse liefern. Wer niemanden benennt, der den Prompt vierteljährlich überprüft und anpasst, hat nach einem Jahr ein Werkzeug, das nominell existiert, aber niemand mehr vertraut.

Was mit der Einführung wirklich passiert — und was nicht

Die technische Seite ist der einfache Teil. Schwieriger ist oft die Frage: Wer darf das?

In manchen NOC-Umgebungen sind Post-Mortem-Berichte formal validierte Dokumente, die ein benannter Ingenieur unterzeichnet. Das Einführen eines KI-Assistenten bedeutet dann nicht nur eine neue Software, sondern eine Änderung des Signaturprozesses — was die Qualitätssicherung, den Datenschutzbeauftragten und die Rechtsabteilung involviert.

Was häufig unterschätzt wird:

• Skepsis gegenüber KI-generierten Fakten ist im NOC-Kontext gut begründet und sollte nicht als Widerstand behandelt werden. Die richtige Reaktion: Transparent zeigen, dass der Entwurf immer ein Entwurf ist, und den Überarbeitungsschritt institutionell verankern.
• Frühes Engagement des Datenschutzbeauftragten spart Arbeit. Wer den DSB erst nach dem Piloten fragt, riskiert eine Nachkonfiguration oder Neuauswahl des Tools. Besser: DSB vor der Tool-Auswahl einbinden, AVV-Anforderungen von Anfang an klären.
• Wissenssilos im NOC werden durch bessere Post-Mortems sichtbar — und das ist der eigentliche langfristige Nutzen. Ein Team, das nach zwölf Monaten dreißig strukturierte, durchsuchbare Post-Mortems hat, kann erstmals auswerten, welche Geräte überdurchschnittlich häufig zu Ausfällen beitragen, welche Änderungstypen riskant sind und wann im Jahr die Incident-Dichte am höchsten ist. Dieser Erkenntnisgewinn entsteht nicht automatisch — er setzt voraus, dass die Berichte in einem durchsuchbaren Format archiviert und regelmäßig ausgewertet werden.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Die KI erfindet Fakten — das können wir uns bei regulatorisch relevanten Berichten nicht leisten.” Das ist der wichtigste Einwand — und er ist berechtigt. Der Fehler liegt aber nicht in der Grundidee, sondern in der falschen Erwartung: Der KI-Assistent ersetzt nicht die menschliche Prüfung, er ersetzt die manuelle Erst-Erstellung. Der Ingenieur prüft den Entwurf, korrigiert, ergänzt — und unterschreibt. Die Verantwortung liegt weiterhin beim Menschen. Wer das institutionell verankert (Überarbeitungsschritt ist Pflicht, kein Bericht ohne Vier-Augen-Prüfung bei regulatorisch relevanten Vorfällen), hat das Haftungsrisiko im Griff.

„Wir haben nur acht bis zehn Incidents pro Jahr — das lohnt sich nicht.” Das stimmt für den komplexen Integrationspfad. Für den manuellen Pilot-Ansatz ist es trotzdem ein fairer Test: ein Nachmittag Prompt-Arbeit, angewendet auf die nächsten drei Incidents. Wenn das zehn Stunden Schreibarbeit spart, ist der Aufwand amortisiert. Ob danach eine vollständige Integration lohnt, entscheidet das Incident-Volumen.

„Unsere Alarmdaten sind nicht strukturiert genug dafür.” Dann ist das der wichtigste erste Befund — nicht ein Argument gegen den KI-Einsatz, sondern ein Argument für bessere Alarmdaten-Hygiene. Viele Betreiber entdecken beim Versuch, Daten für einen KI-Prompt vorzubereiten, dass ihre NMS-Exporte unvollständig, inkonsistent oder schwer maschinenlesbar sind. Das zu beheben hat einen Eigenwert — unabhängig vom KI-Einsatz.

Woran du merkst, dass das zu dir passt

Dieser Anwendungsfall passt, wenn folgende Punkte zutreffen:

• Du hast mindestens zehn bis fünfzehn dokumentationspflichtige Incidents pro Jahr — darunter ist der Integrationsaufwand kaum zu rechtfertigen
• Dein NOC-Team verbringt nach Incidents spürbar Zeit mit Berichtschreiben — vier bis acht Stunden pro Major Incident ist der typische Ausgangspunkt
• Du hast strukturierte Alarmdaten — mindestens exportierbare, zeitgestempelte Alarm-Logs aus deinem NMS
• Du hast ein Ticketing-System mit chronologischer Kommentarhistorie (ServiceNow, Jira, Freshservice oder ähnliches)
• Post-Mortem-Qualität ist dir wichtig — nicht nur das Abarbeiten der Dokumentationspflicht, sondern das Lernen aus Incidents über Zeit

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als 8–10 relevante Incidents pro Jahr (oder entsprechend hohes Netz-Zuverlässigkeitsniveau). Der Setup-Aufwand — Prompt-Entwicklung, Datenpfad-Einrichtung, Prozess-Definition — amortisiert sich nur bei ausreichendem Incident-Volumen. ISPs mit hochstabilen Netzen und selten auftretenden Incidents erzielen mit manueller Berichterstattung denselben Effekt ohne Tool-Investition.

2. Kein strukturiertes Ticketing-System und keine exportierbaren Alarmlogs. Ein LLM kann keine Zeitleiste aus einem Telefonanruf und einer handgeschriebenen Notiz rekonstruieren. Wenn die Incident-Dokumentation bisher im Kopf der On-Call-Ingenieure oder in formlosen E-Mails stattfindet, ist der erste Schritt nicht KI, sondern ein strukturiertes Incident-Management-System. Der KI-Assistent kommt danach.

3. Keine Person mit Zeit und Verantwortung für Prompt-Pflege und Qualitätssicherung. Ein KI-Post-Mortem-System, das eingerichtet und dann vergessen wird, produziert nach einem NMS-Update oder Formatänderung im Ticket-System qualitativ schlechtere Entwürfe — ohne dass jemand es bemerkt. Ohne eine namentlich benannte Person, die den Prompt quartalsweise überprüft und die Entwurfsqualität stichprobenartig bewertet, entsteht ein Werkzeug, das nach zwölf Monaten still degradiert.

Das kannst du heute noch tun

Öffne NotebookLM oder ChatGPT und füge die Daten des letzten abgeschlossenen Incidents ein — Alarm-Log (oder auch nur die wichtigsten Alarmzeilen), die Ticket-Kommentare und eine Liste der Lösungsschritte. Dann gib den Prompt unten ein.

Das dauert zwanzig Minuten. Du siehst direkt, welche Qualität ein LLM mit deinen Rohdaten produziert — und wo die Lücken in deiner Datenbasis liegen.

Quellen & Methodik

• incident.io (2025): „Incident post-mortem software ROI: quantifying MTTR reduction and engineer time savings” — incident.io Blog. Zitierte Kennzahlen: 75 Minuten gesparte Documentation-Archaeology pro Incident, 37 % MTTR-Reduktion. URL: https://incident.io/blog/postmortem-software-roi-calculator

• Zalando Engineering Blog (September 2025): „Dead Ends or Data Goldmines? Investment Insights from Two Years of AI-Powered Postmortem Analysis” — Erfahrungsbericht Zalandos zur KI-gestützten Post-Mortem-Analyse über zwei Jahre. Berichtete Halluzinationsrate früher Modelle: bis zu 40 %; Attributionsfehler bei Claude Sonnet 4: ca. 10 %. URL: https://engineering.zalando.com/posts/2025/09/dead-ends-or-data-goldmines-ai-powered-postmortem-analysis.html

• PagerDuty Pricing (2025): PagerDuty AIOps-Add-on ab 699 USD/Monat. PagerDuty Copilot (Post-Mortem-Generierung) seit Q3 2024 allgemein verfügbar. URL: https://www.pagerduty.com/pricing/aiops/

• Stundensatzschätzung: Basierend auf Destatis-Verdienststatistik für IT-Berufe in Deutschland 2024; Bruttostundensatz für IT-Fachkräfte (Senior-Level) 45–65 EUR. Keine direkte Repräsentativerhebung für NOC-Ingenieure — Schätzwert.

• Regulatorischer Kontext: Telekommunikationsgesetz (TKG), insbesondere §§ 168 ff. zur Meldepflicht bei erheblichen Sicherheitsvorfällen und Netzausfällen. DSGVO Art. 28 (Auftragsverarbeitung).

Du willst wissen, ob deine Alarmdaten und dein Ticketing-System gut genug für einen KI-gestützten Post-Mortem-Prozess geeignet sind? Meld dich — das klären wir in einem kurzen Gespräch.