Von RPA zur agentischen KI

Jeder RPA-Anbieter hat inzwischen ein agentisches Produkt, und jeder Agenten-Anbieter hat eine Erzählung darüber, wie er RPA ablöst. Beide verkaufen dieselbe Behauptung aus entgegengesetzter Richtung: dass ein Sprachmodell in der Schleife die alten Probleme auflöst.

Das tut es nicht, und der Grund dafür ist interessanter als beide Verkaufsargumente. Agenten verändern genau eine Sache, und alles Weitere folgt daraus.

Der eine Unterschied

RPA entscheidet zur Bauzeit. Ein Agent entscheidet zur Laufzeit.

Das ist die gesamte Unterscheidung. Ein Roboter ist eine aufgezeichnete Folge: hier klicken, das eingeben, darauf warten. Die Entscheidungen hat getroffen, wer ihn gebaut hat; sie sind als Koordinaten und Selektoren festgehalten und werden unverändert wiederholt. Ein Agent erhält ein Ziel und ermittelt die Folge unterwegs, aus dem, was der Bildschirm gerade zeigt.

Alles andere, also Kostenprofil, Prüfbarkeit, Governance und Fehlerbilder, folgt aus dieser einen Verlagerung.

Bemerkenswert ist, was sich nicht ändert: die Schnittstelle. Beide bedienen dasselbe Portal über denselben Browser. Beide automatisieren etwas, das für Menschen gebaut wurde, weil es keinen anderen Weg hinein gibt. Das Integrationsproblem ist identisch; verlagert hat sich nur die Urheberschaft der Schritte.

Zuerst die Begriffe entschärfen

Drei Bezeichnungen werden im selben Gespräch für Unvereinbares verwendet, und die Verwirrung ist nicht zufällig.

Agentische Prozessautomatisierung ist meist der Name, den RPA-Anbieter dem Einbau eines Modells in ihr bestehendes Produkt geben. Manchmal bedeutet es, dass ein Modell zur Laufzeit zwischen Zweigen wählt, was tatsächlich agentisch ist. Häufig bedeutet es, dass ein Modell an einem Knoten eines ansonsten festen Graphen ein Dokument einordnet, was ein Arbeitsablauf mit einem Klassifikator ist. Beides erscheint unter derselben Bezeichnung.

Intelligente Automatisierung ist älter als Sprachmodelle und meinte ursprünglich RPA plus Texterkennung plus Regelwerk. Die Bedeutung hat sich zweimal verschoben und trägt heute wenig Information.

Hyperautomatisierung ist eine Analystenkategorie, keine technische. Sie beschreibt ein Programm, keine Fähigkeit.

Der Test, der durch alle drei hindurchschneidet und sich in jeder Vorführung stellen lässt: Steht die Folge der Schritte vor dem Lauf fest oder entsteht sie währenddessen? Lautet die Antwort davor, ist es ein Arbeitsablauf, gleich wie viele Modelle darin stecken. Das ist keine Wortklauberei: Die beiden haben unterschiedliche Kostenprofile, unterschiedliche Fehlerbilder und unterschiedliche Prüfanforderungen, und das eine zu kaufen, während man für das andere plant, ist der Punkt, an dem Programme entgleisen.

Wohin das Geld tatsächlich fließt

Das Preisgespräch dreht sich meist um Lizenzen, und Lizenzen sind in beiden Welten selten der größte Posten.

Bei RPA ist die laufende Kostenstelle die Pflege: die Menschen, die Roboter reparieren, wenn Masken sich verschieben. Lizenzkosten sind sichtbar und budgetiert; Pflege ist verteilt und landet bei dem Team, dem der Prozess gehört. Deshalb wirken RPA-Programme im ersten Jahr günstig und im dritten teuer, und deshalb überrascht die Gesamtsumme so oft: Der teure Teil stand nie auf einer Rechnung.

Bei Agenten ist die laufende Kostenstelle die Inferenz, und sie konzentriert sich an einer Stelle, an der niemand nachsieht: der Seitendarstellung. Jeder Zug überträgt eine Beschreibung des aktuellen Bildschirms erneut. Eine dichte Portalseite als Accessibility-Baum ist eine erhebliche Textmenge, und sie geht in jedem einzelnen Zug wieder hinaus. Die Token für die Schlussfolgerung sind meist die kleinere Hälfte.

Drei unmittelbare Folgen:

