RPA und UiPath

Wie ein Ablauf mit einem Modellschritt aufgebaut ist, beschreibt Kapitel 01 am Beispiel eines Rechnungseingangs. In Kapitel 03 bucht der Ablauf die Rechnung am Ende über die Schnittstelle der Buchhaltung. Manches Buch­hal­tungs­pro­gramm hat aber keine. Dieses Kapitel beschreibt das Werkzeug für diesen Fall: einen Software-Roboter, der das Programm von außen bedient, so wie bisher ein Mensch.

Ein Programm, das klickt und tippt wie ein Mensch

Robotic Process Automation, kurz RPA, heißt eine Gattung von Software, die die Oberfläche anderer Programme bedient. Sie öffnet Fenster, klickt auf Schaltflächen, liest Felder aus und tippt Werte ein. Der Roboter ist dabei ein Programm, das auf einem Rechner läuft. Van der Aalst, Bichler und Heinzl haben 2018 ein Editorial (externe Seite, link.springer.com) dazu geschrieben. Darin ist RPA ein Oberbegriff für Werkzeuge, die auf der Oberfläche anderer Systeme arbeiten, wie es ein Mensch täte. Das Editorial ist eine Einordnung der Herausgeber einer Fachzeitschrift auf vier Seiten und enthält keine eigene Messung.

UiPath, einer der großen Anbieter, beschreibt RPA als Software-Roboter (externe Seite, uipath.com) für wiederkehrende Aufgaben nach Regeln, etwa die Eingabe von Daten. Wie der Hersteller die Entwicklung von RPA in drei Phasen einteilt, steht schon in Kapitel 01.

Das Programm bleibt, wie es ist

Der Kern der Bauform liegt im Weg, über den sie ein fremdes System erreicht. Eine Schnittstelle führt von innen hinein, sie muss im Programm vorgesehen sein. Der Roboter kommt von außen, über die Masken, die ohnehin für Menschen da sind. Das Editorial nennt das den Unterschied zur herkömmlichen Ablaufsoftware: Das Fachsystem bleibt unverändert (externe Seite, link.springer.com).

Daraus ergibt sich der Ort, an dem RPA eingesetzt wird. UiPath nennt ihn selbst: vor allem dort, wo Systemen eine Schnittstelle fehlt (externe Seite, uipath.com) oder wo sie eine Bedienung in fester Abfolge verlangen. Microsoft beschreibt für die Desktop-Flows von Power Automate ganz ähnliche Einsatzfälle (externe Seite, learn.microsoft.com), darunter das Auslesen von Lie­fe­ran­ten­rech­nungen und die Dateneingabe in ein ERP-System. Bedient wird dort über Elemente der Oberfläche, über Bilder oder über Koordinaten auf dem Bildschirm.

Der Rechnungseingang ohne Schnittstelle

Angenommen, das Buch­hal­tungs­pro­gramm hat nur seine Buchungsmaske. Der Rechnungseingang läuft bis zur Freigabe wie gehabt. Eine Mail mit PDF startet ihn, und ein Modellschritt liest sechs Felder aus. Eine Regel rechnet nach, ob Netto und Steuer den Gesamtbetrag ergeben, und ein Mensch gibt frei. Danach übernimmt der Roboter. Er öffnet die Buchungsmaske, tippt Lieferant, Rechnungsnummer, Datum und Beträge in die Felder und speichert.

seitlich verschiebbar

eigene Darstellung nach der Dokumentation von Power Automate und UiPath, Stand 16.10.2026

Bei Microsoft lassen sich die beiden Hälften auf zwei Bauteile verteilen. Das vortrainierte Rechnungsmodell von AI Builder läuft in einem Cloud-Flow. Der Beispielablauf auf der Seite des Modells (externe Seite, learn.microsoft.com) startet, wenn eine neue Rechnung in einem Ordner landet, und ruft dann das Modell auf. Ein Desktop-Flow übernimmt die Arbeit an der Oberfläche. Er bekommt die ausgelesenen Felder über Eingabevariablen (externe Seite, learn.microsoft.com) aus dem Cloud-Flow. In dieser Aufteilung steckt das Modell im ersten Teil, und der Roboter im zweiten Teil kommt ohne Modell aus.

