n8n Assistant im Preview sicher testen

n8n hat den n8n Assistant vorgestellt. Er soll Workflows aus einer natürlichsprachlichen Beschreibung planen und auf der Arbeitsfläche erstellen. Das klingt nach einer großen Abkürzung. Genau deshalb lohnt ein nüchterner Blick auf den Status: n8n liefert die Funktion hinter einem Preview-Schalter aus und entwickelt sie aktiv weiter (n8n, 09.09.2026, zuletzt aktualisiert 24.09.2026).

Ich beschreibe hier, wie du das in einem kleinen Team ausprobierst, ohne dass am Ende ein halb fertiger Workflow Rechnungen verschickt oder Datensätze überschreibt.

Was kann der n8n Assistant laut Hersteller?

Wichtig vorweg: Die folgenden Punkte sind Herstellerangaben von n8n, keine unabhängig geprüften Sicherheits- oder Qualitätsnachweise. Belastbare Benchmark-Zahlen zur Trefferquote gibt es öffentlich nicht, und ich erfinde keine.

• Laut n8n kann der Assistant einen gewünschten Ablauf planen, den Workflow auf der Arbeitsfläche erstellen, benötigte Zugangsdaten anfordern, ihn ausführen und bei Fehlern an einer Korrektur arbeiten.
• Laut n8n fragt der Assistant vor dem Zugriff auf Credentials und vor der Aktivierung eines Workflows nach einer ausdrücklichen Bestätigung.
• Laut n8n ist die erste erzeugte Version nicht garantiert produktionsreif, die Prüfung bleibt Aufgabe des Nutzers.
• Laut n8n ersetzt der Assistant keine Kontoeinrichtung: Braucht ein Workflow einen externen Dienst, muss die Verbindung vorhanden sein.

Aus diesen vier Punkten folgt mein Testdesign. Der interessanteste Satz ist der dritte. Ein Anbieter, der selbst sagt, dass das Ergebnis geprüft werden muss, gibt dir die Prüfpflicht schriftlich mit.

Warum reicht die eingebaute Bestätigung nicht aus?

Eine Bestätigungsabfrage ist eine technische Bremse. Sie schützt nicht davor, dass jemand im Arbeitsfluss auf Bestätigen klickt, weil der Assistant gerade plausibel klingt. In meinen n8n-Projekten sind die teuren Fehler selten technische Fehler. Es sind Klickfehler unter Zeitdruck.

Dazu kommt der Preview-Status. n8n hat im September 2026 Korrekturen veröffentlicht, die leere Workflow-Vorschauen im AI Assistant betreffen, unter anderem in den Releases 2.39.8 und 2.40.3 vom 18.09.2026. Auch 2.39.7 vom 17.09.2026 zeigt, wie eng die Release-Taktung ist. Die Funktion verändert sich also messbar weiter.

Wie baust du eine Testumgebung, die nichts kaputt machen kann?

Das Grundprinzip: Der Assistant darf nur in einer Umgebung arbeiten, in der der schlimmste denkbare Fehler folgenlos bleibt. Konkret heißt das:

1. Nutze eine separate n8n-Instanz oder ein klar isoliertes Testprojekt. Keine Verbindung zur produktiven Workflow-Umgebung.
2. Gib nur einem kleinen, namentlich festgelegten Nutzerkreis Zugriff auf den Preview-Schalter.
3. Hinterlege ausschließlich Test-Credentials, etwa für ein Sandbox-Konto oder einen Mock-Endpunkt. Produktions-Credentials haben in der Testinstanz nichts zu suchen.
4. Lass Webhooks, Zeitpläne und Event-Trigger zunächst deaktiviert. Du führst manuell aus, nicht automatisch.
5. Kennzeichne jeden erzeugten Workflow mit einem sichtbaren Präfix wie TEST-AI-.
6. Prüfe vor jedem Lauf, ob ein Node Nachrichten versendet, Datensätze verändert, Dateien überschreibt oder externe Aktionen auslöst.

Punkt 6 ist der wichtigste. Ein Workflow, der nur liest und ausgibt, ist harmlos. Sobald ein Node schreibt oder sendet, brauchst du eine bewusste Entscheidung, keine Gewohnheit.

Welche Daten darfst du im Pilot verwenden?

Hier bin ich bewusst konservativ. Ich gebe keine Rechtsberatung, sondern eine redaktionelle Empfehlung für den Pilotbetrieb.

• Nur synthetische Beispieldaten oder ausreichend anonymisierte Testdaten einsetzen.
• Keine Kundennamen, Zugangsdaten, personenbezogenen Originaldaten oder vertraulichen Geschäftsinformationen in Prompts einfügen.
• Für jeden Testfall eine erlaubte Datenklasse festlegen, etwa öffentlich, intern mit Testdaten oder synthetisch.
• Eingaben und Ausgaben protokollieren, soweit das in deiner Umgebung zulässig und technisch möglich ist.
• Testdaten regelmäßig löschen und nicht in produktive Systeme zurückschreiben.
• Externe KI-Dienste und Datenflüsse vor dem Pilot dokumentieren und die einschlägigen Anbieter- und Organisationsvorgaben prüfen.

Wann darf ein generierter Workflow den Pilot verlassen?

Ich arbeite mit einer festen Checkliste. Sie kostet zehn Minuten pro Workflow und ersetzt lange Diskussionen darüber, wer jetzt eigentlich freigegeben hat.

Die Notwendigkeit der manuellen Prüfung folgt direkt aus dem Hinweis von n8n, dass der erste erzeugte Workflow nicht garantiert produktionsreif ist. Das ist kein Misstrauen gegenüber dem Werkzeug, sondern die vom Hersteller selbst beschriebene Arbeitsteilung.

Wie sieht ein realistischer Pilot in zwei Wochen aus?

1. Woche 1, Tag 1: Testinstanz aufsetzen, Preview aktivieren, Version notieren, Test-Credentials anlegen.
2. Woche 1, Tag 2 bis 4: Drei bis fünf klar umrissene Anwendungsfälle beschreiben und vom Assistant bauen lassen. Nur lesende Workflows zuerst.
3. Woche 1, Tag 5: Erste Auswertung. Was hat funktioniert, wo musstest du korrigieren, wo hat der Assistant Credentials angefordert?
4. Woche 2, Tag 1 bis 3: Schreibende Workflows gegen Sandbox-Endpunkte testen. Fehlerfälle bewusst provozieren.
5. Woche 2, Tag 4: Vier-Augen-Prüfung anhand der Checkliste.
6. Woche 2, Tag 5: Entscheidung. Entweder ein einzelner Workflow geht mit separater Freigabe in Produktion, oder du verlängerst den Pilot.

Mein ehrlicher Eindruck aus Automatisierungsprojekten: Der größte Nutzen solcher Assistenten liegt am Anfang, beim Gerüst. Die letzten zwanzig Prozent, also Fehlerbehandlung, Retries, Datenvalidierung und saubere Benennung, bleiben Handarbeit. Wenn dein Team das einplant, ist der Preview-Test entspannt. Wenn dein Team erwartet, dass ein Prompt einen fertigen Produktionsworkflow liefert, wird es unangenehm.

Wenn du unsicher bist, welche Prozesse sich überhaupt für einen solchen Pilot eignen und wo du besser die Finger von Automatisierung lässt, schau gern einmal gemeinsam mit mir drauf. Du kannst dafür ein KI-Audit buchen, dreißig Minuten, ohne Verpflichtung.