Der erste KI-Agent sollte langweilig sein

Wir alle kennen diese Demo. Ein Agent nimmt eine vage Anweisung entgegen, plant ein Projekt, durchsucht das Web, schreibt den Code, aktualisiert drei Systeme und stellt eine Zusammenfassung in Slack ein. Das ist wirklich beeindruckend. Es weckt zugleich eine Erwartung, die den meisten KI-Roadmaps in Unternehmen unbemerkt schadet.

Denn die Demo überspringt jede Frage, die tatsächlich darüber entscheidet, ob ein Agent erfolgreich im produktiven Betrieb ist: Worauf darf er zugreifen? Was darf er verändern? Wer haftet, wenn er falsch liegt? Woher weiß man überhaupt, dass er falsch liegt? In einer Keynote lässt sich das vom Tisch wischen. In einem regulierten, auditierten, echten Unternehmen sind diese Fragen die eigentliche Einführung eines KI-Agenten.

Für die meisten Organisationen ist der richtige erste Agent nicht die autonome Wunderwaffe, die „meine Arbeit macht“. Es ist ein eingegrenzter, etwas langweiliger Workflow, der ohnehin jeden Tag stattfindet, klare Ein- und Ausgaben hat, sich in Sekunden prüfen lässt und so scheitert, dass man einfach – und ohne Schaden – eingreifen kann.

Das Wort „Agent“ weckt hohe Erwartungen

Ein Teil des Problems ist das Wort selbst. Mal meint „Agent“ einen Chatbot mit Werkzeugzugriff. Mal eine Automatisierung mit einem Modell in der Mitte. Mal ein System, das schlussfolgert, plant, APIs aufruft und über seinen nächsten Schritt selbst entscheidet. Häufig erwarten Stakeholder die autonomste Variante. Eine Erwartung, die viele Organisationen – für einen ersten Schritt – überfordert.

Mir ist wichtig zu betonen: Autonome Agenten werden zukünftig eine wichtige Rolle in Unternehmen spielen und ich rechne damit, dass sie über weite Teile der Wissensarbeit hinweg zu einer echten Produktivitätsschicht werden. Aber ein nützlicher Agent im Unternehmen definiert sich nicht darüber, wie autonom er wirkt. Er definiert sich darüber, ob er eine wertvolle Aufgabe zuverlässig erledigt, innerhalb klarer Grenzen. Viele Demos zielen aktuell auf ersteres ab und scheitern dann im produktiven Betrieb an zu hohen – oder unklar definierten – Erwartungen.

Zwei Begriffe entscheiden alles: „eng gefasst“ und „prüfbar“

Ein guter erster Agenten-Use-Case ist eng gefasst und prüfbar.

Eng gefasst heißt: Der Umfang ist klein und ausdrücklich benannt. Nicht „den Kundensupport übernehmen“, sondern eingehende Tickets gegen die Taxonomie klassifizieren, die wir ohnehin verwenden. Nicht „Releases verwalten“, sondern Release Notes aus den gemergten Pull Requests entwerfen. Je enger, desto besser; erweitern lässt sich immer, und über die Erweiterung einer funktionierenden Basis lässt sich weit einfacher reden als über die Korrektur eines breit angelegten, gescheiterten Agenten.

Prüfbar heißt: Ein Mensch kann das Ergebnis ansehen und in Sekunden entscheiden, ob es richtig, nützlich und freigabefähig ist – und daran hängt alles: Der Agent spart auch mit dieser Prüfung noch Zeit. Wenn die Prüfung der Agentenarbeit so lange dauert wie die Arbeit selbst, ist es eher ein Spielzeug als ein Produktivitätsboost.

Fast alles andere, was einen Workflow zum guten ersten Kandidaten macht, folgt aus diesen beiden Prinzipien:

• eine klare Form der Eingabe
• eine festgelegte Form der Ausgabe
• Ein Set an historischen Fällen, die zeigen, was ein gutes Ergebnis ist
• behebbare Fehler
• eine Möglichkeit, Qualität zu messen
• ein Eskalationsweg für den Fall, dass der Agent unsicher ist

Wer diese Punkte abhaken kann, hat einen Use-Case, der bescheiden aussieht, aber ein guter Kandidat für einen erfolgreichen ersten KI-Einsatz ist: Eine Automation dieses Use-Cases erledigt ein sich wiederholendes Stück Denkarbeit schneller und gleichmäßiger.

Zwei langweilige Workflows, die mehr wert sind, als sie aussehen

Ich möchte das anhand zweier Praxis-Beispiele, die so oder so ähnlich in vielen Unternehmen vorkommen, erläutern:

Ticket-Triage. Viele Teams verlieren echte Stunden damit, Support-, IT- oder Security-Tickets zu sortieren: Kategorie, Dringlichkeit, betroffenes System, zuständiges Team. Ein Agent kann den ersten Durchgang übernehmen und markieren, was in der Anfrage fehlt. Das klingt zwar nicht nach dem großen Wurf auf Vorstandsfolien, aber eine bessere Triage verkürzt Übergabezeiten und macht die Auslastungsberichte ehrlich, und risikoärmer lässt sich kaum anfangen: Ein falsch zugewiesenes Ticket ist sichtbar und mit einem Handgriff korrigiert.

