Agentic AI

Ein System, das ein Ziel statt einer Schrittfolge bekommt. Der Agent nimmt seine Umgebung wahr (Dokumente, Tickets, Systemzustände), schlussfolgert, plant Schritte, führt sie über Werkzeuge aus und prüft sein eigenes Ergebnis — in einer Schleife, bis das Ziel erreicht ist oder eine Regel ihn stoppen lässt. Der Unterschied zum RPA-Bot ist fundamental: Der Bot spielt ein Drehbuch ab; der Agent schreibt sich seines für jeden Fall selbst — innerhalb der Grenzen, die ihm gesetzt wurden.

Drei Stufen der Selbstständigkeit. Der Chatbot antwortet, wenn man ihn fragt — er handelt nicht. Der Copilot arbeitet einem Menschen zu, der jede Aktion selbst ausführt. Der Agent führt selbst aus und meldet sich, wenn er fertig ist oder nicht weiterkommt. Die Grenze verläuft bei der Frage: Wer legt die Schritte fest? Wählt das System Weg und Werkzeuge selbst, ist es ein Agent — und braucht Identität, Grenzen und ein Protokoll. Wie viel es ohne Freigabe ausführen darf, ist eine eigene Entscheidung (siehe Autonomiestufen). Produktnamen folgen dieser Einteilung nicht: Auch in „Copilot“-Produkten entstehen heute Agenten.

Die Hände des Agenten. Ein LLM allein kann nur Text erzeugen — Tools geben ihm definierte Fähigkeiten: eine SAP-Buchung anlegen, einen UiPath-Roboter starten, eine Datenbank abfragen, eine E-Mail senden. Beim Function Calling beschreibt man dem Modell jedes Werkzeug mit Name, Zweck und Parametern; das Modell entscheidet, wann es welches mit welchen Werten aufruft. Das Model Context Protocol (MCP) vereinheitlicht, wie Systeme dem Agenten ihre Werkzeuge anbieten — seit Dezember 2025 herstellerneutral unter dem Dach der Linux Foundation; das Protokoll A2A regelt, wie Agenten einander Aufgaben übergeben. Die Tool-Schicht ist zugleich die wichtigste Kontrollfläche: Was nicht als Tool freigegeben ist, kann der Agent nicht tun. Allzweck-Werkzeuge wie Bildschirmsteuerung („Computer Use“), Browser oder Code-Ausführung öffnen dagegen alles, was das Konto des Agenten darf — sie brauchen ein eigenes, eng berechtigtes Konto und eine abgeschottete Umgebung.

Das Prinzip, das Autonomie unternehmenstauglich macht: An definierten Stellen übergibt der Agent an einen Menschen — bei Beträgen über der Schwelle, bei niedriger Konfidenz, bei allem, was die Policy als kritisch markiert. Gut gebaut heißt das nicht „ein Mensch schaut alles an“, sondern: Ausnahmen landen in einer Queue mit SLA, mit dem Fall, der Begründung des Agenten und seinem Vorschlag. Der Mensch entscheidet die 5 %, die Urteilskraft brauchen — statt die 95 % abzutippen, die keine brauchen.

Die Leitplanken, innerhalb derer ein Agent handeln darf — als Code, nicht als Absichtserklärung: Buchungslimits, verbotene Aktionen, Freigabepflichten, Datenklassen, die er nicht anfassen darf. Der entscheidende Punkt ist, wo die Regeln durchgesetzt werden: nicht im Prompt (den ein Modell missverstehen kann), sondern in der Tool-Schicht und der Plattform, wo Eingaben sie nicht aushebeln können. Geändert werden sie wie Software — per Review und Pull Request, mit Versionsgeschichte.

Wichtig: Grenzen begrenzen den Schaden, sie verhindern Fehler nicht — innerhalb seiner Grenzen kann ein getäuschter Agent weiter falsch handeln. Deshalb gehören Prüfungen und menschliche Freigaben für heikle Fälle dazu.

