KI-gestütztes Störfall-Eskalationsmanagement im Gasnetz

Das echte Ausmaß des Problems

Die DVGW führt seit 1981 eine Gas- und Wasserstatistik. Demnach ereignen sich in deutschen Gasnetzen jährlich mehrere Tausend meldepflichtige Ereignisse — von einfachen Druckschwankungen bis zu Einsätzen wegen Gasaustritt. Der größte Auslöser für ernste Störfälle ist Fremdeinwirkung durch Bauarbeiten (Drittschaden), gefolgt von Korrosion und Materialversagen.

Was in der Statistik nicht erscheint: der administrative Aufwand, den jeder dieser Vorfälle auslöst.

Bei einem klassischen Drittschaden mit Gasaustritt läuft das Leitstellenpersonal in der ersten Stunde gegen folgende parallele Anforderungen:

• DVGW G 1000 Protokollpflicht: Alle Eskalationsschritte müssen mit Uhrzeit dokumentiert werden — Meldungseingang, Bereitschaftstrupp alarmiert, Absperrventil betätigt, Gasdetektion vor Ort, Freizeichnung.
• Behördeninformation: Das LBEG (Landesamt für Bergbau, Energie und Geologie) oder die zuständige Behörde erwartet eine Vorabmeldung innerhalb definierter Fristen; je nach Bundesland und Schweregrad. Vorabmeldepflichten nach EnWG §52 (Störungsmeldepflicht) sind dabei einzuhalten.
• Kundenkommunikation: Betroffene Abnehmer haben ein Recht auf Information — eine Koordinationsaufgabe, die im Störfall-Stress oft bis nach dem Einsatz verschoben wird.
• Ressourcenplanung: Welche Kolonne ist in der Nähe? Welcher Trupp hat die Gerätschaften für diesen Rohrdurchmesser?

Erfahrene Disponenten haben all das im Kopf. Aber Großstörungen eskalieren genau dann, wenn die Belastung am höchsten ist — und dann zeigen sich die Schwächen von Papierchecklist und Telefonbaum am deutlichsten.

Laut einer Erhebung in KRITIS-Betrieben sind durchschnittlich 4 bis 7 parallele Kommunikationskanäle während eines größeren Incidents aktiv — zu viele für ein einzelnes Leitstellenpersonal ohne Unterstützungssysteme.¹

¹ Schätzung auf Basis von Praxisberichten aus KRITIS-Betrieben; kein öffentlich verfügbarer verifizierter Volltext.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Erfahrungswert aus Pilotprojekten in der Versorgungswirtschaft; keine unabhängige Studie.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Die KI spart Dokumentationsaufwand und Formulierungszeit für Meldungen — das sind 30 bis 60 Minuten je Störfall. Was sie nicht einspart: die Entscheidungszeit. Die Disponentin muss weiterhin die Lagebeurteilung treffen, Maßnahmen freigeben und im Zweifel widersprechen. Verglichen mit Regulierungsberichten oder EDIFACT-Automatisierung, wo repetitive Schritte vollständig automatisiert werden, bleibt hier ein menschlicher Kern unverzichtbar.

Kosteneinsparung — mittel (3/5) Die direkten Kosteneinsparungen sind schwer zu isolieren. Indirekt wirkt das System: Vollständigere Dokumentation reduziert das Risiko von DVGW-Rügen und regulatorischen Bußgeldern. Schnellere Kundenkommunikation senkt Beschwerdeaufkommen. Aber diese Effekte sind keine harten Kostenpositionen in der Buchhaltung.

Schnelle Umsetzung — niedrig (2/5) Das ist der schwierigste Schritt dieser Use Cases: Integration in bestehende SCADA/EMS-Systeme, Zertifizierung für den KRITIS-Betrieb und Einbindung in Leitstellenprozesse erfordern 6 bis 12 Monate. KRITIS-Betreiber müssen außerdem die Eignung gemäß BSI-Grundschutz nachweisen. Eine Schnellimplementierung ist hier nicht realistisch.

