KI-Workflows mit n8n: Von der Idee zur produktiven Automation

Chat-Oberflächen wie Open WebUI lösen das Problem „Mensch fragt, KI antwortet". In der Praxis fehlt danach fast immer die zweite Hälfte: Was passiert mit der Antwort? Ticket-System aktualisieren, Slack benachrichtigen, CRM-Eintrag anlegen, Eskalation bei Dringlichkeit. Dafür nutze ich n8n – self-hosted, visuell, mit Hunderten Integrationen.

Ich kam zu n8n aus der Systemadministration. Als Sysadmin habe ich Jahre lang Cron-Jobs und Skripte verbunden. n8n ist für mich die moderne Variante: Trigger, Schritte, Fehlerpfade – sichtbar im Editor, auditierbar, ohne für jeden Prozess eine eigene Microservice-App zu bauen. Für KI-Projekte bedeutet das: LLM-Aufrufe sind ein Schritt im Workflow, nicht das gesamte Produkt.

In diesem Tutorial zeige ich zwei Workflows, die ich in fast jedem KI-Projekt irgendwann brauche: Zusammenfassung per Webhook und eine einfache RAG-Pipeline. LLM-Anfragen laufen über LiteLLM; für manuelle Tests und Exploration nutze ich parallel Open WebUI.

n8n ersetzt für mich keine eigene Backend-Entwicklung, wenn komplexe Geschäftslogik, strenge SLAs oder feingranulare Berechtigungen nötig sind. Aber für 80 % der „KI soll danach noch X tun"-Anforderungen ist es der schnellste Weg – und Ops-Teams verstehen visuelle Workflows besser als Python-Repos.

Für wen lohnt sich das?

n8n lohnt sich, wenn KI in bestehende Prozesse eingebettet werden soll – nicht isoliert im Chat-Fenster. Typische Fälle:

• Ticket-Systeme: eingehende Anfragen klassifizieren, zusammenfassen, priorisieren
• Dokumenten-Workflows: Upload triggert Embedding und Indexierung
• Benachrichtigungen: LLM bewertet Dringlichkeit → Slack/Teams/E-Mail
• Scheduled Jobs: tägliche Reports, Wissensstand-Updates, Datenqualitätsprüfungen

Weniger sinnvoll ist n8n als Ersatz für eine Hochlast-API mit strengen Latenz-SLAs unter 200 ms. Für interaktive Chats mit Menschen bleibt Open WebUI die bessere Wahl. n8n ist der Klebstoff zwischen KI und Unternehmenssystemen.

Architektur auf einen Blick

Trigger (Webhook, Cron, Jira, E-Mail)
              │
              ▼
            n8n Workflow
    (Transform, IF, Error Handler)
              │
    ┌─────────┼─────────┬──────────┐
    ▼         ▼         ▼          ▼
 LiteLLM   Vektor-DB   Jira     Slack
 (LLM)     (RAG)      (Ticket)  (Alert)

n8n orchestriert; es inferiert keine Modelle selbst. Alle LLM-Calls gehen an LiteLLM oder einen anderen OpenAI-kompatiblen Endpoint.

Schritt 1: n8n self-hosted starten

services:
  n8n:
    image: n8nio/n8n:latest
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=n8n.intern.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.intern.example.com/
      - GENERIC_TIMEZONE=Europe/Berlin
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    volumes:
      - n8n_data:/home/node/.n8n
    restart: unless-stopped

volumes:
  n8n_data:

WEBHOOK_URL muss die öffentliche oder interne URL sein, unter der Webhooks erreichbar sind – sonst generiert n8n falsche Callback-URLs. N8N_ENCRYPTION_KEY sichert Credentials in der Datenbank. Produktion: HTTPS, Auth aktivieren, Volume n8n_data backuppen.

Ich setze n8n im selben Docker-Netzwerk wie LiteLLM (ai-internal), damit HTTP-Requests an http://litellm:4000/v1 ohne TLS-Terminierung intern laufen. Nach außen ist nur n8n über Reverse Proxy erreichbar – nicht LiteLLM direkt.

