Ein Agent, der handelt - und bei dem nachvollziehbar bleibt, wer was ausgelöst hat? WZ-IT baut Agenten mit definierten Werkzeugen, Freigaben an den kritischen Stellen und vollständigem Protokoll. KI-Agenten ansehen · KI-Agenten erweitern
Bei einem Assistenten, der nur antwortet, ist der schlimmste Fehler eine falsche Auskunft. Bei einem Agenten, der handelt, ist er eine falsche Aktion in einem produktiven System - und die war nicht vorhergesagt, weil der Agent seinen Weg zur Laufzeit selbst wählt. Dieser Artikel behandelt die Fragen, die in Agentenprojekten zu spät gestellt werden: unter wessen Konto gehandelt wird, was der Agent überhaupt anfassen darf, wo ein Mensch zustimmen muss und was am Ende im Protokoll steht. Stand Oktober 2026.
Inhaltsverzeichnis
- Chatbot, Workflow, Agent: der Unterschied ist die Route
- Unter wessen Konto handelt der Agent?
- Werkzeugkatalog statt Vollzugriff
- Wo ein Mensch zustimmen muss
- Was ins Protokoll gehört
- MCP: die Schnittstelle, die den Modellwechsel überlebt
- Was der Rechtsrahmen verlangt
Chatbot, Workflow, Agent: der Unterschied ist die Route
Die drei Begriffe werden im Marketing durcheinandergeworfen, obwohl sie unterschiedliche Risiken tragen. Die trennscharfe Frage ist nicht, wie klug das System wirkt, sondern wer den Weg bestimmt.
Ein Chatbot antwortet aus vorhandenen Inhalten und verändert nichts. Es gibt keinen Weg, nur eine Antwort. Ein Fehler ist eine falsche Auskunft: ärgerlich, aber umkehrbar.
Ein Workflow führt eine Kette von Schritten aus - Ticket anlegen, Mail senden, Datensatz schreiben. Den Ablauf haben Sie vorher festgelegt; das Modell füllt höchstens Felder. Ein Fehler bricht den Ablauf ab oder schreibt falsche Werte, ist aber reproduzierbar und damit reparierbar.
Ein Agent entscheidet innerhalb gesetzter Grenzen selbst, welche Werkzeuge er in welcher Reihenfolge benutzt. Sie setzen die Grenzen, nicht die Route. Ein Fehler ist eine Aktion, die niemand vorhergesagt hat.
Das ist keine akademische Unterscheidung, sondern die Grundlage der Aufwandsschätzung. Ein erheblicher Teil dessen, was als Agentenprojekt angefragt wird, ist in Wahrheit ein Workflow - und das ist eine gute Nachricht: billiger, schneller fertig, leichter zu prüfen. Die ehrliche Einordnung gehört ins erste Gespräch, nicht ins Nachtragsangebot.
Unter wessen Konto handelt der Agent?
Ein Agent, der handelt, braucht eine Identität im Zielsystem. Welche das ist, entscheidet darüber, was ein einzelner Benutzer über ihn auslösen kann - und diese Frage fehlt in den meisten Anforderungslisten.
Ein Dienstkonto für alles. Der Agent bekommt ein technisches Konto mit allen Rechten, die er je brauchen könnte. Das ist schnell eingerichtet und schafft eine Vereinigungsmenge: Jeder Benutzer kann über den Agenten mittelbar alles auslösen, wozu das Dienstkonto berechtigt ist, auch das, wozu er selbst nicht berechtigt wäre. Wer den Agenten bittet, „den Vorgang zum Kollegen Müller zu prüfen", bekommt möglicherweise eine Antwort, die er selbst nie hätte abrufen dürfen. Vertretbar ist das nur, wenn der Agent ausschließlich Dinge tut, die ohnehin jeder auslösen darf.
Die Identität des Anfragenden durchreichen. Der Agent handelt im Namen des Benutzers, der ihn angestoßen hat, und erbt dessen Rechte im Zielsystem. Wer selbst kein Ticket in dieser Queue anlegen darf, kann es auch über den Agenten nicht. Das ist aufwendiger, weil das Zielsystem delegierte Identitäten unterstützen muss - und es ist der Regelfall, weil die Rechte dort bleiben, wo sie ohnehin gepflegt werden. Sie verwalten keine zweite Berechtigungswelt neben Ihrem Verzeichnisdienst.
Ein getrenntes Konto je Aufgabe. Für Aktionen, die niemand persönlich auslöst - nächtliche Läufe, Systemwartung - bekommt der Agent ein eigenes, eng geschnittenes Konto pro Aufgabe statt eines allmächtigen. Ein Konto, das Backups prüfen darf, muss keine Rechnungen freigeben können.
In der Praxis kommen alle drei vor. Der Fehler ist nicht, ein Dienstkonto zu benutzen - der Fehler ist, es zu benutzen, ohne die Vereinigungsmenge ausgerechnet zu haben.
Werkzeugkatalog statt Vollzugriff
Ein Agent ohne Werkzeuge ist ein Chatbot. Die Frage ist, wie viel Fläche die Werkzeuge freigeben.
Der bequeme Weg ist ein breiter Zugang - ein Datenbankbenutzer, ein API-Token mit vollem Umfang - und die Hoffnung, dass sich das Modell benimmt. Das ist dieselbe Konstruktion wie die Prompt-Anweisung bei RAG-Systemen und scheitert aus demselben Grund: Eine Bitte ist keine Grenze.
Die tragfähige Konstruktion ist ein benannter Werkzeugkatalog: eine Liste erlaubter Operationen mit definierten Parametern. „Ticket in Queue X anlegen" ist ein Werkzeug, „SQL ausführen" ist keines. Was nicht im Katalog steht, existiert für den Agenten nicht.
Drei Eigenschaften machen einen Katalog belastbar:
Eng geschnittene Operationen. Je enger das Werkzeug, desto kleiner der Schaden bei Missbrauch und desto besser die Auswertbarkeit. Zehn spezifische Werkzeuge sind besser als eines mit zehn Parametern.
Schreibende Werkzeuge sind selten. Der überwiegende Teil eines Katalogs sollte lesend sein. Jedes schreibende Werkzeug ist eine bewusste Entscheidung mit eigener Begründung.
Die Rechteprüfung bleibt im Zielsystem. Ein Werkzeug ruft die reguläre Schnittstelle auf, nicht die Datenbank dahinter. Damit greifen die Prüfungen, die im Zielsystem ohnehin existieren - und Sie pflegen keine zweite Rechtelogik im Agenten.
Wo ein Mensch zustimmen muss
Menschliche Aufsicht lässt sich nicht nachrüsten. Sie entsteht daraus, dass bestimmte Schritte eine Freigabe brauchen und dass jemand benannt ist, der sie erteilt. Das gehört in die Architektur, nicht in eine Richtlinie.
Die praktikable Abgrenzung: Eine Freigabe braucht alles, was nach außen wirkt oder nicht ohne Aufwand rückgängig zu machen ist.
- Nachrichten an Kunden, Lieferanten oder Behörden
- Änderungen an Stammdaten
- Geldflüsse jeder Art
- Löschungen
- Statuswechsel mit Vertragsfolge
Die Faustregel für den Grenzfall: Wenn Sie den Fehler nicht in fünf Minuten selbst beheben können, gehört eine Freigabe davor.
Zwei Konstruktionsfehler treten dabei regelmäßig auf. Der erste ist die Freigabe als Formalie - ein Dialog, der so oft erscheint, dass er weggeklickt wird. Wenn ein Freigabeschritt zehnmal am Tag auftritt, ist er falsch geschnitten; dann gehört die Aktion in einen Workflow mit festen Regeln statt in einen Agenten. Der zweite ist die Freigabe ohne Kontext: Wer zustimmen soll, muss sehen, was der Agent tun will und woraus er das ableitet - nicht nur einen Werkzeugnamen.
Was ins Protokoll gehört
Was nicht mitgeschrieben wurde, lässt sich später nicht nachweisen. Bei einem Agenten reicht das übliche Anwendungsprotokoll nicht, weil zwei Angaben fehlen, die auseinanderfallen können: wer ausgelöst hat und unter welcher Identität ausgeführt wurde.
Ein brauchbarer Eintrag hält fest: Auslöser, ausführende Identität, benutztes Werkzeug, übergebene Parameter, Ergebnis, und bei kritischen Schritten die Person, die freigegeben hat. Dazu der Lauf als Ganzes - welche Werkzeuge in welcher Reihenfolge -, damit sich eine Entscheidungskette rekonstruieren lässt statt nur ihr letztes Glied. Langfuse zeichnet solche Läufe als Traces auf und ist der übliche Baustein dafür im offenen Stack.
Das Protokoll gehört auf Ihre Infrastruktur. Ein Anbieter, der die Läufe für sich auswertet, ist bei internen Vorgängen keine Option - und im Streitfall nützt Ihnen ein Protokoll wenig, auf das Sie keinen unmittelbaren Zugriff haben.
MCP: die Schnittstelle, die den Modellwechsel überlebt
Das Model Context Protocol ist ein offener Standard, über den ein Modell Werkzeuge und Datenquellen einheitlich anspricht. Der Nutzen ist weniger technischer als wirtschaftlicher Natur: Ein einmal gebauter Anschluss an Ihr Ticketsystem bleibt nutzbar, wenn Sie das Modell darunter austauschen. Angesichts der Geschwindigkeit, mit der Modelle wechseln, ist diese Entkopplung der eigentliche Gewinn.
Zwei Einschränkungen gehören dazu. MCP standardisiert den Zugriffsweg, nicht die Berechtigung - wer welche Werkzeuge benutzen darf, entscheiden weiterhin Ihr Katalog und das Zielsystem. Und ein Standard entbindet nicht von der Frage, wem Sie einen Server anvertrauen: Ein fremder MCP-Server im eigenen Netz ist eine Zugriffsentscheidung wie jede andere.
Die Spezifikationsversion 2026-07-28 verschiebt dabei einiges in Richtung Unternehmensbetrieb (Changelog). MCP ist zustandslos geworden: Es gibt keine Sitzung und keinen Verbindungsaufbau mehr, jede Anfrage trägt Protokollversion und Client-Fähigkeiten selbst, und Clients sollen sich bei jeder Anfrage ausweisen. Für die Rechtefrage wichtiger ist die offizielle Erweiterung Enterprise-Managed Authorization: Statt dass jeder Mitarbeitende jeden MCP-Server einzeln freigibt, entscheidet der Identity Provider des Unternehmens anhand von Gruppen und Richtlinien, wer welchen Server nutzen darf, und Zugänge werden dort auch zentral entzogen. Die einzelne Aktion prüft weiterhin das Zielsystem. Außerdem sind Roots, Sampling und Logging als veraltet markiert; sie funktionieren während einer Übergangsfrist von mindestens zwölf Monaten weiter, neue Server sollten sie aber nicht mehr einsetzen.
Wo bereits eine Schnittstelle existiert - Zammad, n8n, ERP, CRM -, ist sie meist der kürzere Weg. Eine Parallelwelt zu bauen, damit ein Agent damit reden kann, lohnt selten.
Was der Rechtsrahmen verlangt
Als Einordnung, nicht als Rechtsberatung - und mit dem Stand nach dem Digital Omnibus, der seit dem 27. Juli 2026 in Kraft ist.
Transparenz gilt bereits. Seit dem 2. August 2026 muss erkennbar sein, dass man mit einem KI-System interagiert. Für einen Agenten heißt das mehr als ein Hinweis im Chatfenster: Auch eine von ihm ausgelöste Aktion sollte als solche erkennbar bleiben. Eine Mail, die aussieht, als habe ein Mensch sie geschrieben, ist der Fehler.
Hochrisiko ist verschoben, nicht aufgehoben. Die Pflichten aus Anhang III gelten ab dem 2. Dezember 2027, die aus Anhang I ab dem 2. August 2028. Wer einen Agenten in Personalwesen, Kreditvergabe oder ähnlich eingestuften Bereichen plant, gewinnt Zeit - keine Entwarnung.
Aufsicht und Protokollierung sind Bauentscheidungen. Beides lässt sich nicht rückwirkend herstellen. Wer die Freigabestellen und das Protokoll von Anfang an richtig setzt, hat die Nachweise, wenn sie verlangt werden.
Die meisten Unternehmensagenten fallen nicht unter Hochrisiko, sondern unter Transparenz und Dokumentation. Welche Klasse für Ihren Fall gilt, klären Sie mit Ihrer Rechtsberatung; die technische Beschreibung, auf der diese Einschätzung aufsetzt, liefern wir.
Was das für Ihr Projekt heißt
Die drei Entscheidungen, die den Aufwand bestimmen, fallen vor der ersten Zeile Code: unter welcher Identität gehandelt wird, wie eng der Werkzeugkatalog geschnitten ist und wo eine Freigabe sitzt. Wer sie später trifft, baut zweimal.
Wie Berechtigungen in einem antwortenden System greifen, steht in RAG mit Berechtigungen - die Mechanik dort ist die Grundlage für alles, was ein Agent liest. Was Agenten und Automatisierung grundsätzlich leisten, ordnet KI-Agenten & Automatisierung ein, und die Pflichten im Überblick zeigt EU AI Act für Unternehmen. Wenn ein Agent auf interne Dokumente zugreift und Mitarbeiter ihn nutzen, kommt die Mitbestimmung dazu - dazu KI-Assistent und Betriebsrat.
