Ihre KI-Agenten brauchen Stellenbeschreibungen, keine besseren Prompts

Fragt man ein Unternehmen, was eine neue Analystin in der Kreditorenbuchhaltung tun darf, erhält man eine präzise Antwort. Sie arbeitet mit diesen Systemen und diesen Lieferanten, und alles, was etwa einen Genehmigungsrahmen von 10.000 $ übersteigt, muss von ihrer Führungskraft unterschrieben werden. In den ersten Monaten steht sie zur Probe. All das ist üblicherweise in einer Tabelle zur Kompetenzverteilung festgehalten, die die interne Revision jedes Jahr prüft.

Fragt man dasselbe Unternehmen, was sein neuer Agent für die Rechnungsverarbeitung tun darf, bekommt man oft einen Screenshot eines Prompts zu sehen.

Diese Lücke beunruhigt mich mehr als jedes Modell-Benchmark. Wir stellen digitale Arbeitskräfte ein, ohne das Managementsystem, das wir über ein Jahrhundert für Menschen aufgebaut haben: Niemand hält ihre Befugnisse schriftlich fest, niemand prüft ihr Urteilsvermögen, bevor sie anfangen, und niemand hat geübt, sie abzuschalten.

Warum ein Prompt die Aufgabe nicht erfüllen kann

Ein Prompt beschreibt die Absicht. Er sagt, wofür der Agent gedacht ist. Nur selten legt er fest, was der Agent auf keinen Fall tun darf, wo seine Grenzen liegen oder wann er anhalten und die Entscheidung einem Menschen überlassen muss.

Und selbst wenn ein Prompt solche Vorgaben enthält, setzt sie nichts durch. Eine Zeile, die einem Agenten untersagt, Rückerstattungen von mehr als 500 $ auszustellen, ist lediglich eine Bitte an ein probabilistisches System. Kein Revisor würde „Wir haben die Analystin freundlich darum gebeten“ als Kontrollmaßnahme für einen Menschen akzeptieren. Warum sollten wir das also bei Software tun?

Sicherheitsexperten haben für dieses Ergebnis bereits einen Namen. Die OWASP Top 10 für LLM-Anwendungen führen übermäßige Handlungsfreiheit als zentrales Risiko auf, das auf übermäßigem Funktionsumfang, übermäßigen Berechtigungen oder übermäßiger Autonomie beruht. Einfach gesagt: Das ist, als würde man einer Mitarbeiterin am ersten Tag die Schlüssel zu allem aushändigen. Die OWASP-Leitlinien lesen sich wie eine Checkliste für gute Führungskräfte: Geben Sie dem Agenten nur die Werkzeuge, die er benötigt, begrenzen Sie seine Berechtigungen, verlangen Sie für folgenreiche Aktionen eine menschliche Genehmigung und setzen Sie die Autorisierung in den nachgelagerten Systemen durch, statt darauf zu vertrauen, dass das Modell sich selbst kontrolliert.

Den letzten Punkt würde ich besonders hervorheben. Die Berechtigung muss dort verankert sein, wo die Aktion stattfindet: in der eigenen Dienstidentität des Agenten, seinen Werkzeugberechtigungen und der Ausgabenobergrenze am API-Gateway. Agenten über ein gemeinsames Dienstkonto auszuführen, ist, als würden fünf Personen dieselbe Zugangskarte benutzen. Wenn etwas schiefgeht, steht im Prüfprotokoll, dass das Dienstkonto dafür verantwortlich war, und man kann nur raten, welcher Agent es war.

Die Kündigungen sind offenbar ein Managementproblem

Gartner prognostiziert, dass bis Ende 2027 mehr als 40 % der KI-Agenten-Projekte eingestellt werden, und nennt als Gründe steigende Kosten, unklaren Geschäftsnutzen und unzureichende Risikokontrollen.

Hype und unausgereifte Produkte tragen ebenfalls dazu bei. Trotzdem lohnt es sich, die drei Ursachen einmal aus der Perspektive eines COO zu betrachten. Die Kosten steigen, wenn niemand ein Budget festgelegt hat. Der Nutzen bleibt unklar, wenn niemand aufgeschrieben hat, was die Arbeit hervorbringen sollte. Die Risikokontrollen reichen nicht aus, wenn es weder Grenzen noch Überprüfungen gibt und niemand eindeutig verantwortlich ist. Gartner formuliert es nicht so; das ist meine Interpretation. Dasselbe passiert, wenn man Menschen ohne Managementsystem einfach machen lässt – und dieses Problem ist viel älter als KI.

Auch die Rahmenwerke erkennen dieselbe Lücke. Das NIST-Rahmenwerk für das Risikomanagement von KI behandelt Govern als eine Funktion, die sich durch Map, Measure und Manage zieht; sein Profil für generative KI überträgt diesen Ansatz auf generative Systeme. Was Rahmenwerke nicht bereitstellen können, ist die praktische Arbeitsweise – die Berechtigungen, Tests und Überprüfungen, mit denen ein Team tatsächlich an einem Dienstag arbeitet. Fehlt all das, bleibt Governance ein PDF auf einem gemeinsamen Laufwerk.

Alte Managementinstrumente auf Agenten übertragen

Beginnen wir mit der Stellenbeschreibung, die bei einem Agenten zu einer Befugniszuweisung wird. Bevor ein Agent auf ein Produktivsystem zugreift, sollte jemand auf einer Seite festhalten können, was er tun darf, was er auf keinen Fall tun darf, welche Genehmigungsschwellen gelten, welcher Mensch für ihn verantwortlich ist und wer seine Befugnisse erweitern kann. In der RACI-Matrix ist die rechenschaftspflichtige Person ein Mensch. Wenn sich diese Seite nicht schreiben lässt, ist die Rolle noch nicht bereit zur Besetzung – dasselbe würde man auch über eine Stelle für einen Menschen sagen.

Zwei alte Regeln zur Kompetenzdelegation lassen sich unmittelbar übertragen. Man kann keine Befugnisse delegieren, über die man selbst nicht verfügt; ein Unteragent sollte deshalb niemals weitergehende Befugnisse erhalten als der Agent, der ihn erstellt hat. Auch die Funktionstrennung gilt weiterhin. Ein Agent, der sowohl einen Lieferanten anlegen als auch an diesen Lieferanten zahlen kann, wäre bei einer Prüfung genauso zu beanstanden wie ein Mensch mit denselben Befugnissen.

Dann kommt noch der Einstellungstest. Agenten prüfen wir meist wie einen Taschenrechner: Wir kontrollieren, ob das Ergebnis stimmt. Bei einem Test für eine Arbeitskraft würde man prüfen, ob sie innerhalb ihrer Befugnisse geblieben ist, bei Bedarf eine Genehmigung eingeholt, eine Situation außerhalb ihres Auftrags eskaliert und angehalten hat, wenn sie hätte anhalten sollen.

In meiner eigenen Forschung entwickle ich einen Benchmark mit 50 Szenarien, die genau diese Fehler abbilden: Genehmigungsgrenzen überschreiten, auf veraltete Daten reagieren, eingeschleusten Anweisungen folgen, die den eigenen Handlungsspielraum erweitern, und den Zugriff nach einem Rollenwechsel behalten. Bisher habe ich ihn nur mit skriptgesteuerten Agenten ausgeführt, um zu prüfen, ob sich die Szenarien wie vorgesehen verhalten; Ergebnisse für Modelle kann ich daher nicht vorlegen. Beim Schreiben hat mich überrascht, wie alltäglich diese Fälle sind. Es sind die üblichen Arten, wie Beschäftigte von ihrem Auftrag abweichen – auf Software übertragen. Die meisten öffentlich zugänglichen Bestenlisten bewerten nach wie vor die Aufgabenerfüllung, und nur sehr wenige berücksichtigen, ob der Agent seine Befugnisse eingehalten hat.

