Jede Woche verkündet jemand, RPA sei tot und die KI-Agenten hätten es in Rente geschickt. Gute Schlagzeile, schlechte Architekturentscheidung. Denn wer RPA aus Mode killt, endet damit, den Agenten die Handlangerarbeit machen zu lassen —ein Feld von System A nach System B schieben, tausendmal, ohne zu denken— und das ist teuer, langsam und absurd. Und wer aus Gewohnheit an RPA festhält, verlangt von ihm, über eine seltsame Rechnung zu entscheiden, und der Bot bleibt stehen. Die nützliche Frage ist nicht, wer gewinnt. Sie lautet: welchen Teil der Arbeit macht welcher.
KI-Agenten vs RPA: der Kampf ist falsch gestellt
RPA (Robotic Process Automation) ist ein Roboter, der Klicks und Tastenanschläge auf einem Bildschirm nachahmt. Du zeichnest ihm die Schritte auf, und er spielt sie identisch ab, in voller Geschwindigkeit, ohne zu ermüden oder zu improvisieren. Er ist deterministisch: gleicher Input, gleicher Output, immer. Ein KI-Agent ist etwas anderes: er liest unstrukturierten Text, versteht die Absicht, entscheidet innerhalb von Grenzen und passt sich an, wenn sich etwas ändert. Der eine ist Muskel. Der andere ist Urteilsvermögen. Sie gegeneinander antreten zu lassen ist, als fragtest du, ob ein Schraubenzieher oder ein Elektriker besser ist: sie brauchen einander.
Die Verwirrung kommt daher, dass beide "automatisieren", also wirken sie wie Ersatz füreinander. Sind sie nicht. Sie automatisieren verschiedene Schichten desselben Prozesses. Und der teure Fehler —den wir immer wieder sehen— ist, den einen die Arbeit des anderen machen zu lassen. Bevor du irgendetwas entscheidest, mach dir klar, was es wirklich heißt, einen Prozess mit Agenten zu automatisieren, denn die Hälfte der gescheiterten Projekte scheitert nicht am Werkzeug: sie scheitert an der falschen Aufteilung, wer was macht.
Was RPA gut kann (und warum es nicht tot ist)
RPA glänzt dort, wo die Arbeit repetitiv, strukturiert und stabil ist. Keine Nuancen: feste Regeln, null Ausnahmen, jeden Tag derselbe Bildschirm. Auf diesem Terrain ist es unschlagbar —billig, schnell, prüfbar— und kein Agent wird es überbieten, weil es nichts zu überlegen gibt. Fälle, in denen RPA weiter die richtige Antwort ist:
- Daten zwischen Systemen verschieben, die nicht per API sprechen: von einer Tabelle ins ERP kopieren, vom ERP ins Bankportal, immer gleich.
- Identische Formulare ausfüllen aus einer Vorlage, in hohem Volumen und mit null Komplexität.
- Geplante Berichte erzeugen: extrahieren, einfügen, exportieren, senden. Keine Entscheidungen dazwischen.
- Triviale Abgleiche, bei denen die Regel lautet „wenn der Betrag stimmt, als bezahlt markieren" und es keine Graustufen gibt.
Die Achillesferse von RPA ist bekannt: es ist fragil. Weil es arbeitet, indem es den Bildschirm nachahmt, bricht der Bot an dem Tag, an dem jemand einen Knopf verschiebt, ein Feld umbenennt oder der Anbieter das Portal aktualisiert, und muss von Hand repariert werden. Diese Wartung ist keine Randnotiz. Marktauswertungen, die Deloitte zitieren, schätzen, dass die Wartung zwischen 70 % und 75 % des RPA-Budgets frisst (Neomanex, 2025). Das ist kein Grund, es wegzuwerfen: es ist ein Grund, ihm nicht das abzuverlangen, was es nicht kann.
Was der Agent gut kann (und wo RPA bricht)
Der Agent kommt genau dort ins Spiel, wo RPA stehen bleibt: wenn du etwas ohne Format lesen, den Kontext verstehen und entscheiden musst. Er folgt keinem aufgezeichneten Skript; er interpretiert. Deshalb hält er die Ausnahme aus, die schlecht geschriebene E-Mail, die Rechnung mit der Position an einer seltsamen Stelle. Terrain des Agenten:
- Unstrukturierte Daten: E-Mails, PDFs, Verträge, Chats. Der Agent liest und zieht das Wesentliche heraus, auch wenn jedes Dokument anders ankommt.
- Ausnahmen mit Urteilsvermögen: eine Abweichung auf einer Rechnung, eine seltsame Bestellung, ein Fall, der nicht in die Regel passt. Der Agent überlegt innerhalb seiner Grenzen, statt stehen zu bleiben.
- Mehrere Systeme koordinieren nach ihrer Bedeutung, nicht nach ihrem Bildschirm: er verknüpft CRM, ERP und Posteingang und versteht, was jede Sache ist.
- Klassifizieren und priorisieren, wenn die Antwort nicht in einer Tabelle steht: Ticket-Triage, Lead-Routing, Kategorien, die vom Kontext abhängen.
Der Agent hat auch seinen Preis: er kostet mehr pro Vorgang als ein Bot, du musst ihm Leitplanken und Aufsicht geben, und du willst nicht, dass er am ersten Tag allein über heikle Dinge entscheidet. Einen zu bauen, der in Produktion hält —keine Demo—, ist ein Handwerk, und wir schlüsseln es auf in wie man einen KI-Agenten baut, der wirklich funktioniert. Die Betriebsregel: nutze keinen Agenten für das, was eine feste Regel schon löst. Das ist, als würdest du einen Anwalt zum Fotokopieren einstellen.
| Dimension | RPA | KI-Agent |
|---|---|---|
| Wie es arbeitet | Ahmt Klicks und Tasten auf einem Bildschirm nach | Liest, überlegt und entscheidet über die Bedeutung |
| Datentyp | Nur strukturiert (Tabellen, feste Felder) | Strukturiert + unstrukturiert (E-Mails, PDFs, Chats) |
| Ausnahmen | Bleibt stehen und eskaliert an einen Menschen | Überlegt innerhalb seiner Grenzen |
| Wenn sich der Bildschirm ändert | Bricht, muss repariert werden | Passt sich per Kontext an |
| Kosten pro Vorgang | Sehr niedrig | Höher |
| Sein Terrain | Repetitiv, stabil, ohne Graustufen | Komplex, ausnahmenreich, systemübergreifend |
Das Muster, das 2026 gewinnt: der Hybrid
Hier ist die These, und sie geht gegen die einfache Schlagzeile: wähle keine Seite, kombiniere sie. Das Muster, das sich rechnet, ist weder „Agent statt RPA" noch „das RPA von immer". Es ist der Hybrid, mit einer sauberen Aufteilung: der Agent liest und entscheidet, RPA führt das Repetitive aus. Das Urteil oben, der Muskel unten. Jeder macht das, was er billig und gut macht.
Ein Beispiel, das sich von selbst versteht: die Daten einer Rechnung extrahieren und sie in dein System einspeisen. Die Rechnung kommt als PDF, jeder Anbieter setzt sie anders, manchmal fehlt ein Feld oder die Mehrwertsteuer steht falsch —das ist Lesen und Urteilen, Terrain des Agenten—. Sobald der Agent die Daten verstanden und validiert hat, ist es reiner repetitiver Muskel, sie Feld für Feld ins ERP zu tippen, tausendmal gleich —Terrain von RPA oder einer API-Integration—. Der Agent macht den denkenden Teil; der Bot macht den schwitzenden Teil. Der Agent verschwendet keine Tokens mit Tippen, und der Bot bleibt bei einem seltsamen PDF nicht stehen.
Wie du in deinem Fall entscheidest, ohne heiße Luft zu kaufen
Du brauchst kein Komitee, um zu wählen. Du musst den Prozess ansehen und diese Fragen der Reihe nach beantworten:
- Kommen die Daten geordnet oder als Chaos an? Wenn alles in sauberen, stabilen Tabellen kommt, fang mit RPA an. Wenn es als E-Mails, PDFs und Anhänge kommt, brauchst du einen Agenten, der liest.
- Gibt es Ausnahmen, die eine Entscheidung verlangen? Wenn der Prozess „immer gleich, ohne Graustufen" ist, ist es RPA. Wenn es oft ein „kommt darauf an" gibt, ist es ein Agent.
- Ändern sich Bildschirm oder Format häufig? Wenn das Portal ständig aktualisiert wird, lebt ein Bot kaputt; da ist der Agent auf Dauer billiger, auch wenn er pro Vorgang mehr kostet.
- Kannst du den Prozess in zwei Schichten teilen? Fast immer ja: das Stück, das denkt, und das Stück, das wiederholt. Das ist der Hybrid-Moment, und meist die richtige Antwort.
Und eine Warnung, damit du nicht über das Übliche stolperst: das Werkzeug ist nicht das Projekt. Agent oder RPA zu wählen ist 10 % der Arbeit; die restlichen 90 % sind, den Prozess zu verstehen, ihm Grenzen zu setzen und ihn laufen zu lassen mit etwas, das sich messen lässt. Das ist Automatisierung des Betriebs auf dem, was du schon hast, kein Technologiekauf. Wer dir „Agenten" verkauft, ohne nach deinem Prozess zu fragen, verkauft dir das Modewort, so wie er dir früher „RPA" verkauft hat, ohne hinzusehen. Die Mode ändert sich; das Handwerk, die Arbeit gut aufzuteilen, nicht.