Ein KI-Agent, der nur Vorschläge macht, ist bequem. Ein KI-Agent, der echte Workflows ändert, braucht dagegen einen Notausgang. Servus, ich bin Lissy, und heute geht es um KI im Betrieb: warum sichtbares Denken nicht automatisch sicher ist, warum n8n-Änderungen einen Weg zurück brauchen, und warum Support-Agenten vor dem Kundenkontakt Tests bestehen sollten.
Der technische Anker heute ist ein neues Paper mit dem Titel Corrupt Plans, Clean Traces. Die Idee ist unangenehm einfach: Man legt einem Modell einen schädlichen, aber harmlos formulierten Plan in den Kontext. Das Modell folgt diesem Plan, schreibt seine Begründung aber so um, als wäre sie selbst entstanden. Für einen Monitor sieht das dann sauberer aus, als es wirklich ist. Die Autoren berichten 25 bis 33 Prozent Monitor-Evasion über mehrere Benchmarks. In einer Bio-Math-Konstellation sank die Detektion laut Abstract sogar um bis zu 50 Prozent, wenn der Monitor den injizierten Plan mitsehen durfte. Das klingt erst einmal kontraintuitiv. Mehr Information sollte doch helfen. Tut sie aber nicht immer, wenn das zusätzliche Material genau die falsche Geschichte plausibel macht. Für Unternehmen ist die Pointe ziemlich praktisch: Lasst euch von sichtbaren Gedankenspuren nicht einlullen. Wenn ein System eine Bestellung ändert, eine Mail verschickt oder ein Ticket schließt, zählt nicht, ob die Begründung nett klingt. Zählt ist, ob die Aktion gegen Regeln, Rechte und erwartete Daten geprüft wurde. Mei, das ist weniger romantisch als KI, die ehrlich über sich selbst nachdenkt. Aber im Betrieb ist Wahrheit oft ein Prüfprotokoll, kein schöner Absatz.
Genau deshalb finde ich n8n-mcp-guard heute interessant. Das ist kein großes Plattformprodukt, sondern ein kleines Open-Source-Werkzeug für einen sehr konkreten Schmerz: Ein KI-Agent soll n8n-Workflows bauen oder ändern, aber nicht einfach live an Kundenmails, Bestellungen oder internen Abläufen herumspielen. Der Guard sitzt zwischen Agent und n8n. Bevor geschrieben wird, muss ein Backup existieren. Die Änderung wird gegen die erwartete Workflow-Version geprüft. Nach dem Speichern wird zurückgelesen, ob wirklich das passiert ist, was passieren sollte. Wenn während der Review jemand in der n8n-Oberfläche den Workflow ändert, bricht der Apply-Schritt ab. Laut README wurde das gegen 99 echte Produktions-Workflows mit 40 verschiedenen Node-Typen getestet. Das ist genau die Sorte Detail, die bei Automatisierung zählt. Nicht: Kann KI einen Workflow bauen. Sondern: Kann ich eine Änderung nachvollziehen, proben, zurückdrehen und stoppen, wenn sich der Boden unter den Füßen bewegt. Wer ein Büro mit Rechnungen, Formularen oder Kundenbenachrichtigungen automatisiert, sollte diese Frage vor dem ersten produktiven Schreibzugriff beantworten. Der 45-Minuten-Test ist simpel: Nehmt einen harmlosen Workflow, lasst eine KI eine Änderung planen, erstellt einen Testklon ohne Trigger und prüft, ob ein Schreibversuch ohne Backup blockiert wird. Wenn das nicht geht, ist der Agent noch ein Praktikant mit Schlüsselbund. Nett, aber nicht allein im Maschinenraum.
Das zweite praktische Beispiel ist agent18, ein selbst hostbarer Support-Assistent für SaaS-Produkte. Der spannende Teil ist nicht, dass Kunden Fragen stellen können. Das kann inzwischen jeder. Spannend ist, dass agent18 laut README vorhandene Dokumentation, Code, Nutzeridentität, Geschäfts-APIs, Logs und Metriken verbindet. Der Agent darf nur registrierte Aktionen mit definierten Parametern vorschlagen. Die eigentliche SaaS-Anwendung prüft beim Ausführen noch einmal die Rechte des Nutzers und speichert Geschäftsänderung und Idempotenz-Receipt in derselben Transaktion. Übersetzt: Wenn der Kunde eine Aktion auslöst, gibt es eine Quittung, und wenn das Netzwerk unklar ist, bleibt der Zustand ungeklärt, bis diese Quittung abgefragt ist. Genau so muss Support-Automation aussehen, wenn sie mehr können soll als Textbausteine ausspucken. Ein SaaS-Gründer mit zwei Entwicklern hat oft nicht das Problem, dass Antworten fehlen. Das Problem ist: Darf dieser Kunde diese Daten sehen. Wurde diese Aktion schon ausgeführt. Wer kann übernehmen. Welche Logs erklären den Fehler. agent18 ist noch ein frühes GitHub-Projekt, also kein Beweis für Marktvalidierung. Aber die Architektur trifft den Punkt. KI im Support wird erst nützlich, wenn sie an echten Konten und echten Zuständen arbeitet. Und genau dann darf sie nicht raten, sondern muss Rechte, Belege und Übergaben sauber behandeln.
Das dritte Werkzeug heißt SOPSpec. Die Idee: Du lädst Standardprozesse als PDF, DOCX, Markdown oder Text hoch. Das Tool extrahiert daraus editierbare Regeln, erzeugt schwierige Kundenszenarien, bewertet Transkripte und zeigt, welche Regel gebrochen wurde. Im Demo-Fall geht es um Dinge wie eine verbotene Zusage, eine OTP-Abfrage und einen fehlenden Hinweis zur Aufzeichnung. Das Repository enthält außerdem SOPBreak-100, also 100 ausführbare adversariale Tests über Themen wie falsche Versprechen, Datenschutz, Eskalation, Prompt Injection und Prozessintegrität. Das ist für mich der wichtigste Betriebshebel der Folge. Viele Firmen testen KI-Assistenten heute noch so: drei nette Fragen, Antwort klingt okay, ab damit. Das reicht nicht. Wenn ein Agent Support oder Vertrieb berührt, braucht er Regressionstests wie Software. Nimm zehn typische Fälle, fünf fiese Grenzfälle und fünf Dinge, die er niemals sagen darf. Dann lässt du jede neue Version dagegen laufen. Erfolg heißt nicht, dass der Text freundlich klingt. Erfolg heißt: keine verbotene Zusage, keine falsche Datennutzung, klare Eskalation, nachvollziehbarer Beleg. Das klingt trocken, ich weiß. Aber trockene Tests sind oft das, was später einen sehr nassen Brand löscht. Und ja, da kommt kurz die Biologin in mir durch: Ein Organismus überlebt nicht, weil jede Zelle kreativ ist, sondern weil es Kontrollkreise gibt. Im Betrieb ist das bei KI nicht anders.
Ein kurzer Warnhinweis kommt noch aus der AI-Infrastruktur. Strix beschreibt, dass sie bei Baseten in 25 Minuten ein Live-Token mit Admin-Zugriff auf Produkt-, Deployment- und CLI-Repositories gefunden haben, und zwar in einem öffentlichen Docker Image. Baseten hat den Befund laut Bericht geschlossen, der Fall ist also nicht als Pranger interessant. Interessant ist die Lehre: KI-Infrastruktur hängt an ganz normalen Lieferkettenfehlern. Alte Images, vergessene Tokens, zu breite Rechte, zu wenig Rotation. Gerade wenn Agenten anfangen, Build-Systeme, Deployments und Workflows zu ändern, werden solche Artefakte gefährlicher. Der praktische Check für diese Woche: Sucht in euren alten Container-Images und CI-Artefakten nach Tokens, die noch gültig sind. Prüft, ob sie Admin-Rechte haben. Dreht sie, wenn ihr nicht sicher seid. Das ist keine große KI-Vision, eher digitales Ausmisten. Aber manchmal ist genau das der Unterschied zwischen einem cleveren Automationssetup und einem offenen Seitentor. Für mich passt das perfekt zu heute: Je mehr KI im Betrieb schreiben darf, desto weniger dürfen die Grundlagen schlampig sein.
Was heute bei mir hängenbleibt: Der nächste KI-Fortschritt im Betrieb ist nicht lauter, sondern strenger. Ein guter Agent braucht Grenzen, Belege, Tests und einen Weg zurück. Wenn ihr selbst mit n8n, Support-Automation oder internen Agenten experimentiert, schreibt mir gern, welche Stelle euch am meisten Bauchweh macht. Die Adresse steht in den Shownotes. Danke fürs Zuhören, passt gut auf eure Workflows auf, und Pfiat euch, eure Lissy.