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

Das echte Ausmaß des Problems

Der DVGW erfasst Schäden und Ereignisse in Gasverteilnetzen in einer eigenen Statistik, und Fremdeinwirkung durch Bauarbeiten, der sogenannte Drittschaden, gehört zu den typischen Auslösern von Gasaustritten. Belastbare Zahlen für euer Netz liefert eure eigene Schadensstatistik.

Was in keiner Statistik 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:

• Einsatzdokumentation: Der Einsatzplan verlangt, dass alle Eskalationsschritte mit Uhrzeit dokumentiert werden, Meldungseingang, Bereitschaftstrupp alarmiert, Absperrarmatur betätigt, Gasmessung vor Ort, Freigabe. Das DVGW-Arbeitsblatt G 1000 regelt dagegen die Qualifikation und Organisation des Netzbetreibers, nicht das Protokollformat eines Einsatzes.
• Behördeninformation: Schwere Ereignisse meldet der Netzbetreiber der Energieaufsichtsbehörde seines Landes; welche Behörde das ist und welche Ereignisse wann gemeldet werden, ist von Land zu Land verschieden und steht in eurem Einsatzplan. § 52 EnWG ist dagegen keine Sofortmeldung, sondern ein Jahresbericht über alle Versorgungsunterbrechungen an die Bundesnetzagentur bis zum 30. April.
• 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.

In der Geschichte oben laufen in den ersten Minuten fünf Kanäle parallel: Bereitschaftstrupp, externer Notfalldienst, Straßensperre, Behörde, Kunden, und dann ruft noch die Bezirksverwaltung an. Eine belastbare Erhebung, wie viele es bei größeren Einsätzen typischerweise sind, haben wir nicht gefunden; zählt es bei eurer nächsten Übung einfach mit.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Annahme dieser Seite, keine Erhebung. Messt die Zeit bis zur ersten Kundeninformation in euren Einsatzprotokollen, bevor ihr sie mit einem System vergleicht.

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, sehr niedrig (1/5) Der schwächste Kostenwert in dieser Branche. Selbst die eigene Rechnung unten kommt bei 120 Störfällen im Jahr auf einen Zeitwert von 7.200 Euro, und der deckt nicht einmal den laufenden Betrieb, von der Einrichtung zu schweigen. Vollständigere Dokumentation und schnellere Kundenkommunikation sind real, aber keine Kostenpositionen in der Buchhaltung. Wer das Projekt macht, macht es für Qualität und Sicherheit, nicht fürs Budget.

