RPA 2.0: Wie UiPath und Automation Anywhere klassische Bots zu KI-Agenten umbauen

Klartext: Die RPA-Welt dreht sich gerade. UiPath und Automation Anywhere bauen ihre Plattformen um – weg vom starren Bot, hin zum LLM-gesteuerten KI-Agenten. Aber wer jetzt „Ende der Workflow-Automation“ ruft, liegt falsch. Die harte Wahrheit ist komplizierter, interessanter und für Unternehmen deutlich folgenreicher.

RPA war gestern? Nicht ganz.

Seien wir ehrlich: Klassische RPA hat ein Imageproblem. Screen-Scraping-Bots, die bei jeder UI-Änderung auseinanderfallen. Workflows, die so starr sind wie Behördenformulare aus den Neunzigern. Projekte, die nach zwölf Monaten Implementierung noch immer mehr kosten als sie einsparen. Der Ruf ist ramponiert.

Trotzdem. Beide großen Anbieter – UiPath und Automation Anywhere – positionieren sich heute ausdrücklich als Agentic Automation-Plattformen, nicht als Begräbnisunternehmen für Workflow-Automation. Laut ihrer eigenen Darstellung ist klassische RPA kein Auslaufmodell, sondern die Infrastruktur, auf der KI-Agenten aufsetzen. Robots führen aus. Agenten denken. Menschen führen. So das Narrativ.

Ob das stimmt – oder ob es sich vor allem um Marketing handelt – darüber lohnt sich eine ehrliche Analyse. Schauen wir rein.

Was UiPath unter „Agentic Automation“ versteht

UiPath ist klar: Die Plattform soll eine „open and trusted platform for agentic automation“ sein, bei der „Agentic AI meets ROI“. Konkret bedeutet das, dass AI Agents auf Basis von Large Language Models in die bestehenden UiPath-Komponenten – Orchestrator, Studio, Assistant – integriert werden. Kein separates Produkt. Kein Silo. Sondern eine Erweiterung des bekannten Stacks.

Das auffälligste neue Feature: Autopilot. Der GenAI-Co-Pilot ist in UiPath Assistant, Studio und Orchestrator eingebaut. Er nutzt Kontext aus laufenden Workflows, macht Vorschläge, startet Automationen direkt aus dem Gesprächsfluss heraus – und greift dabei unter anderem auf Anthropic-Modelle zurück, die im Automation Cloud-Tenant aktiviert werden müssen. Technisch braucht das mindestens UiPath Assistant/Robot Version 2024.10.5 und eine Enterprise-Lizenz.

Was UiPath AI Agents von einem gewöhnlichen LLM-Chatbot unterscheidet: die tiefe Integration mit Robots, APIs, Dokumentenverarbeitung und bestehenden Anwendungen. Ein Agent antwortet nicht nur. Er startet Prozesse, überträgt Inhalte kontextsensitiv zwischen Anwendungen (Clipboard AI), klassifiziert Dokumente und orchestriert End-to-End-Workflows. Das betont die UiPath-Community ausdrücklich: isolierte LLM-Antworten sind nicht das Ziel, End-to-End-Automatisierung ist es.

Dazu kommen Generative AI Activities direkt in Studio: Texte übersetzen, klassifizieren, zusammenfassen, Inhalte generieren – alles per Drag-and-Drop in bestehende Workflows integrierbar. Der Entwickler baut keine komplett neue Architektur. Er erweitert, was schon läuft.

Automation Anywhere: „#1 Provider of Agentic Automation“ – Marketingclaim oder Substanz?

Automation Anywhere nennt sich auf der eigenen Startseite das führende System für „agentic process automation“ – eine Kombination aus AI, Automation und RPA für End-to-End-Geschäftsprozesse. Das klingt nach Substanz. Ist es auch. Aber der Claim „#1 Provider of Agentic Automation“ kommt ohne neutrale Messkriterien. Kein Gartner-Ranking dahinter, keine auditierten Marktanteile. Als Marketingaussage zu werten, nicht als Fakt.