Der Roboter braucht kein Modell

Klassisches RPA ist ein fester Ablauf. Jeder Klick und jede Eingabe steht vorher im Skript, und bei derselben Maske tut der Roboter jedes Mal dasselbe. Die Prüffrage aus Agenten und Harness, Kapitel 01 lautet: Wer wählt den nächsten Schritt? Beim Roboter wählt ihn das Skript.

Auch beim Lesen ist das Modell bei UiPath eines von mehreren Mitteln. Die Seite zu Document Understanding (externe Seite, docs.uipath.com), dem Dienst für Dokumente, nennt eine Kombination aus Regeln, Vorlagen und Modellen, darunter Fachmodelle und generative Sprachmodelle. Kommt eine Rechnung jeden Monat in derselben Gestalt, kommt eine Vorlage in Frage. Zur Bauform gehört außerdem, dass ein Mensch die ausgelesenen Werte prüfen kann.

Dieselbe Abwägung beschreibt der Beitrag über eine eigene Texterkennung: Eine Regel entscheidet je Seite, ob zum Lesen überhaupt ein Modell nötig ist.

Wo es eine Schnittstelle gibt, geht sie vor

Microsoft ordnet in einem Leitfaden (externe Seite, learn.microsoft.com) zur Leistung von Desktop-Flows die Wege, über die ein Ablauf ein Programm anspricht, vom bevorzugten zum am wenigsten bevorzugten:

1. Konnektoren der Cloud, also fertige Anbindungen an Schnittstellen,
2. Aktionen für bestimmte Programme und Dateien, etwa Excel oder PDF,
3. die Bedienung der Oberfläche über UI-Elemente im Programm oder im Browser,
4. zuletzt Bilderkennung, Maus, Tastatur und Zwischenablage.

Der Hersteller eines RPA-Werkzeugs setzt die Bedienung der Oberfläche damit selbst an die dritte Stelle.

Claude Code ordnet seine Werkzeuge genauso. Computer Use, bei dem das Modell den Bildschirm sieht und klickt, gilt dort als breitester und langsamster Weg (externe Seite, code.claude.com) und kommt zuletzt an die Reihe, wie Claude Code, Kapitel 04 beschreibt. Für den Rechnungseingang heißt das: Bietet die Buchhaltung eines Tages eine Schnittstelle an, wechselt der letzte Schritt dorthin.

Mit Aufsicht oder allein

Roboter laufen auf zwei Arten. Ein beaufsichtigter Roboter (attended) arbeitet am Platz eines Menschen, mit dessen Anmeldung und unter seinen Augen. UiPath sieht diese Art für kleinere Aufgaben (externe Seite, docs.uipath.com) vor, als Beispiel nennt die Seite das Einreichen einer Spesenabrechnung.

Ein unbeaufsichtigter Roboter (unattended) läuft allein auf einer eigenen Maschine. Ein Auslöser oder ein Ereignis startet ihn, und laut UiPath (externe Seite, docs.uipath.com) arbeitet er ohne einen Menschen. Ein Rechnungseingang, der nachts alle freigegebenen Rechnungen bucht, ist ein solcher Fall. Was beide Arten für Rechte und Sicherheit bedeuten, steht in der zweiten Ebene.

Was ohne Modell ginge

Der Roboter selbst kommt ohne Modell aus. Ein Modell braucht der Rechnungseingang nur an einer Stelle, beim Lesen des PDF, und auch dort nur, wenn keine Vorlage passt. Eine elektronische Rechnung bringt ihre Felder gleich mit, wie Kapitel 02 zeigt. Was geschieht, wenn der Roboter ein Feld nicht findet oder mitten in der Buchung abbricht, steht in Kapitel 05.

Die erste Ebene hat den Roboter an das Ende des Rechnungseingangs gesetzt, vor die Buchungsmaske. Diese Ebene sieht ihm bei der Arbeit zu. Sie fragt, wie er ein Feld findet, was ihn aus dem Tritt bringt, wo der Modellschritt seine Unsicherheit meldet und welche Rechte ein Roboter bekommt.

Ein Feld über seine Merkmale finden

