Domänen-LLM für Energieversorger

Das echte Ausmaß des Problems

Große Energieversorger und Netzbetreiber akkumulieren über Jahrzehnte enorme Mengen proprietären technischen Wissens: Schutzkonzepte, Parametersätze, Netzanschlussregeln, Revisionshistorien, Abschaltprozeduren, Hersteller-Sonderlösungen für installierte Anlagen, Betriebsanweisungen für überarbeitete Aggregatversionen. Laut einer Erhebung des Bundesverbands der Energie- und Wasserwirtschaft (BDEW, 2024) haben Netzbetreiber im Schnitt über 50.000 Seiten aktive technische Dokumentation — verteilt über SAP PM, SharePoint, SCADA-Anhänge, lokale Laufwerke und papierbasierte Bestandsunterlagen.

Das strukturelle Problem: Diese Wissensbasis wächst seit 30 Jahren, wurde aber nie für maschinelle Auffindbarkeit aufgebaut. Wer weiß, wo welche Information liegt, sind die Mitarbeitenden mit 20+ Jahren Erfahrung — und die gehen. Die BDEW-Studie schätzt, dass zwischen 2025 und 2033 im deutschen Netzbetrieb bis zu 35 Prozent der Belegschaft durch Renteneintritt ausscheiden. Kein dokumentiertes Wissenssystem kann diesen Verlust vollständig kompensieren — ein gut aufgebautes Domänen-LLM kann ihn abfedern.

E.ON hat 2023 als erster großer europäischer Energieversorger einen internen Generative KI-Assistenten für Mitarbeitende aktiviert. Der Rollout begann mit allgemeinen Büroprozessen und wird schrittweise auf technische Fachanwendungen ausgedehnt. RWE und Vattenfall haben eigene KI-Initiativen mit explizitem Fokus auf technische Dokumentation und Betriebswissen. Die strategische Richtung ist klar — die Frage ist nicht mehr ob, sondern wie und wann.

Mit vs. ohne KI — ein ehrlicher Vergleich

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Technische Fachkräfte, die bisher 30–45 Minuten für die Suche in Betriebshandbüchern, SAP-PM-Einträgen und SharePoint-Hierarchien verbringen, erhalten Antworten in 2–5 Minuten — mit Quellennachweis. Bei täglich 3–5 solcher Recherchen ist das eine Stunde und mehr Zeitgewinn pro Person. Über ein 200-köpfiges Technikteam: erheblich.

Kosteneinsparung — niedrig (2/5) Die Einrichtungskosten sind hoch (GPU-Infrastruktur, Datenaufbereitung, Implementierung), und der ROI braucht 2–3 Jahre, um sich zu materialisieren. Die Einsparung ist real — weniger Anrufe im Bereitschaftsdienst, kürzere Störungszeiten, schnellere Einarbeitung neuer Mitarbeitender — aber sie ist schlecht direkt messbar und daher schwer im Vorstand zu kommunizieren. Das ist der faire Vergleich.

Schnelle Umsetzung — sehr langsam (1/5) Das ist das aufwändigste KI-Projekt in der gesamten Kategorie. Datenaufbereitung allein — Dokumente kategorisieren, Versionen bereinigen, Zuständigkeiten klären — dauert länger als erwartet. Realistische Vollimplementierung mit Fine-Tuning: 18–24 Monate. Mit reiner RAG-Architektur auf bereinigten Dokumenten: 6–12 Monate bis Pilotbetrieb. Unterschätze die Datenaufbereitungsphase nicht — sie ist der häufigste Grund für Projektverzögerungen.

ROI-Sicherheit — mittel (3/5) Der Nutzen ist real, aber schwer isolierbar. Wie viele Anrufe im Bereitschaftsdienst wurden durch das System vermieden? Wie viel Einarbeitungszeit hat ein neuer Techniker dadurch gespart? Diese Zahlen existieren, aber sie lassen sich ohne vorab definierte Messpunkte nachträglich kaum beweisen. Wer vor dem Projekt Baseline-Messungen macht (heutige Recherchezeiten, Bereitschaftsdienstvolumen), hat nachher einen belastbaren ROI-Nachweis.