Die Richtung ist trotzdem eindeutig: Auch Automation Anywhere hat RPA zur Basisschicht degradiert. Oben drauf sitzt eine KI-Schicht, die Entscheidungen trifft, Ausnahmen behandelt und unstrukturierte Daten verarbeitet. Der Unterschied zu UiPath liegt weniger in der Strategie als in der konkreten Umsetzung und den Integrations-Ökosystemen. Vergleiche aus dem Enterprise-Markt zeigen: Beide Anbieter werden heute fast ausschließlich im Kontext ihrer AI-Funktionen evaluiert. Reine RPA-Deployments ohne KI-Komponente nehmen relativ ab.

Meine persönliche Einschätzung: Automation Anywhere kämpft aggressiver um die Narrative-Führerschaft, weil UiPath im klassischen RPA-Markt historisch die stärkere Marke war. Das Rebranding zu „Agentic Automation“ ist für beide ein Überlebensprojekt – nur mit unterschiedlichem Ausgangsdruck.

Der echte Unterschied: Bot vs. Agent

Was steckt technisch hinter dem Shift? Klartext: Ein klassischer RPA-Bot folgt einem Skript. Schritt 1, Schritt 2, Schritt 3. Wenn Schritt 2 scheitert, bricht der Prozess ab oder läuft in eine Exception-Queue. Kein Kontext. Keine Entscheidung. Keine Anpassung.

Ein KI-Agent analysiert den Kontext einer Aufgabe, entscheidet, welchen nächsten Schritt er wählt, und passt sich in Echtzeit an – auch bei unstrukturierten Eingaben wie E-Mails, PDF-Dokumenten oder freiem Text. Wo früher ein Mensch eine Ausnahme bearbeiten musste, übernimmt jetzt der Agent, weil er die Absicht hinter der Anfrage versteht.

Ein konkretes Beispiel aus der Praxis: Rechnungsverarbeitung. Klassisch: Der Bot liest eine strukturierte PDF, extrahiert Felder, bucht in SAP. Funktioniert einwandfrei – solange das Layout nicht abweicht. Agentisch: Der LLM-gestützte Agent liest auch die handgeschriebene Notiz auf dem Scan, erkennt, dass eine Teillieferung stattgefunden hat, und leitet die Rechnung zur manuellen Freigabe weiter – statt den Prozess abzubrechen.

Das ist der eigentliche Sprung. Nicht der Chatbot. Nicht der Co-Pilot. Sondern die Fähigkeit, Ausnahmen zu behandeln, die früher zwingend menschliche Intervention brauchten. Die UiPath-Community beschreibt diesen Übergang präzise: „moving beyond fixed workflows“ hin zu Agenten, die Kontext analysieren und Entscheidungen treffen. Wer verstehen will, wie weit dieser Paradigmenwechsel reicht, findet in der Diskussion rund um klassische Chatbots durch KI-Agenten zu ersetzen eine gute Einordnung der zugrundeliegenden Architekturunterschiede.

Multi-Agenten-Systeme: Wo es wirklich komplex wird

Einzelne KI-Agenten sind schon interessant. Multi-Agenten-Systeme sind das eigentliche Spielfeld für komplexe Unternehmensautomation. Hier orchestrieren mehrere spezialisierte Agenten gemeinsam einen Gesamtprozess: Ein Agent liest das Dokument, ein zweiter prüft Compliance-Regeln, ein dritter löst die Folgeaktion im ERP aus.

UiPath und Automation Anywhere bauen genau auf dieses Prinzip. Orchestrator (UiPath) bzw. die zentrale Automation-Plattform (Automation Anywhere) koordinieren, welcher Agent welche Teilaufgabe übernimmt – immer mit Blick auf Governance und Nachvollziehbarkeit. Das ist kein Zufall, denn ohne Governance würden solche Systeme in regulierten Branchen sofort gegen Compliance-Anforderungen stoßen.

Schluss damit, Multi-Agenten-Systeme als Science-Fiction abzutun. Sie sind produktiv. Aber: Die Komplexität steigt exponentiell. Debugging wird schwieriger. Halluzinationen eines einzelnen Agenten können den gesamten Prozess vergiften. Wer heute mit Multi-Agenten-Systemen in der KI-Automation startet, braucht solide Fehlerbehandlung, klare Rollback-Strategien und – das wird oft übersehen – erheblich mehr Testaufwand als bei klassischen Workflows.

