Private KI in der Energiebranche: Drei Kontrollen, sonst kein KRITIS-Einsatz.

KI zieht in die operativen Prozesse der Energiebranche ein. Sie hilft beim Lastgangsforecast, schreibt Briefe an Netznutzer, klassifiziert MaKo-Vorgänge, beantwortet Tarif-Fragen, sortiert Trading-Signale. Vieles davon wird über kurz oder lang in Prozesse einsickern, die unter das KRITIS-Regime fallen. An genau diesem Punkt verändern sich die Anforderungen — und der Standard-Cloud-API-Reflex aus dem Marketing-Department reicht nicht mehr.

Wer KI in die Tiefe eines Energieversorgers, eines Direktvermarkters, einer Stadtwerk-Vertriebsorganisation oder eines Verteilnetzbetreibers einbaut, muss drei Dinge gleichzeitig im Griff haben: die Daten, die Verfügbarkeit, das Verhalten. Fehlt eine davon, ist die Lösung für KRITIS-nahe Prozesse nicht tragfähig — egal wie gut das Sprachmodell von außen wirkt.

Kontrolle 1: Die Daten

Über diesen Punkt wird viel geschrieben — und es ist trotzdem unzureichend verstanden. Ein Energieversorger, der einem US-Cloud-KI-Anbieter MaKo-Vorgänge, Bilanzkreis-Daten, Lastprofile, Vertragsstammdaten oder Trading-Positionen in den Prompt schreibt, gibt die wirtschaftlich wertvollsten Daten des Hauses an einen Dritten. Selbst wenn der Anbieter vertraglich „nichts speichert" oder „nicht trainiert": die Daten verlassen das Haus, sie liegen kurzfristig in fremden Logs, und der gesamte Trade-Off ist nicht technisch erzwungen, sondern vertraglich gestützt — und damit beendbar oder ergänzbar mit einer neuen AGB-Version.

Das wirklich Heikle ist nicht der Datenschutz im engeren Sinne. Es ist die wettbewerbliche Substanz. Wer Marktposition, Vermarktungsstrategie, Asset-Verfügbarkeit oder Vertragsmechanik in ein externes Modell pumpt, gibt das Signal her, aus dem ein Wettbewerber — oder die übergeordnete Plattformfirma — Erkenntnisse ziehen kann. Selbst aggregiert. Selbst „anonymisiert". In einem Markt, in dem Margen von 0,5 ct/kWh über die Quartalsbilanz entscheiden, ist das keine vernachlässigbare Größe.

Datenschutzkonforme KI ist eine technische Eigenschaft, kein Marketing-Versprechen. Wenn die Daten irgendwann das eigene Rechenzentrum verlassen — auch nur „zur Telemetrie" — ist es keine private KI mehr. Punkt.

Die saubere Antwort: das Modell läuft beim Unternehmen. Die Vektordatenbank läuft beim Unternehmen. Embeddings, Logs, Audit-Trails — alles bleibt im eigenen Sicherheitsperimeter. Kein Webhook, kein „Telemetrie-Endpoint", keine API-Kette zu einer fremden Cloud. Was im Haus bleibt, bleibt im Haus.

Kontrolle 2: Die Verfügbarkeit

Dieser Punkt wird in der KI-Debatte gerne übersehen — und ist der eigentlich strukturelle. Denn Daten lassen sich vertraglich absichern, regulatorisch flankieren, juristisch nachverfolgen. Verfügbarkeit kann man nicht erzwingen, wenn man sie nicht kontrolliert.

Was bedeutet das konkret? Wenn ein Stadtwerk seinen Kundenservice-Triage-Agenten an einer US-Cloud-API betreibt, dann hängt der Service-Level am vertraglichen Wohlwollen eines Anbieters, der in einer anderen Jurisdiktion sitzt. Sanktionen können Zugriffe einschränken. Regulatorische Auflagen können Modellklassen abschneiden. Ein Anbieter kann ein Modell schlicht deprecaten — und das eigene System läuft ab Donnerstag mit einem anderen Verhalten. Eine Energiekrise oder geopolitische Verwerfung kann den Compute-Markt verteuern und vertragliche Volumen-Garantien aushebeln.

Für Use-Cases im Marketing oder im Vertriebs-Support ist das ein Ärger. Für Use-Cases, die in KRITIS-Prozesse einsickern — Netzleitsteuerung-Assistent, Bilanzkreis-Validierung, Vorgangs-Routing, Tarif-Beratung im Endkundenkanal — ist es ein Versorgungsrisiko. Energieversorger und Netzbetreiber kennen das Muster aus Hardware und Software: wer kritische Systeme in fremde Hände gibt, übernimmt politisches Risiko, das er nicht steuern kann.

Wenn KI in KRITIS-Prozesse einzieht, darf ihre Verfügbarkeit nicht in einer fremden Jurisdiktion liegen. Das ist nicht Cloud-Skepsis. Das ist Versorgungslogik.

Die saubere Antwort: das Modell läuft auf eigener Infrastruktur — oder in einer Private Cloud bei einem europäischen Anbieter, dessen Kontroll-Kette nachvollziehbar bei einem europäischen Rechtskreis endet. Hetzner, OVH, STACKIT, Open Telekom Cloud, Ionos — Anbieter, die kein US-CLOUD-Act-Risiko aufweisen und keine implizite politische Abhängigkeit von außereuropäischen Eskalationen haben. Die Modelle selbst (Llama, Mistral, Qwen, Gemma in ihren offenen Varianten) liegen lokal vor, sind versioniert, austauschbar — und nicht von einem Anbieter abhängig, der sie morgen aus dem Katalog nimmt.

