Computer Use oder RPA: Die richtige Trennlinie für Legacy-Workflows

RPA klingt nach einem Fabrikroboter, bezeichnet aber einen Software-Bot für wiederkehrende Büroarbeit. Die Abkürzung steht für „Robotic Process Automation“. Ein solcher Bot kann etwa eine Rechnung öffnen, Betrag und Rechnungsnummer in eine Buchhaltungssoftware übertragen, immer dieselben Schaltflächen anklicken und das Ergebnis speichern.

Der Ablauf ist vorher festgelegt. Der RPA-Bot bewertet die Rechnung nicht inhaltlich. Er folgt einem digitalen Rezept: Finde dieses Feld, kopiere seinen Inhalt, klicke dort. Die festen Schritte sorgen für Tempo und berechenbare Ergebnisse. Ändert sich jedoch die Oberfläche oder taucht ein unerwarteter Fall auf, kommt der Bot leicht aus dem Tritt.

Computer-Use-Agenten sollen genau an dieser Grenze flexibler sein. Sie interpretieren den sichtbaren Bildschirminhalt und können Anwendungen bedienen, für die keine API existiert. Doch die gewonnene Anpassungsfähigkeit hat einen Preis: Ein Ablauf, der gestern funktioniert hat, kann heute bei derselben Aufgabe scheitern.

Eine im April 2026 veröffentlichte Zuverlässigkeitsstudie macht diese Schwankung messbar. Ihr Befund ist für den produktiven Einsatz entscheidend: Ein einmaliger Erfolg belegt noch keinen stabilen Prozess. Die sinnvolle Grenze zwischen Computer Use und Robotic Process Automation (RPA) verläuft deshalb nicht zwischen neuer und alter Technik, sondern zwischen Anpassungsfähigkeit und Wiederholbarkeit.

Flexibilität hat einen Zuverlässigkeitspreis

Computer-Use-Agenten interpretieren Bildschirminhalte und wählen während der Ausführung ihre nächsten Aktionen. Laut einem Praxisvergleich des Computer-Use-Anbieters Deck eignen sie sich damit besonders für wechselnde Oberflächen, Legacy-Software und Anwendungen ohne API. Ein Agent kann auf Abweichungen reagieren, für die ein starrer Bot neu konfiguriert werden müsste.

Die wissenschaftliche Studie nennt drei Ursachen für schwankende Ergebnisse: Stochastik während der Ausführung, mehrdeutige Aufgabenbeschreibungen und Unterschiede im Verhalten des Agenten. Kleine Abweichungen bei Interpretation oder Planung können dadurch zu einem anderen Klickpfad führen, obwohl Aufgabe und Umgebung unverändert erscheinen.

Wie groß die Lücke zwischen gelegentlichem und stabilem Erfolg ausfallen kann, zeigt die Studie am System GPT-5 Agent S3. Bei zehn Versuchen lag Pass@10 bei ungefähr 78 Prozent: Für diesen Anteil der Aufgaben war mindestens einer der zehn Läufe erfolgreich. Alle zehn Wiederholungen gelangen dagegen nur bei rund 36 Prozent der Aufgaben. Eine überzeugende Demo sagt damit wenig darüber aus, ob derselbe Ablauf im Tagesgeschäft zuverlässig trägt.

RPA bleibt stark bei festen Abläufen

RPA führt vorgegebene Interaktionen mit einer Oberfläche aus. Im Vergleich von Deck werden dafür beispielsweise UI-Selektoren, Fensterbezüge oder Bildschirmkoordinaten hinterlegt und in einer festen Reihenfolge abgearbeitet. Verschiebt sich ein Element oder ändert sich der Prozess, kann der Bot ausfallen. Bleiben Anwendung und Ablauf stabil, wird diese Starrheit zur Stärke: Das Verhalten ist vorhersehbar und einzelne Schritte lassen sich leichter prüfen.

Deck bezeichnet RPA für etablierte Prozesse mit hohem Volumen weiterhin als Produktionswerkzeug. Computer-Use-Agenten seien dagegen langsamer, weniger deterministisch und auf Aktionsebene schwieriger zu auditieren. Diese Einordnung stammt von einem Anbieter im Computer-Use-Markt. Beim Kernproblem der Wiederholbarkeit passt sie jedoch zu den Messungen der Studie.

