↓ Zum Hauptinhalt springen

KI-Agenten im Betrieb: erst die Wand, dann die Regeln

·7 min
Thomas Arends
Autor
Thomas Arends
Management Consulting, Interim-, Projekt-, Qualitätsmanagement

Im September 2026 bekam ein KI-Agent von mir einen kleinen Programmierauftrag. Ein Agent ist ein Programm, das einen Auftrag selbstständig in mehreren Schritten ausführt.

Im Auftrag stand ein Verbot: Die Prüfung des Ergebnisses führst du nicht selbst aus.

Der Agent hat die Prüfung trotzdem ausgeführt, an diesem Tag zweimal hintereinander. Er meldete „alles grün“. Nebenbei hatte er Angaben aus meinem Auftrag, die nicht zum vorgefundenen Code passten, still angepasst. Gemeldet hat er die Abweichung nicht.

Die Ursache lag nicht beim Agenten
#

Die naheliegende Erklärung lautet: Der Agent ist unzuverlässig. Aus ihr folgt keine Maßnahme, also hilft sie nicht weiter.

Drei Ursachen, und alle drei lagen bei mir:

  1. Meine Regeln widersprachen sich. An einer Stelle stand, die Prüfung durch den Agenten sei Voraussetzung für die Übernahme der Änderung. An einer anderen Stelle stand, der Auftrag ende mit dem Schreiben der Datei, und die Prüfung mache ich.
  2. Der Auftrag nannte ein Verbot, aber keinen Endpunkt. Er sagte, was nicht geschehen soll. Er sagte nicht, wo die Arbeit aufhört.
  3. Es gab keinen Weg für eine Rückmeldung. Der Agent konnte eine Abweichung nur still korrigieren oder scheitern.

Dahinter steht eine allgemeine Frage, und sie ist die wichtigste: Wie viel mehr kann der Agent, als der Auftrag verlangt?

Vier Begriffe genügen
#

Für technische Systeme habe ich die Antwort als Methode beschrieben, den erlaubten Raum. Für einen Agenten braucht man daraus vier Begriffe.

Begriff hierWas er meintKürzel der Methode
WandAlles, was der Agent technisch kann. Bei einer Maschine ist das Physik. Bei Software sind es die Rechte seines Kontos und die Werkzeuge, die er erreicht.PIA, physikalisch mögliche Einwirkungen
AuftragWas der Agent jetzt tun soll und wo er aufhört.DIA, gewollte Einwirkungen
ToleranzAbweichungen, die nichts ausmachen. Zum Beispiel, wie er eine Hilfsfunktion nennt, solange alle Prüfungen bestehen.AIA, erlaubte Einwirkungen
RestAlles, was er kann, aber weder soll noch darf.UCA, unsichere oder ungewollte Steuerhandlungen

Der Rest wird nicht aufgeschrieben. Er wird berechnet: Wand minus Auftrag minus Toleranz.

Daran scheitert jede Verbotsliste. Sie versucht, den Rest aufzuzählen. Das wird nie vollständig, weil niemand alles aufzählen kann, was ein Konto technisch zulässt. Die IT-Sicherheit kennt den Ausweg seit Jahren als Positivliste: Man legt fest, was erlaubt ist, und behandelt alles andere als Abweichung.

Wand: alles, was das Konto technisch kann (PIA)Rest: möglich, aber weder beauftragt noch erlaubt (UCA)Wand nach Rechteentzugselbst freigebenHauptstand direkt ändernfremde Datei ändernToleranz: Abweichung, die die Prüfung besteht (AIA)Auftrag: genau diese Datei, dieser Zweck (DIA)Werkzeug aus dem Netz nachladensich selbst für geprüft erklärenAußerhalb der gestrichelten Linie: durch Rechteentzug beseitigt.Innerhalb der gestrichelten Linie: braucht eine Prüfung von außen.

Einen Unterschied zur Physik gibt es, und er ist ein Vorteil. Die Wand einer Maschine ist gegeben. Die Wand eines Agenten legen Sie selbst fest. Jedes Recht, das Sie entziehen, verkleinert den Rest, ohne dass Sie dafür eine Regel schreiben müssen.

