Kurz zusammengefasst
- Nicht die modernste Technologie entscheidet, sondern die stabilste kontrollierbare Schnittstelle für den konkreten Schritt.
- RPA folgt vorgegebenen UI-Schritten und Selektoren; Computer Use interpretiert die Oberfläche fallbezogen mit einem Modell.
- Ein guter Prozess kann API, RPA und Computer Use kombinieren, sollte aber die Grenzen zwischen ihnen sichtbar halten.
- Erfolgsquote allein genügt nicht: Fehlaktionen, menschliche Nacharbeit, UI-Drift, Laufzeit, Kosten und sichere Abbrüche gehören in die Bewertung.
Was unterscheidet API, RPA und Computer Use?
Eine API richtet sich an Software und arbeitet mit expliziten Endpunkten, Feldern und Fehlercodes. RPA richtet sich an eine bestehende Benutzeroberfläche und führt vordefinierte Schritte aus, häufig anhand von UI-Elementen oder Selektoren. Computer Use sieht die Oberfläche über Screenshots oder andere visuelle Signale, interpretiert deren Zustand und erzeugt Maus- sowie Tastaturaktionen dynamisch.
Die visuell flexibelste Option ist nicht automatisch die beste. Je mehr ein Modell den nächsten UI-Schritt selbst wählt, desto schwieriger werden reproduzierbare Tests und desto wichtiger werden Ausführungsgrenzen. Wo eine stabile API verfügbar ist, bleibt sie für Schreiben, Buchen oder Freigeben in der Regel die belastbarere Systemgrenze.
| Zugriffsweg | Stärke | Typische Schwäche | Geeigneter Einsatz |
|---|---|---|---|
| API | Strukturierte Daten, klarer Vertrag, gezielte Rechte und reproduzierbare Fehlerbehandlung | Nicht jede Legacy-Anwendung stellt benötigte Funktionen bereit; Integrationsentwicklung nötig | Stabile Abfragen und Transaktionen mit definierter Fachsemantik |
| RPA | Automatisiert bestehende, wiederholbare Oberflächen ohne Änderung des Zielsystems | Selektoren, Fenster oder Abläufe brechen bei UI-Änderungen und Ausnahmen | Regelbasierte Legacy-Abläufe mit stabiler Oberfläche und überschaubaren Varianten |
| Computer Use | Kann visuell variierende Oberflächen und kontextabhängige Navigation interpretieren | Nicht deterministisch; Screenshots können sensible Daten und fremde Anweisungen enthalten | Begrenzte, schwer integrierbare Fälle, in denen flexible UI-Interpretation einen messbaren Vorteil bringt |
| Menschliche Bearbeitung | Kann neue Ausnahmen, Mehrdeutigkeit und Verantwortung direkt behandeln | Zeitaufwendig und nicht beliebig skalierbar | Seltene, risikoreiche oder unzureichend verstandene Fälle und Eskalationen |
Wie wird der passende Zugriffsweg ausgewählt?
Die Auswahl sollte pro Prozessschritt erfolgen, nicht pauschal für eine ganze Anwendung. Ein System kann beispielsweise Daten zuverlässig über eine API lesen, eine seltene Altmaske nur per RPA öffnen und eine unstrukturierte Beilage mit KI interpretieren. Kritische Schreibaktionen bleiben dabei an der stabilsten verfügbaren Grenze.
- Schritt 1
Fachaktion definieren
Klären, welche Information gelesen oder welche konkrete Änderung ausgeführt werden soll und welche Fehlerfolge sie besitzt.
- Schritt 2
API zuerst prüfen
Existiert ein dokumentierter Endpunkt mit benötigter Semantik, geeigneter Authentisierung, Berechtigung und Fehlerbehandlung, wird er bevorzugt.
- Schritt 3
UI-Stabilität und Regelhaftigkeit bewerten
Ist der Ablauf bekannt und die Oberfläche über robuste Elemente erreichbar, kann RPA die fehlende Schnittstelle überbrücken.
- Schritt 4
Flexibilitätsbedarf nachweisen
Computer Use kommt erst infrage, wenn visuelle Variabilität oder uneinheitliche Navigation mit festen Regeln nicht wirtschaftlich abbildbar ist.
- Schritt 5
Ausfallweg vor Produktivstart festlegen
Timeout, unerwartete Ansicht, Berechtigungsfehler oder geringe Sicherheit müssen zu Abbruch, Warteschlange oder menschlicher Übernahme führen.
Wie sieht eine belastbare hybride Architektur aus?
KI sollte nicht unkontrolliert von einer sichtbaren Information bis zur endgültigen Buchung durchklicken. Ein robuster Aufbau trennt Interpretation, validierte Fachdaten und Ausführung. Computer Use oder Dokumenten-KI können einen Entwurf erzeugen; eine Regelkomponente prüft Pflichtfelder und Werte; die eigentliche Aktion nutzt eine API oder einen eng definierten RPA-Schritt.
- Flexible Wahrnehmung
- KI liest eine Beilage oder findet eine relevante Stelle in einer variierenden Oberfläche. Das Ergebnis bleibt ein Vorschlag mit Herkunft und Unsicherheit.
- Deterministische Validierung
- Schema, Geschäftsregeln, Dublettenprüfung und erlaubte Werte werden in Software geprüft, bevor eine Aktion möglich ist.
- Begrenzte Ausführung
- API oder RPA erhalten nur validierte Felder und dürfen eine klar benannte Transaktion ausführen – nicht frei weiter navigieren.
- Nachweis und Rückweg
- Eingabe, Entscheidung, Aktion, Ergebnis und Ausnahme sind korrelierbar; ein Fehler landet in einer verantworteten Warteschlange.
Welche Rechte und Schutzmassnahmen braucht UI-Automation?
Ein Desktop oder Browser zeigt häufig mehr Daten, als für die aktuelle Aufgabe benötigt werden. Screenshots können Namen, Nachrichten, Passwörter, Gesundheits- oder Finanzangaben erfassen. Deshalb sollte Computer Use in einer dedizierten virtuellen Umgebung mit minimalen Rechten, begrenzten Anwendungen und möglichst eingeschränktem Netzwerkzugang laufen.
Inhalte auf Webseiten, in Dokumenten oder Bildern sind nicht automatisch vertrauenswürdige Anweisungen. Ein Modell kann solche Texte mit dem eigentlichen Auftrag verwechseln. Kritische Entscheidungen – etwa Zahlung, Vertragsannahme, Datenexport oder Löschung – brauchen eine separate, verständliche Freigabe auf Basis der tatsächlichen Aktion und Werte.
- Eigene Serviceidentität und minimale Rollen statt persönlicher Administrationskonten verwenden
- Zielanwendungen, Domains, Aktionen, Dateipfade, Beträge und Empfänger technisch erlauben oder sperren
- Geheimnisse nicht sichtbar eintippen lassen; kurzlebige Zugangsdaten über kontrollierte Mechanismen bereitstellen
- Screenshots vor Speicherung klassifizieren, sensible Bereiche minimieren und Aufbewahrung begrenzen
- Externe Bildschirminhalte als potenzielle Prompt Injection behandeln und nie als Autorisierung akzeptieren
- Vor irreversiblen oder rechtlich relevanten Aktionen eine kontextreiche menschliche Freigabe verlangen
Wie werden Stabilität und Betrieb messbar gemacht?
UI-Automation scheitert nicht nur fachlich, sondern auch an geänderten Fenstern, Selektoren, Ladezeiten, Dialogen oder Bildschirmauflösungen. Microsoft weist beispielsweise darauf hin, dass veränderte Fensternamen oder Elementstrukturen bestehende Selektoren ungültig machen können. Solche UI-Drift gehört als erwartete Betriebsrealität in Monitoring und Wartung.
Tests brauchen eine repräsentative Fallbibliothek mit Standardfällen, Ausnahmen, Berechtigungsfehlern, Pop-ups, langsamen Antworten und absichtlich veränderten Oberflächen. Für Computer Use kommen visuelle Mehrdeutigkeit, manipulierte Bildschirminhalte und sichere Nicht-Ausführung hinzu. Nach jedem Update von Modell, Prompt, Anwendung oder Betriebssystem werden die relevanten Fälle erneut geprüft.
| Messgrösse | Was sie zeigt | Warnsignal |
|---|---|---|
| End-to-End-Erfolgsquote | Anteil korrekt abgeschlossener Fälle einschliesslich fachlichem Resultat | Technisch abgeschlossene, aber fachlich falsch gebuchte Fälle werden nicht separat erfasst |
| Fehlaktions- und Abbruchrate | Falsche Klicks, unerlaubte Aktionen und sichere Stopps nach Ursache | Hohe Erfolgsquote bei gleichzeitig seltenen, aber schweren Fehlaktionen |
| Menschliche Nacharbeit | Zeit für Prüfung, Korrektur, Wiederanlauf und Ausnahmen | Automatisierung verschiebt Arbeit lediglich in eine schwer sichtbare Warteschlange |
| Drift- und Wartungsaufwand | Ausfälle nach UI-, Modell- oder Systemänderungen und Zeit bis Reparatur | Jede kleine Oberflächenänderung löst unplanbare Produktionsausfälle aus |
| Laufzeit und Kosten | Rechen-, Lizenz- und Infrastrukturkosten pro erfolgreichem Fall | Flexibler Computer-Use-Weg ist langsamer und teurer als eine erreichbare API-Integration |
Beispiel: Auftragserfassung in einem Legacy-ERP
Ein Unternehmen erhält Bestellungen als E-Mail-Anhang. Dokumenten-KI extrahiert einen Entwurf. Kundennummer, Artikel, Preis und Lieferadresse werden gegen Stammdaten und Geschäftsregeln geprüft. Das Legacy-ERP besitzt eine Lese-API, aber keine Buchungs-API: Stammdaten werden deshalb über die API geladen, ein RPA-Flow öffnet danach eine stabile Auftragsmaske und füllt validierte Felder ein. Computer Use wird nur für zwei seltene Varianten eingesetzt, bei denen die Maske je Kundentyp anders angeordnet ist; es arbeitet in einer isolierten Sitzung und darf lediglich einen Entwurf speichern. Ein Mensch gibt Preisabweichungen frei. Unerwartete Dialoge, unbekannte Kunden oder UI-Änderungen führen in eine Warteschlange statt zu weiteren Klicks.
Was Sie mitnehmen sollten
Bevorzugen Sie für jede Aktion die strukturierteste und am besten testbare Grenze: API vor stabiler RPA, RPA vor offenem Computer Use. Nutzen Sie visuelle Flexibilität gezielt und kapseln Sie sie mit Validierung, minimalen Rechten, Freigaben und einem belastbaren Ausfallweg.
Quellen und Vertiefung
Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.
Inhaltlich geprüft