Skalierbarkeit — sehr hoch (5/5) Das ist der stärkste Punkt: Einmal aufgebaut, skaliert ein Domänen-LLM auf alle Mitarbeitenden des Unternehmens mit nahezu null Grenzkosten pro Anfrage (bei On-Premise-GPU). Neue Mitarbeitende profitieren sofort; neue Dokumente werden einfach in den Korpus integriert. Kein anderer KI-Anwendungsfall in der Energiebranche hat eine vergleichbare Skalierungskurve.

Richtwerte — stark abhängig von Unternehmensgröße, Qualität des Dokumentenkorpus und vorhandenem Data-Science-Team.

Was das System konkret macht

Der technische Kern dieses Anwendungsfalls kann zwei grundverschiedene Architekturen haben — und die Wahl zwischen ihnen ist die wichtigste technische Entscheidung des Projekts.

Option A: Retrieval-Augmented Generation (RAG)

RAG verbindet ein Standard-Sprachmodell mit einer Vektordatenbank, die den gesamten Dokumentenkorpus des Unternehmens enthält. Wenn eine Frage gestellt wird, sucht das System zuerst in der Datenbank nach relevanten Textpassagen (semantische Ähnlichkeitssuche) und schickt diese als Kontext an das Sprachmodell, das dann eine Antwort formuliert.

Vorteile: Schneller aufzubauen (4–8 Wochen für einen Piloten auf bereinigten Dokumenten), aktualisierbar ohne Model-Retraining, Quellennachweis ist automatisch vorhanden, da die verwendeten Passagen referenziert werden. Nachteile: Das Modell kennt die Domänensprache nur soweit, wie das Basismodell sie gelernt hat — energiespezifische Abkürzungen, betriebliche Eigenbezeichnungen und Anlage-Codierungen müssen explizit im Kontext stehen, damit das Modell sie versteht.

Option B: Fine-Tuning auf domänenspezifischem Korpus

Fine-Tuning verändert die Modellgewichte selbst: Das Modell wird auf tausenden eigenen Dokumenten weitertrainiert und verinnerlicht dabei die Domänensprache, typische Frageformate und fachliche Schlussfolgerungslogik. Ergebnis: ein Modell, das nicht nur antwortet, sondern “denkt” wie ein erfahrener Netztechniker.

Vorteile: Bessere Verarbeitung von Fachsprache und Abkürzungen ohne explizite Kontext-Übergabe, robustere Antworten bei mehrstufigen technischen Fragen. Nachteile: Erheblich aufwändiger (GPU-Stunden, Trainingsdaten-Annotation), Modell muss bei größeren Dokumentenänderungen neu trainiert werden (Retraining-Kosten).

Empfehlung der Praxis: Beginne mit RAG auf einem souverän betriebenen Modell (Ollama + Llama 3.1 70B oder Aleph Alpha Pharia-1) und gut aufbereiteten Dokumenten. Das ist das Projekt für Jahr 1. Fine-Tuning kommt in Jahr 2–3, wenn das RAG-System produktiv läuft und ihr wisst, wo die Grenzen des Basismodells liegen.

Datensouveränität und On-Premise-Deployment

Das ist der zentrale Unterschied zu allgemeinen LLM-Diensten wie ChatGPT oder Claude: SCADA-Betriebsdaten, Handelspositionen, Netztopologie-Details und interne Revision sind KRITIS-relevante oder wettbewerbssensitive Informationen. Sie dürfen die Cloud nicht sehen.

