KI-gestützte Netzsicherheitsüberprüfung und DVGW-Compliance-Prüfung

Das echte Ausmaß des Problems

Das DVGW-Regelwerk für Gasversorgung umfasst über 200 aktive Arbeitsblätter und Merkblätter — von G 260 (Gasbeschaffenheit) bis G 600 (Errichtung von Gasleitungen in Gebäuden). Netzbetreiber müssen nicht alle davon kennen, aber sie müssen für die in ihrem Betrieb relevanten Blätter sicherstellen, dass interne Betriebsanweisungen, Prüfprotokolle und Revisionspläne dem aktuellen Stand entsprechen.

Das Problem ist das Tempo der Aktualisierungszyklen. Allein im Zeitraum 2020–2024 wurden zentrale Blätter wie G 462 (Stahlleitungen bis 16 bar), G 491 (Gasdruckregelanlagen) und G 493-1 (Qualifikationskriterien für Planer) überarbeitet. Wer keine systematische Monitoring-Routine für DVGW-Regelwerksänderungen betreibt, bemerkt eine Änderung typischerweise erst beim nächsten externen Audit — dann ist der Aufwand für Nachkorrekturen erheblich höher.

Gleichzeitig haben sich seit 2023 die Anforderungen im IT-Sicherheits- und KRITIS-Bereich deutlich verschärft. Seit dem 1. Mai 2023 sind Betreiber kritischer Infrastrukturen in Deutschland gemäß § 8a Absatz 1a BSIG verpflichtet, Systeme zur Angriffserkennung (SzA) einzusetzen und deren Betrieb alle zwei Jahre gegenüber dem BSI nachzuweisen. Für Gasnetzbetreiber bedeutet das konkret: Anomalieerkennung auf SCADA-Ebene ist keine Kür, sondern Pflicht.

Und genau dort liegt die zweite Lücke. Die meisten Fernwirksysteme im deutschen Gasnetz erzeugen täglich Millionen von Messpunkten — Druckwerte aus Gasdruckregelanlagen, Durchflussdaten, Temperaturverläufe. Manuell lassen sich diese Daten nur auf grobe Grenzwertüberschreitungen hin überwachen. Schleichende Druckabfälle, die auf eine beginnende Leckage hindeuten, oder Korrelationsmuster zwischen mehreren Sensoren, die auf einen Rohrnetzfehler hinweisen, sind für Menschen ohne algorithmische Unterstützung praktisch nicht erkennbar.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Regulatorische Pflichten: Was wirklich auf dich zukommt

Das regulatorische Umfeld für Gasnetzbetreiber ist in den letzten drei Jahren erheblich komplexer geworden. Ein realistisches Bild braucht drei Ebenen:

DVGW-Regelwerk — technische Regeln, die den “allgemein anerkannten Regeln der Technik” entsprechen. Wer DVGW-konform handelt, erfüllt zugleich die öffentlich-rechtlichen Anforderungen des EnWG. Wichtig: DVGW-Blätter sind nicht unveränderlich — G 462 wurde zuletzt März 2020 aktualisiert, G 493-1 im April 2024. Der Stand deiner Betriebsanweisungen muss mit der jeweils gültigen Fassung übereinstimmen.

BNetzA-Meldepflichten — die Bundesnetzagentur reguliert Netzzugang und Entgelte. Netzengpässe, Störungen und bestimmte Betriebsereignisse sind meldepflichtig. Die GasNZV, die den Netzzugang regelte, läuft Ende 2025 aus — danach übernimmt die BNetzA wesentliche Teile direkt durch Festlegungen. Für die Praxis bedeutet das: Wer seine Compliance-Dokumentation 2025 neu aufbaut, tut das auf einem sich verändernden Fundament.