Ein regelmäßiger Rechnungslauf mit unveränderten Masken braucht keine improvisierende Software. Hier zählen Durchsatz, reproduzierbare Ergebnisse und ein klarer Prüfpfad. Bei einem selten genutzten internen System ohne Schnittstelle, dessen Oberfläche häufiger wechselt, kann die Anpassungsfähigkeit eines Agenten den zusätzlichen Kontrollaufwand dagegen rechtfertigen.

Die Fehlerfolgen bestimmen die Architektur

Die Auswahl sollte mit einer nüchternen Frage beginnen: Was passiert, wenn der Ablauf falsch entscheidet oder mitten im Prozess abbricht? Scheitert ein Agent sichtbar bei einem Recherche- oder Erfassungsschritt und übergibt den Fall an einen Menschen, bleibt der Schaden begrenzt. Führt dieselbe Schwankung zu falschen Buchungen, unbemerkten Datenänderungen oder mehrfach ausgelösten Aktionen, genügt ein guter Durchschnittswert nicht.

Produkt- und Betriebsteams sollten vor der Automatisierung vier Punkte festhalten:

• Wie häufig ändern sich Oberfläche und Ablauf?
• Müssen Pfad und Ergebnis bei jeder Ausführung identisch sein?
• Lässt sich eine fehlerhafte Aktion erkennen und zurücknehmen?
• Gibt es eine sichere Übergabe an einen Menschen?

Die Antworten sprechen häufig für eine Mischarchitektur. Ein Computer-Use-Agent kann einen wechselhaften Abschnitt bearbeiten und ein geprüftes Ergebnis an einen deterministischen Prozess übergeben. RPA übernimmt anschließend die stabilen, volumenstarken Schritte. Ebenso kann ein klassischer Bot den Normalfall abarbeiten und nur Ausnahmen an einen Agenten weiterreichen.

Wichtig ist eine kontrollierte Übergabe: Daten, Status und Verantwortung müssen an der Grenze zwischen beiden Systemen überprüfbar sein. Sonst verbindet die Architektur nicht die Stärken beider Ansätze, sondern addiert ihre Fehlerquellen.

Abnahmetests müssen Wiederholbarkeit messen

Ein einzelner erfolgreicher End-to-End-Test überschätzt die Einsatzreife. Die Studie unterscheidet ausdrücklich zwischen mindestens einem Erfolg über mehrere Versuche und dem Erfolg in allen Wiederholungen. Für die Abnahme eines produktiven Workflows ist die zweite Perspektive wichtiger: Wie oft läuft die Aufgabe hintereinander vollständig korrekt, wenn Eingabe und Umgebung gleich bleiben?

Danach sollte der Test typische Betriebsvarianten abdecken: leicht veränderte Formulierungen, verschobene Elemente und verzögerte Reaktionen der Oberfläche. Für jeden Fall gehören erwartetes und tatsächliches Verhalten ins Testprotokoll. Die Auswahl sollte sich an den wahrscheinlichen Fehlern des konkreten Prozesses orientieren. Mehrere Durchläufe zeigen dann, ob der Agent Abweichungen auffängt oder selbst zusätzliche Varianz erzeugt.

Ich würde keinen Computer-Use-Workflow freigeben, dessen Team nur eine Erfolgsquote aus Einzelversuchen nennen kann. Zur Abnahme gehören eine Wiederholungsserie, definierte Abbruchbedingungen und ein Test der menschlichen Übergabe. Ebenso muss feststehen, wie ein abgebrochener Lauf in einen bekannten Zustand zurückkehrt und wer die Wiederaufnahme freigibt. Bei schreibenden oder anderweitig schwer rückgängig zu machenden Aktionen braucht es außerdem eine technische Grenze gegen unbeabsichtigte Wiederholungen.

Fazit: Flexibilität nur mit kontrollierbarem Fehlerbild

Computer Use erschließt Anwendungen, die sich bislang nur mit hohem Wartungsaufwand automatisieren ließen. RPA bleibt dennoch die bessere Wahl, wenn Wiederholbarkeit, Volumen und Auditierbarkeit den Prozess bestimmen.

Die Mindestregel lautet: Agenten gehören in Prozessabschnitte, in denen Veränderungen unvermeidbar und Fehler sichtbar, begrenzbar sowie rückgängig zu machen sind. Deterministische Bots gehören dorthin, wo jeder Lauf verlässlich dasselbe tun muss. Erst wenn diese Grenze benannt und getestet ist, wird aus einer gelungenen Demo eine belastbare Automatisierung.