Der einfachste Weg zu einem Feld ist seine Stelle auf dem Bildschirm, also ein fester Abstand vom linken und vom oberen Rand. UiPath nennt diesen Weg in der Seite über Selektoren (externe Seite, docs.uipath.com) unzuverlässig. Ein Selektor beschreibt das Feld deshalb über seine Merkmale. Er hält die Attribute des Elements fest und die seiner Eltern, als kleines Stück XML.

Für die Buchungsmaske beginnt die Kette beim Fenster, etwa mit dem Titel „Rechnungen“. Darin liegt ein Bereich für die Kopfdaten, darin das Eingabefeld „Betrag“. Jede Stufe hat ihre Attribute, etwa einen Namen, eine Kennung oder einen Typ. Die Kette beginnt beim obersten Fenster und endet beim Feld.

seitlich verschiebbar

eigene Darstellung nach der Dokumentation von UiPath und Power Automate, Stand 16.10.2026

Power Automate geht denselben Weg. Desktop-Flows arbeiten laut Doku (externe Seite, learn.microsoft.com) mit UI-Elementen und brauchen dafür weder Bilderkennung noch feste Koordinaten. Jedes UI-Element besteht aus einem oder mehreren Selektoren. Wie ein Selektor ein Feld erkennt, hängt vom Programm ab. Neuere Windows-Programme melden ihre Elemente über die Technik UIA, für alte Programme ohne UIA gibt es den älteren Weg MSAA.

Meist entstehen Selektoren von selbst. Wer in UiPath Studio oder Power Automate auf ein Feld zeigt, bekommt den Selektor erzeugt. Von Hand gebaut wird er erst, wenn die Oberfläche sich bewegt.

Was eine geänderte Maske auslöst

Ein Selektor verlässt sich darauf, dass seine Attribute gleich bleiben. UiPath rät deshalb, Attribute mit festem Wert zu wählen. Wechselt ein Wert bei jedem Start des Programms, findet der Selektor das Element nicht mehr (externe Seite, docs.uipath.com). Bei manchen Webanwendungen ändern sich Aufbau und Werte laufend, und Studio kann das laut derselben Seite nicht vorhersehen. Dann bleibt Handarbeit.

Microsoft beschreibt denselben Fall. Ein häufiger Anlass für eigene Selektoren (externe Seite, learn.microsoft.com) sind Programme mit wechselndem Inhalt. Ein fest eingetragener Wert funktioniert in einem gleichbleibenden Programm und kann zum Hindernis werden, sobald sich der Inhalt ändert.

Für den Rechnungseingang heißt das: Ein Update der Buchhaltung kann den Roboter anhalten, auch wenn ein Mensch an der Maske keinen Unterschied sieht. Schon eine andere Bild­schirm­auf­lö­sung reicht. Ein unbeaufsichtigter Desktop-Flow läuft in einer eigenen Sitzung, und deren Auflösung kann von der beim Bau abweichen. Microsoft nennt zwei Folgen: einen Fehler (externe Seite, learn.microsoft.com), weil das Element nicht gefunden wird, oder bei Aktionen mit Maus und Tastatur einen Klick auf das falsche Element. Als Abhilfe nennt Microsoft im selben Absatz, für den unbeaufsichtigten Lauf die passende Auflösung einzustellen.

Die zweite Folge ist die teurere. Ein Fehler hält den Ablauf an, und jemand sieht nach. Ein Klick auf das falsche Feld läuft weiter, und der Betrag steht womöglich im Feld für die Steuer. Wie ein Ablauf solche Fälle bemerkt, steht in Kapitel 05. Wie oft eine Maske einen Roboter anhält, bleibt auf den Seiten beider Hersteller offen.

Was die Hersteller dagegen einbauen

Gegen eine geänderte Maske bieten beide Werkzeuge mehrere Mittel.

