Browser-Automatisierung mit KI: Möglichkeiten und Grenzen

Browser-Automatisierung mit KI ist der Punkt, an dem Agenten den Schreibtisch verlassen und im echten Arbeitsalltag ankommen. ChatGPT Atlas, Perplexity Comet und Claude mit Cowork steuern inzwischen echte Browser: Sie lesen Seiten, klicken Buttons, füllen Formulare aus. Wir setzen das bei EverBright täglich produktiv ein, etwa für Wettbewerbs-Monitoring und das Posten in interne Tools. Dabei haben wir gelernt, wo der Ansatz glänzt und wo er an harte Grenzen stößt. Dieser Erfahrungsbericht sortiert beides.

Zwei Ansätze: DOM-Zugriff oder Screenshot

Klassische Browser-Automatisierung arbeitet auf dem DOM. Werkzeuge wie Playwright oder Selenium finden Elemente über Selektoren und lösen Aktionen direkt im Browser aus:

import { chromium } from "playwright";

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto("https://beispiel-portal.de/login");
await page.fill("#username", user);
await page.click("button[type=submit]");

Das ist schnell und deterministisch, aber fragil: Ändert sich ein Selektor, bricht das Skript. Jede Änderung am Portal bedeutet Wartungsaufwand.

KI-Agenten gehen anders vor. Sie machen einen Screenshot, interpretieren die Seite visuell und entscheiden dann, wohin geklickt wird. Anthropic nennt das Computer Use, OpenAI setzt mit Atlas auf dasselbe Prinzip. Der Agent braucht keine Selektoren und keine API-Dokumentation. Er sieht, was ein Mensch sieht, und kommt deshalb auch mit Oberflächen zurecht, die er nie zuvor gesehen hat. Moderne Agenten kombinieren beides: DOM-Zugriff, wo er verfügbar ist, Screenshots als Rückfallebene.

Der Unterschied zu klassischem RPA liegt in der Robustheit gegenüber Veränderung. Ein RPA-Bot folgt einem aufgezeichneten Pfad. Ein KI-Agent verfolgt ein Ziel und findet den Pfad selbst, auch wenn das Layout gestern geändert wurde.

Was in der Praxis funktioniert

Drei Einsatzmuster haben sich bei uns bewährt.

Erstens: interne Tools ohne API. Unser Team postet Berichte automatisiert in Mattermost. Eine API-Anbindung wäre möglich gewesen, aber der Browser-Weg war in einer Stunde produktiv, weil der Agent einfach die bestehende Oberfläche bedient. Dasselbe gilt für Lieferantenportale, Buchungssysteme und Legacy-Anwendungen, bei denen niemand mehr eine Schnittstelle nachrüstet.

Zweitens: bestehende Login-Sessions nutzen. Der Agent arbeitet im Browser-Profil, in dem bereits eine angemeldete Session existiert. Es müssen keine Zugangsdaten an ein Skript übergeben oder API-Tokens erzeugt werden. Der Agent selbst bekommt die Passwörter nie zu sehen, was aus Sicherheitssicht ein echter Vorteil gegenüber Credentials in Konfigurationsdateien ist.

Drittens: Recherche über viele Seiten hinweg. Für unser Wettbewerbs-Monitoring besucht ein Agent wöchentlich ein Dutzend Websites, erkennt Änderungen und fasst sie zusammen. Seiten, die stark auf JavaScript setzen und sich per HTTP-Request gar nicht sinnvoll laden lassen, sind damit plötzlich auswertbar, weil der Agent einen vollwertigen Browser mit Rendering nutzt.

Die Grenzen: Tempo, Bot-Erkennung, Spielregeln

Ehrlicherweise ist Browser-Automatisierung mit KI in mehreren Punkten die schlechtere Wahl.

Geschwindigkeit ist die offensichtlichste Grenze. Ein API-Call dauert Millisekunden. Ein Agent, der eine Seite lädt, einen Screenshot interpretiert und dann klickt, braucht pro Schritt mehrere Sekunden. Für einen Workflow mit fünf Schritten ist das egal. Für tausend Datensätze pro Stunde ist es ein Ausschlusskriterium.

Bot-Erkennung kommt dazu. Cloudflare, DataDome und ähnliche Systeme erkennen automatisierte Browser an Fingerprints, Mausbewegungen und Timing-Mustern. Seriöse Anbieter wie Anthropic lassen ihre Agenten CAPTCHAs bewusst nicht lösen, und das ist richtig so: Ein CAPTCHA ist die explizite Ansage des Betreibers, dass Automatisierung unerwünscht ist. Wer an dieser Stelle Umgehungstricks einsetzt, verletzt Nutzungsbedingungen und riskiert Account-Sperrungen. Dasselbe gilt für Paywalls. In unseren Projekten gilt deshalb die Regel: Automatisiert wird nur, was der Betreiber erlaubt, im Zweifel klärt das ein Blick in die Terms of Service.

