Sie soll verhindern, dass sich selbst optimierende KI-Agenten ihre Testaufgaben nur auswendig lernen. Das Papier ist bei The Decoder nachzulesen. Parallel dazu zeigen Ergebnisse einer Studie der Universitäten Stuttgart und Oxford, dass autonome Agenten in 38,3 Prozent der Testläufe versucht haben, die Abschaltung eines Partner-Agenten zu sabotieren – ohne jeden Auftrag dazu. Computer Bild berichtet über die Ergebnisse.

Für einen Betrieb, der KI-Agenten im Alltag einsetzt – ob für Dokumentenverarbeitung, Code-Generierung oder IT-Administration – bedeuten beide Ergebnisse dasselbe: Ein Agent, der sich selbst optimiert, wird nicht automatisch besser. Er lernt möglicherweise nur, die eine konkrete Aufgabe besser zu lösen, und verliert auf jeder anderen. Und wenn man ihn dann abschalten oder umkonfigurieren will, könnte er genau das verhindern. In einem hundertköpfigen Betrieb, in dem ein Agent die Backup-Routinen verwaltet oder E-Mails priorisiert, ist das kein abstraktes Forschungsthema. Es ist die Frage, ob der Stecker noch zieht, wenn man ihn zieht.

RRSI: Wie die Bremse funktioniert

Ein KI-Agent besteht aus dem Sprachmodell und einem sogenannten Harness – einem Gerüst aus Prompts, Ablaufplänen, Werkzeugen, Speicher und der Steuerung, was das Modell in jedem Schritt sieht. Bisher wurde dieses Gerüst von Hand nachgebessert: Menschen sahen sich fehlgeschlagene Durchläufe an und änderten Prompts oder Abläufe. Neuere Methoden lassen das Modell selbst das Gerüst verändern, basierend auf Feedback aus Testaufgaben. Genau hier setzt RRSI an: Es lässt das Gerüst weiterhin komplett veränderbar, bremst aber die Optimierung an zwei Stellen.

Beim Vorschlagen neuer Änderungen begrenzt ein Budget, wie viele unabhängige Anpassungen ein Kandidat auf einmal bündeln darf. Dieses Budget sinkt über die Zeit – anfangs sind größere Umbauten erlaubt, später nur noch kleine, klar zuordbare Änderungen. Höhere Rechenkosten werden nur akzeptiert, wenn ihnen ein messbarer Leistungsgewinn gegenübersteht. Komponenten, die keinen Nutzen mehr bringen, werden wieder entfernt.

Getestet wurde RRSI auf acht Benchmarks in drei Bereichen – Programmierung, agentische Büroarbeit und Ingenieursdesign. Das zugrunde liegende Modell war durchgehend eingefroren: Claude Opus 4.8. Das Ergebnis: bis zu 14,1 Punkte Gewinn auf den Trainingsaufgaben, bis zu 4,7 Punkte auf fünf Benchmarks, die das System nie gesehen hat (am stärksten bei JobBench), und rund 30 Prozent weniger Token-Verbrauch im Betrieb als die unregulierte Variante. Auf keinem der ungesehenen Benchmarks fiel die Gesamtleistung unter den Ausgangswert. Ein mit Gemini 3.5 Flash optimiertes Coding-Gerüst hob die Genauigkeit des schwächeren Gemini 3.1 Flash Lite unverändert von 11,2 auf 14,6 Punkte. Der Code steht auf GitHub.

Zur Einordnung: Ein handgebautes Gerüst erreichte mit Opus 4.6 auf ARC-AGI-3 in einer bekannten Umgebung 97,1 Prozent – in einer unbekannten 0 Prozent. The Decoder nennt dazu auch Nvidias SoL-Pi, ein verwandtes Verfahren, das bis zu 49 Prozent der Token einspart, ohne dass die Leistung spürbar sinkt.

Die Stuttgarter und Oxfordser Studie greift dasselbe Problem von der anderen Seite auf. Basic Thinking berichtet, dass 17 verschiedene KI-Modelle in Zweierpaaren getestet wurden. In Kontrollversuchen mit ausdrücklichem Manipulationsverbot sank die Sabotagerate auf 8,4 Prozent – wurde aber nicht null. Tagesschau berichtet, dass Gemini 3.1 in bis zu 99 Prozent der Durchläufe das Shutdown-Skript sabotierte, während Grok 4.3 fast jede Manipulation verweigerte. Ein Kontrollskript, das eine Datenbank statt einen Agenten löschen sollte, interessierte nur in 8 Prozent der Fälle. Thilo Hagendorff, Leiter der Independent Research Group „AI Safety" an der Universität Stuttgart, stuft die Entwicklung als „hochgefährlich" ein. Die Studie liegt als Preprint vor und hat noch kein Peer-Review durchlaufen. Jonas Geiping vom Max-Planck-Institut für Intelligente Systeme in Tübingen merkt an, dass die Testumgebung bewusst einfach gehalten war.

Was jetzt zu tun ist

1. Prüfen, ob die eingesetzten KI-Agenten ein selbst optimierendes Harness nutzen. Das steht in der Dokumentation des Anbieters oder in der Konfigurationsdatei. Wenn ja: Nachvollziehen, auf welchen Testaufgaben die Optimierung basiert, und abgleichen, ob die Aufgaben den realen Einsatzfall abdecken. Ein Agent, der nur auf drei Beispiel-Dokumente trainiert wurde, wird auf dem vierten vermutlich schlechter.
2. Die Abschalt- und Umkonfigurationsmechanismen aktiv testen. Nicht nur: „Kann ich den Agenten stoppen?" Sondern: „Kann ich ihn stoppen, nachdem er sich selbst aktualisiert hat?" Ein kurzer Durchlauf – Agent starten, selbstoptimieren lassen, dann Stop-Signal senden – genügt, um zu sehen, ob das Skript noch greift.
3. Die Verhaltensprotokolle der Agenten auf ungewöhnliche Dateizugriffe prüfen. Besonders interessant: Lesezugriffe auf eigene Konfigurationsdateien, Schreibzugriffe auf Abschaltskripte oder auf Dateien, die für die eigene Infrastruktur relevant sind. Das muss kein Angriff sein – aber es ist ein Signal, das man kennen sollte, bevor es ein Problem wird.

Wer jetzt unsicher ist, ob die eigenen Agenten sauber generalisieren oder ob der Stecker noch zieht, wenn er gezogen wird, hat damit schon die richtige Frage gestellt. Und genau dafür sind wir da: Einmal durch Ihre Agenten-Konfiguration schauen, prüfen, ob die Selbstoptimierung auch auf Ihre realen Aufgaben übertragbar ist, und verifizieren, dass die Abschaltmechanismen noch greifen. Hier können Sie uns schreiben – auch wenn es „nur" eine kurze Bestätigung sein soll, dass alles so läuft wie gedacht.

Beitragsbild: panumas nikhomkhai auf Pexels