KI-Agenten, RPA oder Chatbot: Welche Automatisierung passt zu welchem Prozess?

Drei Werkzeuge für drei verschiedene Aufgaben

Ein typisches Szenario: Bestellungen kommen als PDF-Anhang in einem Dutzend Lieferanten-Layouts, manche mit handschriftlichen Notizen. Eine Sachbearbeiterin öffnet jede einzelne, prüft sie gegen die Preisliste, erfasst sie im ERP und schickt eine Bestätigung. Welche Automatisierung passt? Das hängt davon ab, welchen Teil dieser Arbeit Sie betrachten, denn jede der drei Technologien deckt einen anderen Teil ab.

Robotic Process Automation (RPA) nutzt Software-Roboter, die eine feste Abfolge von Klicks, Tastatureingaben oder Schnittstellenaufrufen abspielen. Für das Erfassen im ERP ist das hervorragend, solange die Daten bereits sauber sind und sich die Masken nicht ändern.

Chatbots sind Dialogoberflächen. Ältere folgen Entscheidungsbäumen, neuere verstehen Freitext mit einem Sprachmodell. Sie sind gut für den Empfang, etwa für den Lieferanten, der fragt, wo seine Bestellung bleibt. Aber ein Chatbot allein bearbeitet nichts.

KI-Agenten sind zielgerichtete Systeme, die mit einem Sprachmodell über mehrere Schritte und Werkzeuge hinweg lesen, entscheiden und handeln. Sie sind die erste Technologie, die den unordentlichen Mittelteil bewältigt: zwölf Layouts lesen, erkennen, dass ein Preis vom Vertrag abweicht, und entscheiden, was damit geschieht. Die ausführliche Definition finden Sie in unserem Artikel Was ist Agentic AI?

Der häufigste Fehler ist, die drei als Generationen zu betrachten – als würden Agenten RPA so ablösen, wie RPA einst Makros abgelöst hat. Das tun sie nicht. Es sind Werkzeuge für unterschiedliche Arten von Eingaben, und die meisten echten Prozesse brauchen zwei davon.

Der Vergleich auf einen Blick

Zwei Zeilen verdienen Aufmerksamkeit. Der fehlende Determinismus ist keine Schwäche von Agenten, die man wegentwickeln müsste; er ist der Grund, warum sie Ausnahmen überhaupt bewältigen können. Und die Zeile zur Wartung erklärt, warum in vielen RPA-Landschaften unbemerkt ein Team entsteht, das Bots am Leben hält: Die Roboter sind nur so stabil wie die Masken, auf die sie klicken.

Wo RPA weiterhin gewinnt

RPA ist häufiger die richtige Antwort, als Agenten-Enthusiasten zugeben. Sie gewinnt, wenn die Oberfläche stabil ist und es keine Schnittstelle gibt, wenn der Prozess strikt deterministisch sein muss, weil ein Prüfer nachfragen wird, wenn das Volumen hoch ist und die Kosten je Durchlauf nahe null liegen müssen – und vor allem, wenn sie bereits funktioniert. Massenerfassung in ein Altsystem, Abstimmungen mit festen Exportformaten, nächtliche Datenübertragungen zwischen zwei Anwendungen: Nichts davon braucht ein Sprachmodell, und eines hinzuzufügen brächte nur Kosten und Unsicherheit.

Unser Rat ist in diesen Fällen bewusst unspektakulär: Bot behalten, dokumentieren und erst dann einen Agenten davorsetzen, wenn die Eingaben nicht mehr sauber sind.

Wo Agenten RPA ablösen oder umhüllen

Agenten lohnen sich dort, wo RPA einen Menschen braucht, der die Eingabe vorbereitet. Dokumente in wechselnden Layouts, E-Mails mit den Bestelldaten im Fließtext, Tickets, in denen das eigentliche Problem im dritten Absatz steht: Hier scheitert das klassische RPA-Projekt, weil der Bot strukturierte Felder braucht und jemand sie erzeugen muss. Ein Agent liest die unstrukturierte Eingabe, extrahiert und validiert die Felder und übergibt erst dann.

Das zweite Feld ist Urteilsvermögen. Lautet die Regel „Rechnung mit Bestellung abgleichen, es sei denn, die Abweichung ist erklärbar“, schafft RPA die erste Hälfte und bleibt bei „es sei denn“ stehen. Ein Agent kann Lieferschein, Vertrag und Korrespondenz heranziehen, eine Erklärung vorschlagen und den Fall entsprechend weiterleiten. Das dritte Feld ist die Ausnahme-Warteschlange selbst, die in vielen RPA-Landschaften von Hand abgearbeitet wird. Ein Agent, der die meisten Ausnahmen löst und den Rest für einen Menschen vorbereitet, bringt oft mehr als die Automatisierung eines weiteren Standardfalls.

Ob ein Agent den Bot ablöst oder umhüllt, hängt vom System dahinter ab. Hat die Zielanwendung eine Schnittstelle, ruft der Agent sie direkt auf, und der Bot geht in den Ruhestand. Führt der einzige Weg über die Benutzeroberfläche, bleibt der Bot die Hand, und der Agent wird zum Kopf. Das ist das Umhüllungsmuster – in mittelständischen IT-Landschaften mit älteren ERP-Systemen das häufigste Ergebnis.

Chatbots sind eine Oberfläche, keine Lösung

