Wie lässt sich Cernion in OpenWebUI, n8n und Fachwerkzeuge integrieren?

Frage

Wie lässt sich Cernion in bestehende KI-Oberflächen, Automatisierungen und Fachanwendungen integrieren?

Kurze Antwort

Cernion stellt aktuell eine kuratierte REST-/OpenAPI-Integrationsfläche unter https://api.cernion.de bereit. Für kontrollierte Assistenz-Workflows ist zusätzlich der OpenAI-kompatible Chat-Completions-Pfad https://api.cernion.de/v1/chat/completions als öffentlicher Integrationsstandard dokumentierbar.

Wichtig bleibt: Der Chat-Completions-Pfad ist ein Adapter für kontrollierte Fachassistenz, Ticket-Notizen und Renderer-/Workflow-Szenarien — kein Freibrief für automatische Prozessaktionen. Tenant, Rollen, zulässige Datenräume und Prozessgrenzen werden serverseitig bestimmt und nicht durch den Prompt des Nutzers.

Aktueller technischer Einstieg

Für Integrationen ist derzeit die öffentlich dokumentierte API-Fläche maßgeblich:

https://api.cernion.de/api/openapi.json
https://api.cernion.de/api/openapi-copilot.json
https://api.cernion.de/v1/chat/completions

Diese OpenAPI-Beschreibungen zeigen, welche REST-, Copilot- und Sidecar-orientierten Endpunkte öffentlich dokumentierbar sind. Der Chat-Completions-Pfad dient als OpenAI-kompatibler Adapter für kontrollierte Assistenz-Workflows. Tokens, Mandantenrechte und Prozessrollen gehören dabei immer in die serverseitige Credential- oder Rollenverwaltung des jeweiligen Systems — nicht in Prompts, Browser-Quelltext, geteilte Workflow-Exports oder Screenshots.

OpenWebUI

OpenWebUI ist als Bedienoberfläche interessant, weil es energiewirtschaftliche Fachfragen in einer bekannten Chat-UI sichtbar machen kann. Für Cernion ist der sichere öffentliche Stand: OpenAI-kompatible Chat-Completions können über den freigegebenen Standardhost https://api.cernion.de angebunden werden, sofern Token, Tenant, Rollen und erlaubte Datenräume serverseitig sauber geführt werden.

Praktisch bedeutet das:

• OpenWebUI kann als Zieloberfläche für Wissenschat und Fachdialog dienen.
• Die Cernion-seitige Freigabe des konkreten Adapterpfads ist Voraussetzung.
• Tenant, Rollen, Evidenzräume und Antwortmodus bleiben serverseitige Cernion-Grenzen.
• Schreibende Prozessaktionen werden nicht durch eine Chat-Antwort ausgelöst.

Wer die Qualität eines solchen Fachdialogs einschätzen möchte, kann zunächst den öffentlichen KI-Nutzertest ansehen: Cernion KI-Nutzertest.

n8n

n8n eignet sich für kontrollierte Workflows rund um Cernion. Der öffentliche Quickstart nutzt den OpenAI-kompatiblen Chat-Completions-Pfad unter https://api.cernion.de/v1/chat/completions; ein importierbarer Beispielworkflow liegt auf der Capability-Hub-Seite bereit.

Webhook oder Manual Trigger
  → Set Context
  → HTTP Request: POST https://api.cernion.de/v1/chat/completions
  → Ticket-Notiz / Respond to Webhook

Geeignete Workflows:

• Eingangssignal aus Formular, Ticket oder Mail fachlich einordnen,
• Cernion-Antwort als interne Entscheidungsvorlage erzeugen,
• Unsicherheiten und fehlende Evidenz als separate Felder in einen Review-Schritt übergeben,
• tägliche Prüflisten wie „Was braucht heute fachliche Entscheidung?“ vorbereiten,
• Ergebnisse erst nach Human-in-the-loop in ein Fachsystem übernehmen.

