Agentic Asset-MDM: Framework für prozessautomatisierte Stammdaten im Verteilnetz

Ein tiefgreifendes technisches Framework zur automatisierten Konsistenzprüfung und agentischen Prozesssteuerung im kaufmännischen und technischen Netzmanagement. Ersetzt starre Datensilos (MaStR, GIS, CRM, Leitsysteme) durch autonome KI-Agenten, die operative Kapazitätsgrenzen in Echtzeit validieren und rechtssichere Entscheidungen (z.B. nach §8 EnWG) im Netzanschlusswesen und Redispatch ermöglichen.

• Grundlagen und Problemraum
• Das Problem des asynchronen Stammdaten-Zustands
• Forschung und Architektur
• Methodik: Agentic Asset-MDM im Netzanschlusswesen
• Die 6-Schritt-Methodik (Validierungspipeline)
• Branchen-Benchmarks & Implementierung
• Agentic MDM im Ex-Post Redispatch 2.0
• Die Abrechnungsfalle im Ex-Post Redispatch
• Proaktive Stammdaten-Heilung — Die Agenten-Logik
• Vom Notfallverfahren zur Automatisierung
• Implementierung & Architektur
• Ausblick: Energiesystemanalyse jenseits der Physik
• Wissenschaftliche Standardisierung und Data Provenance
• Das Cernion Cookbook (Best Practices in Code)

Grundlagen und Problemraum

Analyse des asynchronen Stammdaten-Zustands bei Verteilnetzbetreibern. Warum hochpräzise physikalische Netzmodelle in der Praxis an fragmentierten administrativen Datenströmen (MaStR, GIS, CRM, Leitsysteme) scheitern und wie sich dies auf die Bearbeitungsdauer von Anschlussbegehren auswirkt.

Das Problem des asynchronen Stammdaten-Zustands

Die teuerste Zeile in der Branche ist nicht im SAP. Sie fehlt dort.

Netzbetreiber verfügen über hochpräzise physikalische Rechenmodelle für ihre Stromnetze. Wir wissen exakt, wie viel Kupfer im Boden liegt und ab wann ein Transformator thermisch überlastet ist. Doch der eigentliche Engpass bei der Energiewende – sei es beim Anschluss von Rechenzentren, großen Batteriespeichern oder im Rahmen von Redispatch 2.0 – liegt heute nicht mehr in der Physik. Er liegt in den administrativen Datenströmen.

Die Stammdaten, auf deren Basis Netzanschlussbegehren bearbeitet und genehmigt (oder abgelehnt) werden, sind branchenweit über vier bis fünf isolierte Systeme fragmentiert. Der Effekt ist ein massiver semantischer Bruch zwischen dem kaufmännischen Plan-Netz (was genehmigt wurde) und dem operativen Ist-Netz (was tatsächlich physisch installiert ist).

Die Auswirkungen dieses Daten-Blindflugs sind immens. Das Energiewendekompetenz-Monitoring (EWK) der Bundesnetzagentur von 2024 zeigt dies schonungslos: Die mediane Anschlussdauer für Erneuerbare-Energien-Anlagen auf der Mittelspannungsebene liegt bei 120 Wochen (über zwei Jahre). Noch alarmierender sind die Umsetzungsquoten: Bei einzelnen Verteilnetzbetreibern (VNBs) fällt die Quote realisierter Anschlüsse auf unter 30 %. Von mehreren hundert eingereichten Anträgen werden nur wenige Dutzend tatsächlich umgesetzt.

Diese Verzögerungen und Ablehnungen basieren oftmals nicht auf echtem Kupfermangel, sondern auf fehlender Datenintegrität. Wer Anschlüsse verweigert, muss dies rechtssicher begründen können – und das funktioniert nicht mit asynchronen Daten.

---

Vier Systeme. Ein Netzknoten. Null Konsistenz.

Um das Problem zu greifen, müssen wir die typische Systemlandschaft eines Verteilnetzbetreibers betrachten. Es ist ein klassischer Datenfluss ohne zentrale Wahrheit:

1. MaStR (Marktstammdatenregister): Die regulatorische Registrierung.
2. GIS (Geoinformationssystem): Die physische Topologie und Verortung.
3. CRM / ERP (z. B. SAP): Die kaufmännische Zuordnung und Vertragsdaten.
4. Netzleitsystem: Der operative Zustand.

Der Schlüssel-Insight: Jedes dieser Systeme hat einen eigenen „Master Record“ für exakt denselben physischen Netzknoten.

Stellen wir uns vor, ein 5-MW-Batteriespeicher beantragt einen Anschluss auf der Mittelspannungsebene. Der Netzbetreiber muss nun die bestehende Auslastung des betroffenen Netzknotens bewerten. Die Daten dafür liegen jedoch in Systemen mit völlig unterschiedlichen Aktualisierungszyklen. Eine Anlage kann im MaStR bereits registriert sein, fehlt aber noch im GIS. Oder sie ist im GIS verortet, wird im ERP aber noch dem alten Betreiber zugeordnet.

Diesen Zustand nennen wir den asynchronen Stammdaten-Zustand.

System	Datenhoheit	Typischer blinder Fleck (Delta)
MaStR	Regulatorische Meldung	Anlage ist “In Betrieb” gemeldet, aber physisch noch gar nicht am Netz.
GIS	Geodaten & Topologie	Fehlende oder veraltete Zuordnung von Neuanlagen zum korrekten Abgang.
ERP (SAP)	Kaufmännische Verträge	Gekündigte Verträge blockieren fiktiv weiterhin Netzkapazität.
Netzleitsystem	Echtzeit-Betrieb	Kennt nur Anlagen mit Telemetrie (oft erst ab bestimmten Leistungsklassen).

Wenn diese vier Systeme manuell oder nur über nächtliche, dumme Batch-Exporte synchronisiert werden, ist eine rechtssichere Ablehnung eines Anschlussbegehrens nahezu unmöglich. Der Netzbetreiber läuft Gefahr, einer strukturellen Vertauschung aufzusitzen: Er lehnt ab, weil das kaufmännische Plan-Netz voll ist, obwohl das operative Ist-Netz noch massive Kapazitäten (z.B. durch nie gebaute, aber genehmigte Anlagen) aufweist.

---

§8 EnWG und EWK-Monitoring: Warum Datenqualität jetzt haftungsrelevant ist

Dieser asynchrone Stammdaten-Zustand wird zunehmend zum rechtlichen Risiko. Der Netzbetreiber hat eine gesetzliche Anschlusspflicht nach § 8 EnWG. Eine Ablehnung ist nur unter engen, nachweisbaren Voraussetzungen zulässig.

Das BNetzA-EWK-Monitoring quantifiziert erstmals transparent, wie Netzbetreiber hier performen. Wenn der schnellste VNB auf Mittelspannung EE-Anlagen in 4 Wochen anschließt, das schlechteste Quartil aber über 236 Wochen (4,5 Jahre) benötigt, steigt der Erklärungsdruck enorm.

Netzbetreiber, die Anschlüsse ablehnen oder extrem verzögern, müssen ihre Datenbasis künftig gerichtsfest verteidigen können. Und zwar nicht retrospektiv mit mühsam zusammenkopierten Excel-Tabellen, sondern mit einer auditierbaren, konsistenten Kapazitätsbewertung zum exakten Zeitpunkt der Entscheidung.

Forschung und Architektur

Souveräner Datenaustausch und die Interoperabilitäts-Lücke: Warum Data Spaces Agentic MDM benötigen

Die Vision einer All Electric Society erfordert eine radikale Dezentralisierung und Digitalisierung der Energieströme. In diesem Kontext werden föderierte Datenökosysteme wie Gaia-X und sektorspezifische Initiativen wie Energy-Data-X als das Rückgrat für einen souveränen Datenaustausch zwischen Erzeugern, Netzbetreibern und Prosumern gehandelt. Doch während die akademische und politische Debatte sich auf die Architektur dieser "Daten-Pipelines" konzentriert, bleibt die physikalische und administrative Realität der Verteilnetzbetreiber (VNB) oft unberücksichtigt.

