Was ist ein KI-Agent im Unternehmen?

Ein KI-Agent ist ein Sprachmodell, das Werkzeuge bedienen darf. Das Chatfenster, das viele aus dem Alltag kennen, erzeugt nur Text. Ein Agent kann darüber hinaus Dinge tun: ein Ticket lesen, eine Datei ändern, eine Abfrage ausführen. Er bekommt eine Aufgabe, plant Schritte, ruft Werkzeuge auf und bewertet das Ergebnis, bis die Aufgabe erledigt ist oder er nicht weiterkommt.

Der Unterschied ist derselbe wie zwischen einem Berater am Telefon und einem Mitarbeiter mit Schlüsselbund. Der eine sagt, was zu tun wäre. Der andere tut es. Deshalb ist die wichtigste Frage bei Agenten nicht, wie klug das Modell ist, sondern welche Schlüssel es bekommt.

Dieser Artikel erklärt, was Agenten von Assistenten unterscheidet, woher sie ihr Wissen beziehen und warum das Berechtigungsmodell vor dem Anwendungsfall kommt.

Assistent, Agent, Automatisierung: unterschiedliche Aufgaben

Die Begriffe beschreiben unterschiedliche Eigenschaften und können sich überschneiden [5].

• Ein Assistent unterstützt Menschen: Er liest, fasst zusammen und formuliert. Je nach Anbindung kann er auch Werkzeuge nutzen; welche Aktionen er selbst ausführt, legt das Berechtigungsmodell fest.
• Ein Agent handelt. Er führt Schritte selbst aus, innerhalb der Werkzeuge und Rechte, die man ihm gegeben hat.
• Eine Automatisierung führt definierte Abläufe aus, beispielsweise nach einem Zeitplan oder einem Ereignis. Sie kann KI nutzen, muss es aber nicht. Nutzen und Risiko hängen vom Ablauf und seinen Berechtigungen ab.

Beginnen Sie mit begrenzten Rechten und klaren Freigaben. Erweitern Sie die Selbstständigkeit erst anhand überprüfter Ergebnisse.

Woher der Agent seinen Kontext bekommt

Ein Sprachmodell weiß nichts über Ihr Unternehmen. Alles, was es über Ihre Tickets, Verträge oder Systeme sagen soll, muss ihm zur Laufzeit mitgegeben werden.

Dafür gibt es zwei verbreitete Wege. Beim ersten sucht ein vorgeschaltetes System die passenden Dokumente heraus und legt sie dem Modell mit der Frage vor; das Verfahren heißt Retrieval Augmented Generation, kurz RAG. Beim zweiten bekommt das Modell einen direkten, abgegrenzten Zugang zu einem System über eine definierte Schnittstelle. Ein offener Standard dafür ist das Model Context Protocol (MCP): Es beschreibt, wie ein Agent Werkzeuge findet, aufruft und deren Ergebnisse zurückbekommt [1].

Für die Praxis heißt das: Die Anbindung ist Infrastruktur. Sie wird gebaut, berechtigt und protokolliert wie jede andere Schnittstelle im Haus. Wie man MCP-Anbindungen absichert, steht im Artikel MCP absichern.

Was sich ändert, sobald er schreiben darf

Auch ein rein lesender Agent kann vertrauliche Daten offenlegen und erhebliche Schäden verursachen. Schreibrechte eröffnen zusätzliche Risiken: Ein Agent kann Tickets schließen, Code einreichen oder Berechtigungen vergeben [2].

Ein Beispiel. Ein Team gibt seinem Agenten Lesezugriff auf das Ticketsystem und Schreibzugriff auf das Repository, um kleine Korrekturen zu beschleunigen. Dann legt jemand von außen ein Ticket an, in dessen Text eine Anweisung steckt. Das Modell kann eine Anweisung im gelesenen Text mit dem Auftrag seines Betreibers verwechseln. Der Weg vom präparierten Ticket zur ausgeführten Änderung ist kurz, wenn keine Freigabestufe dazwischen liegt. Die wirksamste Gegenmaßnahme ist keine bessere Anweisung, sondern eine kleinere Berechtigung [2].

Das Berechtigungsmodell kommt vor dem Anwendungsfall

Die verlockende Reihenfolge ist: erst den nützlichen Fall bauen, dann absichern. Die tragfähige ist umgekehrt, aus einem einfachen Grund: Rechte, die einmal vergeben sind, werden selten wieder eingesammelt, weil inzwischen etwas darauf aufbaut.

Vier Fragen legen das Modell fest, bevor der erste Fall entsteht: Unter welcher Identität handelt der Agent, und ist sie von Personen unterscheidbar? Welche Werkzeuge bekommt er, und welche ausdrücklich nicht? Welche seiner Aktionen brauchen eine menschliche Freigabe? Und wo steht hinterher, was er getan hat?

Wer die Aktionen verantwortet

Für den Betrieb müssen Verantwortlichkeiten im Unternehmen festgelegt sein. Das NIST AI RMF beschreibt klare Rollen und Zuständigkeiten für den Umgang mit KI- Risiken. Wer im Einzelfall haftet, bestimmt dieses Rahmenwerk nicht [3].

Praktisch heißt das: Für jede Agentenaktion muss benennbar sein, wer sie verantwortet. Das erledigen drei Bausteine zusammen: die eigene Identität (die Aktion ist dem Agenten zuordenbar), die Freigabestufe (eine Person hat die kritische Aktion gebilligt) und das Protokoll (der Hergang ist rekonstruierbar). Fehlt einer der drei, ist die Antwort auf einen Vorfall Spekulation.

Beispiel: ein Agent im Ticketsystem

Ein typischer Fall. Ein Support-Team lässt einen Agenten eingehende Tickets vorsortieren: Kategorie zuordnen, Dubletten erkennen, eine Antwort vorschlagen. Der Agent hat Lesezugriff auf Tickets und eine eigene Identität. Die vorgeschlagene Antwort schickt er nicht selbst ab, sie erscheint als Entwurf, den eine Person freigibt.

Nach einiger Zeit zeigt das Protokoll, welche Vorschläge unverändert freigegeben werden und welche nicht. Erst auf dieser Grundlage entscheidet das Team, ob der Agent bestimmte Ticketklassen selbst beantworten darf. Die Entscheidung stützt sich auf überprüfte Ergebnisse und das Risiko der jeweiligen Aktion.

Was Sie danach entscheiden können

• Welche Aufgaben Ihr erster Anwendungsfall übernimmt und wie viel Selbstständigkeit dafür nötig ist.
• Welche vier Antworten Ihr Berechtigungsmodell geben muss, bevor die erste Anbindung entsteht.
• Woran Sie festmachen, wann ein Agent mehr Selbstständigkeit bekommt.

Häufige Fragen

Quellen

• Model Context Protocol: Introduction modelcontextprotocol.io
• OWASP Top 10 for LLM Applications OWASP GenAI Security Project
• AI Risk Management Framework NIST
• Künstliche Intelligenz: Informationen und Empfehlungen BSI
• Building effective agents Anthropic