In Präsentationen sehen KI-Agenten beeindruckend aus. Sie lesen eine E-Mail, legen einen Vorgang an, prüfen einen Bestand, entwerfen eine Antwort und aktualisieren das CRM. Im eigenen Haus funktioniert derselbe Ablauf drei Wochen lang gut und scheitert dann an einem Fall, den niemand vorgesehen hat: Der Agent legt denselben Vorgang zweimal an, antwortet einem Kunden mit einem veralteten Preis, oder er bleibt in einer Schleife hängen, weil eine Schnittstelle nicht antwortet. Auffällig ist dabei weniger der Fehler selbst als die Tatsache, dass niemand ihn bemerkt hat.
Deshalb ist die interessante Frage nicht, was Agenten grundsätzlich können, sondern wo sie heute im Büroalltag tragfähig sind und welche Leitplanken dazugehören. Beides lässt sich nüchtern beantworten.
Assistent und Agent: der Unterschied ist die Aktion
Ein Assistent beantwortet Fragen. Ein Agent führt Schritte aus: Er ruft Funktionen auf, verändert Daten, versendet Nachrichten und arbeitet über mehrere Stationen hinweg. Mit der Aktion entsteht Risiko. Ein falscher Satz in einer Antwort ist ärgerlich; eine falsche Bestellung, die tatsächlich ausgelöst wurde, ist ein Geschäftsvorfall.
Daraus folgt eine einfache Bewertungsregel. Je irreversibler eine Aktion und je größer ihr Schaden, desto mehr muss der Agent als Vorschlagsmaschine arbeiten und der Mensch als Ausführer. Die technischen Leitplanken für solche Systeme haben wir unter KI in Geschäftsprozessen sicher einsetzen beschrieben.
Wo Agenten heute tragen
Tragfähig sind Aufgaben, die häufig vorkommen, textlastig sind, einen klaren Abschluss haben und sich rückgängig machen lassen. Beispiele aus der Praxis:
- Eingangspost sortieren: E-Mails klassifizieren, dem richtigen Vorgangstyp zuordnen und an die zuständige Stelle weiterleiten.
- Felder vorbefüllen: Aus Anhängen und Textfeldern einen Vorgang anlegen und Werte vorschlagen, die ein Mensch bestätigt.
- Belege abgleichen: Lieferscheine, Bestellungen und Rechnungen gegenüberstellen und Abweichungen melden, wie unter Dokumentenverarbeitung automatisieren beschrieben.
- Entwürfe erstellen: Antworten, Angebotstexte oder Statusberichte aus Vorlagen und Systemdaten vorbereiten.
- Prüflisten abarbeiten: Dokumente gegen Checklisten kontrollieren und fehlende Angaben auflisten.
- Recherche bündeln: Informationen aus mehreren Systemen zusammentragen und als Übersicht bereitstellen.
Gemeinsam ist allen Fällen: Der Nutzen entsteht aus Volumen und Wiederholung, und nachgelagert prüft immer ein Mensch. Der Agent ersetzt keine Fachentscheidung, er verkürzt den Weg dorthin. Bewährt hat sich dabei ein festes Antwortmuster: Vorschlag, Begründung in einem Satz, Belegstelle und der Hinweis, was fehlt. Wer diese vier Teile sieht, kann in Sekunden entscheiden. Fehlt die Belegstelle, wird jede Prüfung zur Recherche und der Zeitgewinn ist wieder aufgezehrt.
Voraussetzung für alle genannten Fälle ist ein beschriebener Prozess. Wer nicht sagen kann, welche Schritte, Entscheidungen und Ausnahmen ein Ablauf hat, kann ihn nicht automatisieren. Das System würde dann die sichtbaren Klickfolgen nachbilden und beim ersten Sonderfall abbrechen. Die Prozessbeschreibung ist deshalb der eigentliche Projektaufwand, nicht die technische Anbindung.
Wo sie noch nicht tragen
Schwierig wird es bei langen, verzweigten Prozessen über mehrere Systeme ohne verlässliche Schnittstellen. Ebenso bei Aufgaben, bei denen Erfolg subjektiv ist, oder bei Vorgängen mit unmittelbarer rechtlicher und finanzieller Wirkung. Praktische Grenzen sind:
- Prozesse ohne definierten Ausnahme- und Eskalationsweg,
- Systeme ohne stabile Schnittstelle, in denen nur über Oberflächen gearbeitet werden kann,
- Vorgänge mit Zahlungen, Vertragsbindung oder Stammdatenänderungen,
- Aufgaben, bei denen ein Fehler erst Wochen später auffällt.
Besonders schwierig ist die Verkettung. Ein Agent, der in fünf Schritten durch drei Systeme arbeitet, muss nach jedem Schritt prüfen, ob das Ergebnis plausibel ist. Fehlt diese Prüfung, summieren sich kleine Abweichungen zu einem Ergebnis, das am Ende korrekt aussieht. In der Praxis bricht ein solcher Ablauf bei ungewöhnlichen Fällen häufig ab, und ohne Protokoll bleibt unklar, an welcher Stelle.
Hinzu kommt ein Sicherheitsthema, das in Demos selten vorkommt. Ein Agent, der Dokumente und E-Mails liest, verarbeitet fremde Inhalte. Diese Inhalte können Anweisungen enthalten, die das Modell zur Ausführung bringt – ein Angriffsmuster, das als indirekte Prompt-Injection bekannt ist. Das NIST beschreibt solche und weitere Risiken generativer KI im Detail, siehe NIST AI 600-1. Konsequenz: Inhalte aus Quellen sind Daten, niemals Anweisungen, und Werkzeugrechte werden nicht aus Dokumentinhalten abgeleitet.
Ein weiteres praktisches Thema sind Wiederholungsversuche. Bricht eine Schnittstelle ab, muss die Anwendung wissen, ob der Schritt bereits gewirkt hat. Ohne diese Information entstehen Dubletten, doppelte Bestellungen oder doppelte E-Mails. Genau deshalb ist die Idempotenz der Schritte keine Feinheit, sondern eine Voraussetzung für den Betrieb.
Technische Leitplanken
Für den produktiven Betrieb haben sich folgende Maßnahmen bewährt:
- Idempotenz: Jeder Schritt ist so gebaut, dass er bei Wiederholung nicht doppelt wirkt.
- Trockenlauf: Neue Aktionen laufen zunächst nur simuliert und werden protokolliert, nicht ausgeführt.
- Vier-Augen-Prinzip: Irreversible Schritte benötigen eine ausdrückliche Freigabe.
- Minimale Rechte: Jedes Werkzeug erhält nur die Rechte, die für diese eine Aufgabe nötig sind.
- Grenzen und Auszeiten: Maximale Schrittzahl, Zeitlimit und Obergrenze für Aktionen pro Vorgang.
- Notausschalter: Ein Weg, den Agenten sofort und nachvollziehbar zu stoppen.
- Vollständiges Aktionsprotokoll: Welche Funktion wurde mit welchen Parametern von wem ausgelöst.
Weil Agenten Daten aus mehreren Systemen zusammenführen, gelten die Anforderungen an Schnittstellen und Rechte, die unter KI-Assistent an ERP und CRM anbinden beschrieben sind, hier in verschärfter Form.
Einführung und Messung
Der erste Prozess sollte hohes Volumen, geringe Reichweite und eine klare Erfolgsdefinition haben. Vor dem Start werden Ausnahmebehandlung und Verantwortlichkeit festgelegt, nicht danach. Bewährt hat sich ein Schattenbetrieb: Der Agent arbeitet mehrere Wochen mit, seine Vorschläge werden aber von Menschen ausgeführt. Abweichungen zwischen Vorschlag und tatsächlicher Bearbeitung zeigen sehr genau, wo die Grenzen liegen.
Gemessen werden Trefferquote, Anteil der Vorgänge ohne Nacharbeit, Durchlaufzeit und die Zahl der Fälle, die eskaliert wurden. Auch die Zahl der vom Agenten ausgelösten Fehlaktionen gehört dazu, ebenso die Zeit, die das Team für die Betreuung aufwendet. Ein Prozess gilt erst dann als geeignet, wenn diese Werte über mehrere Wochen stabil bleiben. Verantwortlich ist ein benannter Prozesseigentümer im Fachbereich, nicht die IT allein.
Fazit: KI-Agenten tragen heute in begrenzten, häufig wiederkehrenden Büroprozessen mit klarem Abschluss und menschlicher Freigabe. Sie tragen nicht als unsichtbare Vollautomatisierung über Systemgrenzen hinweg. Wer mit Schattenbetrieb beginnt, Ausnahmen regelt, Werkzeugrechte begrenzt und jede Aktion protokolliert, bekommt einen Nutzen, der sich belegen lässt. Alles andere ist eine Demo.