Die Reality-Check-Barriere: Das "Garbage In, Garbage Out"-Paradoxon

Das Versprechen verteilter Datenräume basiert auf der Annahme, dass die beteiligten Akteure über konsistente, maschinenlesbare Informationen verfügen, die sie souverän teilen können. Die operative Praxis bei VNBs offenbart jedoch eine tiefgreifende System-Asynchronität.

Stammdaten sind heute über isolierte Silos wie das Marktstammdatenregister (MaStR), Geoinformationssysteme (GIS), ERP-Systeme (SAP) und Netzleitsysteme fragmentiert. Besteht zwischen diesen Systemen ein semantischer Bruch, führt die Integration in einen Data Space unweigerlich zu einer Skalierung von Fehlern in Echtzeit:

Ein Data Space ohne lokale Datenvalidierung transportiert lediglich "Garbage In, Garbage Out" mit Hochgeschwindigkeit. Agentic Asset-MDM fungiert hier als notwendige "Wasseraufbereitungsanlage" an der Quelle, bevor Daten in die globale Pipeline fließen.

Agentic MDM als Enabler der FAIR-Prinzipien

Um den Anforderungen des modernen Forschungsdatenmanagements (FDM) und der Energiewende gerecht zu werden, müssen Daten den FAIR-Prinzipien (Findable, Accessible, Interoperable, Reusable) entsprechen. Unser Framework transformiert chaotische Netzdaten durch eine autonome Validierungspipeline in FAIR-Data:

Resilienz und Cyber-Security in der KRITIS-Umgebung

Für Stadtwerke als Betreiber kritischer Infrastrukturen (KRITIS) stellt die Öffnung hin zu externen Data Spaces ein potenzielles Sicherheitsrisiko dar. Agentic MDM adressiert diese Sorge durch eine lokale Schutzschicht:

Fazit: Die technologische Vorbedingung für Energy-Data-X

Data Spaces wie Energy-Data-X bieten die Infrastruktur für die Energiewelt von morgen. Doch ihre Leistungsfähigkeit steht und fällt mit der Qualität der eingespeisten Daten.

Agentic Asset-MDM ist nicht bloß ein weiteres Tool zur Datenpflege; es ist die zwingende technische Vorbedingung, um die theoretische Souveränität von Datenräumen in die operative Exzellenz der All Electric Society zu übersetzen.

Im Rahmen der Themengruppe 4 des Forschungsnetzwerks Energiesystemanalyse (FNE) treiben wir die methodische Verknüpfung von administrativer Datenintegrität und autonomer Prozesssteuerung voran, um die administrative Lücke der Energiewende endgültig zu schließen.

Für weitere Informationen zur Implementierung dieser Methodik verweisen wir auf die schlüsselfertigen Lösungen von Cernion, die diesen agentischen Ansatz bereits heute in die operative Praxis von Verteilnetzbetreibern überführen.

Methodik: Agentic Asset-MDM im Netzanschlusswesen

Analyse des asynchronen Stammdaten-Zustands bei Verteilnetzbetreibern. Warum hochpräzise physikalische Netzmodelle in der Praxis an fragmentierten administrativen Datenströmen (MaStR, GIS, CRM, Leitsysteme) scheitern und wie sich dies auf die Bearbeitungsdauer von Anschlussbegehren auswirkt.

Die 6-Schritt-Methodik (Validierungspipeline)

Vom statischen Datenabgleich zum autonomen Validierungsagenten

Die vorangegangene Analyse zeigt, dass das Problem nicht in einem einzelnen Datenfehler liegt, sondern in der systemischen Asynchronität zwischen den Quellsystemen. Ein manueller Abgleich skaliert nicht, ist nicht auditierbar und wiederholt sich bei jedem neuen Anschlussbegehren von vorn.

Agentic Asset-MDM ersetzt diesen manuellen Prozess durch eine formalisierte, sechsstufige Validierungslogik, die von einem autonomen Softwareagenten kontinuierlich durchlaufen wird. Der Agent operiert nicht auf Anfrage (Request-Response), sondern permanent: Er traversiert die Datenquellen in einem definierten Zyklus, erkennt Inkonsistenzen eigenständig und bereitet Entscheidungsgrundlagen vor, bevor ein menschlicher Sachbearbeiter den Vorgang überhaupt öffnet.

Die sechs Schritte bilden eine deterministische Pipeline, deren Ergebnis ein maschinenlesbares Entscheidungsobjekt ist. Im Folgenden wird die Pipeline anhand des Fallbeispiels durchlaufen: Ein Netzanschlussbegehren für einen 5-MW-Batteriespeicher auf Mittelspannungsebene.

---

Schritt 1: Bestandsinventur — Autonomer Quellenabgleich

Der Agent gleicht die Einträge des Marktstammdatenregisters (MaStR) gegen die GIS-Daten und das ERP ab. Das Ergebnis ist ein Delta-Report:

{
 "agent": "agentic-asset-mdm",
 "step": "01_inventory_reconciliation",
 "grid_node": "UW-Mitte_MS-Abgang_04",
 "timestamp": "2026-03-28T06:14:22Z",
 "sources_reconciled": ["mastr", "gis", "erp"],
 "reconciled_capacity_kw": {
   "confirmed_active": 2140,
   "disputed": 1650,
   "requires_manual_review": 3
 },
 "deltas": [
   {
     "type": "status_conflict",
     "mastr_id": "SEE900487263910",
     "capacity_kw": 180,
     "status_mastr": "InBetrieb",
     "status_erp": "Vertrag_gekuendigt",
     "note": "MaStR zeigt aktiv, ERP zeigt gekündigten Vertrag seit 2025-06."
   }
 ]
}

Der Agent unterscheidet strikt zwischen bestätigter und strittiger Kapazität und quantifiziert die Latenz der Inkonsistenzen.

---

Schritt 2: Kapazitätsbewertung — Aggregation gegen Auslegungsgrenzen

Der Agent berechnet die elektrische Auslastung des Netzabgangs. Er aggregiert die bestätigten Anlagenleistungen (z.B. 2.140 kW) und setzt sie ins Verhältnis zur Auslegungsgrenze des Transformators (z.B. 10 MVA).

---

Schritt 3: Gleichzeitigkeitsfaktoren — Anlagentyp-spezifische Korrektur

Die nominale Auslastung aus Schritt 2 überschätzt die Realität. Agentic Asset-MDM verwendet daher anlagentyp-spezifische Gleichzeitigkeitsfaktoren (z.B. PV: 0,8 | Wallbox: 0,2). Der Agent wendet diese Faktoren auf den Bestand an und berechnet die gleichzeitigkeitskorrigierte Auslastung.

---

Schritt 4: Go/No-Go — Dreistufiges Entscheidungsraster

Der Agent klassifiziert das Ergebnis:

1. Direktanschluss (Restkapazität > 20 %)
2. Bedingter Anschluss (Restkapazität 10–20 %, z.B. §14a-Steuerung)
3. Netzausbau erforderlich (Restkapazität < 10 %)

Das System erzeugt ein auditierbares Entscheidungsobjekt:

{
 "agent": "agentic-asset-mdm",
 "step": "04_go_no_go_decision",
 "grid_node": "UW-Mitte_MS-Abgang_04",
 "decision": {
   "classification": "STUFE_1_DIREKTANSCHLUSS",
   "data_quality_flag": "YELLOW",
   "data_quality_note": "Entscheidung basiert auf bestätigter Kapazität. Bei Auflösung der strittigen Deltas (1.650 kW) zugunsten höherer Ist-Last verbleibt Restkapazität bei 21.0% (Stufe 1 stabil)."
 },
 "audit_trail": {
   "sources_used": ["mastr_2026-03-28", "gis_2026-03-15", "erp_2026-03-27"]
 }
}

Das Feld data_quality_flag quantifiziert die Unsicherheit. Die Entscheidung ist revisionssicher, da exakt dokumentiert ist, auf welcher Datenbasis sie getroffen wurde.

---

Schritt 5: Alternativ-Anschlusspunkte