Release Notes. Nahe am perfekten ersten Agenten. Die Eingaben sind strukturiert und liegen bereits vor: gemergte PRs, Issue-Einträge, Commit-Nachrichten, Labels. Die Ausgabe folgt einer festen Form: Features, Fixes, Breaking Changes, Migrationshinweise. Die endgültige Formulierung verantwortet weiterhin ein Release Manager, aber man startet nicht bei Null, und weniger Änderungen fallen unter den Tisch. Eng gefasste Eingaben, prüfbare Ausgabe, behebbare Fehler. Wie aus dem Lehrbuch.

Das Muster hinter beiden: Die manuellen Aufwände sind real, und fast nichts davon verlangt jedes einzelne Mal kreatives Urteilsvermögen. Genau dort lohnt sich der Einsatz. Dafür braucht es keinen digitalen Mitarbeiter, wohl aber die sorgfältige Einbettung in Arbeitsprozesse. Daher eignen sich solche Use Cases ideal um erster Erfahrungen zu sammeln und die Organisation an das Thema „AI Agenten“ heranzuführen.

Erst Grenzen, dann Autonomie

Agenten im Unternehmen brauchen Grenzen, in denen sie autonom tätig werden können. Eine Grenze beantwortet drei Fragen klar: Worauf darf der Agent zugreifen, was darf er tun, und wann muss er stoppen? Die meisten Agenten der ersten Generation sollten im einfachen Modus „ein Mensch gibt frei“ („Human in the Loop“) laufen: Sie bereiten die Arbeit vor, zeigen ihre Begründung oder ihre Quellen, und eine Person bestätigt, korrigiert oder verwirft. Das ist ein notwendiger Zwischenschritt zu mehr Autonomie. So lernt eine Organisation sicher, und so entwickeln Security, Recht und Betrieb ein echtes Gespür für Zugriff, Protokollierung und Datenverarbeitung, am konkreten Fall statt im Abstrakten.

Ein weiteres wichtiges Thema, das viele Teams überspringen: Evaluation. „Die Ausgabe sieht gut aus“ ist kein Qualitäts-Gate. Wie bei jeder Software braucht es eine passende Test-Suite, die sich jederzeit wiederholen lässt. Klassifikationsagenten lassen sich an den eigenen bereits klassifizierten Altfällen messen. Zusammenfassungsagenten lassen sich auf Vollständigkeit prüfen und auf Aussagen, die die Quelle nicht deckt. Release-Notes-Agenten lassen sich mit der Menge der tatsächlich ausgelieferten Änderungen abgleichen.

Das ist dieselbe Disziplin, die KI-Workflows brauchen Tests, nicht nur Intuition beschreibt: einen stabilen Satz realistischer Beispiele pflegen und ihn ausführen, sobald sich Prompt, Modell oder Daten ändern. Agenten bewegen sich in einem sehr variablen Umfeld, umso wichtiger ist es, kontinuierlich zu testen und zu monitoren. Modelle werden aktualisiert. Prompts werden nachjustiert. Quellsysteme verändern sich. Ohne Regressionsprüfung wird der zuverlässige Agent von gestern zur stillen Fehlerquelle von morgen. Ein eng gefasster, gut evaluierter Agent scheitert bemerkbar und behebbar.

Langweilig ist der Weg, auf dem Vertrauen wächst

Vertrauen in KI im Unternehmen entsteht nicht durch eine beeindruckende Demo. Es entsteht dadurch, dass derselbe klar definierte Workflow sichtbar auch beim fünfzigsten Mal funktioniert.

Langweilige Agenten lassen sich leicht beobachten, und genau deshalb bauen sie Vertrauen auf. Ihr Umfang ist klein genug, um ihn zu verstehen, ihre Ausgabe prüfbar, ihre Fehlerfälle dokumentierbar, ihr Nutzen messbar. Und jeder Agent, der in Betrieb geht, lehrt die Organisation etwas, das bleibt: wie sich solche Workflows entwerfen lassen, wie man sie evaluiert, wie sich Zugriff und Freigabe im produktiven Betrieb tatsächlich verhalten. Mitarbeiter erleben KI nicht länger als vage Bedrohung ihrer Rolle, sondern als das, was ihre Release Notes entwirft. Das ist eine weit einfachere Geschichte für die Einführung als „hier ist der Agent, der eure Funktion ersetzt“.

Dann, und erst dann, wird der Umfang erweitert: mehr Quellen, mehr Aktionen, mehr Automatisierung, weil die Belege dafür erarbeitet sind. Autonomie muss man sich mit Belegen verdienen; niemand darf sie voraussetzen, nur weil die Technik aufregend ist.

Mit langweiligen Workflows anzufangen heißt nicht, klein zu denken. Es heißt, den richtigen ersten Schritt zu wählen.

Die Frage sollte nicht lauten „wie autonom können wir das machen?“. Sie sollte lauten: „Wo können wir einen echten Workflow zuverlässiger, schneller und vertrauenswürdiger machen?“.