ROI-Sicherheit — mittel (3/5) Der Nutzen ist real, aber seine Größe hängt stark von der Störfallhäufigkeit ab. Ein Netzbetreiber mit wenigen Ereignissen pro Jahr wird einen anderen ROI sehen als einer mit hohem Drittschadenaufkommen in urban verdichteten Gebieten. Die Grundvoraussetzung für einen messbaren ROI ist eine saubere Datenbasis aus historischen Störfalldokumentationen.

Skalierbarkeit — mittel (3/5) Die Plattform skaliert gut mit steigender Störfallanzahl — parallele Incidents werden besser beherrschbar, ohne dass die Personalkapazität proportional steigen muss. Die Skalierbarkeit ist begrenzt durch die Qualität der SCADA-Integration: Wer viele schlecht angebundene Sensorzonen hat, bekommt auch viele unklassifizierte Alarme.

Richtwerte — stark abhängig von Netzgröße, SCADA-Ausstattung und regionalem Störfallaufkommen.

Was das System konkret macht

Das KI-Störfallsystem sitzt als Schicht zwischen dem SCADA/EMS-System und dem Leitstellenpersonal. Es tut drei Dinge:

1. Klassifizierung: Sobald ein Alarm eingeht — aus SCADA, aus dem Störungstelefon-Transkript oder aus einer externen Meldung — ordnet das System den Vorfall einer DVGW-Störfallkategorie zu (Gasaustritt Kategorie 1/2/3, Druckabfall, Drittschaden, interner Defekt). Diese Klassifizierung ist regelbasiert, nicht rein KI-gestützt: Schwellenwerte, Druckgradienten und Alarmkombinationen folgen definierten Logiken aus dem Einsatzplan. Die KI ergänzt: Sie erkennt Muster aus historischen Störfällen, die auf einen schwereren Verlauf hindeuten.

2. Eskalationsvorschlag: Basierend auf der Klassifizierung schlägt das System die nächsten Schritte vor: Welche Truppen alarmieren, welche Absperrventile schließen, ob die BNetzA-Vorabmeldung ausgelöst werden muss. Die Disponentin bestätigt oder korrigiert jeden Schritt — keine vollautomatische Ausführung in einem sicherheitsrelevanten System.

3. Dokumentation und Kommunikation: Das System schreibt laufend mit: Zeitstempel, ausgeführte Maßnahmen, beteiligte Ressourcen. Parallel generiert ein LLM Textentwürfe — die Vorabmeldung ans LBEG, die Kunden-SMS für die betroffene Straße, das Post-Mortem-Protokoll für die Qualitätssicherung. Diese Entwürfe werden vom Personal freigegeben, nicht blind versendet.

Was das System nicht macht

Es trifft keine Sicherheitsentscheidungen autonom. Es sperrt keine Ventile ohne menschliche Freigabe. Es ersetzt nicht die Fachkunde der Disponentin — es entlastet sie von der Verwaltungsarbeit, damit sie sich auf die Lagebeurteilung konzentrieren kann.

Konkrete Werkzeuge — was wann passt

Die Werkzeugauswahl hängt entscheidend von der KRITIS-Einstufung ab. Betreiber mit mehr als 420 GWh/Jahr transportiertes Gas (gemäß BSI-KritisV, Sektor Energie, Kategorie Gasversorgung) unterliegen der BSI-KritisV und müssen für IT-Systeme in der Leitstelle strenge Anforderungen an Datensouveränität und Zertifizierung erfüllen.

Aleph Alpha — für KRITIS-konforme LLM-Funktionen Aleph Alpha ist der einzige deutsche LLM-Anbieter mit nachgewiesener KRITIS-Eignung und On-Premise-Deploymentoption. Für die Textgenerierung von Behördenmeldungen und Störfallprotokollen in einer Leitstelle ist das die einzige Option, die ohne umfangreiche Risikoprüfung produktiv eingesetzt werden kann. Nachteil: Die Modelle sind weniger leistungsfähig als GPT-4, und der Integrationsaufwand ist erheblich.