Eigene Fachanwendungen

Ein Netzplanungs-, Asset-MDM- oder Betriebsfrontend kann Cernion im Hintergrund über dokumentierte API-Pfade ansprechen. Der Nutzer arbeitet weiter in seiner Fachoberfläche, erhält aber Cernion-Hinweise wie:

• ähnliche frühere Anfrage gefunden,
• fehlende Evidenz für eine Entscheidung,
• VDMI-Rolle oder Verantwortlichkeit unklar,
• Prozessschritt sollte erst bestätigt werden,
• Dossier für die nächste Befassung vorbereiten.

Hier ist besonders wichtig: Die Fachanwendung darf Cernion-Hinweise nicht ungeprüft in Prozessaktionen übersetzen. Cernion kann Einordnung, Evidenz und nächste Prüfschritte liefern; Ausführen, Senden, Schreiben oder Freigeben bleibt ein getrennter, rollen- und freigabegesicherter Prozess.

MS365 Copilot und Agenten

Für Copilot- und Agenten-Szenarien ist ein OpenAI-kompatibler Chat-Endpunkt nicht immer die beste erste Schnittstelle. Häufig ist ein OpenAPI-, Tool- oder Answer-Dossier-Ansatz robuster, weil er die Fachlogik in Cernion hält und die Oberfläche nur als Renderer nutzt.

Das Muster:

Copilot / Agent / Office-Oberfläche
  → kuratierter Tool- oder OpenAPI-Aufruf
  → Cernion liefert fachliche Einordnung, Evidenz und Grenzen
  → Oberfläche rendert die Antwort für den Menschen
  → Prozessaktion bleibt separat freigabepflichtig

Retool und Budibase

Retool, Budibase und vergleichbare interne Fachmasken sind gute Integrationsziele, wenn sie serverseitige Credentials, kontrollierte HTTP-Requests und getrennte Review-Schritte unterstützen.

Typische Nutzung:

• Fachmaske zeigt Vorgangsdaten,
• Backend oder gesicherter Connector ruft Cernion auf,
• Antwortfelder werden sichtbar getrennt: Einordnung, Evidenz, offene Frage, empfohlener nächster Prüfschritt,
• ein Mensch übernimmt oder verwirft den Vorschlag.

Make, Zapier und vergleichbare No-Code-Automation

Make, Zapier und ähnliche Werkzeuge können Cernion prinzipiell über HTTP-Requests anbinden, sofern Header, JSON-Body, Antwortauswertung und Credential-Schutz sauber konfigurierbar sind.

Für regulierte Fachprozesse sollte diese Klasse von Werkzeugen aber besonders vorsichtig eingesetzt werden:

• keine Tokens in frei sichtbaren Feldern,
• keine automatischen Außenkommunikationen aus Cernion-Antworten,
• klare Protokollierung, welcher Schritt nur Vorschlag ist,
• Review- oder Freigabe-Gate vor jedem Schreiben in Zielsysteme.

Node-RED, CLI und Batch

Node-RED, CLI-Skripte und Batch-Jobs eignen sich für technische Betriebsautomation, Monitoring oder Entscheidungslisten. Beispiele:

• wiederkehrende Plausibilitätsprüfung offener Vorgänge,
• Vorbereitung einer Liste prüfbedürftiger Datenstände,
• Erzeugung interner Review-Notizen,
• Abgleich, ob Evidenz für eine Entscheidung fehlt.

Auch hier gilt: Cernion sollte Hinweise, Dossiers oder Review-Aufgaben erzeugen — nicht automatisch operative Entscheidungen auslösen.

Integrationsmatrix