Kontrolle 3: Das Verhalten

Daten kontrolliert. Verfügbarkeit kontrolliert. Reicht das?

Nein. Selbst wenn die ersten zwei Punkte sitzen, bleibt das Problem, dass ein LLM ein probabilistisches System ist. Es kann halluzinieren, es kann driften, es kann sich bei einem Modellwechsel überraschend anders verhalten. In einem operativen Energie-Prozess ist das nicht akzeptabel. Die KI braucht Leitplanken.

Das ist die unbequemere Seite der Souveränitätsdebatte. „Wir hosten alles selbst" allein hilft nichts, wenn das System Antworten generiert, die fachlich falsch oder regulatorisch grenzwertig sind. Der dritte Kontroll-Pfeiler ist deshalb technischer Natur — und er hängt direkt mit der eigenen Kontrolle über die Infrastruktur zusammen:

Definierter Verhaltensrahmen. Die KI bekommt eine explizite, getestete System-Prompt-Architektur. Sie weiß, was sie darf und was nicht. Sie kennt die fachlichen Grenzen ihres Use-Cases. Sie hat Eskalationspfade für Fälle außerhalb ihres Mandats.

RAG statt Halluzination. Sachfragen werden nicht aus dem Modellwissen beantwortet, sondern aus einer kuratierten, lokal gehosteten Wissens­basis (Verträge, Pflichtenhefte, Anlagen-Doku, BNetzA-Festlegungen, Compliance-Bibliothek). Jede Antwort kommt mit Quellverweis.

Audit-Trail by Design. Jeder Prompt, jede Tool-Verwendung, jede Antwort wird strukturiert geloggt — für interne Revision, BSI-Audit oder Notfall-Forensik. Wer nachvollziehen muss, was die KI getan hat, kann es nachvollziehen.

Versions-Kontrolle über Modelle. Wenn das Verhalten validiert ist, friert man die Modell-Version ein. Ein Anbieter-Update kommt nur ins Produktiv-System, wenn es vorher gegen die eigene Test-Suite validiert wurde. Das geht nur, wenn man das Modell selbst hat.

Vorhersagbarkeit ist kein Add-on. Sie ist die operative Voraussetzung dafür, dass eine KI in einem energiewirtschaftlichen Prozess überhaupt zugelassen werden kann.

Was wir bei Kunden gerade sehen

Diese Debatte ist nicht akademisch. Sie steht gerade jeden Monat häufiger im Raum, wenn wir mit Stadtwerken, Direktvermarktern und Verteilnetzbetreibern über KI-Use-Cases sprechen.

Die ersten Reflexe von vor 18 Monaten — „setzen wir kurz eine OpenAI-Integration auf" — werden seltener. Die Frage, mit der Gespräche eröffnen, lautet zunehmend: „Geht das auch ohne Cloud-API?" oder „Können wir das im eigenen Rechenzentrum betreiben?" oder direkt: „Was passiert, wenn der US-Anbieter abschaltet?" Wer einen Compliance- oder Datenschutzbeauftragten im Haus hat, kennt diese Fragen schon. Wer einen Aufsichtsrat hat, kennt sie spätestens, seitdem die geopolitische Großwetterlage 2025 wieder lauter geworden ist.

Es ist auch keine Anti-Cloud-Haltung. Für Marketing-Texte, für interne Brainstormings, für Code-Vorschläge in unkritischen Repositories — Cloud-API-KI bleibt die richtige Antwort, weil das Risiko-Profil dort umgekehrt ist. Aber sobald die Daten regulatorisch relevant sind oder der Prozess in eine versorgungs­kritische Kette einzieht, kippt die Rechnung. Und unsere Kunden spüren das.

Es ist nicht die Frage, ob KI in der Energiebranche kommt. Es ist die Frage, welche.

Wohin wir gehen

qurix begleitet Energieversorger, Stadtwerke, Direktvermarkter und Netzbetreiber zunehmend genau bei diesem Übergang: weg von der schnellen Cloud-API-Lösung, hin zu Architekturen, in denen die KI im Sicherheitsperimeter des Unternehmens lebt — auf eigener GPU-Hardware, in europäischer Private Cloud, mit lokalen Modellen, lokalen Vektorspeichern, lokalem Audit-Trail. Wir machen das nicht aus ideologischen Gründen. Wir machen es, weil es die einzige technisch belastbare Antwort für KRITIS-nahe Use-Cases ist.

Das Setup ist anspruchsvoller als ein API-Key in einem Vertriebs-Repo. Es ist aber kein Mondflug. Die Bausteine — quantisierte Open-Source-Modelle, On-Prem-Inferenz-Engines, lokale RAG-Pipelines, Air-Gap-fähige Operations — sind vorhanden, getestet und produktiv. Der Unterschied liegt nicht in der Komplexität, sondern in der Konsequenz: man muss sich entscheiden, die Kontrolle zu behalten, statt sie für ein bequemes API-SDK aufzugeben.

Wer KI in die Energiebranche bringt und dabei die drei Kontrollen — Daten, Verfügbarkeit, Verhalten — nicht im eigenen Haus hat, baut nicht KI. Er baut Abhängigkeit mit KI-Marketing-Lack.