Azure OpenAI Service — für EU-Deployment mit BSI-Prüfung Wenn eine On-Premise-Lösung nicht infrage kommt, kann Azure OpenAI in EU-Rechenzentren als Alternative geprüft werden. Microsoft bietet für Azure Government- und regulierte Industrie-Kunden spezielle Compliance-Dokumentation an. Die Eignung für den KRITIS-Betrieb muss aber individuell mit dem BSI abgestimmt werden — eine automatische Zertifizierung gibt es nicht.

AVEVA PI System — als Datenbasis Das PI System ist in den meisten deutschen Gasnetzbetreibern bereits als SCADA-Historian im Einsatz. Es liefert die Echtzeit-Sensordaten, auf deren Basis die Störfallklassifizierung arbeitet. Keine neue Beschaffung nötig — aber eine API-Anbindung an das KI-System ist erforderlich.

PagerDuty eignet sich gut für IT-Incident-Management-Prozesse, ist aber für den KRITIS-Leitstellenbetrieb nicht geeignet: US-Datenhaltung, kein Deutsch, keine Zertifizierung für Energieinfrastruktur. Für interne IT-Systeme des Netzbetreibers (nicht die Leitstelle selbst) kann es dennoch relevant sein.

Speziallösungen für Energieversorger: Anbieter wie Kisters, Schleupen und PSI entwickeln SCADA-nahe Lösungspakete speziell für Energieversorger und bieten entsprechende Zertifizierungsunterstützung. Diese sind teurer, aber pragmatischer für KRITIS-Betreiber.

Datenschutz und Datenhaltung

Störfalldaten aus dem Gasnetz sind keine personenbezogenen Daten im engeren Sinne — sie betreffen Sensorwerte, Ventilstellungen und Leitungsabschnitte. Dennoch entstehen im Verlauf des Incidents Daten, die in den KRITIS-Schutzbereich fallen: Lageplan des Netzabschnitts, Ressourcenpositionen, Kommunikationsinhalte.

Für KRITIS-Betreiber (>420 GWh/Jahr) gilt: IT-Systeme in der Leitstelle müssen nach BSI IT-Grundschutz abgesichert sein. Cloud-Systeme erfordern eine Risikoanalyse nach BSI-Vorgaben, bevor sie in den Produktivbetrieb gehen. Der BSI-Baustein SYS.1.2 (Server) und OPS.1.1.4 (Schutz vor Schadprogrammen) sind einschlägig.

Praktische Empfehlung: Der LLM-Kern (Texterstellung für Meldungen) kann auf EU-Infrastruktur ausgelagert werden, wenn der Datenpfad isoliert ist und keine Rückschlüsse auf die Netzinfrastruktur zulässt. Die SCADA-Datenschicht bleibt on-premise oder in einer zertifizierten privaten Cloud. Eine DSGVO-Folgenabschätzung ist auch dann empfehlenswert, wenn keine personenbezogenen Daten direkt verarbeitet werden — der Kontext kritischer Infrastruktur erhöht die Anforderungen.

Was es kostet — realistisch gerechnet

Einmalige Projektkosten (Eigenentwicklung oder Integrator):

• Konzeption, SCADA-Integration und Pilotbetrieb: 80.000–200.000 Euro
• Zertifizierungsunterstützung für KRITIS-Konformität: 20.000–50.000 Euro
• Schulung und Change-Management Leitstellenpersonal: 15.000–30.000 Euro

Laufende Kosten:

• LLM-API-Kosten (On-Premise oder EU-Cloud): 500–2.000 Euro/Monat je nach Volumen
• Systemwartung und -pflege: 1–2 Personentage/Monat intern

