Zum Inhalt springen
Implementa.

Einen KI-Agent bauen · Guide 16 von 16

KI-Agent, der im Browser arbeitet: die letzte Option, nicht die erste

Ein KI-Agent, der im Browser arbeitet, öffnet ein Browserfenster, schaut auf den Bildschirm, bewegt den Cursor und klickt — genau wie ein Mensch. Deshalb wird er falsch ausgewählt: Es klingt nach Universallösung. Tatsächlich ist es der langsamste, teuerste und fragilste Weg von allen, und sein Wert liegt nicht darin, was er kann, sondern darin, wann nichts anderes übrig bleibt. Hier sind die drei Fälle, in denen es keine andere Tür gibt, die fünf Ausfälle, die garantiert auftreten, weil sie auf dem Bildschirm eines anderen leben, warum ein Benchmark-Wert deinen nicht vorhersagt, und die vier Bedingungen, die ein Experiment von etwas trennen, das man laufen lassen kann.

Ein KI-Agent, der im Browser arbeitet, ist die letzte Option, nicht die erste

Ein KI-Agent, der im Browser arbeitet, tut genau das, wonach es klingt: Er öffnet ein Browserfenster, schaut auf den Bildschirm, bewegt den Cursor, tippt und klickt, so wie es ein Mensch täte. Und genau darin liegt die Falle, denn es klingt nach Universallösung: Wenn ein Mensch das kann, kann der Agent das auch. Stimmt — und ist belanglos. Ein Mensch kann auch tausend Zeilen von Hand abtippen. Dass etwas möglich ist, macht es noch nicht zur vernünftigen Vorgehensweise.

Die These, ohne Umwege: der Browser ist Plan D. Davor stehen die API des Systems auf der Gegenseite, die Integration über Konnektor oder iPaaS und — häufiger, als zugegeben wird — ein Mensch, der täglich zehn Minuten für etwas aufwendet, das keinerlei Automatisierung rechtfertigt. Der Browser kommt erst ins Spiel, wenn alle drei wirklich verschlossen sind. Die sauberen Wege stehen in KI in deine Systeme integrieren: Jener Leitfaden schließt alles aus, was kein Anschluss zum Einstöpseln ist, und dieser beginnt genau dort, wo er aufhört — bei dem Fall, den er ausschließt.

Der Grund für so viel Vorsicht: Dieser Weg scheitert nicht am Modell. Er scheitert an Dingen außerhalb deiner Kontrolle — dem Bildschirm eines anderen, der Sitzung eines anderen, den Regeln eines anderen. Du kannst alles richtig machen und an einem Dienstag mit einem stehenden Prozess aufwachen, weil jemand einen Button verschoben hat.

Die drei Fälle, in denen es keine andere Tür gibt

Es gibt Situationen, in denen der Browser keine Bequemlichkeit ist, sondern das Einzige, was bleibt. Sie haben ein gemeinsames Erkennungszeichen — es ist nicht so, dass die API noch nicht existiert, sie wird nicht existieren.

  1. Das Portal des Lieferanten oder des Großkunden. Du musst dich in deren Extranet einloggen, um Lieferscheine hochzuladen, Abrechnungen herunterzuladen oder Bestellungen zu bestätigen. Keine API, es wird auch keine geben, und dein Volumen rechtfertigt nicht, dass man eine für dich baut. Die Geschäftsbeziehung läuft in eine Richtung, und es ist nicht deine.
  2. Die Verwaltung. Behördenportale, Vergabeplattformen, Register. Der Zugang ist hier für eine Person mit ihrem Zertifikat gedacht, und der automatisierte Weg existiert entweder nicht oder verlangt eine formale Integration, deren Genehmigung Monate dauert. Vorsicht vor der Annahme, öffentlich hieße offen: Das ist nicht dasselbe.
  3. Das alte Inhouse-System. Dieses ERP von 2009, die Desktop-Anwendung im Lager, das Programm eines Anbieters, den es nicht mehr gibt. Es hat eine Datenbank, aber niemand unterschreibt, sie anzufassen; es hat einen Bildschirm, und der Bildschirm funktioniert. Die API existiert nicht, weil das Budget dafür nicht existiert — eine vollkommen gültige Art, nicht zu existieren.

