From YOLO to Production, Folge 3: Never Gonna Let You Out – Vom Prototyp zum produktiven KI-Agenten
Viele Unternehmen experimentieren mit KI-Agenten – im Produktivbetrieb kommen bisher die wenigsten an. In der aktuellen Ausgabe von Community Insights Live am Mittwoch, 7. Oktober 2026, zeigten Nele Uhlemann und Jonas Wagner von Cloudflare, was zwischen Prototyp und verlässlichem Agenten liegt: schlankes Kontextmanagement, Sandboxing, saubere Rechte und klare Verantwortung.
Moderiert von Florian Kurzmaier (Business Unit Manager & Head of Concepts, LSZ Future Connections), schloss die Folge die Webinar-Reihe „From YOLO to Production“ ab. „YOLO“ steht dabei für die unbekümmerte Experimentierphase. Der rote Faden: Ausprobieren ist ausdrücklich erwünscht, der Weg in den Produktivbetrieb braucht aber Leitplanken.
Wo Unternehmen bei KI-Agenten stehen
Erste Gehversuche gibt es fast überall, zusammenarbeitende Agenten im Produktivbetrieb dagegen nicht. Das zeigte eine Kurzumfrage unter den Teilnehmer:innen: Einzelne Agenten laufen bereits produktiv, mehrere Agenten im Zusammenspiel meldete niemand.
Für Jonas Wagner (Senior Solutions Engineer, Cloudflare) liegt das an zwei Hürden. Erst müssen Use Cases gefunden werden, die echten Nutzen bringen, dann kommen Governance und Sicherheit. Hinzu kommt: Sprachmodelle antworten nicht immer gleich – dreimal dieselbe Anfrage kann drei verschiedene Antworten liefern.
Nele Uhlemann (Customer Engineer Digital Native, Cloudflare) ergänzte einen dritten Punkt: Observability. Agenten brauchen Tracing, damit nachvollziehbar bleibt, was passiert ist.
Ein Agenten-Workspace als Anschauungsbeispiel
Als Demonstrationsobjekt diente Cloudflare OS, eine Open-Source-Anwendung, die Cloudflare laut Uhlemann auch intern produktiv einsetzt – mit Agenten für alle Mitarbeitenden, angebunden an die eigenen Systeme. In einer Live-Demo ließen die beiden einen Agenten eine kleine App mit Musik-Player bauen und zeigten eine aus dem Kalender generierte Journaling-App.
Spannender als die Apps war die Arbeitsweise dahinter. Kontext, Präsentationen und Skills lassen sich im Team teilen, statt dass jede:r für sich etwas aufbaut. Andere Systeme werden über sogenannte Gatekeeper angebunden – fertige Ein-Klick-Verbindungen oder eigene MCP-Server, jeweils mit festgelegten Rechten, wer worauf zugreifen darf. Und Aufgaben laufen in der Cloud weiter, auch wenn der eigene Rechner längst zugeklappt ist.
Für Wagner liegt der Reiz im Teilen: Was gestern jemand Gutes gebaut hat, steht morgen dem ganzen Team zur Verfügung.
Code Mode: Viele Tools, schlankes Kontextfenster
Das Problem: Jedes Tool kostet Kontext
Wer viele MCP-Server anbindet, um Agenten mit internen und externen Systemen zu verbinden, bläht das Kontextfenster auf. In der Live-Demo belegten 112 verbundene Tools im klassischen Modus bereits rund 20 Prozent des Kontextfensters.
Die Lösung: suchen statt vorladen
Im Code Mode bekommt der Agent zunächst nur ein einziges Werkzeug zur Suche. Damit findet er die passenden Tools selbst und schreibt Code dagegen. In der Demo blieb der Kontextbedarf so konstant bei 0,2 Prozent – egal, wie viele Tools verbunden waren.
Der Preis sind etwas mehr Rundläufe und Tool-Aufrufe. Unterm Strich verbrauchte der Agent laut Uhlemann trotzdem deutlich weniger Tokens und ist damit klar ökonomischer. Für Mitarbeitende entfällt außerdem die Frage, welche Server sie für welche Aufgabe vorab auswählen müssen.
Sandboxing: Fehler dürfen passieren, aber folgenlos
Isolierte Umgebungen statt des eigenen Rechners
Ein Agent im Experimentiermodus darf Fehler machen – nur nicht auf dem eigenen System. Wagner zeigte, wie generierter Code in isolierten Sandboxes läuft, bei Cloudflare Dynamic Workers genannt. Sie funktionieren laut Wagner ähnlich wie ein neuer Browser-Tab: aufmachen und sofort da, ohne große Wartezeiten. Für längere Aufgaben, die Stunden oder Tage laufen, stehen Container bereit.
Entscheidend ist die Kontrolle nach außen. Ob ein Agent ins Internet darf, lässt sich gezielt steuern: für den Download eines benötigten Pakets ja, für beliebige Ausflüge nein.
Sicherheit ohne Klick-Müdigkeit
Zu viele Freigabedialoge sind selbst ein Risiko. Wer für alles ständig bestätigen muss, klickt irgendwann nur noch „OK“, ohne zu lesen. Läuft der Agent in einer Sandbox, ist ein Fehlgriff dagegen nicht mehr so schlimm.
Drei Muster auf dem Weg in den Produktivbetrieb
Wie sichert man Agenten ab, ohne ihre Produktivität abzuwürgen? Wagner und Uhlemann nannten drei Muster, die sie bei Kund:innen beobachten:
Projektbasiert arbeiten: Innerhalb eines Projekts darf der Agent lesen, schreiben und auch löschen. Zwischenstände bei jedem Meilenstein, etwa in Git oder als Snapshot, ermöglichen im Worst Case einen einfachen Rollback.
Leserechte vor Schreibrechten: Eine verschickte E-Mail lässt sich nicht zurückholen. Viele Unternehmen starten deshalb mit Lesezugriff und vergeben Schreibrechte erst später.
Guardrails und Audit-Trail: Leitplanken verhindern Fehlgriffe, ein Protokoll im Hintergrund zeigt im Nachgang, warum etwas passiert ist – nicht, um mit dem Finger zu zeigen, sondern um zu verstehen.
Florian Kurzmaier steuerte ein Beispiel aus der LSZ-eigenen Praxis bei: Auch hier verschickt KI nichts eigenständig. Schon ein ungenauer Prompt kann genügen, damit ein Agent eine E-Mail an Kund:innen für in Ordnung hält.
Regeln für alle – auf mehreren Ebenen
Lassen sich Regeln festlegen, die für alle Anwender:innen gelten? Ja, sagte Uhlemann – und zwar an mehreren Stellschrauben: über Rechte und Skills im Workspace, über ein MCP-Portal, das bestimmt, welche Tools welcher Server überhaupt bereitstehen, und über Data Loss Prevention im AI Gateway, die festlegt, welche Daten gar nicht erst nach außen gehen. Data Loss Prevention war bereits Thema einer früheren Folge der Reihe.
Wer trägt die Verantwortung?
KI-Agenten sind zunächst ein Engineering-Projekt – und so sollte auch die Verantwortung geregelt sein. Das beobachtet Uhlemann bei Kund:innen: Meist tragen Engineering Manager:innen oder Product Leads den Hut, sobald sie Agenten für größere Teile des Unternehmens bereitstellen. Dass nicht-deterministische Systeme auch mal danebenliegen, gehört dazu; der Audit-Trail macht es nachvollziehbar, und die Guardrails werden nachgeschärft.
Kundennahe Agenten brauchen schärfere Grenzen
Interagiert ein Agent mit Kund:innen, wird Isolierung noch wichtiger. Uhlemann empfiehlt eine eigene Sandbox pro Kund:in, damit kein Agent auf fremde Kundendaten zugreifen kann, und besonders scharf eingestellte Guardrails. Intern gilt: Jeder Agent arbeitet mit den Berechtigungen der Person, die ihn einsetzt – nicht mit mehr.
Lassen sich Daten und Inferenz in der EU halten?
Ja – aber Baustein für Baustein. So beantwortete Uhlemann eine Frage aus dem Publikum. Eigene Modelle lassen sich auf eigenen Servern in der EU betreiben, und über die Data Localization Suite lässt sich etwa festlegen, dass verschlüsselte Verbindungen nur in der EU aufgelöst werden.
Die Grenze liegt bei externen Diensten. Wer einen Agenten an die Schnittstelle eines Drittanbieters anbindet, kann deren Standort nicht automatisch gewährleisten. Wagner riet, jede Komponente einzeln anzusehen – bei Anbietern mit Enterprise-Vertrag lässt sich das leichter absichern.
Was jetzt zählt
Experimentieren ist kein Fehler, sondern der Anfang. Wagner sieht die YOLO-Phase als notwendigen Schritt, idealerweise mit Testdaten und getrennten Accounts. Wer danach auf Identitäten, Guardrails, Data Loss Prevention und Audit-Trails setzt, kann Agenten intern wie extern produktiv bereitstellen.
Uhlemann erwartet deutlich mehr KI-Agenten in Unternehmen – und dass die Frage nach dem Datenstandort in Kundengesprächen weiter an Gewicht gewinnt. Wie individuell die Hürden sind, zeigte auch die Abschlussumfrage: Einen klaren Sieger unter den Herausforderungen gab es nicht.
Der Schritt vom Ausprobieren in die Produktion steht auch in den KI-Workshops der LSZ-Präsenzformate regelmäßig ganz oben auf der Agenda, berichtete Florian Kurzmaier. Use Cases finden viele inzwischen. Verlässlich wird ein Agent erst, wenn klar ist, wo er arbeiten darf und was er getan hat.