KRITIS-Anforderungen (§ 8a BSIG, § 11 EnWG) — Gasnetzbetreiber, die mehr als 500.000 Personen versorgen, gelten als kritische Infrastruktur. Sie müssen dem BSI alle zwei Jahre nachweisen, dass sie die Anforderungen nach § 11 Absatz 1e EnWG erfüllen — inklusive des Einsatzes von Systemen zur Angriffserkennung (SzA) seit dem 1. Mai 2023. NIS2 und das KRITIS-Dachgesetz erweitern ab 2025 die Anforderungen weiter, unter anderem um explizite OT-Sicherheitsmaßnahmen.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Suchzeiteinsparung liegt vor allem bei der Audit-Vorbereitung. Der operative Effekt der Anomalieerkennung ist schwerer in Stunden zu beziffern — aber ein schleichender Druckverlust, der acht Stunden früher erkannt wird, kann einen Betriebsunterbruch verhindern, der Tage dauert.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Die KI-gestützte DVGW-Dokumentenprüfung verkürzt die Audit-Vorbereitung real von Wochen auf wenige Tage — das ist ein messbarer Hebel vor jedem Prüfzyklus. Im Tagesgeschäft ist der direkte Zeiteffekt geringer als bei Anwendungsfällen mit täglichem Durchsatz wie MAKO-Datenaustausch oder der Netzanschlusskommunikation. Deshalb Mittelfeldposition.

Kosteneinsparung — niedrig (2/5) Compliance-Kosten zu monetarisieren ist schwierig: Eine vermiedene Beanstandung spart Nachbesserungsaufwand, aber es gibt keine saubere Kausalität zwischen dem KI-Einsatz und einem ausbleibenden Bußgeld. Der ROI ist weniger eine Einsparung als eine Risikoreduktion — und Risikoreduktion ist in Unternehmensbuchhaltungen notorisch schwer zu verbuchen. In dieser Branche bleibt kosteneinsparung deshalb bewusst niedrig bewertet.

Schnelle Umsetzung — niedrig (2/5) Wer erwartet, in vier Wochen ein produktives SCADA-Anomalieerkennungssystem aufzusetzen, wird enttäuscht sein. Allein der Zugang zum Historian, die Datenbereinigung und das Training eines ersten Basismodells benötigen in der Praxis drei bis sechs Monate. Dazu kommt die KRITIS-Nachweislogik und die Anbindung der Dokumentenprüfung. Niedrige Bewertung — ehrlich vergeben.

ROI-Sicherheit — mittel (3/5) Die DVGW-Gap-Liste ist direkt prüfbar: Entweder stimmt die Betriebsanweisung mit dem Regelwerk überein oder nicht. Das macht die Qualität des KI-Outputs nachvollziehbar. Die Verbindung zwischen diesem Output und einem messbaren wirtschaftlichen Ergebnis (Bußgeld nicht gezahlt, Ausfall nicht eingetreten) bleibt jedoch indirekt. Mittelfeldposition — nicht höher, weil compliance-Nutzen keine klare Buchungszeile hat.

Skalierbarkeit — hoch (4/5) Ein einmal aufgebautes Dokumentenprüfsystem kann auf weitere DVGW-Blätter, zusätzliche Netzregionen und neue Dokumenttypen erweitert werden ohne proportionalen Mehraufwand. Gleiches gilt für die SCADA-Anomalieerkennung: Weitere Messpunkte, weitere Stationen — das Modell skaliert mit den Daten. Klarer Vorteil gegenüber manuellen Prozessen.

Richtwerte — stark abhängig von Unternehmensgröße, vorhandener Historian-Infrastruktur und Regelwerksumfang im jeweiligen Netz.

Was das System konkret macht

Es gibt hier zwei technisch verschiedene KI-Ansätze — beide sinnvoll, beide unterschiedlich komplex.

Ansatz 1: DVGW-Dokumentenprüfung per RAG

Der technische Ansatz heißt Retrieval-Augmented Generation (RAG): Das aktuelle DVGW-Regelwerk wird als maschinenlesbare Wissensbasis indexiert. Betriebsanweisungen, Prüfprotokolle und Wartungspläne des Netzbetreibers werden hochgeladen. Das System vergleicht automatisch den Inhalt jedes Dokuments mit den relevanten Anforderungen der zutreffenden DVGW-Blätter und erstellt eine Lückenliste — mit Fundstelle im Regelwerk und Handlungsempfehlung.