Die Darstellung zu kürzen ist die wirksamste verfügbare Optimierung. Nur den relevanten Bereich zu senden statt des ganzen Dokuments halbiert die Rechnung regelmäßig und verbessert dabei meist die Trefferquote, weil weniger ablenkt.

Eine Obergrenze für Züge je Aufgabe ist eine Budgetkontrolle, kein Sicherheitsnetz. Ohne Deckel ist das obere Ende Ihrer Kostenverteilung unbegrenzt, und es besteht ausschließlich aus Läufen, die schieflaufen.

Kosten je erfolgreichem Ergebnis ist die einzige ehrliche Kennzahl. Kosten je Lauf schmeicheln, weil sie die günstigen Fehlläufe mitzählen. Wenn ein Fünftel der Läufe nach zwanzig Zügen scheitert, stehen sie im Budget, ob sie im Dashboard stehen oder nicht.

Was daraus folgt

Anpassungsfähigkeit, und das ist das eigentliche Argument

Ein aufgezeichneter Schritt ist eine Wette darauf, dass eine Maske stillsteht. Wird das Portal überarbeitet, ist die Wette verloren und der Roboter hält an. In einem ausgereiften RPA-Programm ist das kein gelegentliches Ärgernis, sondern der beherrschende Kostenblock. Ein Team, das zwanzig Roboter ausgeliefert hat, verbringt das zweite Jahr mit deren Pflege und liefert keinen neuen aus. Das ist der häufigste Weg, auf dem ein Automatisierungsprogramm zum Stillstand kommt.

Ein Agent, der die Seite in jedem Zug neu liest, ist gegenüber einer Überarbeitung weitgehend gleichgültig. Der Knopf hat sich verschoben; er liest die neue Seite und findet ihn. Das ist echt, und es ist das stärkste Argument in dieser Kategorie. Wer Automatisierung gegen viele Portale pflegt, die sich unabhängig voneinander verändern, kann allein damit den Wechsel rechtfertigen.

Die Kosten kehren sich um

RPA hat hohe Aufbaukosten und nahezu keine Grenzkosten. Existiert der Roboter, ist ein Lauf ein Rundungsfehler, und der hundertste kostet so viel wie der erste.

Agenten kehren das um. Der erste Ablauf entsteht deutlich günstiger, oft mit einem Prompt und einem Nachmittag statt zwei Wochen Aufzeichnung und Ausnahmebehandlung. Doch jeder Lauf verbraucht Token, für die Seitendarstellung und für die Schlussfolgerung, und eine Seite mit vierzig Zügen kostet das Vierzigfache einer Seite mit einem Zug.

Die praktische Folge: RPA wird mit Volumen günstiger, Agenten werden mit Vielfalt günstiger. Zehntausend Läufe eines Ablaufs sprechen eindeutig für den Roboter. Je ein Lauf von tausend verschiedenen Abläufen spricht ebenso eindeutig für den Agenten. Reale Portfolios enthalten beides, und der Fehler besteht darin, für das gesamte Portfolio eine Technik zu wählen, weil ein Preismodell es einheitlich aussehen ließ.

Der Determinismus ist weg, und Ihre Prüfstrategie setzte ihn voraus

Ein RPA-Roboter tut jedes Mal dasselbe. Das ist nicht nur bequem, sondern die Grundlage dafür, wie diese Dinge geprüft, freigegeben und revidiert werden. In der Testumgebung laufen lassen, zusehen, freigeben.

Ein Agent kann bei jedem Lauf einen anderen Weg nehmen, und beide Wege können richtig sein. Das bricht die Prüfung über Aufzeichnen und Wiederholen und es bricht das Freigabemodell, das lautet: Wir haben den Prozess verifiziert.

An die Stelle tritt die Prüfung des Ergebnisses statt des Weges:

Prüfung bei RPA	Prüfung beim Agenten
Schritt 7 klickte Element X	Die Rechnung liegt im Buchungsjournal
Der Ablauf hat 12 Schritte beendet	Die extrahierte Summe stimmt überein
Keine Ausnahme wurde ausgelöst	Der Datensatz hat die Prüfung bestanden
Das Bildschirmfoto entspricht der Vorlage	Das richtige Konto wurde belastet

Die linke Spalte ist billiger zu schreiben und sagt fast nichts darüber, ob die Arbeit richtig erledigt wurde. Die rechte Spalte ist das, worauf es ankommt, und sie war auch unter RPA prüfenswert. Der Unterschied ist, dass mit Agenten die Möglichkeit entfällt, die linke Spalte für ausreichend zu halten.