Schritt 2: Workflow – LLM-Zusammenfassung per Webhook

Ziel: POST mit Text → strukturierte Zusammenfassung als JSON.

1. Webhook-Node: POST, Path /summarize, Authentication optional (Header Secret)
2. Set-Node: text aus $json.body.text extrahieren
3. HTTP Request → LiteLLM:

{
  "model": "companygpt-fast",
  "messages": [
    {
      "role": "system",
      "content": "Fasse den Text in genau 3 Bulletpoints auf Deutsch zusammen. Antworte als JSON mit dem Feld bullets (Array)."
    },
    {
      "role": "user",
      "content": "={{ $json.text }}"
    }
  ],
  "response_format": { "type": "json_object" }
}

4. Code-Node: JSON aus choices[0].message.content parsen
5. Respond to Webhook: Ergebnis zurückgeben

API-Key als n8n-Credential speichern (Header Authorization: Bearer …), nie im Workflow hardcoden. Timeout auf 60–120 Sekunden setzen – LLMs sind langsam, das ist normal.

Schritt 3: Workflow – einfache RAG-Pipeline

Ziel: Frage + Kontext-ID → Antwort mit Quellen.

Webhook → Embedding (HTTP) → Vektor-DB Query → Kontext bauen
       → LLM Chat → Antwort + Chunk-IDs zurückgeben

Embedding-Schritt (HTTP Request an LiteLLM/OpenAI):

{
  "model": "text-embedding-3-small",
  "input": "={{ $json.question }}"
}

Vektor-Suche: Je nach Stack Qdrant, Weaviate oder pgvector per HTTP-Node. Top-5-Chunks als context zusammenführen (Code-Node oder Set mit Expression).

LLM-Schritt mit klarem System-Prompt:

Antworte nur basierend auf dem folgenden Kontext.
Wenn die Antwort nicht im Kontext steht, sage: „Dazu liegen mir keine Informationen vor."
Zitiere die Chunk-IDs am Ende der Antwort.

Das ist eine vereinfachte Pipeline – für Produktion gelten die Kriterien aus meiner RAG-Checkliste: Hybrid Search, ACL, Evaluation.

Schritt 3b: Workflow 3 – Ticket-Klassifikation mit Jira

Ein Pattern, das ich oft baue: Jira-Trigger bei neuem Ticket → Ticket-Beschreibung an LiteLLM → Kategorie und Dringlichkeit als JSON → IF-Node → bei Dringlichkeit Slack, sonst nur Label setzen.

Der System-Prompt ist knapp und strukturiert:

Klassifiziere das Ticket. Antworte als JSON:
{ "category": "störung|anfrage|abrechnung", "urgency": 1-10, "summary": "..." }

Wichtig: JSON-Schema im Code-Node validieren, Fallback bei Parse-Fehler. LLMs liefern gelegentlich Markdown um das JSON herum – dann bricht der Workflow ohne Validierung.

Schritt 3c: Idempotenz und Rate Limits

Wenn derselbe Webhook zweimal feuert (Retry des Aufrufers), darf nicht zweimal dasselbe Ticket angelegt werden. Ich speichere eine Hash-ID des Inputs in einer kleinen Tabelle oder prüfe im Zielsystem, ob der Vorgang schon existiert. Parallel begrenze ich gleichzeitige LLM-Calls – n8n kann bei Burst sonst das LiteLLM-Budget in Minuten leeren.

Schritt 4: Fehlerbehandlung einbauen

Produktive Workflows brauchen sichtbare Fehlerpfade:

• Error Workflow global aktivieren (Settings → Workflow Settings)
• Retry auf HTTP-Nodes: 3 Versuche, exponential backoff
• IF-Node: leere Embedding-Antwort oder HTTP-Status ≠ 200 abfangen
• Slack/E-Mail-Node im Error Workflow für Benachrichtigung

Ein Workflow, der bei LLM-Timeout still stirbt, ist schlimmer als einer, der eine Fehlermeldung zurückgibt. Nutzer und Ops-Team müssen wissen, was passiert ist.

