KI-Produktivierung & Observability bei E.ON

E.ON betreibt 1,6 Millionen Kilometer Energienetz für 47 Millionen Kunden in 17 Ländern. Fällt etwas aus, sitzen Menschen im Dunkeln. Mein Engagement hatte zwei Aufträge: KI für 8 Mio.+ Energiekunden in Produktion bringen und das Observability-Fundament darunter reparieren. Der zweite erwies sich als Voraussetzung für den ersten. KI-gestützter Betrieb arbeitet auf Telemetrie, und E.ONs Telemetrie war auf sechs Monitoring-Tools verteilt.

Sechs Tools über IT, OT und Netzbetrieb, keines mit dem vollständigen Bild. Dezentrale Erneuerbare machten das Netz quartalsweise volatiler, und Alert Fatigue zermürbte die Bereitschaftsteams. Die sechs herauszureißen hätte jahrelange Scripts, Integrationen und eingeübte Abläufe rund um diese Tools entwertet, also haben wir darunter konsolidiert. OpenTelemetry wurde der einheitliche, herstellerneutrale Standard für Traces, Metrics und Logs, mit New Relic als Plattformschicht: APM, Infrastructure Monitoring, Kubernetes Auto-Discovery via eBPF, KI-gestützte Ursachenanalyse.

Am härtesten habe ich für semantische Konventionen gekämpft: dafür, dass Teams Dinge einheitlich benennen. Automatische Korrelation funktioniert nur auf Labels, die zusammenpassen, und die KI-Diagnostik, die wir später bauen wollten, hing daran.

Für kritische Infrastruktur ist KI in Produktion vor allem Governance- und Delivery-Arbeit. Die MLOps-Pipelines, die wir bauten, ersetzten manuelle Release-Schritte durch automatisiertes Testen; die Zeit für das Modell-Deployment sank um 45 %, Produktions-Incidents gingen um 60 % zurück. Die Customer-Service-LLMs verarbeiten heute 2 Mio.+ monatliche Interaktionen bei 92 % Genauigkeit. Alles davon liefert innerhalb des regulatorischen Rahmens: BSI-C5-Kontrollen, NIS2, KRITIS/IT-SiG 2.0, mit DSFA-Dokumentation für jede KI-gestützte Verarbeitung von Kundendaten.

Auf dieser Baseline pilotierten wir die agentische Schicht: MCP-verbundene LLMs gegen New Relic in AWS und Azure, für automatisierte Diagnostik und Remediation mit Human-in-the-Loop-Guardrails. Eine Arbeitsgruppe aus Observability, Betrieb und Data Science prüfte, ob die gesammelten Metriken auf definierte SLOs abbilden, sodass der Pilot seinen Wert in Zahlen beweisen musste, denen die Operatoren bereits vertrauten.

Pathpoint verknüpfte Customer Journeys, Bestellprozesse und Backend-Services mit gemeinsamen KPIs, Netzbetreiber bekamen Echtzeit-Zustandsschätzung und Engpasserkennung. Ein Incident kam früher als „dieser Service ist down“ an. Heute kommt er als „das betrifft X Kunden im Abrechnungsprozess“ an, und die Priorisierungsdiskussionen wurden kürzer.

Self-Service-Dashboards und Templates brachten Observability zu tausenden Nutzern, ohne dass ein zentrales Team zur Warteschlange wurde. Ein wiederverwendbares Onboarding-Playbook für Collectors, Alerts, SLOs und Dashboards bedeutete: Neue Teams erreichen produktionsreife Observability in Tagen.

• KI in Produktion für 8 Mio.+ Energiekunden: 2 Mio.+ monatliche LLM-Interaktionen bei 92 % Genauigkeit
• 45 % schnelleres Modell-Deployment und 60 % weniger Produktions-Incidents durch MLOps-Pipelines mit automatisiertem Testen
• Sechs Monitoring-Tools zu einer OpenTelemetry-Plattform über IT, OT und Netz konsolidiert
• Agentische Diagnostik mit MCP-verbundenen LLMs pilotiert, abgesichert durch Human-in-the-Loop-Guardrails
• BSI-C5-, NIS2- und KRITIS-konforme Governance mit DSFA-Dokumentation

Wie wir entschieden haben, was ein Agent allein tun darf, und wie die Guardrails darum aussahen, steht in The AI-native Platform Playbook.