Ein öffentlicher Capability Hub für Stadtwerke, Netzbetreiber und Integrationspartner: konkrete Nutzerprobleme, vorhandene CET-Fähigkeiten, Demo-/Integrationspfade und sichere Grenzen.
Summit-Kontext
Cernion/STROMDAO ordnet beim AI Energy Summit ein, wie agentische KI Stadtwerke und Netzbetreiber bei kaufmännischen Prüf-, Entscheidungs- und Dokumentationsprozessen unterstützen kann.
MaStR, ENTSO-E, SMARD, EIC, AGSI und eigene Datenquellen strukturiert nutzbar machen.
REST/OpenAPI, MCP, Copilot-Subset und vorbereitete Tool-Flächen für Fachsysteme.
Fachliche Antworten mit Cernion-Evidenz statt generischer Modellbehauptungen.
Day-Ahead, Erzeugungsprofile, Backtests, Plausibilitäts- und Datenqualitätsmarkierungen.
PLZ/AGS-Ortsauflösung, SLP-Proxies, KAV- und EUR-KPI-Schichten mit klaren Missing-Evidence-Grenzen.
Rollen, Evidenz, Policy, Hash-Chain-Provenienz und kontrollierte Verantwortungsübergaben.
Read-only Fallarbeitsplätze, Blueprint Packs und Demo-Prozesse für überprüfbare Szenarien.
Aus API-Signalen werden Dossiers, Fachberichte, Checklisten und nächste Prüfschritte.
Fähigkeit: Rollen, Verantwortlichkeiten, Mitwirkung und Informationspflichten in einer Prüfakte sichtbar machen.
API-Anker: GET /api/dashboard-api/decision-readiness-matrix, GET /api/dashboard-api/interconnection-release-file.
Grenze: keine Anschluss-, Kapazitäts-, Tarif-, Settlement- oder Gerätefreigabe.
Fähigkeit: Falllisten, Rollenqueues, nächste Prüfschritte und Evidenzstatus für Fachrollen als read-only Arbeitslage vorbereiten.
API-Anker: GET /api/dashboard-api/stadtwerk-mauer-case-actions, POST /api/copilot-process/intents.
Grenze: Workbench bereitet vor; sie schreibt nicht ungeprüft in Fachsysteme.
Fähigkeit: synthetische Prüfakten für Netzanschluss-, BESS-, Redispatch- oder Modellviabilitätsfälle mit Nachweisfeldern strukturieren.
API-Anker: GET /api/dashboard-api/stadtwerk-mauer-blueprint-pack-verify.
Grenze: Evidence Pack, kein Genehmigungsautomat.
Fähigkeit: Quellen, Annahmen, offene Nachweise, Plausibilitätsgrenzen und HITL-Punkte in einer Entscheidungsvorbereitung nachvollziehbar halten.
API-Anker: GET /api/dashboard/cross-system-variance-matrix, GET /api/dashboard/model-viability-evidence-gate.
Grenze: Nachvollziehbarkeit ersetzt keine fachliche oder regulatorische Freigabe.
Fähigkeit: historische Preis-, Erzeugungs- und Portfolio-Szenarien nachvollziehbar rechnen und Datenqualitätsgrenzen markieren.
API-Anker: POST /api/energy-market/portfolio-backtest, GET /api/jobs/:jobId/progress.
Grenze: keine Erlös-, Preis-, Beschaffungs- oder Ergebnisgarantie.
Fähigkeit: kommunale Lagebilder aus Ort/PLZ/AGS, Anlagenkontext, SLP-Proxies und fehlenden Messwerten als erste Befassung darstellen.
API-Anker: GET /api/dashboard-api/load-profile-stream-monitor.
Grenze: nicht abrechnungsrelevant, kein Messwert- oder Autarkieclaim.
Fähigkeit: aus API-/Evidenzsignalen ein prüfbares Antwortpaket für Fachfragen, Reports, Praxisfragen oder n8n/OpenWebUI-Flows ableiten.
API-Anker: POST /v1/chat/completions, POST /api/customer-service/portal-widget.
Grenze: kein Modellqualitätsversprechen und keine Live-Kundendaten in öffentlichen Demos.
Stadtwerke und Netzbetreiber müssen dieselbe Frage oft aus MaStR-Exporten, ENTSO-E/SMARD-Daten, EIC-Listen, Gas-Speicherständen, lokalen CSV/XLSX-Dateien und Fachwissen zusammensetzen. Das kostet Zeit und macht Unsicherheiten schwer sichtbar.
Cernion Energy Tools bündeln Energie- und Betreiberquellen als REST-/MCP-nahe Services: Installationssuche, Preis-/Erzeugungsdaten, Netz-/Redispatch-Kontext, Gas Storage, EIC Codes, German Grid Data und einen Inhouse-Datasource-Layer für eigene Quellen.
Start über REST API, MCP Tools, Inhouse-Daten oder kuratierte Fachseiten wie MaStR-/Redispatch-Tools.
Öffentliche Daten und kundeneigene Daten bleiben getrennt. Import, Cache und Auswertung ersetzen keine fachliche Freigabe. Nächster Schritt: Datenquellen und erlaubte Datenräume abgrenzen.
Fachbereiche wollen Cernion in Portale, BI, n8n, OpenWebUI, Copilot oder eigene Backends einbinden, ohne Tokens in Prompts oder Browser-Exports zu verlieren.
Die Plattform bietet eine dokumentierte REST-/OpenAPI-Fläche, MCP-orientierte Tool-Nutzung, ein Copilot-Prozess-Subset und einen OpenAI-kompatiblen Chat-Completions-Pfad für kontrollierte Assistenz-Workflows.
Siehe Cernion REST API, API Playground, den n8n-Quickstart unten und die Praxisfrage OpenWebUI, n8n und Fachwerkzeuge.
Tokens gehören in serverseitige Credential-Verwaltung. Schreibende Prozessaktionen werden nicht aus einer Chat-Antwort ausgelöst. Nächster Schritt: Integrationsziel und Auth-/Rollenmodell skizzieren.
Dieses Beispiel zeigt einen tokenfreien n8n-Workflow für die OpenAI-kompatible Cernion API. Er eignet sich als Einstieg für einfache Chat-Completions, Ticket-Notizen und Webhook-basierte Integrationen.
Webhook oder Manual Trigger
→ Set Context
→ HTTP Request: POST https://api.cernion.de/v1/chat/completions
→ Ticket-Notiz / Respond to WebhookVoraussetzungen: Cernion API-Zugang mit Bearer Token, eine n8n-Instanz mit HTTP Request Node und ein Zielsystem für die Antwort, z. B. Webhook-Response, Ticket-Notiz oder ein internes Workflow-Feld.
POST https://api.cernion.de/v1/chat/completions
Authorization: Bearer <CERNION_TOKEN>
Content-Type: application/json{
"model": "cernion-default",
"messages": [
{
"role": "system",
"content": "Du bist Cernion und beantwortest fachlich, knapp und nachvollziehbar."
},
{
"role": "user",
"content": "={{ $json.ticketText || $json.question || 'Bitte fasse den Vorgang zusammen.' }}"
}
],
"temperature": 0.2
}n8n-Beispielworkflow herunterladen
Der importierbare Workflow enthält Manual Trigger, Webhook Trigger, Set Context, HTTP Request an /v1/chat/completions, Set Ticket Note und Respond to Webhook. Er ist inaktiv, tokenfrei und nutzt den öffentlichen Standardhost https://api.cernion.de sowie den Platzhalter <CERNION_TOKEN>. Vor produktiver Nutzung müssen Token-Handling, Tenant-/Rollenmodell und Zielsystem intern konfiguriert werden.
Für Answer-Dossier-, Renderer- und Copilot-Szenarien bleibt die technische Referenz docs/n8n-answer-dossier-test.md relevant: n8n rendert dann ein von Cernion geliefertes Dossier-Paket, statt zusätzliche Fachlogik im Workflow zu erfinden.
KI-Agenten klingen hilfreich, bleiben aber riskant, wenn nicht erkennbar ist, welche Daten, Quellen, Rollen und offenen Prüfpunkte hinter der Antwort stehen.
Cernion kann als Evidenz- und Prozessschicht für Agenten dienen: fachliche Datenräume, Grid Context, Knowledge-RAG, Evidence Routing, Rollen-/VDMI-Kontext und no-call Grenzen bleiben serverseitig kontrolliert.
Öffentlich anschlussfähig sind KI-Nutzertest, OpenClaw + Cernion Sidecar und die Praxisfrage KI-Agent im Stadtwerk.
Cernion liefert Einordnung, Evidenz, Unsicherheit und nächsten Prüfschritt. Freigabe, Versand, Schreiben, Abrechnung, Tarif- oder Geräteaktion bleiben getrennte Prozesse. Nächster Schritt: ersten Antwortfall als KI-Nutzertest definieren.
Portfoliofragen scheitern oft daran, dass Preiszeitreihen, Erzeugungsprofile, Kommissionierungsdaten, negative Preise und Datenlücken in verschiedenen Werkzeugen liegen.
Der Portfolio-Backtest kann historische Day-Ahead-Marktwert-Szenarien über Asset-Portfolios nachvollziehbar auswerten, Preis-/Erzeugungsdaten nutzen, Datenqualität kennzeichnen und Plausibilitätsgrenzen sichtbar machen.
Geeignet für API-Backends, Fachreports und Entscheidungsvorlagen. Einstieg über REST API, Preis-/ENTSO-E-Seiten und Fach-Reports.
Backtests sind Szenario-/Datenqualitätsrechnungen, keine Garantie für Erlöse oder regulatorische Behandlung. Nächster Schritt: Beispielportfolio und gewünschte Evidenzstufen abstimmen.
Kommunale Energiefragen brauchen schnell eine erste Karte: Ort/PLZ/AGS, Erzeugungsstruktur, Lastproxy, KAV-/Budgetwirkung, Risiken und fehlende Evidenz. Ohne Grenze werden daraus zu leicht Scheingenauigkeiten.
CET enthält Resolver- und Lagebildbausteine für deutsche Gemeinden, SLP-basierte Proxy-Schichten, EUR-KPIs, Missing-Evidence-Felder und No-Autarky-Guardrails. Damit wird sichtbar, was belastbar ist und was nur Annahme bleibt.
Öffentlich anschlussfähig über Lagebild-/Reportformate, Praxisfragen und Demo-Raum-Artefakte. Siehe Reports und Praxisfragen.
SLP-Proxies und kommunale Szenarien sind nicht abrechnungsrelevant und ersetzen kein Messkonzept. Nächster Schritt: Gemeinde, Datenlage und gewünschte Befassungsebene festlegen.
Viele Prozessfragen sind nicht primär Rechenfragen, sondern Verantwortungsfragen: Wer darf prüfen, wer muss mitwirken, welche Evidenz fehlt, und wann braucht es menschliche Entscheidung?
CET liefert VDMI-/Rollenprojektionen, Governance-Policy-Auswertung, Decision-Provenance mit Quellenstruktur und Hash-Chain-Prüfung sowie HITL-/Resolver-Rollen als explizite Kontrollpunkte.
Geeignet für Copilot-Prozessbrücken, Role Workbenches, Dossiers und Audit-Trails. Einstieg über Sidecar, REST API und Demo-Raum.
Governance-Projektionen bereiten Entscheidungen vor; sie ersetzen keine Freigabe und lösen keine MaKo-, Billing-, Tariff-, Device-Control- oder Public-Publishing-Aktion aus. Nächster Schritt: einen Prozess mit VDMI-Rollen modellieren.
Einzelne API-Endpunkte überzeugen selten, wenn Fachbereiche nicht sehen, wie daraus eine reale Arbeitsoberfläche, Fallliste, Evidenzübergabe oder Prüfakte entsteht.
CET enthält Workbench-Hubs, Rollen-Queues, Selected-Case-Projektionen, Administrator-Inventare, Blueprint-Pack-Seeds und Verify-Runbooks als read-only bzw. verify-only Bausteine für Fallarbeit.
Der Cernion Demo-Raum zeigt public-safe Prozess- und Mini-App-Artefakte. Workbench-Logik kann in Budibase, Fachportalen oder internen Apps gerendert werden.
Workbench bedeutet Anzeige, Prüfung, Vorbereitung und Evidenzhandover — nicht System-of-Record-Übernahme. Nächster Schritt: geeigneten Demo-Prozess auswählen.
Technische Fähigkeiten müssen für Geschäftsführung, Netz, Vertrieb, IT, Compliance oder Gremien anders erklärt werden als für Entwickler.
Aus API-/Evidenzsignalen lassen sich Reports, Praxisfragen, Dossiers, Gap-Listen, Quellenketten und sichere nächste Schritte ableiten. Die Stärke liegt in der Übersetzung von Werkzeugfähigkeit in prüfbare Fachkommunikation.
Siehe Fach-Reports, Praxisfragen, Timeline und ausgewählte öffentliche Artefakte im GitHub-Projekt.
Öffentliche Texte bleiben neutral: keine nicht belegten Kundenerfolge, keine harten regulatorischen Garantien, keine Preise/Tarife ohne Freigabe. Nächster Schritt: internes Signal in public-safe Dossier übersetzen.