Schritt 5: Scheduling, Sub-Workflows und Monitoring

• Cron-Trigger: z. B. täglich 7 Uhr neue Jira-Tickets zusammenfassen
• Execute Workflow: gemeinsame LLM-Logik als Sub-Workflow, von mehreren Flows aufrufbar
• Logs in n8n + extern (Grafana Loki, ELK) für Produktion
• Execution-Daten retention begrenzen – LLM-Workflows speichern oft große Payloads

Für LLM-lastige Flows exportiere ich Metriken: Anzahl Executions, Fehlerrate, durchschnittliche Latenz pro Workflow. Wenn der Zusammenfassungs-Webhook plötzlich von 8 auf 45 Sekunden springt, ist das meist LiteLLM, das Modell oder das Netzwerk – nicht „n8n ist langsam". Ohne diese Trennung debuggt man am falschen Ende.

Schritt 6: Versionierung und Änderungen

n8n-Workflows leben in der Datenbank, nicht zwingend in Git. Ich exportiere produktive Flows regelmäßig als JSON ins Repo und dokumentiere Änderungen im Ticket-System. Ein System-Prompt, der im UI geändert wird ohne Review, ist ein stiller Produktions-Deploy. Für KI-Workflows gilt dieselbe Disziplin wie für Code.

Aus der Praxis

Ein IT-Dienstleister (anonymisiert) bekam täglich 150+ Support-Mails. Ziel: Kategorisierung (Störung, Anfrage, Abrechnung), Kurzzusammenfassung, Dringlichkeitsscore. n8n-Workflow: IMAP-Trigger → LLM-Klassifikation über LiteLLM → bei Score > 8 Slack an Bereitschaftsdienst + Jira-Ticket mit Zusammenfassung.

Erste Version ohne Error Handling: 12 % der Mails blieben hängen, weil das Modell bei leeren Betreffzeilen JSON invalide lieferte. Fix: Schema-Validierung im Code-Node, Fallback-Kategorie „Unklar", Alert an Ops. Nach vier Wochen: 94 % korrekte Kategorisierung, durchschnittlich 8 Sekunden pro Mail. Kein Ersatz für menschliche Bearbeitung – aber die dringenden Fälle landeten oben.

Was oft schiefgeht

API-Keys im Workflow. In Git sichtbar, nicht rotierbar. Credentials nutzen.

Kein Timeout. HTTP-Node wartet ewig, Webhook-Caller gibt auf.

PII in Execution Logs. n8n speichert Input/Output – bei personenbezogenen Daten Execution Data minimieren oder anonymisieren.

RAG ohne Quellenprüfung. LLM halluziniert trotz Kontext. Chunk-IDs und „keine Information" als Pflicht.

n8n öffentlich ohne Auth. Webhooks sind URLs. Jeder mit der URL kann deinen LLM-Budget verbrennen.

Checkliste vor Go-Live

1. n8n mit HTTPS und N8N_ENCRYPTION_KEY
2. LiteLLM-Credentials als n8n-Credential, Virtual Key mit Budget
3. Mindestens ein Workflow mit Error Workflow und Benachrichtigung
4. Webhook-Secrets oder IP-Restriktion
5. Timeouts und Retries auf allen HTTP-Nodes
6. Keine PII in dauerhaften Logs ohne Konzept
7. Monitoring: fehlgeschlagene Executions alarmieren
8. Dokumentation für Ops: Was tun bei LiteLLM-Ausfall?

Fazit

n8n ist der Klebstoff zwischen KI und bestehenden Systemen. Wo Open WebUI den Menschen bedient, automatisiert n8n wiederkehrende KI-Aufgaben – mit sichtbaren Fehlerpfaden und Audit-Trail. Zusammen mit LiteLLM für Modell-Governance und einer soliden RAG-Pipeline für Wissensfragen ergibt sich ein stimmiges Gesamtbild.

Workflow-Design für eure Integration? LinkedIn