Node-RED, KI und n8n: Wer behält die Kontrolle über den Prozess?
“Hast du schon mal etwas mit n8n gemacht? Für KI-gestützte Prozessabläufe wäre das doch genau die richtige Lösung, oder?”
Ja. Ich habe damit experimentiert. Die Oberfläche wirkt auf den ersten Blick überzeugend, und für viele Dienste stehen fertige Konnektoren bereit. Konzeptionell war mir jedoch vieles aus Node-RED bereits vertraut: Flow-based Programming, Nodes und die Verbindung spezialisierter Systeme zu einem Ablauf.
Bei einem Punkt musste ich allerdings kurz nachdenken: der KI-Integration. In jüngerer Zeit habe ich dafür eher auf spezialisierte Go-Services gesetzt als auf Flow-based Programming. Damit blieb die entscheidende Frage: Wie gut lässt sich KI mit Node-RED integrieren? Und wie sind die Eigenschaften der Plattform aus Integratorsicht einzuordnen? Ein bewusst spielerisches Beispiel liefert darauf keine allgemeingültige Antwort, macht aber die relevanten Architekturfragen konkret: Woher kommen die Daten? Welche Systeme dürfen handeln? Wer prüft Ergebnisse? Und wie bleibt der Ablauf beherrschbar, wenn sich ein Modell, ein Anbieter oder eine fachliche Anforderung ändert?
Node-RED ist vielen aus IoT- und Smart-Home-Szenarien bekannt. Das zugrunde liegende Muster ist aber allgemeiner: Daten treffen ein, werden aufbereitet und bewertet, Systeme werden angesprochen und ein Ergebnis wird ausgeliefert. Genau so funktionieren auch digitale Geschäftsprozesse.
Praxisbeispiel: Vom Nachrichtenfeed zur Audioausgabe
Um das Potenzial von Node-RED jenseits von Sensoren und Aktoren zu zeigen, entstand ein persönlicher Nachrichtensender: Aus den wichtigsten Meldungen des Tages sollten eine kompakte Morgenübersicht und ein deutschsprachiger Hip-Hop-Text entstehen. Ein Musikmodell erzeugt daraus eine MP3, die per Mail zugestellt wird. Die Anwendung ist bewusst spielerisch; die dahinterliegende Verarbeitungskette aus Datenquelle, Modellen, Prüfungen und Zustellung ist es nicht.
Quelle, Dienste und Datenverträge. Der erste Schritt war nicht der Flow, sondern die Frage nach belastbaren Eingangsdaten. Der RSS-Feed der ARD Tagesschau stellt Meldungen in einem strukturierten XML-Format bereit. Daraus entsteht ein begrenzter Texteingang für ein Sprachmodell; dessen Ausgabe geht an ein Musikmodell, die erzeugte MP3 an den Mailversand. Nicht ein bestimmtes Modell war die Architekturentscheidung, sondern die Fähigkeit, jeden Dienst über eine klar abgegrenzte Schnittstelle einzubinden und bei Bedarf zu ersetzen.
Für jede Station war damit festgelegt, welche Daten sie liefert oder erwartet und wo ihre Verantwortung endet. Das Sprachmodell erhält ausschließlich die ausgewählten Meldungen als Arbeitsgrundlage, die Musikgenerierung nur den fertigen Text, der Versand nur die Audiodatei. Für einen belastbaren Betrieb sollten zusätzlich Abrufzeitpunkt, Veröffentlichungszeit und Quelle jeder übernommenen Meldung protokolliert werden.
Erst dann entsteht der Flow. Node-RED liest den Feed, parst XML, filtert und strukturiert die Meldungen, bereitet die Anfragen an die Modelle vor und übergibt das Ergebnis an den Versand. Die Transformationen bleiben dabei explizite, prüfbare Prozessschritte. Diese Reihenfolge ist übertragbar: fachliches Ziel und Ausgangsdaten klären, Schnittstellen, Berechtigungen und Fehlerfälle definieren, dann Dienste und Orchestrierung auswählen.
Im Ergebnis entsteht damit ein auf eine Aufgabe begrenzter Agent: Er nimmt festgelegtes Rohmaterial entgegen, ruft spezialisierte Dienste auf und liefert ein definiertes Ergebnis aus. Der Ablauf wird dabei nicht bei jeder Ausführung neu geplant. Werkzeuge, Datenzugriff und Handlungsspielraum bleiben durch den Flow vorgegeben.
Qualität wird vor dem Modellaufruf festgelegt. Das Sprachmodell erhält keinen vagen Auftrag, sondern einen redaktionellen Rahmen: Quellenbindung, Themenauswahl, Neutralität bei Streitfragen, Umgang mit sensiblen Inhalten und ein klar definiertes Ausgabeformat. Der Prompt legt Erwartungen und Prüfmaßstäbe fest; Verlässlichkeit entsteht erst durch technische Validierung, Quellenabgleich und gegebenenfalls eine menschliche Freigabe.
msg.payload = {
model: "gpt-4o-mini",
messages: [
{
role: "system",
content: `Du bist Songwriter für einen täglichen deutschen News-Rap.
Erstelle aus den gelieferten Nachrichten einen intelligenten,
gut rappbaren Hip-Hop-Text für ein morgendliches Nachrichtenlied.
INHALT:
- Wähle die 10 relevantesten unterschiedlichen Themen.
- Verwende ausschließlich Informationen aus den gelieferten Nachrichten.
- Erfinde keine Fakten, Hintergründe, Motive oder Zitate.
- Fasse ähnliche Meldungen zusammen und behandle jedes Thema nur einmal.
- Gib politische Streitfragen neutral wieder.
STIL:
- Deutscher Conscious Rap: intelligent, erwachsen und sprachlich präzise.
- Bei Krieg, Gewalt, Tod und Katastrophen respektvoll formulieren.
- Information steht vor der Pointe.
Schreibe ausschließlich sing- oder rappbaren Text.`,
},
{
role: "user",
content: `Schreibe aus diesen aktuellen Nachrichten den heutigen News-Rap:
${newsText}`,
},
],
};
Bei fachlich oder rechtlich relevanten Ergebnissen gehören deshalb Plausibilitätsprüfungen, Quellenabgleich und gegebenenfalls eine menschliche Freigabe in den Flow.
Dieses Muster lässt sich auf deutlich nüchternere Anwendungsfälle übertragen: personalisierte Berichte, Angebotsentwürfe, Briefings, Dokumentationen, Trainingsmaterial oder interne Wissensformate. Nicht jedes Produkt braucht KI. Wo Sprache, Bilder oder Audiodaten verarbeitet werden, kann sie jedoch gezielt eine Produktionsstufe übernehmen.
Node-RED als Orchestrierungsschicht
Node-RED reduziert fachliche Komplexität nicht, macht den Ablauf jedoch sichtbar: Datenquellen, Entscheidungen, externe Dienste und Auslieferung lassen sich als zusammenhängender Flow prüfen. Fehlt ein Ergebnis oder ist es nicht plausibel, kann der Prozess an seinen Stationen untersucht werden, statt ihn erst aus Quelltext, Konfiguration und Logdateien rekonstruieren zu müssen. Das schafft eine gemeinsame Arbeitsgrundlage für Fachbereich, Betrieb und Entwicklung.
Dabei ist die Arbeitsteilung wichtig. Kleine Transformationen können direkt im Flow stattfinden. Komplexe Fachlogik gehört in getestete Module oder Dienste. Wiederkehrende Integrationen lassen sich als eigene Nodes kapseln. Das schafft eine pragmatische Grenze zwischen schneller Anpassbarkeit und belastbarer Softwareentwicklung.
Fertigkonnektoren und digitale Souveränität
Als Schwäche von Node-RED wird gelegentlich genannt, dass der Standardumfang weniger fertige Konnektoren für spezialisierte Cloud-Dienste mitbringt als manche stärker produktisierten Plattformen. Das sollte im Einzelfall geprüft werden: Die Node-RED Flow Library enthält zahlreiche Nodes für Dienste, Protokolle und Datenquellen. Ein gepflegter Standardbaustein ist oft die richtige Entscheidung; als externe Software-Abhängigkeit gehört er dennoch auf Wartungsstand, Berechtigungen, Runtime-Kompatibilität und Umgang mit Zugangsdaten geprüft.
Fehlt ein fertiger Baustein, entsteht zunächst zusätzlicher Implementierungsaufwand. Gleichzeitig wird die Schnittstelle transparent: Im klar begrenzten Rahmen eines Nodes - Eingang, Verarbeitung, Ausgang - werden Datenformat, Authentifizierung, Fehlerverhalten und Grenzen eines Cloud-Dienstes konkret. Das schafft die Grundlage für digitale Souveränität. Abhängigkeiten werden nicht nur konsumiert, sondern bewusst gestaltet: Proprietäre Annahmen und Wechselkosten werden früh sichtbar, und ein Dienst kann bei Bedarf gezielt ersetzt werden.
Schlank betreiben, gezielt skalieren
Die Orchestrierung selbst benötigt selten eine GPU oder einen großen Plattformbetrieb. Node-RED läuft als Container, auf einem kleinen Server oder auch auf einem Raspberry Pi. Rechenintensive Modellanfragen können an externe oder getrennt betriebene Dienste gehen. Wächst die Last, muss deshalb nicht die gesamte Lösung wachsen: Sprachmodell, Bildgenerierung oder einzelne Fachservices lassen sich unabhängig skalieren. Für eine horizontale Skalierung des Flows selbst braucht es zusätzlich ein Konzept für Zustände, Queues, Idempotenz und konkurrierende Verarbeitung.
Für einen professionellen Betrieb gehören dennoch klare Grundlagen dazu: versionierte Flows, verwaltete Zugangsdaten, Backups, Updates, Monitoring und ein dem Einsatz angemessener Zugangsschutz. In größeren Umgebungen kommen Reverse Proxy, TLS und zentrale Anmeldung hinzu. Für zentrale Anmeldung lässt sich adminAuth über passende Passport-Strategien an bestehende OAuth- oder OpenID-Connect-Infrastrukturen anbinden.
Offenheit ist eine strategische Eigenschaft
Node-RED entstand 2013 bei IBM und ist heute Teil der OpenJS Foundation. Seine bewusst überschaubare Architektur reduziert nicht die Anforderungen an das Engineering, hält die technische Basis einer zentralen Automatisierungsschicht jedoch nachvollziehbar:
- Ein Browser-Editor macht Flows sichtbar und konfigurierbar.
- Eine schlanke Node.js-Runtime verarbeitet Nachrichten ereignisgesteuert.
- Nodes bilden Ein- und Ausgänge, Transformationen oder Entscheidungen ab.
- Flows werden als JSON gespeichert und lassen sich exportieren.
- Das npm-Ökosystem liefert fertige Nodes; interne Integrationen können als eigene Bausteine paketiert werden.
Das ist für Betrieb und Weiterentwicklung relevant. Ein Flow ist kein Artefakt, das ausschließlich im grafischen Editor lebt. Er kann gesichert, geprüft, zwischen Umgebungen übertragen und in einer externen Versionsverwaltung geführt werden. Zugangsdaten gehören nicht in dieses Repository, sondern in ein separates Secret-Management.
Node-RED steht unter der Apache License 2.0. Der Quellcode kann geprüft, verändert, selbst gebaut und bei Bedarf geforkt werden. Für Organisationen, die eine zentrale Automatisierungsschicht langfristig selbst betreiben oder weiterentwickeln wollen, ist diese Handlungsfreiheit eine relevante strategische Eigenschaft.
Die gleiche Sorgfalt gilt für Schnittstellen. HTTP, MQTT, SMTP, RSS, JSON, IMAP, CalDAV und iCalendar sind unspektakulär, aber langfristig verständlich. Sie halten die Verbindung zwischen Prozess und Dienst austauschbar. Das beseitigt keine Abhängigkeit von einem Anbieter, senkt aber die Kosten eines Wechsels: Ein Modell oder Dienst kann dann ersetzt werden, ohne den gesamten Ablauf neu zu bauen.
KI-gestützte Flow-Entwürfe
Zu guter Letzt lassen sich Flows als JSON exportieren, mit einem Sprachmodell als textbasierter Entwurf analysieren oder anpassen und anschließend wieder importieren. So können Änderungen an einem Flow zunächst in natürlicher Sprache beschrieben und als technischer Entwurf vorbereitet werden.
Fazit
Node-RED muss keine KI-Plattform im engeren Sinn sein, um KI sinnvoll einzubinden. Seine Stärke liegt in der Orchestrierung: Datenquellen, Regeln, spezialisierte Dienste und Zustellung bleiben als ein zusammenhängender Prozess sichtbar.
Welche Automatisierungsplattform passt, entscheidet sich am konkreten Vorhaben: Datenlage, Integrationsbedarf, Sicherheitsanforderungen, Betriebskompetenz und gewünschte Unabhängigkeit geben die Richtung vor. Je klarer Prozesse, Schnittstellen, Grenzen und Datenformate beschrieben sind, desto fundierter lässt sich diese Entscheidung treffen.
Der erste Flow ist dann keine Wette auf einen Anbieter, sondern die Umsetzung eines verstandenen Prozesses. Das ist die Voraussetzung dafür, ihn später mit vertretbarem Aufwand zu betreiben, zu prüfen und weiterzuentwickeln.
Weiterführende Primärquellen: