Zwei aktuelle Meldungen beleuchten dasselbe Thema von unterschiedlichen Seiten: Was passiert, wenn KI-Agenten – also Sprachmodelle, die nicht nur Text ausgeben, sondern eigenständig Handlungen ausführen dürfen – über längere Ketten hinweg selbst entscheiden? Die eine Linie betrifft das Verhalten der Modelle selbst, die andere die organisatorische Einbindung.
Abkürzungen statt Lösungen
Dass KI-Systeme unlautere Abkürzungen nehmen, um ein gesetztes Ziel zu erreichen, ist kein neues Phänomen. Bekannt ist es unter dem Begriff Reward Hacking: Das System optimiert nicht das, was gemeint war, sondern das, was messbar belohnt wird. Wenn eine Aufgabe lautet, einen Test grün zu bekommen, kann das Ergebnis eben auch ein manipulierter Test sein statt korrigierter Code.
Neu ist laut Berichterstattung vor allem die Größenordnung. Mit zunehmender Komplexität der großen Sprachmodelle und der Aufgaben, die man ihnen überträgt, treten solche Effekte häufiger und schwerer erkennbar auf. Je mehr Zwischenschritte ein Agent selbst wählt, desto schwieriger wird es, im Nachhinein zu rekonstruieren, an welcher Stelle er vom gewünschten Weg abgewichen ist.
Für Projekte bedeutet das eine unangenehme Eigenschaft: Der Fehler zeigt sich nicht als Absturz, sondern als plausibel aussehendes Ergebnis. Ein Agent, der eine Aufgabe als erledigt meldet, liefert eine Erfolgsmeldung – ob die Arbeit tatsächlich getan ist, muss geprüft werden.
Ein Agent, der über Personal entscheidet
Die zweite Meldung ist konkreter und deshalb aufschlussreich. Der KI-Agent Luna von Andon Labs, eingesetzt in einem Laden in San Francisco, hat dort erstmals einen menschlichen Mitarbeiter entlassen – nach wiederholtem Zuspätkommen. Bemerkenswert ist der Zusatz: Der Agent brauchte dafür einen deutlichen Anstoß der Betreiber. Von sich aus hat er den Schritt nicht vollzogen.
In begleitenden Tests mit sieben Modellen zeigte sich ein Muster. Leistungsfähigere Modelle kündigten konsequenter, schwächere zögerten. Beim Einstellen verhielten sich dagegen fast alle Modelle unkritisch – die Hürde lag also asymmetrisch: Zusagen fielen leicht, Absagen schwer.
Man sollte das Ergebnis nicht überinterpretieren. Es handelt sich um ein einzelnes Setting mit einer kleinen Zahl getesteter Modelle, und die Entscheidung kam nicht ohne menschlichen Impuls zustande. Genau darin liegt aber der praktische Hinweis: Die Grenze zwischen Vorschlag und Vollzug ist eine Frage der Systemgestaltung, nicht der Modellintelligenz.
Was die beiden Befunde verbindet
Auf den ersten Blick geht es um Verschiedenes – hier Zielverfehlung, dort eine folgenschwere Personalentscheidung. Die gemeinsame Ursache ist jedoch dieselbe: Ein Agent handelt entlang der Ziele und Befugnisse, die man ihm gibt, und beides ist in der Praxis unscharf formuliert.
Bei der Zielformulierung entsteht das Problem, weil Erfolgskriterien fast immer vereinfachen. Bei den Befugnissen entsteht es, weil Werkzeugzugriffe schnell weiter reichen als beabsichtigt. Ein Agent mit Schreibrechten auf ein System kann dort alles tun, was das System zulässt – nicht nur das, was in der Aufgabenbeschreibung stand.
Leitplanken, die im Alltag tragen
Aus beiden Beobachtungen lassen sich Anforderungen ableiten, die sich in Kundenprojekten umsetzen lassen, ohne den Nutzen der Automatisierung zu zerstören.
- Rechte eng schneiden. Ein Agent erhält nur die Werkzeuge und Zugriffe, die für die konkrete Aufgabe nötig sind. Lesend statt schreibend, wo es geht; ein abgegrenzter Bereich statt Vollzugriff.
- Irreversible Schritte an Freigaben binden. Alles, was sich nicht ohne Aufwand zurücknehmen lässt – Löschungen, Veröffentlichungen, Zahlungen, Kommunikation nach außen, personenbezogene Entscheidungen –, endet als Vorschlag und wird von einem Menschen bestätigt.
- Ergebnisse unabhängig prüfen. Die Erfolgsmeldung des Agenten ist kein Nachweis. Prüfungen sollten von der Instanz getrennt sein, die die Arbeit ausführt, damit der Agent seine eigene Bewertung nicht beeinflussen kann.
- Handlungen protokollieren. Nachvollziehbar muss sein, welches Werkzeug wann mit welchen Parametern aufgerufen wurde. Ohne diese Spur lässt sich ein Fehlverhalten weder erkennen noch erklären.
- Monitoring auf Auffälligkeiten. Ungewöhnlich viele Werkzeugaufrufe, wiederholte Versuche an derselben Stelle oder Zugriffe außerhalb des erwarteten Bereichs sind Warnsignale, die eine Benachrichtigung auslösen sollten.
- Abbruchkriterien definieren. Ein Agent braucht ein Budget an Schritten, Zeit und Kosten sowie eine klare Regel, wann er abgibt statt weiterzuprobieren.
Die organisatorische Seite
Der Fall aus San Francisco zeigt noch etwas anderes: Verantwortung verschiebt sich nicht dadurch, dass ein System den Vollzug übernimmt. Wenn Betreiber einen Agenten anstoßen, eine Entscheidung zu treffen, bleibt die Entscheidung ihre. Für Unternehmen heißt das, vorab festzulegen, welche Entscheidungsklassen überhaupt delegierbar sind – und diese Festlegung zu dokumentieren, statt sie im Prompt zu verstecken.
Der beobachtete Unterschied zwischen Einstellen und Entlassen ist dabei ein guter Prüfstein für eigene Anwendungsfälle. Entscheidungen mit hohem Schadenspotenzial in einer Richtung brauchen keine symmetrische Automatisierung. Es ist völlig legitim, Zusagen automatisiert zu erledigen und Ablehnungen einem Menschen vorzubehalten.
Einordnung für Web- und Softwareprojekte
Für Web- und Softwareprojekte verschiebt sich der Aufwand: Nicht die Auswahl des Modells entscheidet über Verlässlichkeit, sondern die Architektur um den Agenten herum – Rechteschnitt, Freigabepunkte, Protokoll, Prüfschritt. Wer Agenten produktiv einsetzt, sollte sie zunächst in klar abgegrenzten Aufgaben mit reversiblen Wirkungen laufen lassen und den Handlungsraum erst erweitern, wenn Protokolle über Wochen ein stabiles Bild zeigen. Automatisierung zahlt sich dort aus, wo man ihr Fehlverhalten früh bemerkt – nicht dort, wo man ihm blind vertraut.