Redispatch 2.0 Datenqualität: Klärfälle mit KI-Agenten lösen

Pexon Consulting | 8 Min. Lesezeit | 20.06.2026

TL;DR

Redispatch 2.0 Datenqualität entscheidet darüber, ob die Ausfallarbeit korrekt abgerechnet wird oder im Klärfall versandet. KI-Agenten gleichen Stammdaten aus MaStR, EDM und EIV automatisiert ab, erkennen Abweichungen vor dem Versand und schreiben Korrekturen zurück. Pexon Consulting baut diese Agenten auf einem Azure-Stack mit DSGVO- und KRITIS-tragfähiger Architektur.

Warum eine falsche Nennleistung 5-stellig kostet

Ein Stadtwerk meldet 600 PV- und Windanlagen für Redispatch 2.0. Bei 18 davon steht im Marktstammdatenregister eine Nennleistung, die nicht mehr stimmt — ein Repowering, das nie nachgepflegt wurde. Der Netzbetreiber rechnet die Ausfallarbeit auf Basis dieser falschen Leistung ab. Am Jahresende fehlen dem Anlagenbetreiber mehrere Tausend Euro Entschädigung pro Anlage, und niemand merkt es, weil drei Systeme dieselbe Anlage unterschiedlich kennen.

Das ist kein Randfall. Redispatch 2.0 ist seit dem 1. Oktober 2021 für alle steuerbaren Erzeugungsanlagen und Speicher ab 100 kW verpflichtend (§ 13a EnWG); die BDEW-Branchenlösung beschreibt die Prozesse im Detail. Die Pflicht trifft Netzbetreiber und Anlagenbetreiber gleichermaßen — und sie hängt komplett an Daten, die zwischen Marktrollen hin- und herfließen: Stammdaten, Bewegungsdaten, Prognosen, Nichtbeanspruchbarkeiten. Stimmt ein Feld nicht, kippt die Abrechnung.

Der wirtschaftliche Hebel liegt nicht in der Engpassbehebung selbst, sondern in der Sauberkeit der Daten dahinter. Schlechte Stammdaten erzeugen Klärfälle, Klärfälle erzeugen Aufwand, und falsch berechnete Ausfallarbeit erzeugt entweder Verluste beim Anlagenbetreiber oder Haftungsrisiko beim Netzbetreiber. Genau hier setzen wir KI-Agenten an — nicht beim Netz, sondern beim Datenfluss.

Wo die Daten auseinanderlaufen: MaStR, EDM und EIV

Die kurze Antwort: weil dieselbe Anlage in drei Systemen lebt und keines davon die anderen automatisch korrigiert. Das Marktstammdatenregister (MaStR) hält die regulatorische Wahrheit, das Energiedatenmanagement (EDM) des Netzbetreibers die abrechnungsrelevante, und der Einsatzverantwortliche (EIV) die operative. Driften diese drei auseinander, entstehen Klärfälle.

Typische Abweichungen, die wir in Projekten sehen:

1. Nennleistung — nach Repowering im MaStR aktualisiert, im EDM nicht.
2. Netzanschlusspunkt — fehlend oder mit falscher Marktlokations-ID hinterlegt.
3. Bilanzgruppen-Zuordnung — nach Lieferantenwechsel veraltet.
4. TR-ID / SR-ID — die Kennung der Technischen bzw. Steuerbaren Ressource passt nicht zur Zuordnung beim Netzbetreiber.

Der Datenaustausch läuft standardisiert über die Datendrehscheibe der Netzbetreiber-Kooperation Connect+ (RAIDA) mit ACK-Management: Jede Nachricht wird gegen Prüfregeln validiert, und der Sender bekommt eine technische Quittung zurück. Das Problem ist nur — die ACK-Ablehnung kommt, nachdem der fehlerhafte Datensatz schon raus ist. Dann beginnt das manuelle Clearing. Und Clearing ist genau der Aufwand, den die Branche eigentlich reduzieren will.