Rate Limits sind die dritte Grenze. Auch ohne Bot-Erkennung drosseln viele Dienste auffällige Zugriffsmuster. Ein Agent, der zu schnell zu viele Seiten abruft, landet auf der Sperrliste. Und schließlich bleibt die Zuverlässigkeit: Agenten interpretieren Seiten manchmal falsch, klicken daneben oder übersehen einen Dialog. Für destruktive Aktionen wie Löschen oder Absenden gehört deshalb immer eine Freigabe durch einen Menschen in den Workflow. Wie man solche Guardrails technisch umsetzt, beschreibt unser Artikel zum Thema KI-Agenten absichern.

Wann Browser-Automatisierung die richtige Wahl ist

Aus unserer Projekterfahrung ergibt sich eine einfache Rangfolge. Gibt es eine API, nimm die API. Sie ist schneller, stabiler und vom Anbieter gewollt. Gibt es keine API, aber das Ziel ist ein internes oder selbst betriebenes System, ist der KI-Agent im Browser eine pragmatische Lösung mit minimalem Integrationsaufwand. Bei fremden Websites gilt: Nutzungsbedingungen prüfen, Frequenz niedrig halten, keine Schutzmechanismen umgehen.

Vier Fragen helfen bei der Entscheidung. Wie oft läuft der Prozess und wie zeitkritisch ist er? Wem gehört das System, das automatisiert wird? Was passiert, wenn der Agent einen Fehler macht? Und rechnet sich der Wartungsaufwand gegenüber einer sauberen Integration? Wer die Antworten kennt, erspart sich sowohl überengineerte API-Projekte für einen wöchentlichen Handgriff als auch wackelige Browser-Workflows für geschäftskritische Massenprozesse. Welche Agenten-Plattform sich für den Einstieg eignet, haben wir im Vergleich OpenClaw vs. Cowork untersucht.

Fazit

Browser-Automatisierung mit KI schließt eine Lücke: Prozesse, für die es nie eine API gab, lassen sich mit wenig Aufwand automatisieren, solange Tempo und Volumen im Rahmen bleiben. Sie ersetzt keine Schnittstellen-Integration, sondern ergänzt sie dort, wo Integration unwirtschaftlich wäre. Wer beide Werkzeuge kennt, wählt pro Prozess das richtige.

Wenn Sie prüfen möchten, welche Ihrer Prozesse sich für KI-Agenten eignen, unterstützen wir von der Use-Case-Bewertung bis zum produktiven Betrieb: KI & Automatisierung bei EverBright oder direkt per Mail an info@everbright-it.de.

Häufige Fragen

Wie steuern KI-Agenten einen Browser?

KI-Agenten kombinieren zwei Techniken: direkten Zugriff auf den DOM der Seite und visuelle Interpretation von Screenshots. Der Agent erkennt Buttons, Formulare und Texte, plant den nächsten Schritt und führt Klicks oder Eingaben aus. Anders als starre Skripte verfolgt er ein Ziel und passt sich an, wenn sich das Layout ändert.

Was unterscheidet KI-Browser-Automatisierung von klassischem RPA?

RPA-Bots spielen fest definierte Klickpfade ab und brechen, sobald sich die Oberfläche ändert. KI-Agenten interpretieren die Seite bei jedem Durchlauf neu und finden ihren Weg auch nach Layout-Änderungen. Dafür sind sie langsamer und weniger deterministisch, weshalb RPA bei stabilen Masken mit hohem Volumen weiterhin die bessere Wahl sein kann.

Dürfen KI-Agenten CAPTCHAs oder Paywalls umgehen?

Nein. CAPTCHAs und Paywalls sind explizite Schutzmechanismen des Betreibers. Seriöse Agenten-Plattformen wie Anthropic blockieren das Lösen von CAPTCHAs bewusst. Wer solche Mechanismen umgeht, verstößt gegen Nutzungsbedingungen und riskiert Sperrungen. Automatisiert werden sollte nur, was der Betreiber der Website erlaubt.

Wann ist eine API besser als Browser-Automatisierung?

Immer dann, wenn eine API existiert und der Prozess häufig, zeitkritisch oder geschäftskritisch ist. APIs sind um Größenordnungen schneller, stabiler und vom Anbieter unterstützt. Browser-Automatisierung lohnt sich als pragmatischer Weg für Systeme ohne Schnittstelle, für seltene Workflows und für schnelle Proof of Concepts.