• Ersatzselektoren. Ein UI-Element in Power Automate kann mehrere Selektoren haben. Scheitert einer, nimmt der Ablauf den nächsten in der festgelegten Reihenfolge (externe Seite, learn.microsoft.com).
• Selektoren über den Text eines Elements. Hat ein Element selbst immer denselben Text, etwa eine Schaltfläche „Buchen“, kann der Selektor sich daran halten. Der Text muss im Element selbst stehen. Für ein Eingabefeld, dessen Beschriftung daneben steht, gibt es diesen Weg deshalb nicht. Microsoft hält solche Selektoren für beständiger gegen spätere Änderungen am Aufbau der Seite.
• Reparatur von Hand. Im Selektor-Editor von UiPath gibt es eine Schaltfläche „Repair“. Ein Mensch zeigt damit das Element neu, und sie erscheint nur bei einem ungültigen Selektor (externe Seite, docs.uipath.com).
• Ein Video vom Fehlschlag. Power Automate zeichnet bei unbeaufsichtigten Läufen auf Wunsch die letzten 60 Sekunden (externe Seite, learn.microsoft.com) vor einem Fehler auf. Gedacht ist das für nicht erkannte UI-Elemente, Probleme mit dem Timing und unerwartete Meldungen des Betriebssystems.

Alle vier Mittel arbeiten ohne Modell. UiPath bietet inzwischen auch eine Reparatur an, die KI einbezieht, den Healing Agent. Er steht in der dritten Ebene, weil er an der Prüffrage etwas ändert.

Der Modellschritt meldet seine Unsicherheit

Beim Lesen der Rechnung sitzt das Modell, und dort hat es Unterstützung. Das vortrainierte Rechnungsmodell (externe Seite, learn.microsoft.com) von Microsoft erkennt übliche Felder wie Rechnungsnummer, Datum und offenen Betrag und liefert zu jedem Feld einen Sicherheitswert. Der Beispielablauf der Seite vergleicht den Wert für die Gesamtsumme mit der festen Schwelle 0,65. Liegt er darunter, fragt der Ablauf ein zweites, eigens trainiertes Modell. Die 0,65 ist ein Beispielwert der Doku. Dasselbe Rechnungsmodell stellt Kapitel 03 dem Information Extractor gegenüber, der keinen solchen Wert liefert.

Die Summenprüfung bleibt auch bei hohem Sicherheitswert: Ob Netto und Steuer den Gesamtbetrag ergeben, prüft weiter die Regel im Ablauf. Warum die Form einer Antwort und ihr Inhalt zwei Prüfungen brauchen, steht in der zweiten Ebene von Kapitel 01.

Bei UiPath ist das Lesen von Dokumenten gerade im Umbau. Für Dokumente und Mitteilungen ohne feste Form gibt es jetzt IXP (externe Seite, docs.uipath.com), das daraus Daten in fester Form macht. Für strukturierte und halbstrukturierte Dokumente verweist dieselbe Seite weiter auf Document Understanding. Wer heute ein Angebot für das Lesen von Rechnungen vergleicht, klärt deshalb zuerst, welcher der beiden Dienste gemeint ist.

Mit Aufsicht und ohne, genauer

Ein beaufsichtigter Roboter arbeitet mit der Anmeldung des Menschen, an dessen Platz er läuft. UiPath warnt, dass zwischen dem laufenden Roboter und dem Nutzer keine Trennung (externe Seite, docs.uipath.com) besteht. Der Roboter soll deshalb nur tun, was der Nutzer auch selbst darf. Tut er mehr, verschafft er dem Nutzer unbemerkt einen Zugang, den dieser gar nicht hat.

Microsoft bindet den beaufsichtigten Desktop-Flow ebenfalls an den Menschen. Er läuft nur in einer entsperrten Sitzung (externe Seite, learn.microsoft.com), und der angemeldete Nutzer muss derselbe sein wie in der Verbindung des Ablaufs. Ein gesperrter Bildschirm hält ihn an.

Der unbeaufsichtigte Roboter ist von alledem gelöst. In Power Automate startet ihn ein Cloud-Flow (externe Seite, learn.microsoft.com), und er läuft in einer eigenen Sitzung auf einer Maschine, an der niemand sitzt. UiPath hält unbeaufsichtigte Roboter gerade für Aufgaben mit erweiterten Rechten (externe Seite, docs.uipath.com) für geeignet, weil kein Mensch eingreift. Für den Rechnungseingang heißt das: Der Roboter braucht in der Buchhaltung eine eigene Anmeldung, und jemand legt fest, welche Rechte sie bekommt. Gebraucht werden die Rechte zum Buchen.