Das Gegenbeispiel zählt genauso viel wie die Fälle. Wenn der Anbieter eine API hat und sie dir nur nicht gibt, weil sie in einer anderen Preisstufe liegt, ist das kein technisches Problem, sondern eine Verhandlung. Einen Browser-Agenten zu bauen, um den Konnektor nicht zu bezahlen, kostet im ersten Jahr meist mehr Wartung als der Konnektor selbst — und stellt dich zusätzlich auf die unangenehme Seite ihrer Nutzungsbedingungen. Bevor du die erste Zeile schreibst: Frag nach dem Preis. Manchmal ist die rentabelste Automatisierung eine E-Mail an einen Vertriebler.

Was immer kaputtgeht: fünf Ausfälle, die nicht in deiner Hand liegen

Diese fünf sind keine hypothetischen Risiken, die vielleicht auftreten. Sie sind der Wartungskalender jedes Agenten, der im Browser eines anderen lebt. Wer dir das verkauft, ohne sie zu erwähnen, hatte es nie in Produktion.

  • Die Oberfläche ändert sich, und niemand sagt dir Bescheid. Keine Versionierung, keine Release Notes, keine Übergangsfrist. Ein Redesign, ein neues Pflichtfeld oder ein anderes Cookie-Banner, und der Ablauf bleibt auf halbem Weg stehen. Bei einer kaputten API erfährst du es über einen Fehlercode; hier erfährst du es, weil jemand fragt, warum die Rechnungen nicht angekommen sind.
  • Die Sitzung läuft ab, und der zweite Faktor verhandelt nicht. Einen Agenten in einem Fremdsystem angemeldet zu halten, ist das langweilige Problem, das die Hälfte der Betriebszeit frisst. Verlangt der Zugang einen Einmalcode, eine App auf dem Handy von jemandem oder ein Zertifikat auf einer Karte, dann ist per Design ein Mensch im Ablauf. Das ist kein Fehler des Agenten: Es ist eine Sicherheitsentscheidung der Gegenseite, und sie ist berechtigt.
  • Das Captcha und die Nutzungsbedingungen. Ein Captcha ist keine technische Hürde, die man umfährt: Es ist die ausdrückliche Ansage der Gegenseite, keinen automatisierten Verkehr zu wollen. Es zu überwinden bricht in der Regel die Nutzungsbedingungen und je nach Kontext noch etwas mehr als die Bedingungen. Wenn ein Captcha auftaucht, ist das richtige Gespräch nicht das mit der Technik, sondern das mit demjenigen, der den Vertrag unterschreibt.
  • Die Seite, die er liest, kann ihm auch Befehle geben. Ein Browser-Agent trennt nicht zuverlässig zwischen dem Inhalt, den er lesen soll, und einer darin versteckten Anweisung. Das ist kein Reifeproblem kurz vor der Lösung: OpenAI erklärte im Dezember 2025, dass Prompt Injection — ähnlich wie Betrug und Social Engineering im Netz — wohl nie vollständig gelöst sein wird (TechCrunch, 22. Dezember 2025), und Anthropic veröffentlichte seine Robustheitsergebnisse zur Browsernutzung mit dem ausdrücklichen Hinweis, dass kein Browser-Agent immun ist (Anthropic, 24. November 2025). Die praktische Konsequenz ist architektonisch, keine Frage des Prompts: Der Agent kann nur so weit Schaden anrichten, wie seine Zugangsdaten reichen.
  • Kosten und Uhr zählen pro Schritt. Jeder Schritt ist ein Screenshot, eine Modellentscheidung und eine Aktion. Eine Aufgabe mit zwölf Schritten sind zwölf Entscheidungen mit Bild, kein einzelner Aufruf. Was per API eine Anfrage im Millisekundenbereich ist, sind hier Minuten und ein Verbrauch, der mit jedem Wiederholungsversuch wächst.