Schnelle Umsetzung, niedrig (2/5) Das ist der schwierigste Schritt dieser Use Cases: Integration in bestehende SCADA- und Netzleitsysteme, Einbindung in die Risikoanalyse eures ISMS nach dem IT-Sicherheitskatalog der Bundesnetzagentur und in die Leitstellenprozesse, nach dem Zeitplan unten 12 bis 20 Monate bis zum Vollbetrieb. 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, hoch (4/5) Die Plattform skaliert gut mit steigender Störfallanzahl, parallele Incidents werden besser beherrschbar, ohne dass die Personalkapazität proportional steigen muss. Das ist ein echter struktureller Vorteil gegenüber rein manuellen Prozessen. Einschränkung: Die Skalierbarkeit hängt an der Qualität der SCADA-Integration. Wer viele schlecht angebundene Sensorzonen hat, bekommt auch viele unklassifizierte Alarme, die Plattform kann nicht besser sein als die Datenbasis, die sie verarbeitet.

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 Störfallkategorie aus eurem Einsatzplan zu (etwa Gasaustritt in Stufen, 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 Absperrarmaturen laut Leitungsplan in Frage kommen, ob eine Meldung an die Aufsichtsbehörde fällig ist. 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 Meldung an die Energieaufsicht, 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 weniger an der KRITIS-Einstufung als am IT-Sicherheitskatalog. KRITIS-Anlage ist ein Gasverteilernetz nach BSI-KritisV erst ab 5.190 GWh entnommener Arbeit im Jahr, das erreichen nur die größten Netze. Den IT-Sicherheitskatalog der Bundesnetzagentur muss dagegen jeder Netzbetreiber für die Systeme des sicheren Netzbetriebs einhalten (§ 5c EnWG), und das Netzleitsystem gehört dazu.

Aleph Alpha , für LLM-Funktionen im eigenen Rechenzentrum Aleph Alpha bietet mit PhariaAI ein Sprachmodell, das sich vollständig im eigenen Rechenzentrum betreiben lässt. Eine “KRITIS-Eignung” als Zertifikat gibt es für kein Sprachmodell; die Risikoprüfung im eigenen ISMS bleibt jedem Werkzeug, auch diesem. Nachteil: Die Modelle sind weniger leistungsfähig als aktuelle GPT- oder Claude-Modelle, und der Integrationsaufwand ist erheblich. Seit September 2026 fusioniert Aleph Alpha mit dem kanadischen Anbieter Cohere, fragt vor Vertragsschluss nach der Produktzukunft.

Azure OpenAI Service , für EU-Deployment Wenn eine On-Premise-Lösung nicht infrage kommt, kann Azure OpenAI in EU-Rechenzentren als Alternative geprüft werden. Microsoft stellt dafür Compliance-Dokumentation bereit. Ob der Dienst in die Leitstellen-Umgebung passt, entscheidet eure eigene Risikoanalyse; eine Einzelfreigabe durch das BSI gibt es dafür 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 Leitstellenbetrieb im Gasnetz nicht geeignet: Standard-Hosting in den USA (eine EU-Region gibt es, den Residency-Umfang müsst ihr laut unserer Toolseite selbst prüfen), keine deutsche Oberfläche, gebaut für IT-Betrieb statt für Netzleittechnik. Für interne IT-Systeme des Netzbetreibers (nicht die Leitstelle selbst) kann es dennoch relevant sein.

Hersteller eures Netzleitsystems: Fragt zuerst beim Lieferanten eures Leit- oder SCADA-Systems, ob er Assistenzfunktionen für Störfalldokumentation anbietet oder plant. Eine Funktion im vorhandenen System ist im ISMS meist leichter zu begründen als eine Fremdschicht daneben.

Datenschutz und Datenhaltung

Die Sensorwerte, Ventilstellungen und Leitungsabschnitte eines Störfalls sind keine personenbezogenen Daten, aber sicherheitsrelevant: Lageplan des Netzabschnitts, Ressourcenpositionen, Kommunikationsinhalte.

Für jeden Netzbetreiber gilt: Die Systeme der Leitstelle fallen unter den IT-Sicherheitskatalog der Bundesnetzagentur (§ 5c EnWG), unabhängig von der KRITIS-Schwelle. Cloud-Komponenten brauchen vorher eine Risikoanalyse in eurem ISMS.

Personenbezogene Daten entstehen spätestens bei der Kunden-SMS: Telefonnummern und Adressen der Betroffenen. Dafür braucht ihr eine DSGVO-Rechtsgrundlage und, bei einem externen SMS- oder LLM-Dienst, einen Auftragsverarbeitungsvertrag. Beachtet auch, dass ein Netzbetreiber die Telefonnummern von Letztverbrauchern oft gar nicht hat, die liegen beim Lieferanten.

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 eigenen privaten Cloud.

Was es kostet, realistisch gerechnet

Einmalige Projektkosten (Eigenentwicklung oder Integrator):

• Konzeption, SCADA-Integration und Pilotbetrieb: 80.000–200.000 Euro
• Sicherheitsprüfung und Dokumentation im ISMS (IT-Sicherheitskatalog): 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

Was sich rechnen lässt: Ein mittelgroßer Netzbetreiber verzeichnet 120 Störfälle pro Jahr. Pro Störfall spart das System 45 Minuten Dokumentations- und Koordinationsaufwand, 120 mal 45 Minuten sind 90 Stunden. Bei einem internen Stundensatz von 80 Euro entspricht das 7.200 Euro im Jahr, und das auch nur als Zeitwert, das Leitstellenpersonal bleibt ja. Dagegen stehen 12 mal 500–2.000 Euro = 6.000–24.000 Euro laufende Kosten plus 1–2 Personentage Pflege im Monat. Der Zeitwert deckt also nicht einmal den Betrieb, die 115.000–280.000 Euro Einrichtung verdient das System nie zurück.

Das Projekt lässt sich darum nur über Qualität begründen: lückenlose Zeitstempel, vollständige Meldungen, eine entlastete Disponentin bei parallelen Störfällen. Ob euch das diesen Betrag wert ist, ist eine Sicherheitsentscheidung, keine Wirtschaftlichkeitsrechnung. Wer klein anfangen will, testet zuerst den prompt-gestützten Einstieg unten mit Übungsszenarien, der kostet fast nichts.

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 veraltet das System still und leise, und das Leitstellenpersonal verlässt 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.

“Die Sicherheitsanforderungen machen das unmöglich.” Die Anforderungen des IT-Sicherheitskatalogs 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 Projekt außerhalb des Netzleitsystems.

“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
• Bei TSM-Überprüfungen oder internen Audits unvollständige Einsatzprotokolle ein Thema waren
• Du bereits eine strukturierte SCADA-Datenbasis mit historischen Alarmdaten hast
• Dein ISMS nach dem IT-Sicherheitskatalog der Bundesnetzagentur steht und neue Komponenten aufnehmen kann

Das passt noch nicht zu dir, wenn:

• Du das Projekt über eingesparte Zeit rechtfertigen musst: Selbst bei 120 Störfällen im Jahr deckt der Zeitwert nicht einmal den Betrieb (Rechnung oben)
• 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 Systeme im Geltungsbereich des IT-Sicherheitskatalogs 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 Störfälle mit Gasaustritt hattet ihr in den letzten 12 Monaten, und bei wie vielen liefen mehrere gleichzeitig?
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., Schadens- und Ereignisstatistik Gas (laufend): Statistik zu Schäden und Ereignissen in Gasverteilnetzen; für Häufigkeiten in eurem Netz zählt eure eigene Schadensstatistik.
• BSI-KritisV, Anhang 1: Schwellenwert für Gasverteilernetze 5.190 GWh entnommene Arbeit im Jahr; gesetze-im-internet.de/bsi-kritisv/
• EnWG § 5c (IT-Sicherheit im Anlagen- und im Netzbetrieb, IT-Sicherheitskatalog) und § 52 (Meldepflichten bei Versorgungsstörungen, Jahresbericht bis 30. April); gesetze-im-internet.de/enwg_2005/
• DVGW G 1000: “Anforderungen an die Qualifikation und die Organisation von Unternehmen für den Betrieb von Anlagen zur leitungsgebundenen Versorgung der Allgemeinheit mit Gas und Wasserstoff”; Titel laut DVGW-Suche, dvgw.de. Regelt Organisation und Qualifikation, nicht das Protokollformat eines Einsatzes.