Die Anzeige, ohne die der Ablauf abbricht

Power Automate für Desktop hat eine Aktion, die Text mit GPT erzeugt, derzeit als Vorschau. Die Referenz der Aktion (externe Seite, learn.microsoft.com) verlangt, dass jeder Ablauf mit dieser Aktion das Ergebnis einem Menschen anzeigt, in einem Eingabedialog oder einer Meldung. Fehlt die Anzeige, endet der Ablauf mit einem Fehler.

Damit setzt das Werkzeug selbst durch, dass ein Mensch das Ergebnis zu sehen bekommt. Die Referenz nennt das eine Prüfung durch einen Menschen und schlägt als Beispiel eine Meldung mit Ja und Nein vor. Verlangt wird die Anzeige. In der dritten Ebene von Kapitel 01 entscheidet der Erbauer des Ablaufs, wo ein Mensch freigibt. Hier hat der Hersteller für eine Aktion zumindest den Blick eines Menschen festgelegt.

Die ersten beiden Ebenen haben den Roboter gebaut und ihm bei der Arbeit zugesehen. Diese Ebene ordnet ihn ein. Sie fragt zuerst, für welchen Teil der Arbeit RPA gedacht war und was das Wort bei verschiedenen Quellen meint. Danach geht es darum, wo ein Modell oder ein Agent in die Bauform kommt, ohne dass sie selbst ein Agent wird.

Der lange Schwanz der Arbeit

Das Editorial von 2018 (externe Seite, link.springer.com) begründet den Platz von RPA mit einem Bild. Man sortiert die Fälle eines Betriebs nach ihrer Art und zählt, wie oft jede Art vorkommt. Typisch sei eine Pareto-Verteilung: 80 Prozent der Fälle gehen auf 20 Prozent der Fallarten zurück.

Die häufigen Arten lohnen eine richtige Integration der Systeme. Die vielen seltenen Arten lohnen sie nicht, weil Automatisierung dafür zu teuer ist, und dort tippen bisher Menschen Daten von einem System ins andere.

RPA zielt nach dem Editorial auf die Mitte dieser Verteilung. Roboter sollen mit den verschiedenen Systemen umgehen, als wären sie Menschen. Das äußerste Ende der seltenen Fälle bleibt bei den Menschen. Ein älterer Versuch war Straight Through Processing aus den 1990er-Jahren. Er ließ sich laut den Herausgebern nur auf wenige Prozesse anwenden (externe Seite, link.springer.com), auf die häufigen Fallarten am linken Rand der Verteilung.

Zwei Einschränkungen gehören zu diesem Bild. Die Zahlen 80 und 20 nennt das Editorial als typischen Fall, die zugehörige Abbildung hat keine Werte an den Achsen. Gemessen ist darin nichts. Und das Wort Agent meint dort den RPA-Roboter, sechs Jahre bevor Sprachmodelle Rechner bedienten. Wer das Editorial heute liest, liest „agents“ in der Bedeutung von 2018.

Drei Zählweisen für RPA

Wer Unterlagen zu RPA vergleicht, klärt zuerst, was das Wort umfasst. Drei Quellen zählen verschieden.

• Das Editorial grenzt RPA über die Oberfläche anderer Systeme ab, auch wenn es gleich danach eine fremde Definition zitiert, die Schnittstellen einschließt. So ist die Bauform in der ersten Ebene beschrieben.
• ProAgent, eine Arbeit von 2023, zählt weiter. In Abschnitt 1 (externe Seite, arxiv.org) nennt sie Zapier, n8n und UiPath als Beispiele für RPA. In Abschnitt 5 heißt es, die Roboter riefen entweder Schnittstellen auf oder ahmten die Bedienung der Oberfläche nach. Nach dieser Zählung wäre auch der Ablauf aus Kapitel 03 RPA.
• UiPath verkauft unter dem Namen RPA eine Plattform und schreibt auf derselben Seite, eine RPA-Plattform müsse Oberfläche, Schnittstelle und KI (externe Seite, uipath.com) anbinden.

Dasselbe Problem mit dem Wort Agent beschreibt die zweite Ebene von Kapitel 01. Ein Satz über RPA kann bei UiPath also einen Ablauf über Schnittstellen meinen. Im Editorial meint er den Roboter vor der Maske.