Führt Schritt 4 zu einem “No-Go”, identifiziert der Agent automatisch benachbarte Netzknoten mit höherer Restkapazität basierend auf der GIS-Topologie.

---

Schritt 6: Kosten- und Zeitlinien-Prognose

Abschließend aggregiert die Pipeline die Ergebnisse zu einer Aufwands- und Zeitschätzung (z.B. 15.000 – 50.000 € / 12 – 30 Wochen für Mittelspannung) als erste Planungsgrundlage für den Antragsteller.

Branchen-Benchmarks & Implementierung

EWK-Monitoring 2024 — Der Status Quo in Zahlen

Seit dem Berichtsjahr 2024 erfasst die Bundesnetzagentur im Rahmen des Energiewendekompetenz-Monitorings (EWK) erstmals systematisch, wie schnell und wie vollständig Verteilnetzbetreiber Netzanschlussbegehren bearbeiten.

Anschlussdauer: Mediane Wartezeiten nach Spannungsebene

Kategorie	Anzahl VNBs	Q25	Median	Q75	Maximum
EE-Anlagen, Niederspannung	740	20 Wo	40 Wo	65 Wo	285 Wo
EE-Anlagen, Mittelspannung	502	50 Wo	120 Wo	236 Wo	1.102 Wo
Verbrauchsanlagen, Niederspannung	708	16 Wo	30 Wo	51 Wo	385 Wo

Die Spreizung ist enorm: Auf Mittelspannungsebene schließen die schnellsten Verteilnetzbetreiber EE-Anlagen in 4 Wochen an, während das schlechteste Quartil über 236 Wochen benötigt.

Umsetzungsquote: Wie viele Anschlussbegehren werden realisiert?

Kategorie	Anzahl VNBs	Q25	Median	Mittelwert	Minimum
EE-Anlagen, Mittelspannung	288	57,1 %	100 %	78,1 %	1,1 %
EE-Anlagen, Hochspannung	17	9,0 %	100 %	57,3 %	0,4 %
Verbrauchsanlagen, Niederspannung	668	54,2 %	100 %	77,4 %	1,2 %

Quelle: BNetzA EWK-Monitoring 2024 via vnb-transparenz.de.

Das untere Quartil bei Verbrauchsanlagen auf Niederspannung beginnt bei 54,2 %. Mindestens ein Viertel aller VNBs realisiert weniger als die Hälfte der eingereichten Begehren. Wenn Netzbetreiber mit vergleichbaren Netzstrukturen um den Faktor 50 bei der Anschlussdauer auseinanderliegen, ist die physische Netzkapazität nicht der primäre Erklärungsfaktor. Es ist die Geschwindigkeit und Konsistenz der administrativen Bearbeitung.

---

Nächste Schritte: Von der Erkenntnis zur Implementierung

Der Weg vom heutigen Zustand zu einem konsistenten, auditierbaren Datenbestand lässt sich auf drei Stufen beschreiben:

Option 1: Manueller Abgleich (Status Quo). Exporte aus Einzelsystemen, Abgleich in Excel. Skaliert nicht mit der Energiewende und führt zu den extremen Bearbeitungszeiten des EWK-Monitorings.

Option 2: Klassisches MDM (Batch-basiert). Ein Master-Data-Management-System synchronisiert in Intervallen (täglich/wöchentlich). Verbessert die Qualität, bleibt aber reaktiv: Inkonsistenzen werden erst beim nächsten Batch erkannt und von Menschen manuell geheilt.

Option 3: Agentic Asset-MDM (autonom, kontinuierlich). Ein agentisches System traversiert die Datenquellen permanent, erkennt Inkonsistenzen in Echtzeit und heilt den Stammdaten-Zustand proaktiv. Die sechsstufige Validierungspipeline läuft für jeden Netzknoten autonom und erzeugt auditierbare Entscheidungsobjekte.

---

Der Aufwand: Build vs. Buy

Eine interne IT-Abteilung kann die beschriebene Pipeline auf Basis eigener Schnittstellen (MaStR-APIs, GIS-Exporte, SAP-RFC) implementieren. Der Aufwand liegt hier in der Orchestrierung der kontinuierlichen Datenheilung.

Wer diese Komplexität nicht selbst aufbauen und betreiben möchte, findet mit Cernion eine schlüsselfertige B2B-SaaS-Lösung.

Cernion liefert exakt diese autonomen Validierungsagenten für Verteilnetzbetreiber “out-of-the-box” und integriert sich nahtlos in bestehende Systemlandschaften (MaStR, SAP, GIS). Die Plattform beinhaltet den kontinuierlichen Abgleich der Quellsysteme, die automatische Kapazitätsbewertung und die Erzeugung auditierbarer Entscheidungsobjekte inklusive Worst-Case-Sensitivitätsanalyse.

---

Datenquellen: BNetzA EWK-Monitoring 2024 (vnb-transparenz.de), Marktstammdatenregister (mastr.bundesnetzagentur.de). Abrufdatum: März 2026.

Agentic MDM im Ex-Post Redispatch 2.0

Konzepte zur automatisierten Fehlererkennung und Stammdaten-Heilung in Redispatch-Prozessen. Wie Agenten proaktiv fehlende BTR-Daten oder abweichende Fahrpläne identifizieren, bevor kaufmännische Abrechnungsschleifen eskalieren.

Die Abrechnungsfalle im Ex-Post Redispatch

Die Energiewende erzeugt nicht nur Strom. Sie erzeugt Abrechnungsfälle. Über 2.200 Redispatch-Maßnahmen allein im Januar 2026, mit einem Volumen von 3,3 TWh. Für jeden einzelnen Fall muss ein Verteilnetzbetreiber die Ausfallarbeit berechnen, die Entschädigungsansprüche zuordnen und die Abrechnung an den ÜNB weiterleiten. Die Physik dieser Maßnahmen ist trivial: Anlage abregeln, Leistung reduzieren, Engpass beseitigen. Die Administration ist es nicht.

Das operative Massengeschäft

Redispatch 2.0 ist seit Oktober 2021 verpflichtend. Jede Erzeugungsanlage ab 100 kW ist grundsätzlich redispatch-pflichtig. Für einen typischen städtischen Verteilnetzbetreiber bedeutet das ein Portfolio von 40 bis 80 Anlagen, die potenziell in Redispatch-Maßnahmen einbezogen werden können — Photovoltaik-Freiflächenanlagen, KWK-Anlagen, Biomassekraftwerke, Batteriespeicher und Notstromaggregate.

Jede Abregelungsmaßnahme erzeugt einen finanziellen Entschädigungsanspruch des Anlagenbetreibers. Die Ausfallarbeit — die Differenz zwischen der prognostizierten Einspeisung ohne Abregelung (Planwert) und der tatsächlichen Einspeisung während der Maßnahme (Ist-Wert) — muss berechnet, zugeordnet und abgerechnet werden. Das klingt nach einer Subtraktionsaufgabe. In der Praxis ist es ein Datenzuordnungsproblem, das über vier Systeme verteilt ist.

Die Ex-Post-Prozesskette: Wo sie bricht

Die Abrechnung einer einzelnen Redispatch-Maßnahme durchläuft einen Prozess, der sich in den meisten Verteilnetzbetreibern wie folgt darstellt:

Schritt 1: Abruf im Leitsystem. Der Übertragungsnetzbetreiber (ÜNB) oder der Verteilnetzbetreiber selbst initiiert eine Redispatch-Maßnahme. Das Netzleitsystem (SCADA) dokumentiert den Abruf: Zeitpunkt, betroffene Anlage (identifiziert über die technische Ressource), Sollwert der Leistungsreduktion und Dauer der Maßnahme.

Schritt 2: Identifikation der betroffenen Anlage. Die technische Ressource im Leitsystem muss einer kaufmännischen Einheit zugeordnet werden — dem Betreiber der technischen Ressource (BTR). Diese Zuordnung verknüpft die physische Abregelung mit dem wirtschaftlichen Anspruchsinhaber. In der Realität ist diese Zuordnung keineswegs trivial: Eine Erzeugungseinheit im MaStR kann einem anderen BTR zugeordnet sein als im ERP-System des Netzbetreibers. Der BTR kann gewechselt haben, ohne dass die Änderung in allen Systemen nachgezogen wurde.