Ein On-Premise-Deployment bedeutet: Das Modell läuft auf eigener GPU-Hardware im eigenen Rechenzentrum. Anfragen gehen an localhost, kein Datum verlässt das interne Netz. Die Technologie dafür ist ausgereift — Ollama für kleinere Bereitstellungen (ein Server mit 2–4 NVIDIA A100/H100), Aleph Alpha (PhariaAI) für souveräne Enterprise-Deployments mit Compliance-Anforderungen.

Investitionskosten für GPU-Infrastruktur: Ein Server mit 2× NVIDIA H100 (80 GB VRAM) kostet ca. 80.000–120.000 Euro in Hardware, reicht für ein 70B-Parameter-Modell und bis zu 20 gleichzeitige Anfragen. Für einen Versorger mit 500+ technischen Mitarbeitenden ist das ausreichend für einen Piloten. Ein vollständig skalierter Betrieb für 2.000+ Nutzer braucht 4–8 solcher Server.

EU AI Act und Hochrisiko-Klassifikation: Wenn das System Empfehlungen zu kritischen Anlagenoperationen gibt (z.B. Schutzabschaltungen, Spannungsänderungen), kann es unter die Hochrisiko-Kategorie fallen. Das erfordert technische Dokumentation, menschliche Aufsicht und Protokollierung. Wissensabfragen ohne operative Steuerempfehlungen sind dagegen unkritisch — ein wichtiger Architekturentscheid, der früh getroffen werden muss.

Konkrete Werkzeuge — was wann passt

Ollama — Kostenlos, Open Source, lokal betreibbar. Für den Piloten auf bereinigten technischen Dokumenten ideal: einfacher Einstieg, keine Lizenzkosten, vollständige Datensouveränität. Qualitätsgrenze bei sehr spezifischen, mehrstufigen Fachfragen.

Aleph Alpha (PhariaAI) — Das europäische Sovereign-AI-Flaggschiff, ausgelegt für KRITIS-Anforderungen. Pharia-1 ist auf domänenspezifisches Fine-Tuning ausgelegt; PhariaAI als Platform unterstützt Erklärbarkeit und auditierbare Entscheidungspfade. Preislich im Enterprise-Bereich — sinnvoll, wenn On-Premise-Compliance-Anforderungen nicht verhandelbar sind.

Weaviate — Vektordatenbank für den RAG-Aufbau. Self-hostbar auf eigenem Server (EU-Rechenzentrum oder on-premise), Hybrid-Suche kombiniert semantische und Volltextsuche. Besonders geeignet für große Dokumentkorpora mit gemischten Formaten (PDF, Word, Textauszüge aus SAP-PM).

Azure ML — Für Fine-Tuning und Modell-Training auf der Cloud, wenn On-Premise-GPU für Trainingslast zu begrenzt ist. Trainingsläufe in der EU-Region (Azure Germany North oder West Europe), Betrieb danach on-premise. Sorgfältig prüfen: Trainingsdaten dürfen dabei temporär in die Cloud — ist das für eure Daten akzeptabel?

Power BI — Als Monitoring-Dashboard für Systemnutzung, Anfragequalität und Nutzungsstatistiken. Kein KI-Tool, aber unverzichtbar, um den ROI-Nachweis zu führen: Wie viele Anfragen täglich? Welche Themenbereiche? Wo wird das System als unzureichend markiert?

Wann kein Tool hilft: Wenn eure Dokumentenbasis in einem Zustand ist, der einer Datenarchäologie ähnelt — Word-Dokumente ohne Metadaten, Scan-PDFs ohne OCR, Excel-Kommentare als einzige Wissensquelle — hilft auch das beste Modell nicht. Datenaufbereitung ist Voraussetzung, keine Aufgabe für das KI-Modell.

Datenschutz und Datenhaltung

DSGVO-Konformität ist bei On-Premise-Deployment strukturell gelöst: Kein Datum verlässt das Unternehmensnetz, kein AVV mit einem Dritten erforderlich, kein Subprozessor-Problem.

Für Cloud-Komponenten (z.B. Fine-Tuning-Läufe auf Azure ML): AVV mit Microsoft Deutschland abschließen, EU-Region explizit wählen, Trainingsdaten nur in pseudonymisierter oder aus dem Personenbezug befreiter Form übertragen. Für rein technische Dokumente ohne Personenbezug ist der DSGVO-Aufwand gering.

KRITIS-Anforderungen nach IT-SiG 2.0: Netzbetreiber in Deutschland, die als KRITIS eingestuft sind, unterliegen besonderen IT-Sicherheitsanforderungen. Ein KI-System, das SCADA-Daten oder Netztopologie verarbeitet, muss mit dem BSI-Grundschutz-Kompendium kompatibel sein. On-Premise-Deployment ist hier die sichere Wahl; Cloud-Hybridlösungen erfordern Rücksprache mit dem BSI-Ansprechpartner.

Was es kostet — realistisch gerechnet

Phase 1: RAG-Pilot auf bereinigten Dokumenten

• Datenaufbereitung (Dokumenten-Audit, Bereinigung, Metadaten): 30.000–60.000 Euro
• Technische Implementierung (Vektordatenbank, RAG-Pipeline, Frontend): 40.000–80.000 Euro
• GPU-Server für Piloten (2× A100 oder H100): 60.000–100.000 Euro (einmalig)
• Gesamtpilot: 130.000–240.000 Euro, 4–8 Monate

Phase 2: Rollout und Vollbetrieb

• Erweiterung GPU-Infrastruktur für mehr Nutzer: 50.000–150.000 Euro
• Fine-Tuning (optional, bei nachgewiesenem Bedarf): 80.000–150.000 Euro
• Betrieb und Wartung: 30.000–60.000 Euro/Jahr

ROI-Rechnung am Beispiel: Verteilnetzbetreiber, 300 technische Mitarbeitende, durchschnittliche Recherchezeit 1 Stunde/Tag → 52 Manntage/Jahr je Person → 15.600 Manntage Gesamtaufwand. Wenn das System 40% davon auf 15 Minuten reduziert: 9.750 Manntage Einsparung (ca. 40% der ursprünglichen Zeit). Bei 500 Euro Tagessatz = 4,9 Mio. Euro theoretisches Potenzial. Realistisch erreichbar in Jahr 2: 20–30% davon = 1–1,5 Mio. Euro. Investition: 300.000 Euro. ROI: positiv ab Monat 18–24.

Wie du den Nutzen tatsächlich misst: Vor dem Projekt: Führe 4 Wochen lang ein Protokoll über Recherchezeiten bei technischen Fachfragen (Stichprobe, nicht alle). Nach dem Pilot: Gleiches Protokoll, gleiche Stichprobengruppe. Die Differenz ist dein Wirkungsnachweis.

Typische Einstiegsfehler

1. Datenqualität der Wartungsprotokolle wird massiv unterschätzt. Wartungsprotokolle aus SAP PM sind in der Praxis oft erschreckend unstrukturiert: handschriftliche Einträge nachträglich eingescannt, Abkürzungen ohne Glossar (jeder Techniker hat seine eigenen), fehlende Datumsangaben, mehrere Revisionen ohne Versionsmarkierung. Ein Modell, das auf solchen Daten trainiert wird, lernt Inkonsistenz — und gibt inkonsistente Antworten. Lösung: Daten-Audit als Projektphase 0, nicht als Nebenaufgabe. Plane 3–4 Monate dafür.

2. Der Unterschied zwischen RAG und Fine-Tuning wird nicht klar entschieden. Viele Projekte starten mit dem Ziel “Fine-Tuning”, weil das professioneller klingt — und landen 6 Monate später bei einer schlecht eingerichteten RAG-Pipeline, weil die Trainingsdaten-Qualität nicht ausreicht. Entscheide explizit und begründet, welche Architektur für welche Phase. RAG für Jahr 1, Fine-Tuning nur wenn RAG nachgewiesene Schwächen zeigt.