Unsere klare Position: Datenqualität in Redispatch 2.0 ist kein Stammdaten-Hygiene-Projekt, das man einmal macht. Anlagen werden umgebaut, Lieferanten gewechselt, Marktrollen neu zugeordnet — die Daten driften kontinuierlich. Ein einmaliger Datenputz hält keine zwei Quartale. Was hilft, ist eine laufende Prüfung im Datenfluss.

Was ein KI-Agent im Redispatch-Datenfluss konkret tut

# Stammdaten-Konsistenz vor dem RAIDA-Versand prüfen (pydantic v2)
from pydantic import BaseModel, field_validator

class RedispatchStammdaten(BaseModel):
    sr_id: str                  # Steuerbare Ressource
    nennleistung_kw: float      # aus EDM
    nennleistung_mastr_kw: float  # aus MaStR (Referenz)
    netzanschlusspunkt: str | None
    bilanzgruppe: str

    @field_validator("nennleistung_kw")
    @classmethod
    def leistung_plausibel(cls, v, info):
        ref = info.data.get("nennleistung_mastr_kw")
        if ref and abs(v - ref) / ref > 0.05:   # >5 % Abweichung
            raise ValueError(f"Nennleistung weicht {v} vs MaStR {ref} kW ab")
        return v

Der Agent ist kein Chatbot. Er ist ein Prüf- und Anreicherungs-Layer, der zwischen den Quellsystemen und dem Versand an RAIDA sitzt. Drei Aufgaben übernimmt er:

Erstens den Abgleich. Vor jedem Versand zieht er die Stammdaten aus MaStR (per offener Schnittstelle), aus dem EDM und aus dem EIV und vergleicht Feld für Feld. Eine Nennleistung, die um mehr als 5 % abweicht, ein fehlender Netzanschlusspunkt, eine Bilanzgruppe ohne gültige Zuordnung — das fängt er ab, bevor die Nachricht das Haus verlässt.

Zweitens die Einordnung. Hier kommt das Large Language Model ins Spiel: Klärfall-Texte aus dem ACK-Rücklauf sind Freitext. Der Agent klassifiziert sie, schlägt die wahrscheinliche Ursache vor und ordnet sie der betroffenen Anlage zu. Das ersetzt das manuelle Lesen und Zuordnen, das heute Sachbearbeiter machen.

Drittens das Zurückschreiben. Bestätigte Korrekturen schreibt der Agent in die führende Quelle zurück und dokumentiert die Änderung revisionssicher — für Energieversorger als KRITIS-Betreiber kein Nice-to-have, sondern Pflicht.

Technisch bindet Pexon Consulting die Quellsysteme über das Model Context Protocol an, damit der Agent nicht für jede Schnittstelle neu verdrahtet werden muss. Die Daten selbst landen auf einer AI-ready Datenplattform auf Microsoft Fabric, wo Historie, Lineage und Prüfregeln an einem Ort liegen. Wer tiefer in die Grundlagen sauberer Daten einsteigen will: Wir haben die Hebel, um systematisch Datenqualität zu messen und zu verbessern, separat zusammengeschrieben.

Planwert- oder Prognosemodell — Datenqualität zählt bei beiden

Anlagenbetreiber wählen pro Anlage bis zum 30. November für das Folgejahr zwischen zwei Bilanzierungsmodellen — und die Wahl verschiebt nur, wessen Datenqualität über die Abrechnung entscheidet:

Beim Planwertmodell liefern Sie die Prognose selbst — schlechte Prognosegüte schlägt direkt auf Ihre Ausfallarbeit durch. Beim Prognosemodell prognostiziert der Netzbetreiber, aber auf Basis der Stammdaten, die Sie ihm gemeldet haben. Es gibt kein Modell, bei dem schlechte Daten folgenlos bleiben.

Dazu kommt die Abrechnungsvariante für die Ausfallarbeit: Pauschal (Fortschreibung der letzten Viertelstunde), Spitz (auf Basis gemessener Wetterdaten) oder Spitz-Light (Referenzmesswerte). Je präziser die Variante, desto höher die Anforderung an saubere Mess- und Stammdaten. Wer Spitzabrechnung wählt, um mehr Entschädigung zu holen, aber die Datenqualität nicht im Griff hat, produziert Klärfälle statt Mehrerlös.