Konservativer ROI-Szenario: Ein mittelgroßer Netzbetreiber verzeichnet 120 meldepflichtige Störfälle pro Jahr. Pro Störfall spart das System 45 Minuten Dokumentations- und Koordinationsaufwand (=90 Stunden). Bei einem internen Stundensatz von 80 Euro sind das 7.200 Euro pro Jahr — weit unter den Investitionskosten. Der eigentliche ROI liegt im Vermiedenen: eine fehlerhafte Behördenmeldung, die eine BNetzA-Rüge auslöst, oder eine unvollständige Post-Mortem-Dokumentation, die bei der nächsten DVGW-Prüfung Probleme verursacht. Diese Kosten sind schwer kalkulierbar, aber real. Eine formelle BNetzA-Rüge wegen unzureichender Incident-Dokumentation zieht typischerweise Nachprüfverfahren und interne Korrekturaufwände von 15.000–50.000 Euro nach sich — dazu kommen Reputationsrisiken bei der nächsten Anreizregulierungsperiode.

Drei typische Einstiegsfehler

Fehler 1: SCADA-Integration unterschätzt Die meisten Netzbetreiber haben SCADA-Systeme verschiedener Generationen und Hersteller. Eine einheitliche API-Schicht für Echtzeit-Alarmdaten ist selten vorhanden. Wer das KI-System ohne Vorarbeit an die SCADA-Infrastruktur koppeln will, scheitert am Integrationsprojekt, bevor die eigentliche KI-Arbeit beginnt. Mindestanforderung: ein definiertes Datenschema für Alarme, das aus allen relevanten SCADA-Systemen befüllt werden kann.

Fehler 2: Das Leitstellenpersonal wird nicht früh genug eingebunden Disponenten entwickeln über Jahre ein tiefes, oft implizites Wissen über ihr Netz. Ein KI-System, das Eskalationsvorschläge macht, die dem Erfahrungswissen widersprechen — auch wenn technisch korrekt — wird nicht akzeptiert. Die Einbindung des erfahrenen Leitstellenpersonals in die Definition der Eskalationslogiken ist kein optionales Extra, sondern eine Projektvoraussetzung.

Fehler 3: Keine Wartungsplanung für die Eskalationslogiken DVGW-Regelwerke ändern sich. Neue Behördenvorschriften kommen hinzu. Das Netz wächst oder ändert sich. Die im System hinterlegten Eskalationspfade müssen regelmäßig auf Aktualität geprüft werden — sonst veraltert das System still und still verlässt das Leitstellenpersonal die KI-Vorschläge zunehmend zugunsten eigener Checklisten. Wer verantwortet diese Pflege? Diese Frage muss vor dem Go-live beantwortet sein.

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

Die erste Hürde ist nicht technisch, sondern psychologisch: Erfahrene Disponenten haben jahrelang allein koordiniert. Ein System, das ihnen “sagt”, was sie tun sollen, wird mit Skepsis aufgenommen — manchmal offener Ablehnung. Das ist berechtigt, denn in sicherheitskritischen Situationen muss das Personal dem System vertrauen, bevor es seine Aufmerksamkeit teilweise dorthin lenkt.

Was hilft: Das System zunächst rein passiv einsetzen — es protokolliert mit und macht Vorschläge, aber die Disponentin ignoriert die Anzeige anfangs komplett. Nach einigen Wochen vergleicht man die System-Protokolle mit den handschriftlichen Aufzeichnungen. Diese Gegenüberstellung zeigt konkret, was das System richtig lag und wo es falsch klassifiziert hat. Dann beginnt das Vertrauen, sich zu entwickeln.

Was nicht passiert: Eine spontane Akzeptanz des Systems nach dem ersten Schulungstag. Die Einführung erfordert 3 bis 6 Monate parallelen Betriebs, in denen das System keine eigenständige Rolle spielt, bevor es seinen Platz in der Routine des Leitstellenpersonals findet.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Unser Leitstellenpersonal ist erfahren genug — das brauchen wir nicht.” Stimmt, solange ein Incident auf einmal kommt. Drei Störfälle gleichzeitig an einem Freitagabend sind eine andere Situation. Das System hilft nicht, weil das Personal inkompetent ist, sondern weil die Parallelbelastung Koordinationsfehler wahrscheinlicher macht. Das ist kein Angriff auf die Kompetenz — es ist eine strukturelle Entlastung.

