Vom Demo-Video zur echten Automatisierung
Vor anderthalb Jahren war Computer Use noch eine Anthropic-Demo: Eine KI bewegt einen Mauszeiger, klickt auf Buttons, tippt in Felder. Beeindruckend, aber langsam, fehleranfällig und kaum produktiv einsetzbar. Heute, im Frühjahr 2026, sind Browser-Agenten in einem Reifegrad angekommen, der echte Workflows automatisierbar macht.
Wir setzen sie inzwischen in mehreren Kundenprojekten ein – für Datenmigrationen, Recherche-Tasks und Integrationen mit Systemen, die keine API anbieten. Nicht jeder Use Case ist plötzlich automatisierbar. Aber die Liste der sinnvollen Einsatzfelder ist deutlich länger geworden.
Wie sich die Technik verändert hat
Die alte Generation der Browser-Automatisierung – Selenium, Puppeteer, Playwright – funktioniert über CSS-Selektoren und DOM-Pfade. Sobald sich das HTML einer Seite ändert, brechen die Skripte. Jedes Re-Design einer Drittanbieter-Software bedeutete tagelange Wartung.
Die neue Generation arbeitet über visuelles Verständnis. Der Agent sieht den Bildschirm wie ein Mensch – als Pixel oder über das Accessibility-Tree – und entscheidet auf Basis dessen, was er sieht. „Klicke auf den Speichern-Button" ist eine Anweisung, die er versteht, auch wenn der Button morgen woanders liegt oder anders aussieht. Das macht Browser-Agenten robust gegen UI-Änderungen, die klassische Skripte zerlegen würden.
Hinzu gekommen sind drei wichtige Verbesserungen:
Geschwindigkeit: Der Roundtrip Screenshot → Modell → Aktion ist von mehreren Sekunden auf unter eine Sekunde gefallen. Damit lassen sich Workflows mit dutzenden Schritten in Minuten statt Stunden ausführen.
Zuverlässigkeit: Die Erkennungsgenauigkeit für UI-Elemente liegt bei den führenden Modellen über 95 %. Das ist nicht perfekt, aber gut genug für überwachte Workflows.
Kostenstruktur: Ein typischer Browser-Workflow kostet heute zwischen 5 Cent und 1 Euro – je nach Länge. Damit rechnet sich Automatisierung auch für mittlere Volumen.
Wofür Browser-Agenten sich eignen
Aus unseren Projekten kristallisieren sich klare Stärken heraus:
Legacy-System-Integration: Wenn ein altes ERP- oder CRM-System keine API hat, war früher die einzige Option, einen Mitarbeiter durch das System klicken zu lassen oder ein fragiles Selenium-Skript zu pflegen. Browser-Agenten sind die neue, robustere Variante.
Datenextraktion aus Webseiten: Recherche-Tasks, die Daten von verschiedenen Webseiten zusammenziehen, sind ein natürliches Einsatzfeld. Anders als beim klassischen Web-Scraping muss der Agent nicht für jede Seite einzeln programmiert werden – er versteht die jeweilige Seite ad hoc.
Wiederholte Verwaltungsaufgaben: Anträge in Behördenportalen, Bestellungen über Lieferantenportale, Rechnungsupload in fremden Buchhaltungssystemen. Aufgaben, bei denen ein Mensch täglich dieselben Schritte in einer fremden Oberfläche durchführt – ideale Kandidaten.
End-to-End-Tests: Statt Test-Skripte gegen jede UI-Änderung anzupassen, kann ein Agent angewiesen werden, „die Bestellstrecke vollständig durchzulaufen und Auffälligkeiten zu melden". Die Wartung der Tests verlagert sich von Code zu Anweisungen.
Wofür sie sich nicht eignen
Genauso wichtig: Wo Browser-Agenten heute noch scheitern.
Hochfrequente Vorgänge: Wenn etwas hundertmal pro Minute laufen muss, ist ein Browser-Agent zu langsam und zu teuer. Hier bleibt die API-basierte oder klassische Skript-Lösung erste Wahl.
Sicherheitskritische Aktionen: Banking, Geld-Transfers, Vertragsabschlüsse – alles, was finanzielle oder rechtliche Konsequenzen hat. Selbst eine Fehlerrate von 1 % ist hier nicht akzeptabel.
Captcha- und Bot-Erkennung: Viele Webseiten erkennen automatisierte Bedienung und blockieren sie. Ein Browser-Agent ist legitim, wenn er die eigenen Systeme oder die eigenen Konten bedient. Auf fremden Plattformen kann er gegen die AGB verstoßen – juristisch ein Minenfeld.
Sehr lange Workflows: Aufgaben mit mehr als 30–40 Schritten akkumulieren Fehler. Wenn der Agent in Schritt 27 einen falschen Button klickt, stimmt die Welt ab da nicht mehr. Längere Workflows sollten in Etappen mit Zwischen-Validierung zerlegt werden.
Die Architektur, die funktioniert
Die produktionsreifen Browser-Agenten-Setups, die wir gebaut haben, folgen einem ähnlichen Muster:
Trennung von Orchestrator und Browser-Agent: Ein Orchestrator-System (oft ein Workflow-Tool oder eine eigene Backend-Komponente) entscheidet, welche Workflows ausgeführt werden. Der Browser-Agent erhält klare, abgegrenzte Aufgaben mit definiertem Erfolgskriterium.
Sandboxed Execution: Der Agent läuft in einer isolierten Browser-Umgebung – Container, eigener User-Account, eingeschränkte Netzwerkzugriffe. So bleibt der Schaden eines Fehlers begrenzt.
Validation Layer: Nach jedem Workflow validiert ein zweiter Mechanismus – oft eine API-Abfrage, ein Datenbank-Check oder ein zweiter Agent – ob das gewünschte Ergebnis erreicht wurde. Reiner Self-Report des Agenten reicht nicht.
Human-in-the-Loop für Edge Cases: Wenn der Agent unsicher ist oder auf etwas Unerwartetes trifft, eskaliert er an einen Menschen. Diese Eskalations-Schwelle bewusst zu kalibrieren ist wichtiger als die Modellwahl.
Die rechtlichen und ethischen Fallstricke
Browser-Agenten bewegen sich in einer Grauzone. Drei Punkte sollten vorab geklärt sein:
Erlaubnis durch den Plattformbetreiber. Wenn ein Agent auf der eigenen Webseite oder im eigenen Account läuft, ist das unproblematisch. Auf fremden Plattformen können AGB-Verstöße drohen. Ein klärender Blick in die Terms of Service spart Ärger.
Datenschutz. Browser-Agenten sehen alles, was auf dem Bildschirm ist – auch Daten, die der Agent gar nicht braucht. Wer das System mit Patienten-, Kunden- oder Mitarbeiterdaten konfrontiert, muss die Datenflüsse dokumentieren und absichern.
Verantwortung bei Fehlern. Wenn ein Browser-Agent eine falsche Bestellung auslöst, eine falsche Form einreicht oder einen Fehler in ein Drittsystem schreibt – wer haftet? Das gehört in den Vertrag mit dem Anbieter und in die internen Prozesse.
Was das für Unternehmen bedeutet
Browser-Agenten sind das fehlende Stück für Automatisierung in Unternehmen mit heterogener System-Landschaft. Wer Kunden- oder Mitarbeiter-Workflows betreibt, die heute manuell durch fremde Oberflächen geklickt werden, sollte 2026 zumindest evaluieren, was sich automatisieren lässt. Die Einsparungen sind real, der Implementierungsaufwand ist überschaubar geworden.
Wir bei nh labs starten solche Projekte mit einem schnellen Mapping: Welche Workflows sind häufig genug, klar genug und tolerant genug für Browser-Automatisierung? Aus dieser Liste wird der erste Pilot – fast immer mit ROI in unter drei Monaten.
Fazit
Browser-Agenten sind 2026 dort angekommen, wo Code-Agenten 2024 standen: nicht überall einsetzbar, aber für die richtigen Aufgaben überraschend gut. Wer jetzt erste Erfahrungen sammelt, baut eine Automatisierungs-Kompetenz auf, die in den nächsten Jahren strategisch wichtig wird. Wer wartet, bis die Technologie „komplett ausgereift" ist, verschenkt ein bis zwei Jahre Optimierungspotenzial – und überlässt seinen Wettbewerbern den Vorsprung.