Was RPA ist — und was es kann.

Robotic Process Automation, kurz RPA, ist seit den frühen 2010er-Jahren auf dem Markt. Die Idee ist simpel: Ein Software-Roboter bedient Oberflächen so, wie ein Mensch es täte — er klickt Buttons, füllt Formulare, liest Werte aus Tabellen, kopiert Daten zwischen Anwendungen. Bekannte Anbieter sind UiPath, Blue Prism, Automation Anywhere, in Deutschland auch Servicetrace oder vergleichbare Werkzeuge.

RPA ist stark, wenn drei Bedingungen erfüllt sind. Erstens: Die Eingabedaten sind strukturiert und in festem Format. Zweitens: Die Entscheidungsregeln sind deterministisch — „wenn Feld X leer, dann in Feld Y eintragen: 0". Drittens: Die Oberfläche des Zielsystems verändert sich nicht. Sobald sich eine der drei Bedingungen ändert, bricht der RPA-Prozess.

Typische Einsatzfelder: Datenübertragung zwischen einem alten ERP und einer neuen Cloud-Anwendung, automatisches Befüllen von Reports aus mehreren Quellen, routinemäßiges Kopieren von Werten aus E-Mails in ein Zielsystem — wenn die E-Mails ein einheitliches Format haben. RPA hat seine Stärke dort, wo Vorgänge klar strukturiert und monoton sind.

Was ein KI-Agent ist — und was ihn unterscheidet.

Ein KI-Agent im Sinne der aktuellen Technologie nutzt Sprachmodelle, um Eingaben zu interpretieren, die unstrukturiert oder variabel sind. Er liest freien Text, unterschiedliche Dokumentenformate oder mehrdeutige Anweisungen. Er kann Muster erkennen, auf die er nie explizit trainiert wurde, und kann — innerhalb enger Grenzen — eigenständig auf Situationen reagieren, die der Entwickler nicht vorhergesehen hat.

Die Stärke des Agenten liegt in der semantischen Flexibilität. Eine Rechnung von einem neuen Lieferanten, deren Format er nie gesehen hat, liest er trotzdem. Eine Kundenanfrage in ungewöhnlicher Formulierung klassifiziert er trotzdem. Das ist der qualitative Sprung gegenüber RPA: Der Agent kann mit Varianz umgehen, die RPA zum Absturz bringen würde.

Die Schwäche des Agenten ist die Gegenseite derselben Medaille. Weil er flexibel entscheidet, ist jede einzelne Entscheidung weniger deterministisch. Bei identischem Input kann der Agent an zwei Tagen nuanciert unterschiedlich antworten. Für unkritische Anwendungen ist das egal. Für regulierte Prozesse, in denen exakte Reproduzierbarkeit gefordert ist, ist es ein Hindernis.

Die drei wichtigsten Unterschiede.

Eingabe-Variabilität. RPA funktioniert nur mit einheitlichen Formaten. Der KI-Agent kommt mit Variabilität zurecht. Beispiel: 40 verschiedene Rechnungsformate. RPA würde 40 einzelne Konfigurationen erfordern. Der Agent abstrahiert von der Oberflächen-Variation und arbeitet auf der semantischen Ebene.

Entscheidungsart. RPA folgt deterministischen Regeln. Wenn Feld A gleich X, dann tu B. Der KI-Agent kann interpretieren — „ist dieser Schaden eher Haftpflicht oder Hausrat?". Für Regeln, die sich schwer in einer Wahrheitstabelle ausdrücken lassen, ist der Agent die bessere Wahl.

Wartungsaufwand. RPA-Prozesse brechen, wenn das Ziel-System sich ändert — ein neuer Button, ein veränderter Feldname. Der Agent ist in dieser Hinsicht robuster, wenn die Interaktion über Datenformate (JSON, API) läuft. Bei Browser-Automatisierung durch den Agent gibt es ähnliche Probleme wie bei RPA.

Wann ist RPA die bessere Wahl?