Schritt 3: Berechnung der Ausfallarbeit. Die Ausfallarbeit ergibt sich aus dem Vergleich von Planwert (erwartete Einspeisung ohne Eingriff) und Ist-Einspeisung (gemessene Einspeisung während der Maßnahme). Der Planwert kommt typischerweise vom Einsatzverantwortlichen (EIV) oder wird vom Netzbetreiber selbst prognostiziert. Der Ist-Wert kommt aus dem Messsystem über die Marktlokation (MeLo) und den zugehörigen Zählpunkt. Beide Werte müssen derselben Anlage, demselben Zeitraum und demselben Messkonzept zugeordnet sein.

Schritt 4: Kaufmännische Abrechnung. Die berechnete Ausfallarbeit wird in das ERP-System (typischerweise SAP IS-U) überführt. Dort erfolgt die Erzeugung des Entschädigungsbetrags, die Zuordnung zum Bilanzkreis und die Erstellung der Abrechnungsnachricht im EDIFACT-Format — konkret über den Prozess der AAÜZ-Erzeugung (Ausfallarbeits-Übergangszahlungsanspruch). Die erzeugten Dateien werden per SFTP an den Übertragungsnetzbetreiber übermittelt.

Wo es in der Praxis scheitert

Dieser Vier-Schritt-Prozess funktioniert genau dann reibungslos, wenn die Stammdaten in allen beteiligten Systemen konsistent sind. Das sind sie in der Praxis selten. Die typischen Fehlermuster:

Fehlende BTR-Zuordnung. Die Anlage wurde im Leitsystem abgeregelt, aber die aktuelle BTR-Zuordnung liegt im kaufmännischen System nicht vor. Der BTR hat gewechselt (z. B. durch Verkauf der Anlage), die EDIFACT-Meldung des neuen BTR ist noch nicht verarbeitet, oder der BTR wurde im MaStR aktualisiert, aber nicht im SAP. Resultat: Die Abrechnung kann nicht erzeugt werden, weil der Zahlungsempfänger nicht identifiziert ist.

NAP-MeLo-Fehlzuordnung. Eine reale Herausforderung entsteht, wenn mehrere Erzeugungseinheiten denselben Netzanschlusspunkt (NAP) nutzen, aber unterschiedliche Marktlokationen (MeLo) haben. Ein Fernheizkraftwerk mit vier Dampfturbinen und einem Batteriespeicher kann an einem einzigen NAP angeschlossen sein, aber über vier separate MeLo-IDs verfügen. Wenn das Leitsystem die Abregelung auf NAP-Ebene dokumentiert, die Abrechnung aber auf MeLo-Ebene erfolgen muss, entsteht ein Zuordnungsproblem, das manuell aufgelöst werden muss: Welche MeLo-ID gehört zu welchem Abruf? Welcher Anteil der Leistungsreduktion entfällt auf welche Einheit?

Planwert-Ist-Wert-Diskrepanz. Der Planwert (die prognostizierte Einspeisung ohne Abregelung) stammt aus einem anderen Quellsystem als der Ist-Wert (die gemessene Einspeisung). Wenn der Planwert auf einem veralteten Erzeugungsprofil basiert — etwa weil die Anlage erweitert wurde, aber die Aktualisierung des Profils im Prognosesystem noch nicht erfolgt ist — wird die Ausfallarbeit systematisch falsch berechnet. Der Anlagenbetreiber erhält zu viel oder zu wenig Entschädigung, und die Differenz wird erst sichtbar, wenn die Monatsabrechnung im SAP läuft.

Das Notfallverfahren: Telefon und Excel

Wenn einer dieser Bruchpunkte eintritt — und in einem Portfolio von 50+ Anlagen tritt mindestens einer pro Abrechnungszyklus ein —, greifen Verteilnetzbetreiber auf das zurück, was intern als Notfallverfahren bezeichnet wird. Der Sachbearbeiter identifiziert den fehlerhaften Datensatz manuell, klärt die korrekte BTR-Zuordnung per Telefonat mit dem Einsatzverantwortlichen oder dem Anlagenbetreiber, dokumentiert die Korrektur in einer Excel-Tabelle und vermerkt den Vorgang im Betriebshandbuch.

Dieses Verfahren hat drei Eigenschaften, die es als Dauerlösung disqualifizieren. Erstens ist es nicht auditierbar: Ein Excel-Vermerk im Betriebshandbuch erfüllt nicht die Anforderungen an eine revisionssichere Dokumentation, die bei regulatorischen Prüfungen oder Streitigkeiten mit Anlagenbetreibern standhält. Zweitens skaliert es nicht: Bei steigendem Redispatch-Volumen — national hat sich das Volumen seit Einführung von Redispatch 2.0 vervielfacht — wächst die manuelle Nacharbeit linear mit der Anzahl der Maßnahmen. Und drittens ist es reaktiv: Der Fehler wird erst sichtbar, wenn die Monatsabrechnung scheitert. Wochen nach der eigentlichen Maßnahme. Wochen, in denen der fehlerhafte Datensatz weitere Folgefehler erzeugen kann.

Die Umsetzung in der SAP-Welt — intern oft als „A96-Prozess" referenziert (nach dem SAP-Transaktionscode für die AAÜZ-Erzeugung) — wird in vielen Stadtwerken als kritischster Einzelprozess im Redispatch beschrieben. Nicht wegen der technischen Komplexität der SAP-Transaktion selbst, sondern weil sie am Ende einer Datenkette steht, deren vorgelagerte Glieder nicht synchronisiert sind.

Proaktive Stammdaten-Heilung — Die Agenten-Logik

Das Timing-Problem: Warum Batch nicht reicht

Ein klassisches Master-Data-Management-System synchronisiert Datenquellen in definierten Intervallen — typischerweise einmal täglich als Nachtlauf oder wöchentlich als Batch-Abgleich. Für den Redispatch-Kontext ist das strukturell zu langsam.

Eine Redispatch-Maßnahme kann innerhalb von Minuten angewiesen und innerhalb von Stunden beendet werden. Die kaufmännische Abrechnung dieser Maßnahme muss auf Stammdaten basieren, die zum Zeitpunkt der Maßnahme aktuell waren — nicht zum Zeitpunkt des letzten Batch-Laufs. Wenn ein BTR-Wechsel am Montag wirksam wird, die Abregelung am Dienstag erfolgt und der Batch-Abgleich erst am Sonntag läuft, dann rechnet das System fünf Tage lang gegen den falschen Betreiber ab. Bei einem KWK-Werk mit 10 MW Leistung und einem Strompreis von 80 €/MWh kann die Fehlzuordnung einer einzigen achtstündigen Maßnahme einen fünfstelligen Betrag betreffen.

Der agentische Ansatz: Kontinuierlicher Abgleich statt Monatsende-Korrektur

Ein Agentic-Asset-MDM-System im Redispatch-Kontext arbeitet nach einer anderen Logik. Es wartet nicht auf den Monatsabschluss, um Fehler zu erkennen. Es traversiert die relevanten Datenquellen täglich und gleicht drei zentrale Datenschichten gegeneinander ab:

Schicht 1: Das Anlagenregister. Alle redispatch-pflichtigen Anlagen (≥ 100 kW) mit ihren aktuellen Stammdaten — MaStR-Nummer, Anlagentyp, installierte Leistung, Netzanschlusspunkt (NAP), Marktlokation (MeLo), Spannungsebene, Betriebsstatus. Die autoritative Quelle ist das MaStR, abgeglichen gegen die lokalen Daten im ERP.

Schicht 2: Die BTR-Zuordnung. Für jede Anlage muss der aktuelle Betreiber der technischen Ressource identifizierbar sein. Die relevanten Quellen sind die EDIFACT-Stammdatenmeldungen (UTILMD), das ERP-System (Vertragspartner) und das MaStR (registrierter Betreiber). Ein Agent prüft die Konsistenz dieser drei Quellen und erkennt, wenn eine Quelle von den anderen abweicht.