Die harte Wahrheit über Governance, Compliance und Halluzinationen

Hier wird es unangenehm. LLMs halluzinieren. Das ist keine Panikmache, das ist Stand der Technik. Und in automatisierten Geschäftsprozessen kann eine Halluzination teuer werden – falsch gebuchte Beträge, falsch interpretierte Vertragsklauseln, falsch adressierte Kundendaten.

Beide Plattformen betonen deshalb Enterprise-Grade Governance: Agenten agieren nicht frei im Wilden, sondern innerhalb definierter Grenzen, mit Audit-Trails, Berechtigungskonzepten und menschlicher Kontrollschicht. UiPath hebt ausdrücklich hervor, dass AI Agents in Orchestrator, Robots und bestehende Governance-Mechanismen eingebunden sind. Vollautonome LLM-Entscheidungen ohne Absicherung sind – zumindest in der offiziellen Positionierung – kein Ziel.

Was das für Unternehmen bedeutet: Human-in-the-Loop bleibt in kritischen Prozessen Pflicht. Finanzbuchungen, Compliance-Entscheidungen, Personalvorgänge – hier sollte kein Agent ohne Validierungsschicht agieren. Die KI-Automation senkt die Ausnahmenquote dramatisch. Sie eliminiert menschliche Aufsicht nicht. Wer das plant, plant an der Wirklichkeit vorbei.

Und noch ein Punkt, der in den meisten Artikeln fehlt: Datenschutz beim Einsatz externer LLMs. Wer Rechnungsdaten, Kundenkommunikation oder HR-Unterlagen durch ein externes LLM jagt, berührt DSGVO-Pflichten. Verarbeitungsverzeichnis, Auftragsverarbeitung, möglicherweise Drittlandtransfer – das muss vor dem ersten produktiven Agent-Deployment geklärt sein, nicht danach.

Kosten und ROI: Was der Umbau zur agentischen Plattform wirklich bedeutet

Ein Aspekt, der in Anbieter-Präsentationen auffällig kurz kommt: der finanzielle Aufwand der Migration. Wer eine bestehende UiPath- oder Automation-Anywhere-Landschaft in Richtung agentischer Automation weiterentwickeln will, investiert nicht nur in Lizenzen. Er investiert in drei Dinge gleichzeitig: Plattform-Upgrades, Skill-Aufbau und Prozess-Redesign.

Die Enterprise-Lizenzen beider Anbieter sind erheblich teurer als reine RPA-Lizenzen, weil LLM-Calls, Cloud-Infrastruktur und erweiterte Orchestrierungsfunktionen eingepreist werden. Für kleinere Automatisierungslandschaften mit wenigen Bots kann sich die Investition schnell als unwirtschaftlich herausstellen – wenn die Prozesse schlicht nicht komplex genug sind, um KI-Agenten zu rechtfertigen. Die Faustregel, die sich in der Praxis abzeichnet: Prozesse mit hohem manuellem Ausnahmehandling, heterogenen Eingabeformaten und mehr als mehreren tausend monatlichen Transaktionen sind die wirtschaftlich tragfähigen Kandidaten. Alles darunter bleibt besser beim klassischen Bot.

Hinzu kommt der Aufwand für LLM-Evaluierung und Prompt-Qualitätssicherung. Ein einmal definierter Prompt ist kein statisches Artefakt. Modell-Updates der Anbieter können das Antwortverhalten verändern, ohne dass eine Konfigurationsänderung stattgefunden hat. Wer das nicht durch systematische Regressionstests absichert, erlebt früher oder später, dass ein produktiver Agent plötzlich andere Ergebnisse liefert als gewohnt – ohne erkennbaren Auslöser im eigenen System.

Was bleibt von klassischer Workflow-Automation?

Mehr als viele denken. Seien wir ehrlich: Für stabile, hochvolumige, strikt regelbasierte Prozesse ist klassische Workflow-RPA immer noch die bessere Wahl. Nachvollziehbarer, günstiger im Betrieb, leichter zu auditieren. Kein LLM-Call-Kosten-Overhead, keine Halluzinationsrisiken, kein Prompt-Engineering-Aufwand.