In der Praxis sieht das so aus: Das System analysiert die Betriebsanweisung für Druckregelanlagen und erkennt, dass Punkt 4.2 zur Prüfhäufigkeit noch auf G 491 (2017) basiert, während die aktuelle Fassung von 2022 für diesen Anlagentyp eine veränderte Prüfintervallvorgabe enthält. Es markiert das Dokument, nennt den konkreten Paragraphen und schlägt eine Formulierung für die überarbeitete Fassung vor — zur menschlichen Prüfung und Freigabe.

Ansatz 2: SCADA-Anomalieerkennung per Machine Learning

Machine Learning-Modelle werden auf historischen Zeitreihendaten des Historians trainiert — Druck, Durchfluss, Temperatur über Monate oder Jahre. Das Modell lernt das “normale” Verhalten des Netzes: saisonale Muster, tagesganglinie-bedingte Schwankungen, bekannte Wartungsfenster. Abweichungen davon werden als Anomalien markiert — priorisiert nach Schwere und Persistenz.

Der entscheidende Unterschied zu klassischen Grenzwertalarmen: Ein Predictive Analytics-System kann einen schleichenden Druckabfall von 2 mbar über 18 Stunden erkennen — weit unterhalb manueller Schwellenwerte —, bevor er die 50-mbar-Alarmgrenze erreicht. Sensewaves hat in einem Pilotprojekt mit einem weltweit führenden Gasunternehmen (250 Leitungsabschnitte, ca. 5.000 km) eine Erkennungsrate von 95–99 % bei gleichzeitiger Reduktion der Fehlalarme um Faktor 45–90 im Vergleich zu anderen ML-Methoden erzielt.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Konkrete Werkzeuge — was wann passt

Die Werkzeugwahl hängt davon ab, welchen der beiden Ansätze du zuerst angehen willst — und was schon an Infrastruktur vorhanden ist.

Dokumentenprüfung (DVGW-Compliance-Review)

Für die reine Dokumentenprüfung ohne eigene IT-Infrastruktur kannst du mit einem strukturierten Prompt in Claude oder ChatGPT beginnen: DVGW-Blatt als PDF hochladen, Betriebsanweisung hochladen, vergleichen lassen. Das ist kein produktionsfähiges System, aber ein tauglicher erster Proof-of-Concept — ohne Investition in Infrastruktur. Für produktive Nutzung mit mehreren Dokumenten und einem auditfähigen Protokoll brauchst du ein dediziertes RAG-System auf einer kontrollierten Infrastruktur.

SCADA-Historian und Anomalieerkennung

AVEVA PI System ist für viele mittlere und große Gasnetzbetreiber bereits vorhanden — es ist der De-facto-Standard für industrielle Zeitreihendaten in der deutschen Energieversorgung. Wenn PI als Historian läuft, ist die Datenbasis für Anomalieerkennung schon da. Seeq verbindet sich direkt mit AVEVA PI und ermöglicht Prozessingenieuren ohne Data-Science-Hintergrund die visuelle Korrelationsanalyse und den Aufbau erster Anomalie-Detektionsmodelle — ca. 1.000–1.200 USD/Nutzer/Jahr. Für Teams mit Python-Kenntnissen können über Seeq Data Lab eigene ML-Modelle direkt auf den historischen Daten trainiert werden.

Wer keinen AVEVA PI-Historian hat oder eine modernere, cloud-unabhängige Alternative sucht: InfluxDB ist eine Open-Source-Zeitreihendatenbank, die on-premise betrieben werden kann und sich damit für KRITIS-relevante Daten eignet (die Cloud-Version hostet Daten auf US-Servern — für KRITIS-Anwendungen nicht empfehlenswert). Grafana ergänzt InfluxDB als Dashboard- und Alert-Schicht und bringt seit 2024 eigene ML-gestützte Anomalieerkennung mit. Beide zusammen sind keine Enterprise-Lösung wie AVEVA PI, aber für kleinere Netzbetreiber ein kostengünstiger und datenschutzkonformer Einstieg.

