Ihr Agent beschädigt den Produktivbetrieb nicht wegen „Halluzinationen“, sondern weil er die Oberfläche nicht sieht: warum Laufzeit-Wahrnehmung für Web und Desktop zur Pflicht wird

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau. Ich betreibe mit DennisCraft AI Studio produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres. Die unangenehmsten Vorfälle im Produktivbetrieb entstehen nach meiner Erfahrung meist nicht dadurch, dass ein Modell „fantasiert“, sondern dadurch, dass ein Agent auf eine Oberfläche zugreift, deren aktueller Zustand ihm im Moment der Aktion gar nicht vorliegt.

Das ist mehr als ein sprachliches Detail. Viele Teams diagnostizieren den Fehler falsch und investieren Wochen in Prompt-Anpassungen, obwohl das eigentliche Problem an anderer Stelle liegt: Der Agent handelt auf Grundlage veralteter Annahmen über eine reale Benutzeroberfläche. Wenn ein Agent im Produktivbetrieb Web- oder Desktop-Anwendungen bedient und dabei keinen aktuellen Blick auf den tatsächlichen Zustand der Oberfläche hat, liegt zuerst ein Beobachtungsproblem vor und erst danach ein Modellproblem.

Das Kernproblem ist fehlender Laufzeitzustand

Der Begriff „Halluzination“ ist bequem, weil er die Verantwortung dem Modell zuschiebt. In vielen Vorfällen ist das jedoch zu kurz gegriffen. Der Agent befolgt eine Anweisung in einer Umgebung, die sich verändert hat: Eine Schaltfläche wurde verschoben, ein Pflichtfeld wurde ergänzt, ein Zustimmungsfenster liegt über dem Inhalt, oder nach einer Neudarstellung ist die erwartete Aktion vorübergehend gesperrt. Wenn der Agent das nicht sehen kann, arbeitet er mit einer alten Karte in einer neuen Realität.

Was ich unter Laufzeit-Wahrnehmung verstehe

Gemeint ist kein neues Schlagwort, sondern ein erprobtes Muster. Vor einer kritischen Aktion erhält der Agent aktuelle Hinweise aus der Oberfläche: etwa einen Bildschirmabbild, einen Accessibility-Baum, einen DOM-Schnappschuss, OCR-Text oder eine Kombination daraus. Erst danach wird entschieden, ob die beabsichtigte Aktion im gegebenen Zustand überhaupt zulässig und korrekt ist.

Anthropic beschreibt in seiner Dokumentation zu Computer Use einen Ablauf aus Beobachten, Schlussfolgern und Handeln. Für Agenten, die mit Oberflächen arbeiten, ist genau das die sinnvolle Grundform. Ohne aktuellen Zustand der Umgebung wird nicht gesteuert, sondern geraten. Siehe dazu die Dokumentation von Anthropic aus den Jahren 2024 bis 2025: https://docs.anthropic.com/.

Warum Web- und Desktop-Oberflächen heute schwieriger geworden sind

Unternehmensanwendungen sind weniger stabil, als viele Architekturdiagramme vermuten lassen. React-Neudarstellungen, rollenbasierte Ansichten, iFrames, Mehrsprachigkeit, A/B-Flags, SSO-Umleitungen und zusätzliche MFA-Schritte verändern den sichtbaren Zustand laufend. Im Desktop-Bereich kommen virtuelle Arbeitsplätze, Citrix-Sitzungen, Altanwendungen und Fokuswechsel hinzu. Genau dort versagen Agenten, die nur auf feste Selektoren oder Textanweisungen vertrauen.

Das bedeutet nicht, dass Wahrnehmung APIs ersetzen soll. Im Gegenteil: Ich bevorzuge weiterhin API zuerst, dann ereignisgesteuerte Integration, und nur dort, wo der Geschäftsprozess tatsächlich an die Oberfläche gebunden ist, kommt eine Wahrnehmungsschicht hinzu. Wenn die Oberfläche jedoch Teil des Ausführungspfads ist, wird diese Schicht im Produktivbetrieb zur Pflicht.

Ein belastbares Muster für den Produktivbetrieb

Ich vertraue nicht auf „mehr Freiheit“ für den Agenten, sondern auf einen begrenzten Handlungszyklus mit Prüfstellen. Das Minimalmuster lautet: aktuellen Oberflächenzustand erfassen, Ziel des nächsten Schritts benennen, zulässige Aktionen einschränken, genau eine Aktion ausführen, Ergebnis prüfen und bei Unklarheit stoppen oder an einen Menschen übergeben.

Beispiel: Bildschirmzustand vor der Aktion prüfen

from anthropic import Anthropic
import base64
import os

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

with open("screen.png", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode("utf-8")

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=300,
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Prüfen Sie, ob die Schaltfläche zur Zahlungsfreigabe sichtbar und aktiv ist. Falls nicht, geben Sie BLOCKED mit Begründung zurück."},
            {"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": image_b64}}
        ]
    }]
)

print(response.content[0].text)

Entscheidend ist hier nicht das SDK, sondern die Ausführungsdisziplin. Der Agent handelt nicht sofort. Er klassifiziert zuerst den Zustand des Bildschirms. Liefert das Modell BLOCKED, verzweigt der Ablauf in n8n: fehlendes Feld anfordern, neuen Bildschirmstand erfassen oder an eine Fachperson übergeben.