Schicht 3: Die Abruf-Zuordnung. Jede Redispatch-Maßnahme im Leitsystem wird gegen die kaufmännischen Stammdaten abgeglichen: Ist die abgerufene technische Ressource einer gültigen MeLo zugeordnet? Stimmt die NAP-Zuordnung? Existiert ein aktueller Planwert für die betroffene Anlage?

Wie der Agent arbeitet: Ein konkreter Prüfzyklus

Der Agent durchläuft seinen Validierungszyklus in einem festen Rhythmus — idealerweise täglich, mindestens aber vor jedem Abrechnungslauf. Jeder Zyklus prüft das gesamte redispatch-relevante Portfolio und erzeugt einen strukturierten Validierungsreport.

Das folgende Beispiel zeigt den Output eines solchen Zyklus für ein Portfolio mit 59 Anlagen und einer Gesamtleistung von 73,4 MW:

{
 "agent": "agentic-asset-mdm",
 "module": "redispatch_prevalidation",
 "cycle": "daily_0600",
 "timestamp": "2026-03-28T06:00:12Z",
 "portfolio": {
   "grid_operator": "Beispiel-VNB",
   "total_installations": 59
 },
 "validation_results": {
   "fully_consistent": 51,
   "warnings": 5,
   "critical": 3,
   "findings": [
     {
       "severity": "CRITICAL",
       "type": "MISSING_BTR_DATA",
       "mastr_id": "SEE9XXXXX482910",
       "installation_name": "PV Freiflaeche Sued",
       "capacity_kw": 2298,
       "detail": "BTR-Zuordnung im ERP abgelaufen seit 2026-02-14. MaStR zeigt neuen Betreiber. UTILMD-Meldung fehlt.",
       "impact": "AAÜZ-Erzeugung blockiert. Kein gültiger Zahlungsempfänger.",
       "days_since_inconsistency": 42,
       "recommended_action": "ESCALATE_BTR_REQUEST"
     },
     {
       "severity": "CRITICAL",
       "type": "NAP_MELO_MISMATCH",
       "nap_id": "SAN9XXXXX641336",
       "detail": "NAP versorgt 5 Erzeugungseinheiten. 4 MeLo-IDs erwartet, aber nur 3 im ERP aktiv. MeLo für Gasturbine fehlt.",
       "impact": "Abrufe an Gasturbine nicht abrechenbar.",
       "recommended_action": "RESTORE_MELO_MAPPING"
     }
   ]
 },
 "billing_readiness": {
   "ready_for_aauz": 51,
   "blocked": 3,
   "next_billing_run": "2026-04-01"
 }
}

Drei Aspekte dieses Validierungsreports sind für das Verständnis der agentischen Logik zentral:

Die Kategorie MISSING_BTR_DATA. Der Agent erkennt nicht erst am Monatsende, dass die BTR-Zuordnung für eine 2,3-MW-Anlage fehlt. Er erkennt es 42 Tage vor dem Abrechnungslauf und identifiziert die Ursache (MaStR-Update ohne korrespondierende UTILMD-Meldung). Er kann den Eskalationsprozess eigenständig anstoßen.

Die Kategorie NAP_MELO_MISMATCH. Dieses Finding zeigt ein Problem, das bei manueller Prüfung nahezu unsichtbar ist. Ein Netzanschlusspunkt versorgt fünf Erzeugungseinheiten, die über vier Marktlokationen abgerechnet werden. Wenn eine MeLo-Zuordnung verloren geht, verteilt das System die Ausfallarbeit auf die verbleibenden MeLos — mathematisch korrekt, kaufmännisch falsch. Der Agent erkennt die Diskrepanz durch den Abgleich von MaStR-NAP-Verknüpfungen.

Der zweite Agent: Tagesabgleich Abruf gegen Stammdaten

Neben dem Portfolio-Validierungsagenten arbeitet ein zweiter Agent auf der operativen Ebene: Er gleicht jede einzelne Redispatch-Maßnahme des Vortages gegen die aktuellen Stammdaten ab.

{
 "agent": "agentic-asset-mdm",
 "module": "redispatch_daily_reconciliation",
 "date": "2026-03-27",
 "reconciliation": [
   {
     "measure_id": "RD-2026-0327-002",
     "timestamp_start": "2026-03-27T14:15:00Z",
     "scada_resource": "PV_SUED_01",
     "power_reduction_kw": 1500,
     "status": "BLOCKED",
     "blocking_reason": "MISSING_BTR_DATA",
     "reference": "Portfolio finding SEE9XXXXX482910",
     "action": "Maßnahme in Quarantäne. AAÜZ-Erzeugung gesperrt bis BTR-Klärung abgeschlossen. Frist für BTR-Klärung: 2026-04-15."
   }
 ],
 "summary": {
   "matched": 2,
   "blocked": 1,
   "total_ausfallarbeit_blocked_kwh": 3375,
   "aauz_ready_with_exclusions": "1 Maßnahme in Quarantäne (PV_SUED_01). Verbleibende Maßnahmen abrechnungsfähig."
 }
}

Der entscheidende Mechanismus ist der Status BLOCKED. Der Agent lässt eine Maßnahme nicht in die AAÜZ-Erzeugung einfließen, wenn die Stammdaten-Konsistenz nicht bestätigt ist. Stattdessen wird die Maßnahme in Quarantäne gesetzt — sie wird nicht abgerechnet, nicht ignoriert und nicht manuell „zurechtgebogen". Das ist der fundamentale Unterschied zum Notfallverfahren: Der Agent verhindert, dass fehlerhafte Daten in den Abrechnungslauf gelangen.

Die Prozesskette: Von der Erkennung zur Heilung

Der agentische Ansatz im Redispatch unterscheidet drei Eskalationsstufen:

Stufe 1 — Automatische Heilung. Inkonsistenzen, die der Agent eigenständig auflösen kann (z.B. veraltete Prognoseprofile bei Anlagen-Erweiterung). Keine menschliche Interaktion erforderlich.

Stufe 2 — Angereicherte Eskalation. Inkonsistenzen, die eine menschliche Entscheidung erfordern. Beispiel: Die BTR-Zuordnung fehlt. Der Agent bereitet eine UTILMD-Anforderung vor und legt sie dem Sachbearbeiter zur Freigabe vor.

Stufe 3 — Quarantäne. Maßnahmen, die weder automatisch noch durch Eskalation rechtzeitig lösbar sind. Sie werden isoliert und aus dem regulären SAP-Lauf ausgeschlossen. Der SAP-Abrechnungslauf läuft störungsfrei für alle konsistenten Maßnahmen durch. Die Blockade des gesamten Laufes durch einen Einzelfehler ist Geschichte.

Vom Notfallverfahren zur Automatisierung

Die Ex-Post-Abrechnung im Redispatch 2.0 ist kein Randprozess. Sie ist finanziell signifikant, regulatorisch geprüft und volumetrisch wachsend. Auf nationaler Ebene wurden allein im Januar 2026 über 2.200 Redispatch-Maßnahmen mit einem Gesamtvolumen von 3,35 TWh dokumentiert — davon 83,5 % strombedingter Redispatch und 12,1 % grenzüberschreitender Countertrade. Diese Volumina sind nicht rückläufig. Sie steigen mit jedem Megawatt erneuerbarer Kapazität, das ans Netz geht.

Für den einzelnen Verteilnetzbetreiber bedeutet das: Die Anzahl der redispatch-pflichtigen Anlagen im Portfolio wächst, die Frequenz der Abrufmaßnahmen nimmt zu und die Komplexität der Stammdatenzuordnung steigt mit jeder neuen Anlage, jedem BTR-Wechsel und jeder ERP-Migration.

Das Notfallverfahren — Telefonat, Excel-Tabelle, Betriebshandbuch-Vermerk — kann in einem Portfolio von 20 Anlagen funktionieren. Es kann auch bei 40 Anlagen noch funktionieren, wenn die Personalkapazität in der Netzabrechnung entsprechend dimensioniert ist. Aber es hat drei strukturelle Grenzen, die durch mehr Personal nicht überwindbar sind.