Für die ML-Modellierung auf Historian-Daten bietet Azure Machine Learning eine etablierte Cloud-Plattform — EU-Hosting in Frankfurt verfügbar. Verbindung zum AVEVA PI via REST-API; geeignet für Teams, die eigene Anomalie-Modelle mit Python oder AutoML trainieren und kontinuierlich in Betrieb nehmen wollen.

Wann welcher Ansatz

• Nur Dokumentenprüfung, kein Historian → Start mit Claude/ChatGPT Prompt-basiert, dann RAG-System aufbauen
• AVEVA PI vorhanden → Seeq für Anomalieerkennung und Root-Cause-Analyse
• Kein AVEVA PI, on-premise Pflicht → InfluxDB + Grafana + Python-ML
• Historian vorhanden, ML-Modelle professionalisieren → Azure Machine Learning als Modell-Backend

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Das Alert-Fatigue-Problem: Wenn das System zu laut wird

Das größte operative Risiko bei SCADA-Anomalieerkennung ist nicht, dass das System zu wenig findet — sondern dass es zu viel findet.

Schlecht kalibrierte oder mit unzureichenden Trainingsdaten aufgebaute ML-Modelle erzeugen eine Flut von Fehlalarmen. Operatoren, die täglich dutzende Anomalie-Meldungen erhalten, von denen 80 Prozent sich als normale Netzfluktuationen herausstellen, beginnen systematisch, die Alerts zu ignorieren. Dieses Phänomen heißt Alert-Fatigue — und es macht das gesamte System wertlos, weil der eine echte Alarm im Rauschen untergeht.

Forschungsarbeiten zu SCADA-ML-Anomalieerkennung zeigen: Viele ML-Frameworks liefern hohe Recall-Werte (sie finden die Anomalien), aber sehr niedrige Precision (die Hälfte der Meldungen ist falsch). Das Verhältnis verschlechtert sich bei saisonalen Lastveränderungen — wenn das Modell gelernt hat, wie das Netz im Sommer aussieht, meldet es normales Winterverhalten als Anomalie.

Was konkret dagegen hilft:

• Saisonale Basislinien im Modell — nicht ein globales “Normal”, sondern getrennte Referenzwerte für Winter/Sommer/Übergangszeit
• Persistenzfilter — eine Anomalie gilt erst dann als relevant, wenn sie über mehr als X Minuten anhält, nicht nach einem einzelnen Ausreißermesswert
• Confidence-Scores statt binärer Alerts — das System meldet “Anomalie-Score 0.73” und nicht “ALARM” — Operatoren lernen, die Schwelle zu kalibrieren
• Feedback-Loop — Operatoren markieren False Positives direkt im System, das Modell wird kontinuierlich auf dieser Grundlage nachtrainiert

Sensewaves, die ein Pilotprojekt bei einem weltweit führenden Gasunternehmen durchgeführt haben, erzielte eine Falsch-Alarm-Reduktion von Faktor 45 bis 90 gegenüber Standard-ML-Verfahren — durch genau diese Art von adaptivem Alert-Design.

Datenschutz und Datenhaltung

SCADA-Zeitreihendaten sind in aller Regel keine personenbezogenen Daten im Sinne der DSGVO — Druckmesswerte eines Rohrleitungsabschnitts betreffen keine natürlichen Personen. Relevant wird DSGVO jedoch dann, wenn Mitarbeiterdaten, Zutrittsprotokolle oder Schichtpläne zusammen mit Betriebsdaten verarbeitet werden.

Kritisch ist das Thema Datenhaltung aus einem anderen Grund: KRITIS-relevante OT-Daten (SCADA, Fernwirktechnik) sollten nicht auf US-gehosteten Cloud-Diensten verarbeitet werden. Das BSI empfiehlt für kritische Infrastruktur grundsätzlich On-Premises- oder explizit EU-gehostete Lösungen. Konkret bedeutet das:

• AVEVA PI System: on-premises oder AVEVA Connect mit expliziter EU-Azure-Region — empfehlenswert für KRITIS
• InfluxDB OSS: on-premises, volle Datenkontrolle — geeignet für KRITIS
• Grafana OSS: on-premises selbst betrieben — geeignet für KRITIS; Grafana Cloud (Frankfurt) bedingt geeignet, wenn EU-Region aktiv gewählt
• Seeq: EU-Hosting-Option verfügbar — vor Vertragsschluss explizit schriftlich bestätigen lassen
• Azure Machine Learning: EU-Region Frankfurt (eu-central-1) wählbar — geeignet bei explizit konfigurierter EU-Region
• ChatGPT / Claude als Consumer-Dienste: nicht für echte Betriebsanweisungen oder SCADA-Daten verwenden — ausschließlich für anonymisierte Proof-of-Concept-Tests

Für Betriebsanweisungen, die DVGW-sicherheitstechnische Inhalte enthalten: Diese sind typischerweise nicht personenbezogen, aber können betriebsinterne Sicherheitskonzepte enthalten. Ein Auftragsverarbeitungsvertrag (AVV) ist mit jedem Cloud-Anbieter abzuschließen, sobald betriebliche Dokumente auf externen Servern verarbeitet werden.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Was es kostet — realistisch gerechnet

Dokumentenprüfung (DVGW-Compliance-Review)

Ein einfaches, anforderungsgerechtes RAG-System für DVGW-Dokumente kann ein kleines Unternehmen mit vorhandener Cloud-Infrastruktur für 5.000–15.000 Euro Einrichtungsaufwand aufbauen — wenn das interne Know-how vorhanden ist. Ein externer Dienstleister mit OT-Erfahrung liegt typisch bei 15.000–50.000 Euro für Konzeption, Indexierung des Regelwerks und Anbindung der Dokumentenverwaltung. Laufende Kosten: 200–800 Euro/Monat für Cloud-Infrastruktur und LLM-API-Nutzung.

SCADA-Anomalieerkennung

Das ist der teurere Teil — weil die Infrastruktur teurer ist:

• AVEVA PI System (wenn noch nicht vorhanden): Basisdeployment im fünfstelligen Euro-Bereich pro Jahr; Enterprise-Installationen sechsstellig bis siebenstellig
• Seeq als Analyselayer: ca. 1.000–1.200 USD/Nutzer/Jahr für die Workbench-Lizenz; Data Lab-Modul zusätzlich
• InfluxDB OSS + Grafana OSS (on-premises): keine Lizenzkosten, aber Serverinfrastruktur (1.000–3.000 Euro/Jahr) und erheblicher Implementierungsaufwand intern oder durch Dienstleister (15.000–40.000 Euro)
• Azure ML für Modelltraining und Deployment: nutzungsbasiert, für erste Anomalie-Modelle ca. 500–1.500 Euro/Monat

Was du dagegen rechnen kannst

Hier ist Ehrlichkeit gefragt: Bei der Dokumentenprüfung lässt sich der Nutzen kaum in Euro fassen, solange keine Beanstandung eingetreten ist. Ein externer Audit mit Nachbesserung kostet typisch 5.000–30.000 Euro in interner Arbeitszeit — aber das ist ein Schaden, den das System verhindert haben soll, nicht ein Einsparung, die sich buchen lässt.

Bei der SCADA-Anomalieerkennung ist das Kalkül schärfer: Ein nicht erkannter Rohrleitungsschaden, der zu einem ungeplanten Betriebsunterbruch führt, kostet Netzbetreiber in der Regel mehrere zehntausend Euro — allein die Reparaturkosten, ohne die regulatorischen Konsequenzen. Wer das Verhältnis von Investition zu Schadenspotenzial rechnen will, braucht historische Schadensdaten aus dem eigenen Netz.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Drei typische Einstiegsfehler

1. Mit dem falschen Ansatz beginnen. Das Naheliegende für viele Netzbetreiber ist der Einstieg mit einem generischen KI-Tool — ein LLM, dem man eine Betriebsanweisung und ein DVGW-Blatt zeigt und fragt, ob sie übereinstimmen. Das funktioniert als Proof-of-Concept, aber nicht in der Praxis: Halluzinationen sind bei Fließtext möglich, der Output ist nicht auditierbar, und ohne strukturierte Wissenbasis werden subtile Abweichungen (geänderte Prüfhäufigkeiten, neue Toleranzwerte) übersehen. Ein strukturiertes RAG-System mit kontrollierter Wissensbasis ist der einzige Weg zu verlässlichen Ergebnissen.