Prüfung vor schreibenden Aktionen

type UiDecision = {
  action: "click" | "type" | "blocked";
  target?: string;
  reason: string;
};

function verifyDecision(decision: UiDecision) {
  if (decision.action === "blocked") throw new Error(decision.reason);
  if (!decision.target || decision.target.length < 3) {
    throw new Error("Nicht verifiziertes UI-Ziel");
  }
  return decision;
}

const decision = verifyDecision({
  action: "click",
  target: "button[aria-label='Approve payment']",
  reason: "Element ist sichtbar und aktiv"
});

Eine solche Prüfung verhindert nicht jede Fehlhandlung. Sie macht den Fehler aber sichtbar und erzwingt eine definierte Unterbrechung, statt eine unbemerkte Fehlaktion durchlaufen zu lassen.

Warum das für Regulierung und Prüfung relevant ist

In regulierten Abläufen ist eine Oberflächenfehlhandlung nicht nur ein Bedienproblem. Daraus können falsche Freigaben, Zugriffsfehler oder Datenzuordnungen im falschen Kundenkontext entstehen. Für DACH-Unternehmen ist das unmittelbar mit DSGVO, ISO 27001, NIS2 und je nach Umfeld auch mit dem EU AI Act verbunden. Wer autonome Agenten produktiv einsetzt, muss Nachvollziehbarkeit, Begrenzung von Werkzeugrechten und dokumentierte Prüfpfade vorweisen können.

OWASP benennt in seiner Top-10-Liste für LLM-Anwendungen aus 2025 ausdrücklich Risiken durch übermäßige Handlungsfreiheit und unzureichende Kontrolle von Agentenaktionen: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Aus Sicht des BSI-Grundschutzes ist das nichts anderes als die Forderung nach kontrollierter Ausführung, Protokollierung und nachvollziehbarer Fehlerbehandlung in produktiven Systemen.

Die häufigsten Schadensmuster sind dabei bemerkenswert unspektakulär:

• Der Agent klickt nach einer Layout-Änderung auf ein ähnlich aussehendes Element.
• Ein Dialogfenster verdeckt den Inhalt, während alte DOM-Referenzen noch vorhanden sind.
• Im Desktop-Betrieb geht der Fokus verloren und Eingaben landen im falschen Fenster.
• SSO oder MFA fügen einen zusätzlichen Schritt ein, der im Ablauf nie modelliert wurde.
• Sprachumschaltung verändert Beschriftungen, wodurch Textabgleiche falsch greifen.

Was Sie jetzt prüfen sollten

Wenn in Ihrem Unternehmen bereits Agenten mit Web- oder Desktop-Oberflächen arbeiten, stellen Sie fünf einfache Fragen. Was genau sieht der Agent vor einer kritischen Aktion? Wie prüfen Sie den Zustand nach der Aktion? Was geschieht bei unbekanntem Bildschirmzustand? Können Sie den Ablauf über Protokolle und Bildschirmabbilder nachvollziehen? An welcher Stelle kann ein Mensch sicher übernehmen?

Wenn zwei dieser Antworten unklar bleiben, liegt das Hauptproblem meistens nicht im Prompt. Es liegt daran, dass der Agent nur teilweise sieht, worauf er wirkt. Das ist eine Architekturfrage. Und Architekturfragen löst man nicht mit einer weiteren Formulierung im System-Prompt.

FAQ

Ist eine API-Anbindung weiterhin vorzuziehen?

Ja. Wenn eine API den Geschäftsprozess vollständig abdeckt, ist sie in der Regel die bessere Wahl. Laufzeit-Wahrnehmung wird dort wichtig, wo entscheidende Schritte ausschließlich über die Oberfläche verfügbar sind.

Reicht ein DOM-Schnappschuss ohne Bildschirmabbild?

Häufig nicht. Der DOM-Zustand zeigt nicht zuverlässig, ob Elemente sichtbar, überlagert oder tatsächlich aktiv sind. Für kritische Schritte ist die Kombination mehrerer Beobachtungskanäle sinnvoll.

Ist das nicht zu teuer oder zu langsam?

Es erzeugt zusätzlichen Aufwand pro kritischem Schritt. Im Vergleich zu einem produktiven Fehlvorgang mit Freigabe- oder Datenschutzbezug ist dieser Aufwand in der Regel gut vertretbar.

Gilt das auch für Desktop, VDI und Citrix?

Ja, dort sogar besonders. Gerade in solchen Umgebungen fehlen oft APIs, während Fokus, Auflösung und Sitzungszustand die korrekte Ausführung direkt beeinflussen.

Kann man den Menschen vollständig aus dem Ablauf entfernen?

Teilweise, wenn der Handlungsraum eng begrenzt und sauber prüfbar ist. Bei Zahlungen, Berechtigungen und personenbezogenen Daten bevorzuge ich weiterhin eine klar definierte Eskalationsmöglichkeit.

An welcher Stelle Ihrer LLM-Pipeline entstehen im Produktivbetrieb derzeit die meisten Fehler: bei der Planung, beim Werkzeugaufruf oder genau dann, wenn der Agent eine reale Oberfläche bedienen muss? Ich würde das gern mit den Mustern vergleichen, die ich in DACH-B2B-Umgebungen beobachte.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.