“KRITIS-Anforderungen machen das unmöglich.” KRITIS-Anforderungen sind komplex, aber nicht prohibitiv. Sie erfordern mehr Projektaufwand für Sicherheitsnachweise. Wer einen erfahrenen IT-Sicherheitsberater für Energieinfrastruktur einbezieht, kann ein konformes System bauen — es dauert nur länger und kostet mehr als ein KRITIS-freies Projekt.

“Was passiert, wenn das System beim Störfall selbst ausfällt?” Der manuelle Prozess bleibt bestehen — als Rückfalloption, nicht als Hauptpfad. Das System darf kein Single Point of Failure werden. Die bestehenden Papierchecklist und Telefonbäume bleiben in Kraft und werden regelmäßig geübt. Das KI-System hat immer den Status eines unterstützenden Werkzeugs, nicht eines unentbehrlichen Hauptsystems.

Woran du merkst, dass das zu dir passt

Das passt zu dir, wenn:

• Deine Leitstelle regelmäßig mehr als zwei Störfälle gleichzeitig koordinieren muss
• Du DVGW-Prüfungen erlebst, bei denen unvollständige Protokolle ein Thema waren
• Du bereits eine strukturierte SCADA-Datenbasis mit historischen Alarmdaten hast
• Du ein IT-Sicherheitskonzept für KRITIS-konforme Systeme vorweisen kannst oder aufbauen willst

Das passt noch nicht zu dir, wenn:

• Dein Netz weniger als 50 meldepflichtige Störfälle pro Jahr verzeichnet — der ROI trägt die Investition nicht
• Deine SCADA-Infrastruktur aus mehreren inkompatiblen Altsystemen besteht ohne einheitliche API — das Integrationsprojekt wäre der eigentliche Aufwand
• Du kein dediziertes IT-Team hast, das KRITIS-konforme Systeme betreiben kann — externe Betreibermodelle existieren, sind aber teuer
• Du noch keine digitale Version deiner Einsatzpläne und DVGW-Protokolle hast — diese müssen zuerst vorliegen, bevor ein KI-System sie verarbeiten kann

Das kannst du heute noch tun

Starte nicht mit dem System — starte mit der Bestandsaufnahme. Beantworte schriftlich:

1. Wie viele meldepflichtige Störfälle hattet ihr in den letzten 12 Monaten?
2. Liegen die Einsatzpläne digital und in strukturierter Form vor?
3. Welche SCADA-Systeme sind im Einsatz — und haben sie REST-APIs oder OPC-UA-Schnittstellen?
4. Wer wäre intern verantwortlich für den Betrieb und die Pflege des Systems?

Wenn du auf alle vier Fragen eine klare Antwort hast, ist die Grundlage für ein erstes Gespräch mit einem Systemintegrator gelegt. Wenn du es nicht hast, ist die Vorarbeit klarer als das KI-Projekt selbst.

Quellen & Methodik

• DVGW e.V. — Gas- und Wasserstatistik (laufend): Jährliche Störfallstatistik für Gasverteilnetze in Deutschland seit 1981. Basis für Häufigkeitsangaben.
• BSI — KRITIS-Regulierung (2023): Grundschutzanforderungen für Betreiber kritischer Infrastruktur im Energiesektor; Schwellenwert 420 GWh/Jahr für Gasversorgung.
• DVGW G 1000: Technische Regel für das Qualitätsmanagementsystem in der Gasversorgung; legt Anforderungen an Einsatzpläne, Protokollierungspflichten und Nachweisdokumentation für Störfälle fest.
• Erfahrungswerte aus Beratungsprojekten in KRITIS-Betrieben (eigene Schätzung / nicht veröffentlicht): Analyse zu Kommunikationsbelastungen in Leitstellen während Großereignissen.
• KRITIS-Dachgesetz (Januar 2026): Umsetzung der EU-CER-Richtlinie in deutsches Recht; verschärfte Anforderungen für physischen Schutz kritischer Anlagen.