Governance wird zunächst schwieriger

Das Verhalten eines RPA-Roboters ist durch seine Definition vollständig festgelegt. Man kann sie lesen, vergleichen und weiß, was er tun wird. Das Verhalten eines Agenten wird durch einen Prompt, eine Modellversion und das Angetroffene bestimmt, und nur das Erste liegt in Ihrer Hand.

Drei konkrete Folgen:

Ein Modellwechsel ist eine Verhaltensänderung. Versionen festzuschreiben ist wichtiger, als die meisten erwarten, und ein Satz wie wir haben auf das neuere Modell aktualisiert gehört in ein Änderungsprotokoll, so wie Code.

Die Seite wird zum Eingabekanal. Ein Roboter, der auf feindseligen Text auf einer Seite trifft, liest ihn nicht. Ein Agent liest ihn und handelt möglicherweise danach. Das ist eine Risikoklasse ohne Entsprechung in RPA.

Leitplanken gehören außerhalb des Modells. Eine Anweisung im Prompt ist eine Bitte. Eine Rechteprüfung im Code, der die Handlung ausführt, ist eine Kontrolle. Was nicht geschehen darf, muss unmöglich sein und nicht unerwünscht. Diese Disziplin brauchte RPA nie, weil ein Roboter nur tun konnte, was aufgezeichnet war.

Was gleich bleibt

Die Hälfte des Erkenntniswerts liegt in den Zeilen, die sich nicht bewegen, denn dort finden Migrationsprojekte ihre Überraschungen.

Die Oberfläche ist weiterhin die Integration. Gibt es keine Schnittstelle, gibt es keine Schnittstelle. Ein Agent, der ein Portal bedient, tut genau das, was der Roboter tat, mit anderer Urheberschaft der Schritte. Das zugrundeliegende Problem hat niemand beseitigt.

Die Anmeldung bleibt der schwierige Teil. Sitzungen laufen ab, Zwei-Faktor-Abfragen erscheinen, Portale bemerken Anmeldungen von neuen Adressen. Das ist unverändert und in beiden Welten häufig die größte Fehlerquelle.

Die Nachweispflicht bleibt. Ein regulierter Prozess braucht einen Nachweis darüber, was wann von wem und auf welcher Grundlage getan wurde. Ein Modell in der Schleife lockert das nicht. Eher im Gegenteil: Beim Roboter war die Definition zugleich Dokumentation, beim Agenten ist sie es nicht, sodass das Laufprotokoll die gesamte Last trägt.

Ausnahmebehandlung ist weiterhin der größte Teil der Arbeit. Der Gutfall war nie das Teure. Doppelte Datensätze, Zeitüberschreitungen mitten in der Übermittlung, ein Portal in Wartung, ein Feld, das nur bei bestimmten Kontotypen erscheint. Agenten bewältigen einiges davon elegant und erfinden bei anderem plausibel aussehende falsche Antworten, was gegenüber dem Anhalten nicht offensichtlich eine Verbesserung ist.

Die Browser muss weiterhin jemand betreiben. Ob die Entscheidungen aus einem Skript oder einem Modell stammen: Ein Browser muss gestartet, überwacht, isoliert, erneuert und beobachtet werden. Diese Ebene ist identisch.

Was die Fachabteilung tatsächlich merkt

Der technische Vergleich oben ist das, worüber die IT streitet. Ob eine Migration gelingt, entscheidet sich an etwas anderem, und das steht selten in Anbietermaterial.

Wer den Roboter fachlich verantwortet hat, kann ihn nicht mehr lesen. Eine RPA-Definition ist einsehbar. Jemand aus dem Fachbereich konnte sie öffnen, die Schritte nachvollziehen und sagen, ob sie dem Prozess entsprach, den er im Kopf hatte. Ein Prompt samt Modell ist in diesem Sinne nicht einsehbar, und die Beruhigung, die aus dem Nachsehen kam, entfällt. Ihr Ersatz kostet Arbeit: Laufprotokolle, die den Vorgang fachlich beschreiben statt in Klicks.