ProAgent selbst misst nichts in Zahlen. Der Abschnitt 3 der Arbeit heißt Proof-of-Concept und baut einen einzigen Fall nach: Eine Tabelle mit Geschäfts­be­rei­chen wird gelesen. Je nach Art geht eine Meldung an Slack, oder ein Modell schreibt eine Mail mit Einschätzung an die zuständige Leitung. Gebaut ist er auf n8n mit GPT-4. Eine Erfolgsquote oder einen Vergleichswert nennt die Arbeit nicht. Wie sie Entwurf und Ausführung eines Ablaufs trennt, beschreibt die dritte Ebene von Kapitel 01.

Wer den nächsten Schritt wählt, beim Hersteller selbst

UiPath beantwortet die Prüffrage aus Agenten und Harness, Kapitel 01 in der eigenen Doku, und zwar am Beispiel dieses Pfads. Die Seite zur Wahl des Modellierers (externe Seite, docs.uipath.com) in Maestro, dem Werkzeug für ganze Prozesse, trennt zwei Arten. BPMN und Flow sind für Prozesse mit festen Schritten und vorab angelegten Verzweigungen gedacht. Das gilt laut Seite auch dann, wenn einzelne Bausteine wie Agenten nicht vorhersagbar arbeiten.

Als Beispiel nennt die Seite den Rechnungseingang: Rechnung empfangen, Felder auslesen, mit der Bestellung abgleichen, Ausnahmen an einen Freigebenden geben, im ERP-System buchen. Dazu steht der Satz, dass der Weg feststeht und sich nur die Daten ändern. Für Fälle, deren Weg sich erst zur Laufzeit entscheidet, gibt es Case Management. Dort wählen Regeln, ein Agent oder beides (externe Seite, docs.uipath.com) die nächste Stufe.

Eine zweite Seite zieht die Linie zwischen Agent und Workflow (externe Seite, docs.uipath.com) ausdrücklich. Ein Workflow besteht aus vorab festgelegten Schritten mit festen Übergängen. Er kann Modelle, Schnittstellen und Menschen einbinden, plant aber nicht selbst. Die Verbindung beschreibt UiPath so: Agenten treffen die offenen Entscheidungen und übergeben dann an feste Abläufe, die ausführen. Das deckt sich mit der Unterscheidung von Anthropic, die Agenten und Harness, Kapitel 01 verwendet. Der Roboter vor der Maske ist in diesem Bild der Teil, der ausführt.

Wenn ein Modell die Oberfläche bedient

Seit 2024 gibt es Modelle, die einen Rechner selbst bedienen. Wie Computer Use funktioniert, erklärt Grundkurs, Kapitel 09. Hier geht es um die Abgrenzung zum Roboter. OpenAI beschreibt seinen Computer-Using Agent (externe Seite, openai.com) vom Januar 2025 so: Das Modell verarbeitet die Pixel des Bildschirms und bedient eine virtuelle Maus und Tastatur. Laut Hersteller kommt es mit Aufgaben über mehrere Schritte zurecht, mit Fehlern und mit unerwarteten Änderungen. Dieselbe Seite nennt das Modell noch früh und mit Grenzen.

Der Unterschied zum Roboter liegt in der Prüffrage. In der Doku zu Computer Use (externe Seite, developers.openai.com) stellt die Anwendung die Umgebung und führt aus, was das Modell verlangt. Die Schleife läuft so lange, bis das Modell keine Aktionen mehr zurückgibt. Das Modell wählt also den nächsten Klick und auch das Ende des Laufs. Beim Roboter steht beides im Skript.

seitlich verschiebbar

eigene Darstellung nach der Dokumentation von UiPath, OpenAI und Anthropic, Stand 16.10.2026

Was das Modell dem Roboter voraushat, folgt aus dem Aufbau. Es braucht keinen Selektor und sucht eine verschobene Schaltfläche auf dem nächsten Bildschirmfoto. Dagegen stehen Tempo und Genauigkeit. Anthropic schreibt in seiner Doku zum Tool (externe Seite, platform.claude.com), die Bedienung durch das Modell sei im Vergleich zur Bedienung durch einen Menschen womöglich zu langsam. Für Aufgaben, die vollständige Genauigkeit verlangen, rät die Seite zur Aufsicht durch einen Menschen. Eine Buchung ist eine solche Aufgabe.