KI-Agenten entfalten ihren Nutzen dort, wo Ausnahmen häufig sind, Daten unstrukturiert kommen und Entscheidungen Urteilsvermögen erfordern. Das ist eine klare Arbeitsteilung, keine Verdrängung. RPA wird zur Infrastruktur. KI-Agenten werden zur Intelligenzschicht darüber.

Das bedeutet für Unternehmen konkret: Bestandsworkflows nicht voreilig umbauen. Erst analysieren, welche Prozesse tatsächlich von agentischer Intelligenz profitieren. Dann schrittweise erweitern. Die Werkzeuge – Generative AI Activities in UiPath Studio, Anthropic-Modellintegration, Orchestrator-Anbindung – sind vorhanden. UiPath stellt die technische Grundlage auf seiner Plattformseite dar. Der Implementierungsaufwand ist jedoch real und nicht zu unterschätzen.

Praxis-Szenarien: Wo der Umbau sich lohnt – und wo nicht

Um das Gesagte greifbar zu machen, hilft eine ehrliche Einschätzung anhand typischer Unternehmensszenarien. Szenario 1: Versicherungsschaden-Bearbeitung. Eingehende Schadenmeldungen kommen per E-Mail, als Scan, als Formular – alle mit leicht unterschiedlichen Strukturen. Klassische RPA scheitert hier regelmäßig an Variantenvielfalt. Ein LLM-gestützter Agent, der Absicht und Schadensart aus Freitext extrahiert und die Weiterleitung regelbasiert steuert, ist hier ein echter Fortschritt. ROI-Potenzial: hoch.

Szenario 2: Monatliche SAP-Abstimmungsläufe. Feste Datenstruktur, definierte Buchungsregeln, keine Ausnahmen jenseits bekannter Fehlercodes. Hier ist der klassische RPA-Bot die überlegene Lösung. Stabiler, günstiger, auditierbar. Ein KI-Agent würde hier Kosten erzeugen, ohne nennenswerten Mehrwert zu liefern. ROI-Potenzial: gering bis negativ.

Szenario 3: HR-Onboarding-Prozesse. Neue Mitarbeitende kommen mit unterschiedlichen Vertragstypen, unterschiedlichen Standorten, unterschiedlichen Systemen. Ein Multi-Agenten-System, das Vertragstyp erkennt, die richtigen Systemzugänge anfordert und Ausnahmen an HR eskaliert, kann hier erheblichen manuellen Aufwand abnehmen. Der Haken: Personaldaten sind besonders schutzbedürftig. DSGVO-Prüfung und klares Berechtigungskonzept sind hier keine Option, sondern Voraussetzung.

Was Entwickler und Prozessverantwortliche jetzt wissen müssen

Das Skillset verschiebt sich. Wer heute RPA-Entwickler ist, kommt um drei neue Kompetenzbereiche nicht herum: Prompt Engineering, um LLM-Verhalten zuverlässig zu steuern. Grundverständnis von ML-Architekturen, um Grenzen und Risiken realistisch einzuschätzen. Und Prozessdesign für Nicht-Determinismus – denn Agenten liefern nicht immer dieselbe Antwort auf dieselbe Eingabe.

Citizen Developer haben es hier schwerer. Die Drag-and-Drop-Versprechen der Plattformen sind nicht falsch, aber sie beschreiben den einfachen Einstieg – nicht die Produktivreife. Wer robuste Agenten-Workflows baut, die in regulierten Prozessen stabil laufen, braucht mehr als Autopilot im UI.

Was bleibt also als Handlungsschritte? Erstens: Bestandsanalyse, welche RPA-Prozesse Ausnahmequoten über fünf Prozent haben – das sind die Kandidaten für Agenten-Erweiterung. Zweitens: Datenschutz-Folgenabschätzung für den LLM-Einsatz vor dem ersten produktiven Deployment. Drittens: Pilotprojekt mit kleinem Scope, echten Nutzern und Fallback-Strategie – kein „Big Bang“-Rollout. Und viertens: Governance-Konzept für Agenten-Entscheidungen definieren, bevor der erste Agent live geht.

Welche Ihrer RPA-Prozesse könnten morgen von einem LLM-Agenten besser gehandhabt werden – und welche laufen stabiler, wenn Sie den Bot einfach in Ruhe lassen?