2. Die SCADA-Anomalieerkennung ohne saubere Trainingsdaten starten. ML-Modelle lernen, was “normal” ist. Wenn die Trainingsdaten aus einem Zeitraum stammen, in dem Drucksensoren ausgefallen waren, Messwerte manuell korrigiert wurden oder ein Großabnehmer im Netz seinen Betrieb eingestellt hat — lernt das Modell eine Normalität, die nicht mehr zutrifft. Die Folge: übermäßige Fehlalarme oder systematische Nicht-Erkennung. Vor dem Training muss ein Dateningenieur oder OT-Experte die Historian-Daten auf Lücken, Drifts und bekannte Sonderereignisse durchsuchen und annotieren. Dieser Schritt wird regelmäßig unterschätzt.

3. Das System einrichten und sich nie mehr darum kümmern. Das ist der Fehler, der am teuersten kommt — weil er still passiert. Gasnetzanlagen ändern sich: Neue Abnehmer gehen ans Netz, Druckregelanlagen werden ersetzt, Pipelineabschnitte werden stillgelegt. Ein SCADA-Anomalie-Modell, das auf dem Zustand des Netzes von vor zwei Jahren trainiert wurde, wird zunehmend schlechter — ohne dass es laut darüber klagt. Es gibt weiterhin Outputs, die immer weniger mit der Realität übereinstimmen. Lösung: Quartalsweise Modell-Performance-Reviews, mindestens ein Retraining pro Jahr und ein klares Verfahren für das Einarbeiten von Netzveränderungen in die Trainingsbasis.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

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

Wer dieses Projekt intern antreibt, begegnet erfahrungsgemäß zwei Widerstandsmustern:

Das Kompetenz-Territorium. In jedem Netzbetrieb gibt es erfahrene Netzplaner und Betriebsmeister, die die DVGW-Regeln und die Eigenarten des Netzes seit Jahren kennen. Wenn ein KI-System behauptet, dass eine ihrer Betriebsanweisungen nicht konform ist, werden sie das hinterfragen — zu Recht. Ein KI-Audit ist keine Ablösung für fachliche Kompetenz, sondern eine Checkliste, die systematisch durchgeht, was Menschen in der Routine übersehen. Wer das Projekt als “das System sagt, ihr macht es falsch” kommuniziert, hat verloren. Richtig kommuniziert: “Damit müssen wir vor der Prüfung nicht mehr drei Wochen lang alles manuell durcharbeiten.”

Die Schwarze-Kiste-Skepsis. Compliance-Manager und externe Prüfer wollen nachvollziehen können, warum das System etwas als Abweichung klassifiziert hat. “Die KI hat das gesagt” ist kein auditierter Nachweis. Das RAG-System muss für jede gemeldete Lücke die genaue Fundstelle im DVGW-Blatt und den konkreten Wortlaut der Betriebsanweisung angeben — und die menschliche Freigabe jeder Bewertung muss protokolliert sein. Damit wird die KI zum Rechercheassistenten mit Dokumentationsfunktion, nicht zum autonomen Entscheider.

Was konkret hilft:

• Einen erfahrenen Netzingenieur zum Co-Entwickler machen — er liefert die Domain-Logik, was welches DVGW-Blatt für welchen Anlagentyp relevant ist
• Die ersten drei Monate ausschließlich mit historischen Prüfprotokollen testen — Fälle, für die das Ergebnis schon bekannt ist
• Jede KI-Bewertung braucht eine namentlich verantwortliche Person für die finale Freigabe — im Protokoll festhalten

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Realistischer Zeitplan mit Risikohinweisen

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Häufige Einwände — und was dahintersteckt