OpenAI rät, jeden Lauf mit Grenzen für Schritte, Zeit und Kosten zu versehen. Das Ergebnis prüft man laut Doku in der Anwendung selbst, statt sich allein auf die Schlussantwort des Modells zu verlassen.

Eine Zahl dazu meldet OpenAI selbst. Auf dem Benchmark OSWorld, in der Fassung, die im Januar 2025 galt, löste das Modell 38,1 Prozent (externe Seite, openai.com) der Aufgaben am ganzen Rechner, und mit mehr erlaubten Schritten stieg der Wert. Menschen kamen auf 72,4 Prozent. Beides ist eine Angabe des Herstellers. Wie weit die Bedienung von Oberflächen bei längeren Aufgaben hinter anderen Fähigkeiten zurückliegt, zeigt die Messung von METR in der dritten Ebene von Beurteilen und Einordnen, Kapitel 03.

Ein Agent im festen Ablauf, für einen Moment

UiPath setzt an die Stelle, an der ein Roboter scheitert, einen Agenten, der bei Bedarf KI einbezieht. Die Seite zum Healing Agent (externe Seite, docs.uipath.com) nennt die Gründe: Oberflächen ändern sich ständig, dazu kommen Netz, Ladezeiten und wechselnde Techniken der Oberfläche. Als Einsatzfälle nennt sie unbeaufsichtigte und beaufsichtigte Abläufe. Von den unbeaufsichtigten schreibt sie, sie scheiterten häufig, etwa an Ladezeiten, instabilen Selektoren oder unerwarteten Fenstern. Eine Zahl dazu nennt die Seite nicht.

Der Healing Agent arbeitet auf zwei Arten.

1. Er empfiehlt. Scheitert ein Ablauf an der Oberfläche, schlägt er neue Selektoren vor, Wartezeiten an bestimmten Stellen oder geänderten Code für ein unerwartetes Fenster. Ein Mensch übernimmt den Vorschlag oder lässt ihn.
2. Er heilt selbst. Er wendet eine oder mehrere Strategien an, damit der Ablauf weiterläuft. Das ergänzt die Ersatzstrategie, die UiPath unter dem Namen Unified Target schon vorher hatte.

Für die Prüffrage ist die zweite Art die wichtige. Im Moment der Heilung wählt der Healing Agent den nächsten Schritt. Er analysiert dazu laut UiPath den Lauf in diesem Augenblick, und seine Strategien verbinden feste Logik mit KI (externe Seite, docs.uipath.com), wo sie nötig ist. Der feste Ablauf bekommt damit an genau einer Stelle einen Teil, der selbst entscheidet, für die Dauer einer Reparatur. Wie oft dabei ein Modell entscheidet, sagt die Seite nicht. Bei der ersten Art bleibt die Wahl beim Menschen, und der Ablauf ist danach wieder ein fester.

Die Idee ist älter als das Produkt. Schon das Editorial von 2018 (externe Seite, link.springer.com) nennt es ein Ziel von RPA, dass sich die Software an ein geändertes Formular anpasst, so wie ein Mensch es täte. Gemeint ist ein neues Layout bei gleichem Inhalt, und helfen sollen dabei Verfahren des maschinellen Lernens. Derselbe Text warnt: Roboter, die Menschen nachahmen, können nach geänderten Umständen falsche Entscheidungen treffen, und das kann eine Zeit lang unbemerkt bleiben. Ausnahmefälle kann der Roboter an einen Menschen übergeben.

Für den Rechnungseingang folgt daraus eine Bedingung. Eine Selbstheilung, die nach einem Update der Buchhaltung den Betrag in ein anderes Feld tippt, kann im Protokoll aussehen wie ein gelungener Lauf. Jede Heilung muss sich deshalb melden, und eine Rechnung, die danach gebucht wurde, gehört geprüft. Wie ein Ablauf so etwas meldet und was ein halb gelaufener Lauf hinterlässt, steht in Kapitel 05.