Für einen klar strukturierten, repetitiven Prozess mit deterministischen Regeln ist RPA oft die günstigere und zuverlässigere Wahl. Drei Beispiele, bei denen RPA meist gewinnt.

Erstens: Periodische Datenübertragungen. Am Monatsende werden Werte aus drei Bestandssystemen in ein Reporting-System übertragen — immer dieselben Werte, immer dieselbe Logik. RPA läuft das zuverlässig und über Jahre.

Zweitens: Bulk-Aktualisierungen. Eine Preisliste mit zehntausend Einträgen muss ins ERP übertragen werden. Die Logik ist einfach, die Menge groß. RPA macht das effizient und prüfbar.

Drittens: Legacy-Integrationen ohne API. Ein altes System, an das keine andere Anbindung möglich ist, muss regelmäßig gefüttert werden. RPA über die Benutzeroberfläche ist die pragmatische Lösung — auch wenn sie technisch weniger elegant wirkt.

Wann ist ein KI-Agent die bessere Wahl?

Wo RPA an Grenzen kommt, beginnt die Stärke des KI-Agenten. Drei typische Situationen.

Erstens: Eingaben mit Variation. Wenn der Prozess zwanzig verschiedene E-Mail-Formate, dreißig Dokumentvorlagen oder freie Textfelder interpretieren muss, ist der Agent die richtige Wahl. Die Varianz würde eine RPA-Lösung in einen Wald an Sonderfällen zwingen.

Zweitens: Entscheidungen mit Kontext. Wenn eine Klassifizierung Wissen über die historische Beziehung zum Kunden, frühere Fälle oder branchenspezifische Formulierungen erfordert, kann der Agent diesen Kontext einbeziehen. RPA kann das nicht in vergleichbarer Qualität.

Drittens: Prozesse, die sich langsam weiterentwickeln. Wenn sich der Prozess alle paar Monate leicht verändert, ist ein Agent wartungsärmer. Er interpretiert neue Formate, ohne dass jedes Mal ein Entwickler eingreifen muss — solange sich die grundlegende Aufgabe nicht ändert.

Hybride Ansätze: meistens die beste Wahl.

In der Praxis ist die Entscheidung selten ein reines Entweder-oder. Viele gut gebaute Automatisierungen kombinieren beide Technologien, jede in ihrer Stärke.

Ein Beispiel: Der KI-Agent liest eine eingehende Rechnung, extrahiert strukturierte Felder. Ein deterministischer Regel-Schritt prüft die Felder gegen die offene Bestellung. Ein RPA-Bot überträgt die Buchung in das alte ERP-System, zu dem es keine API gibt. Jede Technologie macht das, wofür sie am besten ist.

Die konkrete Kombination richtet sich nach der Systemlandschaft. In modernen Umgebungen mit APIs ist RPA oft überflüssig — der Agent kann direkt mit den Systemen arbeiten. In Umgebungen mit alten, nicht-API-fähigen Systemen ist RPA weiterhin die passende Brücke zwischen intelligentem Agent und Legacy-Anwendung.

Wann lohnt der Umstieg von RPA auf einen KI-Agent?

Viele mittelständische Unternehmen haben bereits vor Jahren erste RPA-Bots in Betrieb genommen. Die Bots laufen, werden gelegentlich angepasst, und niemand stellt sie grundsätzlich in Frage. Trotzdem taucht in jedem zweiten Gespräch die Frage auf: Wann ist der Moment, einen bestehenden RPA-Prozess durch einen KI-Agent zu ersetzen — und wann ist es Geldverschwendung, etwas umzubauen, das funktioniert?

Drei Signale sprechen für einen Umstieg. Das erste: Ihre Wartungsfrequenz ist merklich gestiegen. Ein RPA-Bot, der vor zwei Jahren einmal im Quartal nachjustiert werden musste, braucht heute monatliche Eingriffe. Ursache ist fast immer eine zunehmende Variabilität im Eingangsformat — neue Lieferanten, neue E-Mail-Layouts, neue Produktkategorien. Was früher ein einheitlicher Prozess war, wird zu einem Flickenteppich aus Sonderfällen. Jede neue Variante kostet Entwicklungszeit im Bot. Ein KI-Agent hingegen interpretiert die Varianz auf semantischer Ebene und braucht für die meisten neuen Fälle keine Anpassung.