Grenze 1: Keine präventive Wirkung. Das Notfallverfahren repariert Fehler, die bereits in der Abrechnung gelandet sind. Es verhindert nicht, dass fehlerhafte Datensätze überhaupt in den Abrechnungslauf gelangen. Jeder Fehler, der den SAP-Lauf erreicht, hat Folgekosten: manuelle Korrektur, Nachbuchung, Kommunikation mit dem Anlagenbetreiber und möglicherweise eine Korrekturnachricht an den ÜNB.

Grenze 2: Kein Audit-Trail. Eine Excel-Tabelle ist kein revisionssicheres Medium. Wenn die Bundesnetzagentur oder ein Anlagenbetreiber die Nachvollziehbarkeit einer Abrechnungskorrektur einfordert, kann der Netzbetreiber auf Zellenverweise und Tabellenblätter verweisen — aber nicht auf ein maschinenlesbares Protokoll, das Quellsysteme, Zeitstempel und Entscheidungslogik lückenlos dokumentiert.

Grenze 3: Kein Lerneffekt. Das Notfallverfahren behandelt jeden Fehler als Einzelfall. Es erkennt keine Muster. Wenn dieselbe Fehlerklasse (z. B. fehlende BTR-Daten nach Betreiberwechsel) systematisch bei einem bestimmten Anlagentyp oder in einem bestimmten Netzsegment auftritt, bleibt das unsichtbar. Der Sachbearbeiter löst das Problem jedes Mal neu, statt die Ursache zu beseitigen.

Agentic Asset-MDM als Skalierungslogik

Die agentische Methodik, wie sie in den vorherigen Abschnitten beschrieben wurde, adressiert alle drei Grenzen gleichzeitig:

Der Portfolio-Validierungsagent (täglicher Prüfzyklus) verhindert, dass inkonsistente Stammdaten den Abrechnungslauf erreichen. Er arbeitet proaktiv und erkennt Probleme Tage oder Wochen vor dem SAP-Lauf. Der Tagesabgleich-Agent (Maßnahmen-Zuordnung) stellt sicher, dass jede einzelne Redispatch-Maßnahme vollständig und konsistent den richtigen kaufmännischen Entitäten zugeordnet ist, bevor sie in die AAÜZ-Erzeugung einfließt. Und der Quarantäne-Mechanismus entkoppelt die fehlerfreien Maßnahmen von den problematischen — der SAP-Lauf wird nicht mehr durch Einzelfehler blockiert.

Das Ergebnis ist eine Prozesskette, die nicht mehr am Monatsende unter Zeitdruck manuell zusammengeklebt wird, sondern die kontinuierlich einen konsistenten, abrechnungsfähigen Datenbestand vorhält.

Die drei Optionen: Manuell, Batch, Agentisch

Wie beim Netzanschluss-Use-Case (→ Kapitel 1: Rechtssichere Netzanschlussentscheidungen) lässt sich der Reifegrad der Redispatch-Abrechnung in drei Stufen beschreiben:

Kriterium	Manuell (Notfallverfahren)	Batch-MDM (Nachtlauf)	Agentic Asset-MDM
Fehlererkennung	Erst im SAP-Lauf	Nächster Batch-Lauf (T+1 bis T+7)	Kontinuierlich (T+0)
BTR-Validierung	Per Telefonat	Report + manuelle Nacharbeit	Autonomer MaStR/UTILMD-Abgleich
NAP-MeLo-Prüfung	Nicht systematisch	Regelbasiert, aber ohne Kontext	Kontext-aware mit MaStR-NAP-Graph
Planwert-Aktualität	Unkontrolliert	Periodisch, aber ohne MaStR-Abgleich	Automatischer Kapazitäts-Profilabgleich
SAP-Lauf-Blockade	Häufig (Einzelfehler blockiert Gesamtlauf)	Reduziert	Eliminiert durch Quarantäne
Audit-Trail	Excel + Betriebshandbuch	Datenbankprotokoll	Maschinenlesbar, revisionssicher
Skalierung bei +20 Anlagen	+1 FTE	Konfigurationsaufwand	Automatisch

Build vs. Buy

Die in diesem Kapitel beschriebene Methodik ist vollständig offengelegt. Ein Verteilnetzbetreiber, der über die entsprechenden Schnittstellen verfügt — MaStR-API, SFTP-Anbindung für EDIFACT-Nachrichten, Leitsystem-Export und SAP-RFC-Konnektivität — kann die Agenten-Logik auf Basis eigener Infrastruktur implementieren. Die technische Kernkomponente ist dabei weniger die einzelne Abfrage als die Orchestrierung: der kontinuierliche, getaktete Abgleich über Systemgrenzen hinweg, die Pflege der NAP-MeLo-Zuordnungsgraphen und die Erzeugung revisionssicherer Entscheidungsobjekte.

Wer diese Orchestrierungskomplexität nicht selbst aufbauen und betreiben möchte, findet mit Cernion eine schlüsselfertige B2B-SaaS-Plattform, die genau diese Methodik operationalisiert.

Cernion bietet autonome Validierungsagenten für den Redispatch-Kontext, die sich in bestehende VNB-Systemlandschaften integrieren. Die Plattform umfasst den kontinuierlichen Abgleich von MaStR, ERP und Leitsystem, die automatische BTR-Validierung, die NAP-MeLo-Konsistenzprüfung und die Erzeugung abrechnungsfähiger Datensätze mit vollständigem Audit-Trail. Für Verteilnetzbetreiber, deren Redispatch-Portfolio über die manuelle Beherrschbarkeit hinauswächst, ist das der Weg vom Notfallverfahren zum auditierbaren Regelprozess — ohne den Aufwand einer internen Eigenentwicklung.

---

Datenquellen: Netztransparenz.de (Redispatch-Maßnahmen 2026), Marktstammdatenregister (mastr.bundesnetzagentur.de), BNetzA-Festlegungen BK6-20-059 / BK6-20-061. Abrufdatum: März 2026.

Datenquellen: Netztransparenz.de (Redispatch-Maßnahmen 2026), Marktstammdatenregister (mastr.bundesnetzagentur.de), BNetzA-Festlegungen BK6-20-059 / BK6-20-061. Abrufdatum: März 2026.

Implementierung & Architektur

Der Paradigmenwechsel in der Systemarchitektur: Von statischen Punkt-zu-Punkt-APIs hin zu aktiven, prozessgesteuerten KI-Agentennetzwerken. Referenzarchitekturen und Best Practices für die sichere Integration in KRITIS-Umgebungen.

Ausblick: Energiesystemanalyse jenseits der Physik

Die deutsche Energiesystemanalyse hat sich über Jahrzehnte als ingenieurwissenschaftliche Disziplin verstanden. Ihre Werkzeuge sind Lastflussberechnungen, Netzausbauoptimierungen und stochastische Einspeisemodelle. Ihre Sprache ist die Sprache der Physik: Impedanzen, Spannungsbänder, (n-1)-Sicherheit. Ihre Ergebnisse fließen in Netzentwicklungspläne, NOVA-Prüfungen und Investitionsentscheidungen über Kupfer und Transformatoren.

Diese Perspektive war richtig und notwendig. Sie reicht aber nicht mehr aus.

Die vorangegangenen Kapitel dieser Serie haben gezeigt, dass der operative Engpass der Energiewende nicht in der physikalischen Netzplanung liegt, sondern in der administrativen Prozesssteuerung: in der Asynchronität zwischen Marktstammdatenregister und GIS, zwischen BTR-Zuordnung und EDIFACT-Meldung, zwischen Prognoseprofil und tatsächlicher Anlagenkapazität. Diese Prozess-Asynchronität erzeugt Reibungsverluste, die sich nicht durch Netzausbau beseitigen lassen — weil sie nicht physischer, sondern informationeller Natur sind. Ein neuer Transformator löst kein Problem, das in einer fehlenden MeLo-Zuordnung liegt.