Redispatch 2.0 Datenqualität automatisieren: Kosten und Zeitrahmen

Ehrliche Einordnung zuerst: Für einen Anlagenbetreiber mit fünf Windrädern lohnt sich kein KI-Agent. Da reicht ein sauberes Stammdaten-Sheet und ein Dienstleister. Der Agent rechnet sich ab dem Punkt, an dem das manuelle Clearing zum wiederkehrenden Posten wird — erfahrungsgemäß bei Netzbetreibern, Stadtwerken und Direktvermarktern mit dreistelliger Anlagenzahl.

Ein typischer Einstieg bei Pexon Consulting ist ein 6-Wochen-Pilot auf einem abgegrenzten Anlagen-Portfolio. In Woche eins steht der Abgleich MaStR/EDM, danach kommt die LLM-gestützte Klärfall-Klassifikation, am Ende das Zurückschreiben. Budgetrahmen für so einen Piloten: 50.000 bis 90.000 Euro, je nach Zahl der anzubindenden Quellsysteme. Das ist kein Plattform-Großprojekt — es ist ein Schnitt durch den Datenfluss, der zeigt, ob die Automatisierung die Klärfall-Last messbar senkt.

Unsere Empfehlung, wenn Sie gerade evaluieren: Fangen Sie nicht mit dem Agenten an, sondern mit einer Bestandsaufnahme der aktuellen Klärfälle. Wie viele pro Monat? Welche Ursachen wiederholen sich? Wenn 70 % der Klärfälle aus drei Stammdaten-Feldern kommen, ist der Business Case in einer Stunde gerechnet — und der Agent löst genau diese drei Felder zuerst.

Häufig gestellte Fragen

Was kostet die Automatisierung der Redispatch 2.0 Datenqualität?

Ein 6-Wochen-Pilot auf einem abgegrenzten Portfolio liegt bei 50.000 bis 90.000 Euro, abhängig von der Zahl der anzubindenden Quellsysteme (MaStR, EDM, EIV, Direktvermarkter-Schnittstelle). Der Pilot zeigt, ob die Klärfall-Last messbar sinkt, bevor in eine breite Ausrollung investiert wird.

Ersetzt ein KI-Agent unsere bestehende Redispatch-Software?

Nein. Der Agent sitzt als Prüf-Layer zwischen Quellsystemen und Versand, nicht anstelle von RAIDA oder Ihrem EDM. Bestehende Prozesse und die Connect+-Anbindung bleiben — der Agent fängt nur fehlerhafte Datensätze vor dem Versand ab und klassifiziert Klärfälle aus dem ACK-Rücklauf.

Ist das DSGVO- und KRITIS-konform?

Ja, wenn die Architektur stimmt. Wir bauen den Stack auf Azure mit Daten in EU-Regionen, revisionssicherer Dokumentation jeder Änderung und ohne Abfluss in öffentliche LLM-Endpunkte. Für Energieversorger als KRITIS-Betreiber ist die Nachvollziehbarkeit jeder Datenkorrektur Pflicht, nicht Option.

Manuelles Clearing vs. KI-Agent — wo liegt der Unterschied?

Manuelles Clearing reagiert auf abgelehnte ACKs, der Agent prüft vor dem Versand. Ein Sachbearbeiter braucht je nach Fall 20 bis 60 Minuten pro Klärfall; der Agent prüft das Portfolio vollständig und eskaliert nur die Ausnahmen, die eine menschliche Entscheidung brauchen.

Brauchen wir dafür Microsoft Fabric?

Nicht zwingend, aber es hilft. Der Agent funktioniert auch gegen eine bestehende Datenbank. Eine zentrale Datenplattform mit Historie und Lineage macht das Zurückschreiben und die revisionssichere Dokumentation deutlich einfacher — gerade wenn mehrere Marktrollen auf dieselben Stammdaten zugreifen.

Nächster Schritt

Wenn Sie wissen wollen, wie viele Ihrer Klärfälle ein Agent automatisiert lösen würde, spielen wir das an Ihren echten Anlagen durch — kein generisches Webinar, sondern Ihre drei häufigsten Klärfall-Ursachen.

Verwandte Themen