Das zweite Signal: Die Anzahl der Sonderfall-Regeln im Bot übersteigt die Anzahl der Regelfall-Regeln. Wenn Ihre RPA-Konfiguration zu 60 Prozent aus Workarounds für Ausnahmen besteht, ist der Prozess nicht mehr deterministisch — er ist nur noch formal deterministisch. In diesem Zustand ist ein Agent wartungsärmer, weil er die Ausnahmen mit der gleichen Logik wie die Regelfälle behandelt.

Das dritte Signal: Ihre Mitarbeiter nachbearbeiten RPA-Ergebnisse häufiger, als sie dem Bot die Arbeit abgeben. Wenn ein Bot 70 Prozent der Vorgänge verarbeitet und bei 30 Prozent an den Menschen zurückgibt — und davon wiederum die Hälfte eigentlich machbar gewesen wäre, wenn der Bot besser interpretieren könnte — dann ist die wirtschaftliche Grundlage wackelig. Ein Agent kann die Trefferquote in solchen Fällen oft auf 85 bis 90 Prozent heben, ohne dass die Fehlerkosten steigen.

Gegen einen Umstieg sprechen andere Signale. Wenn Ihr RPA-Prozess seit Jahren ohne Änderung läuft, die Eingabeseite stabil ist und die Wartung minimal — lassen Sie ihn. Ein funktionierender RPA-Bot hat einen wichtigen Vorteil gegenüber jedem Agent: vorhersagbare Kosten. Keine Modell-Nutzungsgebühren, keine Versions-Sprünge, keine Prompt-Regressionen.

Unser pragmatischer Vorschlag: Warten Sie nicht auf eine Komplett-Migration, sondern prüfen Sie pro Bot, ob er noch in sein ursprüngliches Einsatzprofil passt. Wenn die Antwort Nein ist, bauen Sie punktuell um — oft reicht es, einen Agent als vorgelagerte Extraktions-Schicht einzuziehen, während der bestehende Bot den zweiten, deterministischen Teil weiter macht. Diese Hybrid-Architektur ist ökonomisch meistens die klügste Zwischenstufe. Bei einer Rechnungsverarbeitung für einen Logistik-Kunden haben wir genau diesen Weg gewählt: Agent liest, deterministische Regeln gleichen ab, file-basiertes Import-Interface schreibt ins ERP.

Eine Entscheidungshilfe.

Wenn Sie zwischen den beiden Wegen wählen müssen, hilft eine einfache Abfolge. Prüfen Sie zuerst: Sind Ihre Eingabedaten strukturiert und in einheitlichem Format? Wenn ja, ist RPA die erste Wahl. Prüfen Sie zweitens: Sind Ihre Entscheidungsregeln vollständig in einer Wahrheitstabelle darstellbar? Wenn ja, wiederum RPA. Prüfen Sie drittens: Bleibt die Oberfläche des Ziel-Systems stabil? Wenn ja, RPA.

Sobald eine der drei Fragen mit Nein beantwortet wird, kommt der KI-Agent ins Spiel — entweder als Ergänzung oder als Ersatz für RPA. Und sobald Sie alte Systeme ohne API integrieren müssen, sollten Sie prüfen, ob eine hybride Architektur der sinnvollere Weg wäre.

Wir bei AI Atelier bauen beides — RPA dort, wo es passt, KI-Agenten dort, wo Intelligenz gebraucht wird, und Kombinationen davon, wenn der Prozess es verlangt. Wenn Sie unsicher sind, welcher Weg für Ihren Prozess der richtige wäre, hilft ein 45-minütiges Erstgespräch. Wir sagen ehrlich, was passt — auch wenn die Antwort nicht „ein KI-Agent" lautet.