Forschungsnetzwerk Energiesystemanalyse: Themengruppe 4

Das Forschungsnetzwerk Energiesystemanalyse (FNE) hat diesen Paradigmenwechsel erkannt. Für den Forschungszyklus 2026/2027 wurde die Themengruppe 4: „Automatisierte Konsistenzprüfung und agentische Prozesssteuerung im Assetmanagement (Agentic Asset-MDM)" unter der Leitung der STROMDAO GmbH eingerichtet. Die Themengruppe adressiert die systematische Lücke zwischen der physikalischen Netzmodellierung und der administrativen Datenintegrität, die den operativen Netzbetrieb heute stärker limitiert als die installierte Leitungskapazität.

Die Fokusthemen der Themengruppe umfassen drei Forschungsfelder. Erstens die Komplexitätsreduktion im Verteilnetzbetrieb: Wie lassen sich die kombinatorischen Abhängigkeiten zwischen vier bis fünf Quellsystemen (MaStR, GIS, ERP, Leitsystem, Prognoseplattform) so orchestrieren, dass der Sachbearbeiter nicht mehr als Integrator zwischen asynchronen Datenständen fungieren muss? Zweitens die Integration öffentlicher Stromnetzdaten: Welche Rolle spielt das Marktstammdatenregister als autoritative Referenz für Netz-Assets, und wie lassen sich seine Datenqualitätsprobleme (Phantom-Anlagen, fehlende Stilllegungen, Netzgebiets-Fehlzuordnungen) systematisch adressieren? Drittens die autonomen Validierungspipelines: Wie müssen Software-Agenten architektonisch beschaffen sein, damit sie den Stammdaten-Zustand eines Netzgebiets nicht nur prüfen, sondern heilen können — deterministisch, auditierbar und mit definierten Eskalationsstufen?

STROMDAO: Offene Dateninfrastruktur für die Energiewende

Die STROMDAO GmbH hat das Framework Agentic Asset-MDM nicht als akademische Übung entwickelt, sondern aus der operativen Erfahrung im Verteilnetzbetrieb. Als Unternehmen, das seit 2017 an der Schnittstelle von Energiedateninfrastruktur und regulatorischer Praxis arbeitet, hat STROMDAO die Lücke zwischen der regulatorischen Pflicht (§ 8 EnWG, Redispatch 2.0, EWK-Monitoring) und der technischen Machbarkeit im kommunalen Verteilnetz systematisch analysiert und in eine formalisierte Methodik überführt — dokumentiert in dieser Serie auf corrently.io.

Die Methodik ist offen. Die wissenschaftlichen Fragestellungen, die sie aufwirft, sind es ebenfalls. Die Themengruppe 4 im FNE ist der institutionelle Rahmen, in dem diese Fragen mit Netzbetreibern, Forschungseinrichtungen und Regulierungsbehörden diskutiert werden.

Einladung

Das FNE-Jahrestreffen 2026 wird die Themengruppe 4 erstmals im Auditorium vorstellen. Verteilnetzbetreiber, die den Diskurs über administrative Datenintegrität als Engpass der Energiewende mitgestalten wollen, sind eingeladen, sich an der Themengruppe zu beteiligen.

Wer die Ergebnisse nicht abwarten, sondern die Methodik heute in die operative Praxis umsetzen möchte, findet mit Cernion die schlüsselfertige Implementierung — autonome Validierungsagenten für Verteilnetzbetreiber, entwickelt von STROMDAO, getestet im Realbetrieb.

Wissenschaftliche Standardisierung und Data Provenance

Die Energiewirtschaft zählt zu den kritischen Infrastrukturen (KRITIS). Mit zunehmender Dezentralisierung stoßen traditionelle, silobasierte Stammdaten-Systeme an ihre Grenzen. Die Einführung von Künstlicher Intelligenz – insbesondere Agentic AI – zur automatisierten Konsistenzprüfung von Anlagenstammdaten erfordert ein neues Maß an Auditierbarkeit und Interoperabilität. Die Lösung für das sogenannte Vendor-Lock-in-Problem proprietärer Software-Silos liegt in der konsequenten Adaption wissenschaftlicher Datenstandards.

Cernion, als Referenzimplementierung für das Agentic Asset Master Data Management (a²mdm), löst diese Herausforderung architektonisch durch den FAIR Data Layer (eingeführt in v0.11 und finalisiert in v0.12).

Dieses Kapitel beleuchtet die technische Implementierung der FAIR-Prinzipien (Findable, Accessible, Interoperable, Reusable), die Integration der Open Energy Ontology (OEO) und die Sicherstellung von Data Provenance gemäß den Vorgaben des EU AI Acts für Hochrisiko-Systeme.

---

1. Vermeidung von Vendor-Lock-ins durch die Open Energy Ontology (OEO)

Ein zentrales Problem der Datenintegration bei Verteilnetzbetreibern ist das Fehlen eines gemeinsamen, maschinenlesbaren Vokabulars. Cernion begegnet diesem Problem durch eine native, statische Mapping-Schicht auf die Open Energy Ontology (OEO), dem Standard-Vokabular der Nationalen Forschungsdateninfrastruktur (NFDI4Energy).

Technische Umsetzung (oeo-mappings.js & sync-oeo.js):
Cernion verzichtet bewusst auf einen ressourcenintensiven, vollumfänglichen Knowledge Graph (SPARQL-Endpoint) zur Laufzeit. Stattdessen zieht ein dediziertes Entwickler-Skript (npm run sync:oeo) die aktuellste OEO-ETD-CSV von GitHub und kompiliert daraus ein hochperformantes, statisches Lookup-Modul (src/oeo-mappings.js).

Dieses Modul umfasst ca. 150 kuratierte Mappings, die präzise auf die Anforderungen im Assetmanagement (z.B. Marktstammdatenregister / MaStR) zugeschnitten sind. Beispielsweise wird das MaStR-Feld Lage bei Windkraftanlagen nicht einfach als Text verarbeitet, sondern semantisch differenziert in wind-onshore (OEO_00000446) und wind-offshore.

Semantische Anreicherung der KI (Classifier Enrichment):
Ein besonderer Architektureingriff liegt in der Nutzung der deutschen OEO-Labels (labelDe, z.B. „Umspannwerk“ oder „Solaranlage“). Diese Begriffe werden automatisiert in den Keyword-Pool der Cernion-Klassifizierungs-KI (Classifier) überführt. Dies boostet die heuristische Erkennungsrate bei unstrukturierten, deutschsprachigen Daten-Uploads von Netzbetreibern erheblich, ohne den eigentlichen Scoring-Algorithmus anpassen zu müssen.

OpenAPI-Annotationen:
Alle REST-Endpunkte (über 45 Actions in 7 Domänen wie grid-operations oder energy-market) sind via OpenAPI mit einer x-oeo-class-Erweiterung annotiert. Zusätzlich wird ein JSON-LD Endpunkt (GET /api/datapoints/oeo-context) bereitgestellt, der das Mapping von internen Cernion-Feldern auf OEO-IRIs als @context-Dokument ausliefert.

---

2. Data Provenance & KRITIS-Compliance (Der EU AI Act in der Architektur)

Systeme, die als Sicherheitskomponenten in der Verwaltung kritischer Infrastrukturen eingesetzt werden, unterliegen künftig den strengen Vorgaben des EU AI Acts für Hochrisiko-KI-Systeme (Art. 10, 12, 15). Die Kernanforderung lautet: Data Provenance. Es muss jederzeit kryptografisch nachweisbar sein, auf welcher Datengrundlage (Quellen, Lizenzen, Zeitstempel) ein KI-Agent eine Entscheidung (z.B. eine automatisierte Stammdaten-Korrektur) getroffen hat, um “KI-Halluzinationen” auszuschließen.

Die In-Memory-Edge-Architektur (PouchDB):
Cernion garantiert KRITIS-Compliance durch eine strikte In-Memory-Policy am Edge. Sensible Netztopologie- oder Assetdaten (z.B. im Datapoint Layer) verbleiben in der lokalen PouchDB-Instanz des Betreibers und werden nicht unmaskiert an externe Cloud-LLMs gesendet. Die Agenten operieren primär auf Basis der anonymisierten OEO-IRIs.