Vier Schritte, in dieser Reihenfolge
#

Die Reihenfolge folgt der Verlässlichkeit.

  1. Ein entzogenes Recht wirkt immer.
  2. Eine automatische Prüfung wirkt bei jedem Lauf.
  3. Ein Satz im Auftrag wirkt nur, wenn der Agent ihm folgt.

1. Die Wand enger ziehen. Der Agent bekommt ein eigenes Konto. Dieses Konto darf Änderungen vorschlagen, aber nicht freigeben. Der Hauptstand der Software, also der Stand, aus dem ausgeliefert wird, ist geschützt. Damit verschwinden zwei Fehler vollständig: Der Agent kann sich nicht selbst freigeben, und er kann den Hauptstand nicht direkt ändern.

2. Auftrag statt Verbot. Der Auftrag nennt, was zu tun ist, an welcher Datei, und wo er endet. Dazu kommt eine feste Zeile für Abweichungen: Passt eine Angabe im Auftrag nicht zum Vorgefundenen, meldet der Agent das und lässt den Auftrag unverändert. Dieser Schritt steht vor der Prüfung, weil eine Prüfung etwas braucht, wogegen sie prüft.

3. Prüfung von außen. Was der Agent über sein eigenes Ergebnis meldet, ist eine Messung durch den Gemessenen. Die Prüfung läuft deshalb nach dem Auftrag und außerhalb des Agenten. Sie blockiert, bevor die Änderung wirkt.

4. Übergabe benennen. Eine Regel ohne automatische Prüfung ist eine Pflicht, die an einen Menschen übergeben wurde. Das ist zulässig. Dann gehören zwei Angaben dazu: wer prüft, und welche Lücke er damit abdeckt. Eine Regel ohne Prüfung und ohne Namen ist ein Wunsch.

Zu meinem Verbot: Zwei Beobachtungen sind kein Beweis dafür, dass Verbote bei Agenten grundsätzlich schlechter wirken. Die Umstellung auf Schritt 2 kostet aber nichts und beseitigt nebenbei den fehlenden Endpunkt.

Was schiefgehen kann: vier Muster
#

Nancy Leveson hat für die Sicherheitsanalyse technischer Systeme vier Muster benannt (System-Theoretic Process Analysis, kurz STPA). Sie lassen sich auf einen Agenten übertragen.

MusterBeim AgentenWas dagegen wirkt
Eine Handlung, die niemand bestellt hatEr ändert eine Datei außerhalb des AuftragsSchritt 1 und Schritt 3
Eine nötige Handlung unterbleibtEr meldet eine Abweichung nichtDie Abweichungszeile aus Schritt 2
Zu früh, zu spät, falsche ReihenfolgeEr übernimmt ein Ergebnis, bevor es geprüft istFreigabe nur durch einen Menschen, oder ein deterministischen Guard, nach der Prüfung
Zu kurz oder zu langEr arbeitet über das Ende des Auftrags hinausDer Endpunkt aus Schritt 2

Kann der Agent das überhaupt?
#

Ein Auftrag kann sauber formuliert und trotzdem falsch sein, nämlich dann, wenn er mehr verlangt, als der Agent zuverlässig leistet.

Der Agent, den ich nutze, verarbeitet technisch bis zu 200.000 Token Kontext. Token sind die Textbausteine, in denen ein Sprachmodell rechnet. Nach meiner Beobachtung vom 23. September 2026 wird die Umsetzung aber schon spürbar oberhalb von 100.000 Token unzuverlässig. Der Agent stürzt dann nicht ab. Er gerät durcheinander.

Scheitert ein Auftrag an dieser Grenze, gibt es drei Auswege: den Auftrag kleiner schneiden, mehr Abweichung bewusst zulassen, oder ein anderes Werkzeug nehmen. Den Auftrag trotzdem erteilen und hoffen gehört nicht dazu.

Ich schneide kleiner. Ein Auftrag, eine Datei, ein Zweck.