3. Kein Retraining-Konzept für neue Dokumentenversionen. Das System beantwortet nach 18 Monaten Betrieb Fragen auf Basis des Dokumentenstands vom Einführungstag. Inzwischen haben sich 30% der Parametersätze geändert, neue Schutzrelais wurden installiert, zwei Hersteller-Handbücher aktualisiert. Das Modell weiß es nicht — und gibt veraltete Antworten, ohne darauf hinzuweisen. Lösung: Dokumenten-Update-Prozess als laufende Governance, nicht als einmaliges Projekt. Zuständigkeit namentlich benennen.

4. Keine Baseline-Messungen vor dem Projekt. Der häufigste Grund, warum ROI-Nachweise nach dem Projekt scheitern: Es gibt keine Vorher-Daten. Wie lange hat eine Recherche vorher durchschnittlich gedauert? Wie oft wurde der Bereitschaftsdienst für technische Fragen angerufen? Wer das vor dem Projekt nicht gemessen hat, kann den Erfolg hinterher nicht belegen — und kämpft in der nächsten Budgetrunde ohne Argumente.

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

Die erste Phase überrascht fast immer positiv: Ein RAG-System auf gut aufbereiteten Dokumenten liefert bereits nach 6–8 Wochen Pilotergebnisse, die Techniker im Test für überzeugend halten. Das ist ermutigend — und gefährlich. Der Pilot läuft auf den 10% der Dokumente, die aufgeräumt sind. Die 90% kritischeren Dokumente kommen erst.

Die zweite Phase — die Datenaufbereitung der schwierigen Restmenge — ist die härteste. Hier entstehen die echten Projektverzögerungen. Wer plant, das System Q3 zu launchen, sollte Q1 des Folgejahres als realistischen Termin setzen.

Was nicht passiert: Das System ersetzt keine fachliche Urteilskraft. Ein Techniker, der nicht weiß, was er sucht, findet auch mit dem besten Assistenzsystem die falsche Antwort. Das System ergänzt Erfahrung — es substituiert sie nicht. Dieser Punkt muss in der Einführungskommunikation klar sein, damit die Skepsis erfahrener Mitarbeitender (“Das kann mir meine 20 Jahre Erfahrung nicht ersetzen”) nicht zum Blockadeargument wird. Die richtige Aussage: “Das System gibt dir in 2 Minuten, was du früher 30 Minuten gesucht hast — damit du mehr Zeit für die Fragen hast, die wirklich Erfahrung brauchen.”

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Wir haben keine Zeit, 50.000 Seiten Dokumentation aufzuräumen.” Das stimmt: Das Projekt erfordert Dokumentenarbeit, und das ist die Ressource, die am schwierigsten freizustellen ist. Die pragmatische Alternative: Beginne nicht mit dem Anspruch, alle Dokumente aufzubereiten. Fang mit dem Bereich an, wo der Schmerz am größten ist — typisch: Schutzrelais-Parametrierung, Netzanschlussregeln, Betriebsanweisungen für häufig genutzte Anlagetypen. Ein Pilot auf 500 Seiten wirklich guter Daten zeigt mehr als ein System auf 50.000 Seiten schlechter.

„Ein LLM kann halluzinieren — im Netzbetrieb ist das inakzeptabel.” Das ist ein berechtigter Einwand — und er erklärt, warum die Architektur wichtig ist. Ein RAG-System zitiert immer die Quelle, aus der die Antwort kommt. Wenn du nach der Antwort fragst und das System antwortet “laut Handbuch REF-615, Version 2022-Q2, Abschnitt 4.3.1”, kannst du die Quelle prüfen. Das ist strukturell anders als ein Modell, das aus seinem Training antwortet. Die Halluzinations-Kontrolle ist das Quellennachweis-Protokoll — nicht ein Vertrauen in die Unfehlbarkeit des Modells.