„Wir haben bei den letzten drei Audits keine Beanstandungen gehabt.” Dann habt ihr entweder sehr gute interne Prozesse — oder ihr hattet Glück mit dem Prüfschwerpunkt. DVGW-Audits sind Stichproben, keine Vollprüfungen. Ein System, das systematisch alle relevanten Blätter gegen alle Betriebsanweisungen prüft, macht keine Stichproben. Die Frage ist nicht “haben wir Beanstandungen bekommen?”, sondern “haben wir Lücken?”.

„Für KRITIS-Daten können wir keine Cloud-KI verwenden.” Das ist ein richtiger Reflex, aber kein Totschlagargument. Der Ansatz der DVGW-Dokumentenprüfung kann vollständig on-premises oder auf einem deutschen Cloud-Anbieter laufen. InfluxDB OSS und Grafana können on-premises betrieben werden. AVEVA PI System ist als On-Premises-System ausgelegt. Die Werkzeuge existieren, die Architekturentscheidung ist lösbar — sie muss früh im Projekt getroffen werden.

„Wir haben kein KI-Knowhow intern.” Das ist der realistischste Einwand. SCADA-Anomalieerkennung mit ML setzt interne oder externe OT-/Data-Science-Kompetenz voraus — das ist nicht wegzureden. Die Dokumentenprüfung dagegen ist mit einem gut konfigurierten RAG-System handhabbar, wenn ein Dienstleister die Infrastruktur aufbaut. Wer keinen internen Champion hat, der das System dauerhaft betreuen kann, sollte zunächst mit der Dokumentenprüfung starten — das ist wartungsärmer als ein SCADA-ML-System.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Woran du merkst, dass das zu dir passt

Signale, die passen:

• Ihr bereitet DVGW-Audits aktuell durch manuelle Durchsicht von Betriebsanweisungen vor — das dauert Wochen und mehrere Personen
• Euer Fernwirksystem erzeugt täglich tausende Messpunkte, die ihr nur auf Grenzwertüberschreitungen überwacht — schleichende Anomalien fallen euch nicht auf
• Ihr müsst als KRITIS-Betreiber dem BSI den Betrieb von SzA (Systemen zur Angriffserkennung) nachweisen und seid in der Vorbereitung
• Ein neues DVGW-Blatt erscheint und ihr braucht Wochen, um zu wissen, welche eurer Dokumente betroffen sind
• Der nächste externe Prüftermin ist in weniger als sechs Monaten und ihr habt keinen systematischen Abgleich gemacht

Drei harte Ausschlusskriterien — wann es sich (noch) nicht lohnt:

1. Zu kleiner Netzbetreiber (unter KRITIS-Schwelle). Netzbetreiber, die weniger als 500.000 Personen versorgen, unterliegen nicht automatisch der KRITIS-SzA-Pflicht nach § 8a BSIG. Ohne diese Compliance-Verpflichtung fehlt einer der stärksten ROI-Treiber. Für kleinere Netzbetreiber ist ein Excel-basierter DVGW-Regelwerks-Tracker oft der realistischere erste Schritt.

2. Kein Historian mit Mindesthistorie. Wer keinen laufenden SCADA-Historian (AVEVA PI, InfluxDB oder vergleichbar) mit mindestens zwölf Monaten sauberer, lückenloser Betriebsdaten hat, kann kein sinnvolles Anomalie-Erkennungsmodell trainieren. Das Modell bräuchte zwei vollständige saisonale Zyklen, um Sommer- und Winterverhalten zuverlässig zu unterscheiden. Wer erst heute mit dem Logging anfängt, muss mindestens 18 Monate warten.

3. Keine dedizierte OT/IT-Ressource für Systempflege. Ein SCADA-Anomalie-Modell, das nach dem ersten Deployment nicht aktiv betreut wird, driftet mit dem Netz. Wenn neue Abnehmer ans Netz gehen, Druckregelanlagen ausgetauscht werden oder sich Lastprofile verändern, muss das Modell angepasst werden. Wer keine Person benennen kann, die diese Aufgabe quartalsweise übernimmt, hat nach 18 Monaten ein System, das systematisch falsch liegt — und das im KRITIS-Kontext ein regulatorisches Risiko darstellt.

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Das kannst du heute noch tun