Warum der Benchmark-Wert deinen nicht vorhersagt

Die öffentlichen Zahlen dieser Kategorie sind besser, als viele denken, und schlechter, als die Demo suggeriert. Auf WebArena, dem Referenz-Testfeld, liegt das beste in der öffentlichen Rangliste geführte System bei rund 74 % gelöster Aufgaben gegenüber 78 %, die ein Mensch erreicht (Steel.dev, WebArena-Rangliste). OpenAI berichtete für seinen Computer-nutzenden Agenten 87 % auf WebVoyager und 58,1 % auf WebArena in internen Tests. Respektable Werte für ein schweres Problem.

Das Problem ist, was sie messen. Diese Testfelder laufen auf Nachbauten öffentlicher Seiten, auf dem guten Pfad, ohne Unternehmensanmeldung, ohne zweiten Faktor, ohne Captcha und — das ist der entscheidende Punkt — ohne Konsequenz. Ein Fehlklick im Benchmark fügt einer Tabelle einen Fehlschlag hinzu. Ein Fehlklick im Portal deines Lieferanten bestätigt eine Bestellung über elftausend Euro. Es gibt keine Möglichkeit, einen Prozentwert vom Ersten auf das Zweite zu übertragen, also versuch es gar nicht: Die einzige Zahl, die zählt, ist deine — gemessen auf deinem Portal, mit deinen echten Fällen, über zwei Wochen im Beobachtungsmodus.

Übersetzt in eine Entscheidung: Kauf nicht nach Demo und nicht nach Rangliste. Verlang einen Test auf deinem Bildschirm, die unangenehmen Fälle eingeschlossen — der Lieferant, der die Rechnungsnummer mit Bindestrich schreibt, die Bestellung mit zwei stornierten Positionen — und zähl, wie oft eingegriffen werden muss. Dieser Prozentsatz entscheidet, ob der Prozess Arbeit spart oder sie nur an eine andere Stelle verschiebt.

Die vier Bedingungen für den Produktivbetrieb

Wenn der Fall legitim ist und der Test vernünftig lief, fehlt noch der Teil, der ein Experiment von etwas trennt, das allein weiterlaufen kann. Vier Bedingungen, keine davon optional: Bei drei von vier geht das nicht in Produktion.

  1. Umkehrbare Aktion. Der Agent führt nur Dinge aus, die sich rückgängig machen lassen, ohne jemanden anzurufen: herunterladen, lesen, einen Entwurf ausfüllen, speichern ohne Senden. Bestätigen, zahlen, unterschreiben und stornieren bleiben ab Tag eins außerhalb des automatischen Umfangs, auch wenn der Agent sie problemlos anklicken könnte.
  2. Harte Schrittgrenze. Eine Obergrenze an Aktionen pro Aufgabe, die beim Erreichen stoppt und meldet. Ohne sie wiederholt ein Agent, der sich auf einem Bildschirm verirrt hat, bis das Budget aufgebraucht ist — und der erste Hinweis darauf, dass etwas schieflief, steht auf der Rechnung.
  3. Aufzeichnung jeder Aktion. Screenshot oder Protokoll, was er gesehen und was er geklickt hat, bei jedem Schritt, außerhalb der Sitzung gespeichert. Das ist keine Bürokratie: Es ist das Einzige, womit sich rekonstruieren lässt, was passiert ist, wenn der Lieferant sagt, eine Bestellung sei bestätigt worden, an die sich niemand erinnert. Ohne Nachweis keine Prüfung, und ohne Prüfung ist das kein System, sondern eine Wette.
  4. Mensch bei allem Unumkehrbaren. Der Schritt, der Geld bindet, etwas an Dritte sendet oder einen nicht rücknehmbaren Zustand ändert, geht über eine Person, die sieht, was gleich passiert, und es freigibt. Mit genug Kontext, um in zehn Sekunden zu entscheiden — nicht ein Fenster, das aus Gewohnheit weggeklickt wird.