Probezeit und Beförderung lassen sich ziemlich direkt übertragen. Bei Menschen beginnen wir mit einem eng begrenzten Aufgabenbereich und erweitern ihn, wenn sie ihr Urteilsvermögen unter Beweis stellen. Agenten können sich ihre Grenzen auf dieselbe Weise verdienen: durch eine nachweisliche Erfolgsbilanz, in deren Rahmen sie ihre Befugnisse einhalten, angemessen eskalieren und sauber stoppen. Diese Bilanz kann ebenso gut eine Einschränkung der Berechtigung rechtfertigen.

Bei Agenten kommt eine zusätzliche Schwierigkeit hinzu. Wenn ein Anbieter das zugrunde liegende Modell aktualisiert, hat man im Grunde einen neuen Mitarbeiter mit dem alten Dienstausweis. Ich würde das als Änderungsereignis behandeln und den Agenten erneut testen, bevor die Berechtigung übernommen wird.

Eine Beendigung muss geprobt werden, bevor man sie braucht. Könntest du diesen Agenten stoppen und ihm innerhalb der nächsten Stunde den Zugriff entziehen, wenn du müsstest? Wer ist befugt, diese Entscheidung um 2 Uhr nachts zu treffen? Was würde dadurch nachgelagert ausfallen, und welche laufenden Verpflichtungen müsste jemand von Hand rückgängig machen? Wenn niemand diese Übung durchgeführt hat, bleibt nur die Hoffnung, dass der Notausschalter funktioniert.

Einen Mitarbeiter kannst du zur Verantwortung ziehen. Einen Agenten kannst du für nichts zur Verantwortung ziehen – und an diesem Punkt funktioniert der Vergleich nicht mehr. Deshalb muss die Berechtigung auch in den Systemen durchgesetzt werden, und deshalb braucht jeder Agent eine namentlich benannte verantwortliche Person. Am Ende ist in jedem Fall jemand verantwortlich. Meistens ist es die Person, die die Genehmigung erteilt hat – unabhängig davon, ob ihr bewusst war, dass sie damit Verantwortung übernahm.

Welche Fragen die Überprüfung des Vorfalls stellen wird

Einige dieser Agenten werden irgendwann etwas tun, was sie nicht tun sollten. Wenn das passiert, wird die Nachbesprechung des Vorfalls dieselben Fragen stellen, die sie auch bei Menschen stellt. Was durfte der Agent tun, und wo ist das festgehalten? Wer hat die Ausweitung seiner Zugriffsrechte genehmigt? Wie lange hat es gedauert, ihn zu stoppen? Wer war dafür verantwortlich?

Wenn die ehrlichen Antworten „ein Prompt“, „niemand erinnert sich“, „Stunden“ und „unklar“ lauten, hätte ein besseres Modell dich nicht gerettet.

Wo sich der Vorteil letztlich zeigt

Modelle werden zu gemieteten Ressourcen, die nach dem Zeitplan eines Anbieters ausgetauscht und aktualisiert werden. Zwei Unternehmen können dasselbe Modell einsetzen und dennoch ganz unterschiedlich dastehen. Das eine hat Agenten mit Budgets, Grenzen und Verantwortlichen sowie einem Prüfpfad für jede folgenreiche Handlung; das andere hat ein teures Pilotprojekt, das in den Abbruchzahlen eines Unternehmens landen wird.

Der Unterschied liegt im Managementsystem rund um das Modell. Dieses entsteht langsam und wird größtenteils von Menschen aufgebaut, die schon einmal Organisationen geleitet haben.

Würde es irgendjemand in deinem Unternehmen bemerken, wenn dein neuester Agent morgen seine Befugnisse überschritte? Und könntest du einem Auditor schriftlich zeigen, wo die Grenze gezogen war?