Es lief gestern ist kein Beleg mehr. Bei einem deterministischen Roboter sagte ein erfolgreicher Lauf tatsächlich etwas über den nächsten aus. Bei einem Agenten weniger, als angenommen wird, und wenn ein vertrauter Ablauf sich das erste Mal anders verhält, sinkt das Vertrauen stärker, als der tatsächliche Fehler rechtfertigt. Diese Erwartung früh zu setzen ist günstiger, als sie später zu reparieren.

Aus Ausnahmen wird eine Warteschlange statt eines Alarms. RPA-Ausnahmen waren Fehler: Etwas hielt an, jemand musste es reparieren. Eskalationen eines Agenten sind ein normales Betriebsergebnis mit Volumen, und jemand muss die Warteschlange verantworten. Wo das übersprungen wird, endet der Eskalationsweg in einem Postfach, das niemand liest, was einer fehlenden Leitplanke gleichkommt.

Das Muster, das tatsächlich trägt

Die wirksamsten Installationen sind nicht agentisch. Sie sind hybrid, und die Aufteilung folgt einem Prinzip:

Die deterministischen Teile skripten. Anmeldung, Navigation zu einem bekannten Bereich, Blättern, Herunterladen. Diese Teile sind stabil, häufig und günstig zu kodieren. Ein Modell dort einzusetzen bezahlt Entscheidungen, die längst getroffen sind.

Das Modell dort rufen, wo das Skript nicht auflösen kann, was es sieht. Ein Selektor greift nicht. Die Seite hat nicht die erwartete Form. Ein unerwarteter Dialog erscheint. Ein neues Feld ist da. Das ist die Ermessensentscheidung, und dafür lohnt sich die Bezahlung.

Nach der Auflösung zurück ins Skript. Die Ausgabe des Agenten ist eine Entscheidung, keine Übernahme. Er nennt das Element, das Skript klickt es.

Diese Struktur liefert das Kostenprofil des Roboters auf fünfundneunzig Prozent der Fälle und die Anpassungsfähigkeit des Agenten auf die fünf Prozent, die früher ein Pflegeticket erforderten. Sie ist zudem in einer Revision erheblich leichter zu vertreten, weil die deterministischen Teile lesbar bleiben und die nichtdeterministischen auf benennbare Entscheidungspunkte begrenzt sind.

Dass dieses Muster wenig beworben wird, liegt daran, dass es in keine der beiden Verkaufsgeschichten passt. Es ist kein Agentenprodukt und kein RPA-Produkt.

Eine Migrationsreihenfolge, die nicht schiefgeht

Beginnen Sie mit den Abläufen, die am häufigsten brechen, nicht mit denen, die am häufigsten laufen. Der Wert der Anpassungsfähigkeit ist proportional zum Pflegeschmerz. Ein Roboter, der dieses Jahr sechs Reparaturen brauchte, ist ein guter Kandidat. Einer, der zwei Jahre unangetastet lief, ist ein schlechter, denn seine Migration verwandelt einen funktionierenden, kostenlosen, deterministischen Prozess ohne Gegenwert in einen bezahlten, nichtdeterministischen.

Lassen Sie den Roboter parallel weiterlaufen. Beide gegen dieselben Eingaben laufen lassen und die Ergebnisse einige Wochen vergleichen. Das ist der einzige ehrliche Weg herauszufinden, ob die Fassung des Agenten tatsächlich richtig ist, und er ist günstig, weil der Roboter bereits existiert.

Instrumentieren Sie die beiden neuen Fehlerbilder, bevor Sie sie brauchen. Die Verteilung der Zugzahl und die Eskalationsquote. Beide sind still, beide sind neu, und beide lassen sich am ersten Tag viel leichter ergänzen als während eines Vorfalls.

Migrieren Sie den Nachweis nicht zuletzt. Ist der Prozess reguliert, ist der Nachweis das Ergebnis, und ein Agent, der einwandfrei arbeitet, aber nicht belegen kann, was er getan hat, hat nichts ersetzt.

In einem Satz

Agenten haben RPA nicht überflüssig gemacht. Sie haben die Entscheidung von der Bauzeit in die Laufzeit verlagert, was für vielfältige und instabile Arbeit ein echter Fortschritt ist und für gleichförmige und stabile Arbeit ein echter Rückschritt.

Wer am meisten daraus zieht, entscheidet sich nicht. Er setzt das Modell dorthin, wo Ermessen gefragt ist, und lässt das Skript dort, wo nie eines nötig war. Wie der Glossareintrag zu RPA es zusammenfasst: Sie bezahlen Urteilskraft nur dort, wo sie gebraucht wird.