Die beiden letzten Bedingungen sind nicht spezifisch für diesen Weg: Es sind dieselben, die welche Berechtigungen ein KI-Agent bekommt und wie viel Autonomie man ihm gibt regeln. Was sich hier ändert, ist der Spielraum: Wenn der Agent auf dem Bildschirm eines anderen handelt, mit den Zugangsdaten eines deiner Mitarbeitenden, bleibt der Fehler nicht im Haus.

Die Entscheidungsreihenfolge, an einem Nachmittag

Vier Fragen, in dieser Reihenfolge. Das erste Ja entscheidet, und wenn du bei der vierten ankommst, weißt du bereits, worauf du dich einlässt.

  1. Gibt es eine API, und kann man sie dir geben? Wenn sie existiert, selbst kostenpflichtig, frag nach dem Preis, bevor du irgendetwas programmierst. Ein langweiliger Konnektor schlägt einen brillanten Agenten, der bei jedem Redesign bricht.
  2. Gibt es eine fertige Integration — Konnektor, iPaaS, geplanter Export? Der nächtliche Export in eine Datei, mit dem in keiner Demo geprahlt wird, löst mehr Prozesse, als man meint, und er bricht nicht.
  3. Wie viel menschliche Arbeit steckt hier wirklich? Zehn Minuten am Tag bezahlen nicht die Wartung eines Browser-Agenten. Miss es, bevor du entscheidest; manchmal ist das Ergebnis der Übung, nicht zu automatisieren, und das ist eine völlig gute Antwort.
  4. Wenn du bis hierher gekommen bist: Sind alle vier Bedingungen erfüllt? Umkehrbar, Schrittgrenze, alles aufgezeichnet, Mensch beim Unumkehrbaren. Fehlt eine, ist der Prozess nicht bereit, und ihn zu erzwingen heißt, ein Risiko einzukaufen, um sich einen Vorgang zu sparen.

Wir kommen widerwillig zu diesem Weg und nutzen ihn, wenn es sein muss — häufiger, als uns lieb ist: Ein guter Teil Europas rechnet noch immer gegen Portale ohne API ab. Wenn es so weit ist, bauen wir ihn mit allen vier Bedingungen ab Tag eins und mit eingeplanter Wartung, denn was diese Projekte umbringt, ist nicht das Bauen, sondern das dritte Redesign. Das steckt unter Automatisierung des Betriebs und unter KI-Infrastruktur für Unternehmen, wenn der Prozess mit Systemen koexistieren muss, die bereits in Produktion sind. Die übrigen Aufbauentscheidungen — Berechtigungen, Autonomie, Gedächtnis, Kanal — stehen in einen KI-Agenten bauen, der Produktion aushält.

Häufig gestellte Fragen

Wenn das System auf der Gegenseite keine API hat und auch keine bekommen wird. Drei typische Fälle: das Lieferanten- oder Großkundenportal, in das du dich einloggen musst und bei dem dein Volumen nie rechtfertigen wird, dass man etwas für dich baut; die Verwaltung, wo der Zugang für eine Person mit Zertifikat gedacht ist; und das alte interne System, das einen Bildschirm hat, aber kein Budget für eine API. Ein Signal trennt den legitimen Fall von der Bequemlichkeit: Wenn die API existiert und du sie nur deshalb nicht hast, weil sie in einer anderen Preisstufe liegt, ist das eine kaufmännische Verhandlung und kein technisches Problem — und den Konnektor zu bezahlen ist meist günstiger, als einen Agenten zu pflegen, der bei jedem Redesign bricht.

