KI-Agenten sind Programme, die auf Basis eines Sprachmodells eigenständig mehrere Arbeitsschritte planen und ausführen – etwa Daten abrufen, eine Schnittstelle aufrufen, ein Ergebnis bewerten und daraufhin den nächsten Schritt wählen. Genau diese Eigenständigkeit macht sie für Geschäftsprozesse interessant. Und genau sie macht sie schwer kontrollierbar.

Ein aktueller Bericht beschreibt das Problem mit einem anschaulichen Vergleich: Unternehmen setzen Agenten ein, als würden sie tausend Bankangestellte ohne Ausweis beschäftigen. Die Tätigkeiten laufen, aber niemand kann im Nachhinein zweifelsfrei sagen, wer was wann getan hat. Aufsichtsbehörden in der EU und den USA fordern eine Überwachung der Agentenaktivitäten in Echtzeit. Die gängigen Frameworks, mit denen solche Agenten gebaut werden, stellen die dafür notwendigen Daten nach dieser Darstellung jedoch nicht bereit.

Warum die Lücke entsteht

Die verbreiteten Agenten-Bibliotheken sind in erster Linie auf Funktionalität ausgelegt: Prompts verketten, Werkzeuge anbinden, Ergebnisse zurückgeben. Observability – also die Fähigkeit, den inneren Zustand eines Systems von außen anhand seiner Ausgaben zu beurteilen – war bei vielen dieser Projekte kein Entwurfsziel der ersten Stunde.

Dazu kommt eine strukturelle Eigenheit: Bei klassischer Software ist der Ablauf vorab festgelegt und damit protokollierbar. Ein Agent entscheidet den Ablauf zur Laufzeit. Ein Protokoll, das nur das Endergebnis festhält, verliert deshalb die eigentlich interessante Information – nämlich warum der Agent diesen Weg gewählt hat, welche Werkzeuge er aufgerufen hat und auf welche Daten er dabei zugegriffen hat.

Was in einem belastbaren Protokoll stehen sollte

Unabhängig von der konkreten Technologie lassen sich die Anforderungen an ein Agenten-Protokoll recht klar benennen. Wer ein solches Projekt startet, sollte diese Punkte früh klären:

  • Identität: Unter welcher technischen Identität handelt der Agent, und in wessen Auftrag? Ein Agent, der Aktionen unter einem geteilten Sammelkonto ausführt, ist im Nachhinein nicht zuordenbar.
  • Werkzeugaufrufe: Welche Schnittstellen, Datenbanken oder Dateien wurden mit welchen Parametern angesprochen – inklusive Zeitstempel und Rückgabestatus.
  • Entscheidungspfad: Welche Zwischenschritte führten zum Ergebnis? Ohne diese Spur lässt sich ein Fehlverhalten weder reproduzieren noch beheben.
  • Datenzugriffe: Welche personenbezogenen oder vertraulichen Daten hat der Agent verarbeitet und an welches Modell übermittelt?
  • Abbruch- und Eskalationspunkte: Wann wurde ein Vorgang gestoppt, und wer wurde informiert?

Entscheidend ist, dass diese Daten nicht nur irgendwo in einem Logfile landen, sondern auswertbar sind – strukturiert, mit einer durchgängigen Vorgangs-ID und mit einer Aufbewahrungsfrist, die zu den eigenen Compliance-Anforderungen passt.

Echtzeit ist eine andere Anforderung als Nachvollziehbarkeit

Die beiden Begriffe werden häufig vermischt, meinen aber Unterschiedliches. Nachvollziehbarkeit ist rückblickend: Sie beantwortet nach einem Vorfall die Frage, was passiert ist. Echtzeit-Überwachung ist vorausschauend: Sie soll einen Vorgang unterbrechen, bevor Schaden entsteht – etwa wenn ein Agent ungewöhnlich viele Datensätze abruft, in kurzer Zeit auffällig oft dieselbe Schnittstelle aufruft oder Berechtigungen nutzt, die er für seine eigentliche Aufgabe nicht braucht.

Technisch bedeutet das, dass Protokolldaten nicht erst am Ende eines Laufs geschrieben werden dürfen, sondern während der Ausführung an ein Monitoring-System fließen müssen. Dort braucht es Schwellenwerte, Alarmierung und – das ist der schwierigste Teil – einen funktionierenden Not-Aus, der einen laufenden Agenten tatsächlich stoppt und nicht nur eine Benachrichtigung verschickt.

Konsequenzen für die Architektur

Wenn die Frameworks die benötigten Daten nicht von sich aus liefern, verschiebt sich die Verantwortung in die Architektur des eigenen Projekts. Praktisch heißt das meist: Der Agent erhält keinen direkten Zugriff auf produktive Systeme, sondern arbeitet über eine eigene Zwischenschicht.

Diese Schicht – gelegentlich als Gateway oder Policy-Layer bezeichnet – übernimmt drei Aufgaben gleichzeitig. Sie authentifiziert den Agenten, sie prüft jede Aktion gegen hinterlegte Regeln, und sie schreibt das Protokoll. Der Vorteil: Die Protokollierung hängt nicht mehr davon ab, ob eine bestimmte Bibliothek sie unterstützt, und ein Wechsel des Frameworks oder des Modellanbieters lässt die Nachvollziehbarkeit unberührt.

Zusätzlich lohnt sich das Prinzip der minimalen Rechte, das aus der klassischen IT-Sicherheit bekannt ist: Ein Agent bekommt genau die Berechtigungen, die seine Aufgabe erfordert – befristet und, wo möglich, auf Lesezugriff beschränkt. Schreibende oder löschende Operationen werden entweder durch eine menschliche Freigabe abgesichert oder auf klar umrissene Datenbereiche begrenzt.

Was das für die Projektplanung heißt

Monitoring und Protokollierung werden in Agenten-Projekten häufig als Thema für die zweite Ausbaustufe behandelt. Das ist aus zwei Gründen riskant. Erstens lässt sich eine Protokollschicht nachträglich nur mit erheblichem Aufwand in eine gewachsene Agenten-Landschaft einziehen. Zweitens fehlt ohne sie in der Pilotphase genau die Datengrundlage, mit der sich beurteilen ließe, ob der Agent überhaupt zuverlässig arbeitet.

Sinnvoller ist der umgekehrte Weg: Zuerst entstehen Identität, Rechtemodell und Protokollierung, danach der erste produktive Anwendungsfall. Für die Auswahl von Werkzeugen und Dienstleistern ergibt sich daraus eine konkrete Prüffrage – welche Ereignisse das System von sich aus ausgibt, in welchem Format, und ob sich diese Daten in die bestehende Monitoring-Landschaft überführen lassen.

Einordnung

Für Web- und Softwareprojekte verschiebt sich damit ein Teil des Aufwands von der Funktion zur Kontrolle: Ein Agent, der Inhalte pflegt, Formulardaten verarbeitet oder in einer Entwicklungs-Pipeline mitarbeitet, braucht dieselbe Nachvollziehbarkeit wie ein Redaktionssystem mit Versionierung und Benutzerkonten. Wer Agenten einsetzen möchte, sollte Protokollierung, Rechtemodell und Abschaltmöglichkeit als Teil des Leistungsumfangs budgetieren und nicht als optionale Ergänzung. Das erhöht den Anfangsaufwand spürbar, ist aber die Voraussetzung dafür, solche Systeme später überhaupt in einen produktiven und prüfbaren Betrieb zu überführen.

Quellen