Die Enttäuschung über die Chatbots des letzten Jahrzehnts hatte einen einfachen Grund: Ein Gespräch ist keine Fähigkeit. Ein Bot, der „Ich möchte meine Lieferadresse ändern“ perfekt versteht, aber den Auftrag nicht öffnen und ändern kann, erzeugt Reibung statt Service. Der Kunde landet in derselben E-Mail-Warteschlange wie zuvor, nur verärgert.

Die aktuelle Generation ändert die Rechnung nur, wenn Sie das Chatfenster als Eingangstür zu etwas begreifen, das handeln kann. Hinter einem guten Kundenservice-Chat sitzt ein Agent mit Werkzeugen: Auftrag nachschlagen, Richtlinie prüfen, Adresse ändern, bestätigen. Hinter einem guten internen Helpdesk-Chat sitzt ein Wissensassistent, der die tatsächlichen Dokumente durchsucht und, wo erlaubt, die Anfrage ausführt. Erst die Fähigkeit entwerfen, dann das Gespräch.

Hybride Muster, die sich in der Praxis bewähren

Die produktive Antwort ist selten eine einzelne Technologie. Drei Kombinationen begegnen uns in unseren Projekten zu agentischen Workflows immer wieder.

• Der Agent entscheidet, RPA oder eine Schnittstelle führt aus. Das Sprachmodell übernimmt Lesen, Extraktion und Beurteilung. Die Ausführung läuft über deterministische Konnektoren: Schnittstellen, wo es sie gibt, RPA-Bots, wo nur eine Oberfläche existiert, dazwischen eine Workflow-Engine. Die Grenze zwischen beiden ist explizit und wird protokolliert.
• Chat vorne, Agent dahinter. Das Gespräch ist der Einstieg für Kunden oder Mitarbeitende; der Agent dahinter hat Werkzeuge und Berechtigungen, und die Autonomiestufe ist je Aktion festgelegt.
• RPA fährt den Standardfall, der Agent übernimmt die Ausnahmen. Der bestehende Bot macht weiter wie bisher. Was er nicht verarbeiten kann, geht an einen Agenten, der den Fall löst oder für einen Menschen vorbereitet. Das ist der schonendste Weg, eine RPA-Landschaft zu modernisieren.

Ein Entscheidungsrahmen in fünf Fragen

Beantworten Sie für jeden Prozess auf Ihrer Liste diese fünf Fragen der Reihe nach. Das Antwortmuster zeigt meist auf eine Architektur.

1. Wie sehen die Eingaben aus? Strukturiert, vorhersehbar und immer an derselben Stelle: RPA oder eine einfache Integration. Unstrukturiert, variabel oder in mehreren Formaten: Mindestens für die Erfassung braucht es einen Agenten.
2. Wie viel Urteilsvermögen steckt in der Mitte? Keines, die Regeln sind vollständig: RPA. Etwas, und eine erfahrene Sachbearbeiterin wendet Faustregeln an: ein Agent mit Leitplanken. Reiner menschlicher Ermessensspielraum, etwa Verhandlungen: nur Assistenz, keine Automatisierung der Entscheidung.
3. Was passiert, wenn es schiefgeht? Umkehrbar und günstig: Der Agent darf in Grenzen handeln. Teuer oder unumkehrbar: eine Freigabe vor der Ausführung, oder die Maschine bleibt bei der Empfehlung.
4. Wie stabil sind die Systeme? Schnittstellen vorhanden: Der Agent ruft sie direkt auf, idealerweise über einen Standard wie MCP. Nur eine Oberfläche: RPA als Hand. Masken, die sich jedes Quartal ändern: Rechnen Sie mit Bot-Wartung und budgetieren Sie sie.
5. Wer oder was löst den Prozess aus? Ein Mensch, der in natürlicher Sprache fragt: eine Chat-Oberfläche. Ein Ereignis in einem System oder ein geplanter Lauf: ein Agent oder Bot im Hintergrund, bei dem Menschen nur bei Ausnahmen benachrichtigt werden.

Zeigen die Antworten auf einen Agenten, lautet die nächste Frage, mit welchem Prozess Sie beginnen. Unser Leitfaden zur Auswahl des ersten Use Case für einen KI-Agenten enthält dafür ein Bewertungsmodell.

Drei Beispiele

Auftragserfassung aus E-Mails und PDFs. Eingaben unstrukturiert, Urteilsvermögen moderat, Fehler vor der Buchung umkehrbar, ERP mit teilweiser Schnittstelle. Architektur: ein Agent für Lesen, Validierung und Rückfragen; die Schnittstelle für die Buchung; RPA nur für die eine Altsystem-Maske ohne Schnittstelle. Siehe KI-Agenten in Operations.

IT-Helpdesk: Passwort-Resets und Zugriffsanfragen. Eingaben dialogisch, aber eng gefasst, Urteilsvermögen minimal, Regeln vollständig. Architektur: eine Chat-Oberfläche, deterministische Automatisierung dahinter, ein Agent nur für die mehrdeutigen Tickets, bei denen das eigentliche Problem in der Beschreibung vergraben ist. Siehe IT und Engineering.

Monatliche Bankabstimmung mit festen Exportformaten. Eingaben strukturiert, kein Urteilsvermögen nötig, Systeme stabil. Architektur: RPA oder eine geplante Integration. Kein Agent, kein Chatbot. Schlägt jemand einen vor, fragen Sie, was das Sprachmodell dabei entscheiden soll.