Ein Chatbot beantwortet Fragen. Ein Agent geht einen Schritt weiter: Er plant Aktionen, nutzt Tools, greift auf Daten zu und führt Arbeitsschritte aus. Genau darin liegt der Produktivitätshebel – und gleichzeitig das Risiko. Denn sobald ein System nicht nur textet, sondern Tickets erstellt, Daten ändert oder Bestellungen auslöst, entscheidet die technische Einbettung über Sicherheit, Qualität und Nachvollziehbarkeit.
Im Unternehmenskontext lohnt sich ein nüchterner Blick: Welche Agenten-Architektur passt zu welchem Prozess? Wie werden Berechtigungen und Datenzugriffe gestaltet? Und welche Leitplanken verhindern, dass „autonom“ in „unkontrolliert“ kippt?
Was KI-Agenten von Chatbots unterscheidet
Planen, ausführen, überprüfen: der Agenten-Zyklus
Ein Agent durchläuft typischerweise einen wiederholten Zyklus: Ziel verstehen, Teilaufgaben ableiten, passende Tools auswählen, Ergebnisse prüfen und bei Bedarf nachsteuern. In der Praxis ist das weniger „Magie“ als ein orchestrierter Ablauf, der mehrere Komponenten kombiniert: ein Sprachmodell für Entscheidungen, Tool-Adapter für Aktionen, sowie Zustands- und Speichermechanismen.
Entscheidend ist, dass Agenten nicht nur eine Antwort erzeugen, sondern Tool-Calls auslösen – beispielsweise eine Datenbankabfrage, das Erstellen eines CRM-Datensatzes oder das Anstoßen eines CI-Jobs. Genau diese Fähigkeit muss im Design kontrollierbar gemacht werden.
Autonomie ist ein Spektrum, kein Schalter
„Voll autonom“ ist selten sinnvoll. In Unternehmen ist Autonomie ein abgestuftes Modell: von Vorschlägen (Agent empfiehlt Schritte) über teilautomatisierte Ausführung (Agent darf bestimmte Tools nutzen) bis zur vollständig automatischen Bearbeitung in klar begrenzten Workflows. In frühen Phasen ist ein „Human-in-the-Loop“ meist der produktivere Weg, weil er sowohl Qualität als auch Akzeptanz sichert.
Architektur-Bausteine: so werden Agenten betrieblich handhabbar
Orchestrierung, Tools und Zustandsverwaltung
Ein wartbarer Agent ist modular. Übliche Bausteine:
- Agent Orchestrator: steuert den Ablauf (Planung, Tool-Auswahl, Iterationen, Abbruchbedingungen).
- Tool-Layer: klar definierte Schnittstellen zu Systemen (z. B. ITSM, ERP, CRM, DWH).
- Zustand: Gesprächskontext, Zwischenresultate, Aufgabenstatus, Idempotenz-Informationen.
- Policy-/Guardrail-Layer: Regeln, welche Tools in welchem Kontext erlaubt sind.
- Observability: Logging, Tracing, Metriken, Alerts, Audit.
Gerade der Zustands-Teil wird unterschätzt: Ohne Task-State entstehen doppelte Aktionen (z. B. Ticket mehrfach anlegen) oder schwer reproduzierbare Fehlerbilder. Ein stabiler Agent benötigt daher explizite Statusmodelle (z. B. „geplant“, „ausgeführt“, „bestätigt“, „fehlgeschlagen“).
Tool-Design: klein, deterministisch, testbar
Tools sollten eng zugeschnitten sein. Ein Agent, der „beliebige SQL ausführen“ darf, ist kaum kontrollierbar. Besser sind spezialisierte Funktionen: „Kundenticket anlegen“, „Status abfragen“, „Liefertermin prüfen“. Diese Tools liefern strukturierte Antworten und erzwingen Validierungen. So wird der Agent in Richtung deterministischer Handlungen geführt, statt kreative Freiheiten im produktiven System zu bekommen.
Speicher: was dauerhaft, was nur situativ ist
Agenten wirken oft „intelligent“, weil sie sich Dinge merken. Praktisch gibt es verschiedene Speicherarten: kurzfristiger Kontext (nur für die aktuelle Aufgabe), Projektspeicher (z. B. Produktkatalog, Prozesswissen) und persönlicher Speicher (z. B. Präferenzen eines Nutzers). Gerade persönlicher Speicher ist heikel: Er erfordert klare Regeln, wer was speichern darf und wie Löschung/Änderung umgesetzt wird. Für sensible Inhalte ist ein Ansatz aus Datenminimierung bei GenAI oft der stabilere Default.
Risiken: typische Fehlerbilder und wie sie kontrolliert werden
Falsche Aktionen sind teurer als falsche Antworten
Eine ungenaue Textantwort ist ärgerlich. Eine ungenaue Aktion kann Kosten auslösen, Daten beschädigen oder Compliance-Risiken erzeugen. Daher braucht ein Agent eine Trennung zwischen „denken“ und „handeln“: Planung darf frei sein, Ausführung muss streng sein. Praktisch heißt das: jede Aktion wird gegen Policies geprüft, Parameter werden validiert, und für kritische Schritte wird eine Bestätigung benötigt.
Berechtigungen: Agenten dürfen nicht „mehr“ als Nutzer
Ein häufiger Architekturfehler ist ein Agent, der mit einem generischen Super-Account arbeitet. Besser ist das Prinzip „least privilege“: Der Agent agiert im Kontext des anfragenden Nutzers oder in eng begrenzten Service-Rollen. Zusätzlich helfen technische Leitplanken wie Netzwerksegmentierung, erlaubte Tool-Listen pro Use Case und explizite Deny-Regeln für irreversible Aktionen.
Prompt-Injection und Tool-Missbrauch
Sobald ein Agent externe Texte verarbeitet (E-Mails, Webseiten, PDFs), besteht das Risiko, dass Inhalte den Agenten zu unerwünschten Tool-Calls drängen. Schutz entsteht durch mehrschichtige Kontrolle: strikte Tool-Schemas, Policy-Prüfungen vor jedem Call, und eine klare Trennung zwischen „untrusted input“ und operativen Entscheidungen. Sensible Daten sollten zudem vor Weitergabe an Modelle reduziert oder redigiert werden; dafür ist PII-Redaktion für GenAI ein zentraler Baustein.
Entscheidungshilfe: welche Agenten-Form passt zum Prozess?
Von Skript-Automation bis Multi-Agent
Nicht jeder Prozess braucht einen komplexen Multi-Agenten-Verbund. Häufig sind die einfacheren Varianten robuster:
| Variante | Geeignet für | Stärken | Grenzen |
|---|---|---|---|
| Geführter Assistent | Wissensarbeit mit Nutzerfreigabe | Hohe Kontrolle, gute Akzeptanz | Weniger Automatisierung |
| Single-Agent mit Toolset | Klare, wiederkehrende Aufgaben | Einfacher Betrieb, gut testbar | Komplexität steigt bei vielen Systemen |
| Workflow-orchestriert | Prozesse mit festen Schritten | Determinismus, Auditierbarkeit | Weniger flexibel bei Ausnahmen |
| Multi-Agent (Rollen) | Recherche, Planung, Verhandlung von Teilzielen | Bessere Spezialisierung | Schwerer zu debuggen, mehr Kosten |
In der Praxis ist „workflow-orchestriert + LLM an den richtigen Stellen“ oft der Sweet Spot: Der Prozess bleibt kontrollierbar, während das Modell für Klassifikation, Zusammenfassung oder Entscheidungsunterstützung eingesetzt wird.
Eine kurze Entscheidungslogik für den Einstieg
- Wenn der Prozess wenige Schritte hat und Fehler teuer sind: geführter Assistent mit Bestätigung.
- Wenn es klare Aktionen in mehreren Systemen gibt: Single-Agent mit eng definierten Tools.
- Wenn es ohnehin BPM/Runbooks gibt: Workflow-orchestriert, LLM als „Copilot“ pro Schritt.
- Wenn viele Teilprobleme parallel gelöst werden müssen: Multi-Agent, aber mit strikten Grenzen und Observability.
Betrieb & Qualität: was im Alltag entscheidet
Beobachtbarkeit: Audit-Trail statt Bauchgefühl
Agenten brauchen nachvollziehbare Spuren: Welche Eingaben kamen rein? Welche Zwischenschritte wurden geplant? Welche Tools wurden mit welchen Parametern aufgerufen? Ohne diese Daten ist Debugging praktisch nicht möglich und Governance leidet. Wichtig ist ein Audit-Trail pro Task, der fachlich interpretierbar bleibt (z. B. „Ticket angelegt“ statt nur „HTTP 200“).
Tests: Agenten benötigen andere Teststrategien als klassische Software
Ein Agent ist kein reiner Funktionscode. Trotzdem muss das System testbar sein: Tool-Contracts, Policy-Checks, Idempotenz, Abbruchlogik. Für die Modellkomponente ist reproduzierbares Testen schwieriger, aber nicht optional. Praktisch helfen feste Testfälle mit erwartbaren Outcomes, Stubs für Tool-Responses und Regressionstests auf Prompt- und Policy-Ebene. Für eine strukturierte Vorgehensweise passt LLM-Evaluierung im Unternehmen als Anschluss.
Rollout-Strategie: schrittweise Freigaben
Agenten sollten nicht „big bang“ ausgerollt werden. Bewährt hat sich ein Stufenmodell: erst nur Leserechte und Vorschläge, dann ausgewählte Aktionen mit Freigabe, anschließend begrenzte Autonomie in einem klaren Korridor. Technisch lässt sich das über Feature-Flags für GenAI absichern, um Funktionen pro Team/Use Case kontrolliert zu aktivieren.
Praktische Schrittfolge für den ersten produktiven Agenten
Ein minimal lebensfähiger Agent ist bewusst klein, aber vollständig durchdacht. Die folgenden Schritte helfen, Komplexität zu begrenzen und trotzdem echten Nutzen zu liefern:
- Ziel präzisieren: ein Prozess, ein klarer Outcome, definierte Erfolgskriterien.
- Systemgrenzen festlegen: welche Systeme sind in Scope, welche explizit nicht.
- Toolset designen: 3–8 kleine Tools mit validierten Parametern, keine „Allzweck“-Tools.
- Guardrails definieren: erlaubte Aktionen, Deny-Listen, Freigabepunkte, Abbruchbedingungen.
- Task-State modellieren: Status, Idempotenz-Schlüssel, Wiederholungslogik.
- Logging/Audit bauen: pro Task alle Tool-Calls, Entscheidungen und Ergebnisse nachvollziehbar ablegen.
- Pilotieren: kleine Nutzergruppe, echte Fälle, Feedbackschleifen; erst danach erweitern.
Organisatorische Leitplanken: Verantwortlichkeiten und Freigaben
Rollen und Zuständigkeiten für Agenten-Änderungen
Agenten ändern Verhalten häufig über Prompts, Policies, Tool-Konfiguration und Modelle. Ohne klare Zuständigkeiten entstehen Schattenänderungen. Sinnvoll ist eine Aufteilung in fachliche Verantwortung (Prozess, Regeln), technische Verantwortung (Tooling, Betrieb), sowie Security/Compliance (Policies, Audits). Für strukturierte Verantwortungsmodelle ist RACI für GenAI-Teams eine passende Vertiefung.
Datenzugriff braucht Klassifizierung und klare Regeln
Agenten sind datenhungrig, aber nicht jeder Datenbereich ist geeignet. Datenklassifizierung und Zugriffspolicies sollten vor dem Produktivgang geklärt sein: Welche Dokumente darf der Agent lesen? Welche Felder darf er schreiben? Welche Daten dürfen im Kontext gespeichert werden? Ein konsistenter Rahmen reduziert spätere Reibung und verhindert unkontrollierte Datennutzung.
Wenn Agenten als kontrollierte Ausführungsinstanz verstanden werden – mit kleinen Tools, klaren Berechtigungen, belastbarem Audit und schrittweisem Rollout – lassen sich robuste Automatisierungen aufbauen, ohne die Organisation in ein Experiment zu zwingen. Dann entsteht der eigentliche Mehrwert: weniger manuelle Übergaben, schnellere Durchlaufzeiten und Prozesse, die auch unter realen Bedingungen stabil bleiben.