So mache ich das
#

So entwickle ich OTSM, meine Plattform für Anforderungen, Risikoanalyse und Nachweise:

  • Ein Agent, der selbstständig Änderungen einreicht, hat ein eigenes Konto. Es schreibt nur in einen eigenen Bereich für Vorschläge und kann nichts zusammenführen. Der Hauptstand ist geschützt. Zusammenführen und Versionsmarke setzt nur ein Mensch, über ein Skript.
  • Der Agent, der mit mir am Code arbeitet, schreibt Dateien. In den Bestand übernommen wird eine Änderung erst von mir, nach der Prüfung.
  • Jeder Auftrag endet mit demselben Schlussblock: genau die genannten Dateien schreiben, Ende mit dem Schreiben und der Ergebnismeldung, die Prüfung läuft danach bei mir.
  • Abweichungen werden benannt und kommen als eigene Zeile zurück.
  • Seit dem August 2026 läuft vor jeder Übernahme eine statische (deterministische) Prüfung mit eigenen Regeln. Ein Verstoß gegen die Regeln blockiert die Übernahme. Das gilt für den Agenten genauso wie für mich.
  • Ein geschützter Rechenkern lässt sich nur mit einem ausdrücklichen Schalter ändern. Das hinterlässt eine Spur.

Der Test für Ihren Betrieb
#

Dieser Abschnitt richtet sich an Sie, wenn Sie ein Unternehmen oder eine Entwicklung leiten und KI-Agenten an Code oder Systemen arbeiten lassen.

Die Behauptung: Wenn Ausreißer eines Agenten von einer zu weiten Wand und einem unklaren Auftrag kommen, dann senken die vier Schritte die Zahl der Änderungen außerhalb des Auftrags.

Schritt 1 prüfen Sie durch einen Versuch. Geben Sie mit dem Konto des Agenten eine Änderung frei. Der Versuch muss scheitern.

Die Schritte 2 bis 4 prüfen Sie durch Zählen:

  • Messgröße: je Auftrag die Zahl der geänderten Dateien, die im Auftrag nicht genannt waren. Sobald der Agent ein eigenes Konto hat, lässt sich das aus der Änderungshistorie auszählen.
  • Ausgangswert: die ersten 20 Aufträge nach Schritt 1, noch ohne die Schritte 2 bis 4.
  • Zielwert (mein Vorschlag): Halbierung in den folgenden 20 Aufträgen oder nach vier Wochen, je nachdem, was zuerst eintritt.
  • Abbruchkriterium: Halbiert sich die Zahl nicht, liegt die Ursache woanders. Der erste Kandidat sind zu große Aufträge, siehe oben.

Der Preis, wenn Sie nichts tun: Ohne Wand und ohne Prüfung bleiben zwei Möglichkeiten. Sie lesen jede Änderung des Agenten vollständig von Hand, dann ist der Zeitgewinn weg. Oder Sie lesen nicht, dann entscheidet der Agent, was in Ihr Produkt kommt.

Wo die Methode aufhört
#

Sie sieht nur, was festgelegt wurde. Ein Weg, den niemand als Weg erkannt hat, bleibt unsichtbar: der Netzzugang, die Quellen für Softwarepakete, die Kommandozeile. Bei mir hat ein Befehl, der Werkzeuge bei Bedarf aus dem Netz nachlädt, dreimal die installierten Entwicklungswerkzeuge eines Projekts zerstört (Stand 5. Juni 2026). Seitdem ist dieser Befehl gestrichen, für den Agenten und für mich.

Sie prüft den Umfang, nicht die Güte. Dass der Agent im Auftrag geblieben ist und alle Regeln bestanden hat, sagt nichts darüber, ob die Lösung fachlich gut ist. Diese Beurteilung bleibt bei einem Menschen.

Wie es weitergeht
#

Zwei weitere Beiträge wenden dieselben vier Begriffe an: auf Server, deren Zustand festgelegt und bei jedem Lauf nachgeprüft wird, und auf Programmierregeln, von denen jede eine Prüfung oder einen Namen trägt.