Der OEMetadata v2.0 Exporter (oemetadata.service.js):
Das Herzstück der Provenance-Sicherung ist der OEMetadata-Exporter (eingeführt in v0.11, strikt validiert in v0.12). Jeder verwaltete Cernion-Datenpunkt erzeugt auf Anfrage ein JSON, das exakt dem offiziellen schema.json v2.0 des OEMetadata-Projekts entspricht.

Der Exporter extrahiert dynamisch:

• Temporal & Spatial Data: Zeitreihen-Begrenzungen und Georeferenzierungen (Bounding Boxen) basierend auf den abgerufenen Datensätzen (z.B. das Netzgebiet „Ludwigshafen“).
• Sources & Licenses: Ein Cernion-Agent dokumentiert automatisch in den Metadaten, welche Microservices er abgefragt hat (sources). Das System mappt diese auf die korrekten Quell-Lizenzen (z.B. DL-DE/BY-2.0 für das MaStR oder CC-BY-4.0 für ENTSO-E).
• Kryptografischer Hash: Jeder Export beinhaltet einen kryptografischen Hash (z.B. SHA-256) der rohen Quelldaten zum Zeitpunkt der Agenten-Analyse, was die Auditierbarkeit für den Netzbetreiber rechtssicher macht.

Um sicherzustellen, dass keine invaliden Metadaten ausgeliefert werden, lädt das System während des Builds (npm run sync:oemetadata) das offizielle JSON-Schema von der Open Energy Platform herunter. Jede REST-Anfrage (GET /api/datapoints/:name/oemetadata?validate=true) wird zur Laufzeit via ajv validiert.

---

3. Orchestrierung über Systemgrenzen: Der OEP-Connector

Um KI-Agenten im Assetmanagement wirklich proaktiv handeln zu lassen, müssen sie die lokale Sicht (das eigene Netzgebiet) mit globalen Entwicklungen abgleichen können. Cernion v0.12 führt hierfür einen dedizierten, Read-Only-Connector (oep.service.js) zur Open Energy Platform (OEP) ein.

Dieser Microservice ermöglicht es dem Agent-Planner, komplexe Fragestellungen in mehrstufige Pläne (Steps) zu zerlegen.
Ein Prompt wie: “Vergleiche die installierte PV-Leistung bei den TWL Netzen mit dem Netzentwicklungsplan-Szenario (NEP) 2035” triggert nun folgende automatisierte Kette:

1. Der Agent fragt den lokalen Cernion-Service (assets.solar) für das MaStR-Netzgebiet ab.
2. Der Agent nutzt den OEP-Connector (oep.query), um das öffentliche NEP-Szenario direkt aus der Datenbank der nationalen Forschungsinfrastruktur zu ziehen.
3. Das LLM (als Reasoning-Layer) interpretiert das Delta lokal und speichert das Ergebnis als validierten Datenpunkt zurück in die PouchDB.

Um die Latenz bei Agenten-Entscheidungen gering zu halten, werden die OEP-Tabellenmetadaten in Cernion im RAM gecacht (TTL von 24h), während die eigentlichen Tabellendaten aus Datenschutzgründen lediglich durch den Speicher fließen (Pass-through).

---

4. Datapoint Scheduling: Kontinuierliche Datenhygiene

Für den operativen Betrieb eines Stadtwerks reicht ein manueller Aktualisierungs-Trigger nicht aus. KI-Agenten können nur dann belastbare Konsistenzprüfungen durchführen, wenn das Daten-Fundament (“Datapoint Layer”) stets aktuell ist.

Mit v0.12 implementiert Cernion ein lokales Interval-Scheduling (strategy: "interval"). Der datapoint.service.js prüft kontinuierlich (z.B. in einem 60-Sekunden-Tick), ob Datenpunkte veraltet sind. So kann beispielsweise eine “Tägliche Portfolio-Inventur (PV, Wind, Speicher)” konfiguriert werden (intervalMinutes: 1440). Ist ein Datenpunkt veraltet, markiert der interne Health-Endpoint diesen als stale und triggert autonom einen Refresh.

(Dieser Mechanismus ist essentiell für die Vorbereitung auf Cernion v0.14+, in dem autonome Validierungsagenten kontinuierlich und unbeaufsichtigt auf der Datapoint-Schicht nach Fehlern in der Marktkommunikation oder dem MaStR suchen werden).

---

Investitionssicherheit durch FAIR Data

Mit der Architektur des FAIR Data Layers positioniert sich Cernion als Referenzimplementierung für das Agentic Asset-MDM. Kein anderer kommerzieller Energiedaten-Agent erzeugt aktuell vollautomatisch OEMetadata-konforme Exporte inkl. OEO-Annotationen und Data-Provenance-Hashes. Für Stadtwerke bedeutet dies: Investitionssicherheit (kein Vendor-Lock-in), lückenlose Nachvollziehbarkeit für Audits (EU AI Act) und sofortige Interoperabilität mit der nationalen Energieforschungslandschaft.

Das Cernion Cookbook (Best Practices in Code)

Der Paradigmenwechsel von starren ETL-Pipelines hin zu Agentic Asset-MDM (A²MDM) erfordert in der KRITIS-Praxis konkrete, validierbare Implementierungen. Um die Lücke zwischen theoretischem Framework und operativem Systemaufbau zu schließen, bündelt das Cernion Cookbook Referenzimplementierungen ("Rezepte") in Code.

Diese Rezepte demonstrieren, wie die Cernion Energy Tools (als A²MDM Plattform) komplexe Herausforderungen der Energiewirtschaft autonom über Knowledge Graphs auflösen.

Rezept #1: Der Automatisierte MaStR-Qualitätsaudit

Eine Kernaufgabe von A²MDM-Agenten (siehe Schritt 1: Bestandsinventur) ist der autonome Quellenabgleich. Die toxische Datenqualität des Marktstammdatenregisters (MaStR) führt regelmäßig zu Phantom-Engpässen in der Zielnetzplanung.

Das mastr-quality-audit Rezept implementiert die Heuristik zur Bereinigung:
Anstatt Daten naiv aus dem MaStR in ein GIS-System zu spiegeln, traversiert der Cernion-Agent das Portfolio kontinuierlich. Er erkennt Inkonsistenzen autonom, beispielsweise wenn der Status "In Planung" zu lange anhält oder Leistungsangaben (z.B. 100 kWp) im Knowledge Graph im Widerspruch zu externen geografischen Kontexten (OpenStreetMap-Gebäudeflächen) stehen. Das Ergebnis ist ein validierter "Trusted State", der als verlässliche Entscheidungsgrundlage für nachgelagerte Prozesse dient.

(Die technische Umsetzung und die API-Endpunkte für dieses Audit sind über die Cernion Timeline dokumentiert).

Rezept #2: Die End-to-End Pipeline für Energy Sharing (§42c EnWG)

Transaktionale Sicherheit ist eine der größten Herausforderungen in Netzbetreiber-Architekturen. Wenn kaufmännische Logik auf physikalische Restriktionen trifft, versagen herkömmliche relationale Datenbanken.

Das energy-sharing-full-pipeline Rezept demonstriert die architektonische Überlegenheit von Knowledge Graphs bei der Abwicklung des Energy Sharings nach §42c EnWG.
Der Agent bündelt Erzeuger und Verbraucher dynamisch in virtuellen Bilanzkreisen. Kommt es zu einem Netzeingriff (z.B. Redispatch 2.0 / Abregelung einer Community-PV-Anlage), erkennt das System den physikalischen Zustand und löst sofort den kaufmännischen Konflikt: Die Ausfallarbeit wird berechnet, und die Allokationsschlüssel der Community-Mitglieder werden vollautomatisch und revisionssicher korrigiert.

(Weitere Best-Practice-Pipelines, u.a. zur Zielnetzplanung und zu §14a EnWG-Simulationen, werden fortlaufend in das Cookbook integriert).