Der Bildschirm der Gegenseite, ohne Vorwarnung. Es gibt keine Versionierung und keine Release Notes: ein Redesign, ein neues Pflichtfeld oder ein anderes Cookie-Banner, und der Ablauf bleibt auf halbem Weg stehen — du erfährst es, weil jemand fragt, warum die Rechnungen nie ankamen. Danach kommen die ablaufende Sitzung und der zweite Faktor, denn einen Agenten in einem Fremdsystem angemeldet zu halten frisst die Hälfte des Betriebsaufwands; das Captcha, das keine technische Hürde ist, sondern die ausdrückliche Ansage der Gegenseite, keinen automatisierten Verkehr zu wollen; in der Seite versteckte Anweisungen; und die Kosten, die pro Schritt zählen und nicht pro Anfrage.

Nur wenn du unterstellst, dass die gelesene Seite ihm Befehle geben kann, und entsprechend baust. Ein Browser-Agent unterscheidet nicht zuverlässig zwischen dem Inhalt, den er lesen soll, und einer darin versteckten Anweisung, und das ist kein Problem kurz vor der Lösung: OpenAI erklärte im Dezember 2025, dass Prompt Injection wohl nie vollständig gelöst sein wird, und Anthropic veröffentlichte seine Robustheitsergebnisse zur Browsernutzung mit dem ausdrücklichen Hinweis, dass kein Browser-Agent immun ist. Die Verteidigung sitzt nicht im Systemprompt, sie sitzt in der Zugangsberechtigung: Jede Schreibrechtevergabe ist eine Fähigkeit, die erbt, wer den Agenten kapert. Eigener Zugang, minimaler Geltungsbereich, umkehrbare Aktionen und ein Mensch bei allem Unumkehrbaren.

Sie teilen sich die Oberfläche und brechen aus denselben Gründen, aber sie entscheiden nicht gleich. Klassisches RPA nimmt eine Klickfolge über Koordinaten und Selektoren auf und bleibt stehen, sobald sich etwas verschiebt; der Agent sieht den Bildschirm und entscheidet, was er klickt, übersteht also kleine Änderungen, die den Roboter umbringen würden. Diese Flexibilität zahlt man doppelt: höhere Kosten pro Schritt und Nicht-Determinismus, das heißt, derselbe Bildschirm kann unterschiedliches Verhalten erzeugen. Für einen identischen Vorgang tausendmal am Tag bleibt RPA günstiger und vorhersehbarer. Für einen Vorgang mit Varianten und Dokumenten, die interpretiert werden müssen, hält der Agent stand.

Deine eigene Eingriffsquote auf deinem eigenen Bildschirm, nicht den Wert irgendeines öffentlichen Benchmarks. Diese Testumgebungen laufen auf Nachbauten öffentlicher Seiten, auf dem idealen Pfad, ohne Unternehmensanmeldung, ohne zweiten Faktor und ohne Konsequenz: Ein Fehlklick fügt einer Tabelle einen Fehlschlag hinzu, er bestätigt keine Bestellung über elftausend Euro. Lass ihn zwei Wochen im Beobachtungsmodus auf echten Fällen laufen — die unangenehmen eingeschlossen — und zähle, wie oft eingegriffen werden muss und wie viele Schritte er im Schnitt verbraucht. Diese beiden Zahlen sagen dir, ob der Prozess Arbeit spart oder sie nur verschiebt, was der übliche Ausgang ist, wenn nach einer Demo entschieden wird.

KI-Impact-Plan · kostenlos

Der Guide ist generisch. Dein Plan nicht.

Erzähl uns von deinem Unternehmen und du bekommst eine Diagnose mit Prioritäten, Zahlen und dem, was zuerst gebaut wird. Ohne Sales-Termin, ohne einen Euro zu zahlen.

KI-Agent, der im Browser arbeitet: die letzte Option, nicht die erste · Implementa