Integration	Aktueller öffentlicher Stand	Nutzen	Leitplanke
OpenWebUI	über https://api.cernion.de als OpenAI-kompatibler Chat-Completions-Pfad integrierbar	Chat-UI für Fachfragen	Token, Tenant und Rollen serverseitig sauber führen
n8n	öffentlicher Beispielworkflow für /v1/chat/completions verfügbar	Workflow-, Ticket- und Review-Automation	Human-in-the-loop vor Prozessaktion
Eigene Fach-App	über dokumentierte API-Pfade realistisch	Cernion im Hintergrund	Credentials serverseitig halten
MS365 Copilot / Agenten	über OpenAPI-/Tool-/Dossier-Muster	bekannte Arbeitsoberfläche	Oberfläche rendert, Cernion führt Fachlogik
Retool / Budibase	geeignet für interne Fachmasken	strukturierte Prüfansicht	Vorschlag und Entscheidung trennen
Make / Zapier	prinzipiell über HTTP möglich	einfache SaaS-Automation	Token- und Freigabegrenzen streng prüfen
Node-RED / CLI	geeignet für Batch, Monitoring und Review-Listen	technische Betriebsautomation	keine automatische Fachentscheidung

Aktuelle Grenze: Wissenschat und Dossier

Der sichere Einstieg ist bewusst konservativ. Cernion soll beantworten, einordnen, Evidenz benennen und sichere nächste Schritte formulieren. Es ist nicht dafür gedacht, automatisch operative Entscheidungen auszulösen.

Für Stadtwerke und Netzbetreiber ist der nächste Schritt dennoch entscheidend: Der Agent muss nicht nur die letzte Chatnachricht sehen, sondern den Arbeitszustand eines Prozesses verstehen.

Nächste Ausbaustufe: Prozessgedächtnis

Für produktive Fachprozesse braucht Cernion ein tenant-sicheres Prozessgedächtnis. Gemeint ist kein freies Langzeitgedächtnis des Sprachmodells, sondern ein kontrollierter Zustand innerhalb von Cernion:

• Welcher Prozess oder welche Arbeitsmappe ist betroffen?
• Welche ähnliche Anfrage gab es gestern oder letzte Woche?
• Welche Entscheidung ist offen?
• Welche Evidenz wurde bereits geprüft?
• Welche VDMI-Rolle ist verantwortlich?
• Welche Prozessaktion ist nur vorbereitet und braucht Bestätigung?

Ein Netzplaner könnte dann zum Beispiel fragen:

Was muss ich heute entscheiden?

Cernion würde nicht aus dem Modellgedächtnis antworten, sondern den tenant-gebundenen Arbeitsstand prüfen: offene VDMI-Aufgaben, Prozessintents, frühere ähnliche Anfragen, vorhandene Dossiers, fehlende Evidenz und nächste sinnvolle Review-Schritte.

Leitplanke für Prozessnutzung

Die Cernion-Schnittstelle sollte drei Ebenen klar trennen:

1. Wissenschat: erklären, einordnen, Evidenz zeigen.
2. Prozessgedächtnis: Arbeitsstand, ähnliche Vorgänge und offene Entscheidungen tenant-sicher erinnern.
3. Prozessaktion: nur als Entwurf oder pending_confirmation, niemals automatisch ohne passende Rolle und Freigabe.

Diese Trennung ist der Unterschied zwischen einer hilfreichen Fachassistenz und einem riskanten Autopiloten.

Risiko selbst prüfen

Vor der Integration in ein Werkzeug wie n8n, OpenWebUI, Retool, Budibase, Make, Zapier, Node-RED oder ein Netzplanungs-Frontend sollten drei Fragen beantwortet werden:

1. Wird Cernion nur als Wissens- und Evidenzschicht genutzt oder schon als Prozessgedächtnis?
2. Wo liegt der Token: serverseitig sicher oder versehentlich im Client, Prompt, Screenshot oder Workflow-Export?
3. Welche Aktion bleibt ausdrücklich beim Menschen?

Wenn diese Fragen geklärt sind, kann Cernion schrittweise in bestehende Werkzeuge eingebunden werden, ohne die fachliche und organisatorische Kontrolle aus der Hand zu geben.