Das derzeit wichtigste Sicherheitsrisiko agentischer Systeme: Anweisungen, die in den Inhalten stecken, die ein Agent verarbeitet — in einer Mail, einem PDF, einer Webseite, einem Dokument aus der Wissensbasis oder der Beschreibung eines fremden MCP-Servers. Sprachmodelle können Anweisungen und Daten nicht zuverlässig trennen; ein präparierter Satz kann den Agenten vom Ziel abbringen oder Daten hinaustragen lassen. OWASP führt Prompt Injection an erster Stelle seiner Top 10 für LLM-Anwendungen, und Sicherheitsbehörden wie das britische NCSC halten das Problem für nicht vollständig lösbar.

Der professionelle Umgang: nicht auf Erkennung allein setzen, sondern begrenzen, was ein getäuschter Agent anrichten kann — eng geschnittene Werkzeuge, Grenzen in der Tool-Schicht, Freigaben für heikle Aktionen, nur geprüfte Quellen und Server und Angriffsfälle in den Evals.

Wenn Software selbstständig handelt, muss nachvollziehbar sein, wer gehandelt hat. Deshalb bekommt jeder Agent eine eigene Identität im Identitätssystem des Unternehmens — Microsoft Entra Agent ID oder Okta führen Agenten inzwischen als eigene Identitätsart —, mit einer verantwortlichen Person und nie als geteilten Service-Account. Dazu gehören eng gescopte Berechtigungen und kurzlebige Tokens (Minuten statt Monate): Kompromittierte Zugänge verfallen von selbst, Access-Reviews und Entzug funktionieren wie bei menschlichen Mitarbeitern. Agenten-Identität ist der Punkt, an dem KI-Betrieb und Security-Organisation zusammenkommen.

Das lückenlose Protokoll des Agenten-Handelns: jede Wahrnehmung, jede Entscheidung samt Begründung, jeder Tool-Aufruf, jedes Ergebnis — unveränderlich gespeichert und idealerweise hash-verkettet, sodass nachträgliche Manipulation auffällt. Der Audit-Trail beantwortet die Frage, die Revision, Regulator und der eigene Vorstand stellen werden: Warum hat das System das getan? Er ist außerdem das beste Werkzeug für die eigene Fehleranalyse — man kann jeden Fall Schritt für Schritt nachspielen.

In Multi-Agent-Systemen zerlegt ein orchestrierender Agent die Aufgabe und delegiert an Spezialisten — einer recherchiert, einer prüft, einer schreibt die Antwort; über das Protokoll A2A auch über Herstellergrenzen hinweg. Das lohnt sich, wenn sich eine Aufgabe in unabhängige Teile zerlegen lässt. Bei eng verzahnten, schrittweisen Abläufen ist ein einzelner Agent mit guten Werkzeugen oft zuverlässiger und günstiger — jede Übergabe kostet Rechenzeit und kann Fehler vervielfachen. Deshalb mit einem Agenten beginnen und erst aufteilen, wenn Evals den Nutzen zeigen. Mehrere Agenten vervielfachen zudem die Governance-Fragen: Jeder Agent braucht Identität, Scope und Protokoll, und die Übergaben zwischen ihnen gehören genauso in den Audit-Trail wie die Aktionen selbst — und sind wie fremde Eingaben zu prüfen.

Eine Treppe, keine Schwelle: L0 manuelle Arbeit · L1 skriptbasierte Automatisierung (RPA) · L2 intelligente Automatisierung (ML im Prozess) · L3 assistierte Agenten (der Agent schlägt vor, der Mensch bestätigt jede Aktion) · L4 kontrollierte Autonomie (der Agent handelt in Grenzen, der Mensch überwacht per Ausnahme). Der Weg nach oben ist kein Technologie-, sondern ein Vertrauensaufbau: Man steigt pro Prozess genau dann eine Stufe, wenn Evals, Audit-Trail und Ausnahmequoten es rechtfertigen — nicht früher.

Die Stufen sind ein Reifemodell für Prozesse, keine Norm; andere Modelle zählen anders. Gemeinsam ist allen: Wie selbstständig ein Agent handeln darf, ist eine Entscheidung je Fallgruppe, keine Eigenschaft des Modells.