Für den Einstieg in die DVGW-Dokumentenprüfung brauchst du weder einen Historian noch eine ML-Plattform. Nimm drei Dinge: Das aktuelle DVGW-Arbeitsblatt, das für euren Anlagentyp am relevantesten ist (z.B. G 491 für Gasdruckregelanlagen oder G 462 für Stahlleitungen), die dazugehörige Betriebsanweisung aus eurem System, und öffne Claude mit einem Enterprise-Zugang (EU-Hosting über Bedrock) oder ein Dokumentenanalyse-Tool auf eurer eigenen Infrastruktur.

Das ist kein produktionsfähiges Audit — aber in 30 Minuten bekommst du einen ersten Eindruck, ob und wo Abweichungen bestehen. Das Ergebnis zeigt dir, ob sich eine Investition in ein strukturiertes RAG-System lohnt.

Für den produktiven Einsatz ist hier ein strukturierter Prompt, den du direkt verwenden kannst:

Diese Darstellung ist eine fachliche Orientierung, kein Rechts- oder Ingenieurersatz. DVGW-Konformität, BNetzA-Meldepflichten und KRITIS-Compliance erfordern eine Prüfung durch zugelassene Sachverständige, Netzbetreiber-Compliance und ggf. die zuständige Regulierungsbehörde.

Quellen & Methodik

• DVGW-Regelwerk G 462, G 491, G 493-1: Aktuell gültige Fassungen — G 462 (März 2020), G 491 (2022), G 493-1 (April 2024). Quelle: DVGW-Regelwerk online (dvgw-regelwerk.de) und DVGW-CERT (dvgw-cert.com). Regelwerksblätter sind kostenpflichtig; Abstracts und Bezug über DVGW-Regelwerkshop.
• KRITIS-SzA-Pflicht § 8a BSIG: BSI, “Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung” (2023); Secion GmbH, “IT-Sicherheitsgesetz 2.0: KRITIS-Unternehmen müssen Anomalieerkennung sicherstellen” (secion.de); OpenKRITIS, “Sektor Energie in NIS2 und KRITIS” (openkritis.de).
• GasNZV-Ablauf Ende 2025: VKU, “Festlegungen sollen Gasnetzzugangsverordnung ersetzen” (vku.de). Rechtsstand Mai 2026.
• Sensewaves Fallstudie Anomalieerkennung: Sensewaves, Case Study “Detection of anomalies and hazardous events affecting gas pipelines” (sensewaves.io). Pilotprojekt mit einem weltweit führenden Gasunternehmen, 250 Leitungsabschnitte / ca. 5.000 km; Erkennungsrate 95–99 %, Falschalarm-Reduktion Faktor 45–90 gegenüber Vergleichsmethoden.
• Fraunhofer IAO Gasnetzprognose: Fraunhofer IAO, “Gasnetzbetreiber verbessert Prognosegüte für Gasbedarf” (iao.fraunhofer.de).
• Alert-Fatigue bei SCADA-ML: Akademische Forschungsübersicht: Fiah, “Anomaly detection in SCADA systems using machine learning” (Mississippi State University, 2023); DeepPipeNet-Studie zu False-Positive-Reduktion: Springer Nature, “DeepPipeNet: AI-Driven Monitoring System” (2026).
• Werkzeugpreise: AVEVA PI (AVEVA-Produktseite und Branchenberichte, Stand April 2026); Seeq Workbench ca. 1.000–1.200 USD/Nutzer/Jahr (Seeq-Vertriebsinformationen, Stand April 2026).
• Dokumentationsanforderungen G 453/G 454: vionta.de, “Leitfaden zur Abnahmedokumentation nach DVGW G 453 und G 454” (2024); DVGW-Prüfungsvorschriften für Erdgasanlagen (energie-wasser-praxis 4/2009).

Du willst wissen, welche DVGW-Blätter für euren Anlagentyp priorisiert geprüft werden sollten und wie ein SzA-Nachweis für eure KRITIS-Meldung strukturiert aussehen könnte? Meld dich — das klären wir gemeinsam in einem kurzen Gespräch.