„Wir brauchen erst eine bessere Datenstrategie, bevor wir mit KI anfangen.” Dieser Einwand ist often berechtigt — aber er wird manchmal als Verschiebungsargument genutzt. Die Datenstrategie, die für ein LLM-System sinnvoll ist, ist die gleiche, die für jedes andere Informationssystem sinnvoll wäre: klare Versionierung, Metadaten, Zuständigkeiten. Wenn diese Strategie seit Jahren fehlt, wird sie auch ohne KI-Projekt noch lange fehlen. Ein LLM-Pilotprojekt kann — wenn klug formuliert — zum Katalysator für die überfällige Datenstrategie werden, nicht zu ihrem Opfer.

Woran du merkst, dass das zu dir passt

• Dein Unternehmen betreibt Netze oder Erzeugungsanlagen mit Anlagenparks von über 10 Jahren Betriebszeit und entsprechend angewachsener Dokumentation
• Ihr habt eine messbare Abhängigkeit von einzelnen Schlüsselpersonen für technisches Fachknowhow — und das ist strategisch bekannt
• Es gibt ein Data-Science-Team oder eine dedizierte IT-Einheit, die ein solches Projekt technisch trägt
• Datensouveränität ist eine Nicht-Verhandlungsposition: SCADA-Daten, Handelspositionen oder Netztopologie dürfen die Cloud nicht sehen

Wer noch nicht soweit ist:

• Versorger unter 500 MW installierter Leistung ohne dediziertes Data-Science-Team — der Implementierungsaufwand übersteigt den Nutzen bei dieser Größe
• Unternehmen, deren Dokumentenqualität so schlecht ist, dass eine grundlegende Bereinigung noch aussteht — zuerst Datenqualität, dann KI
• Teams, die sich einen schnellen ROI innerhalb von 12 Monaten erhoffen — dieses Projekt hat eine Amortisation von 18–30 Monaten

Das kannst du heute noch tun

Mache einen ehrlichen Dokumenten-Audit für einen einzigen Anlagentyp, der dir täglich Fragen kostet — beispielsweise einen bestimmten Relaishersteller oder Trafotyp. Wie viele Dokumentenquellen existieren? Wie viele Versionen? Welche sind aktuell, welche veraltet? Wer ist verantwortlich?

Die Antworten auf diese Fragen sagen dir mehr über die Realisierbarkeit eines LLM-Projekts als jede technische Machbarkeitsstudie.

Quellen & Methodik

• E.ON Pressemitteilung (2023): “Assistant with energy expertise: E.ON’s own generative artificial intelligence goes live” — eon.com, bestätigt öffentlichen Rollout eines internen GenAI-Assistenten
• BDEW Jahresbericht (2024): Studie zu digitaler Transformation und Personalentwicklung in Netzbetrieben; Schätzung zu Dokumentenvolumen und demografischem Wandel
• Arxiv (2025): “Towards EnergyGPT: A Large Language Model Specialized for the Energy Sector” — arxiv.org, Literaturüberblick zu domänenadaptierten Modellen
• Fraunhofer ISE (2024): Beiträge zu KI und domänenadaptierter Sprachverarbeitung im Energiesektor
• Aleph Alpha Unternehmensangaben (2024/2025): PhariaAI-Referenzkunden in kritischer Infrastruktur und öffentlichem Sektor
• EU AI Act (2024): Anhang III — Klassifikation KI-Systeme in kritischer Infrastruktur; KRITIS-Anforderungen nach IT-SiG 2.0
• Eigene Projekterfahrungswerte: Datenaufbereitungsaufwände und Implementierungslaufzeiten basierend auf vergleichbaren Branchenprojekten

Du willst wissen, ob eure Dokumentenbasis realistisch für einen LLM-Piloten geeignet ist — oder wo die größten Aufbereitungslücken liegen? Meld dich — ein strukturierter Dokumenten-Audit in einem halben Tag gibt dir mehr Klarheit als jede Grundsatzdiskussion.