Warum gute KI-Agenten in der Produktion versagen: Die fehlende Infrastrukturebene

Es war 6.00 Uhr, als der erste Alarm ausgelöst wurde. Dann der zweite. Dann der dritte.

Die Person im Bereitschaftsdienst öffnete das Laptop und stellte 3 nicht zusammenhängende Fehler eines einzelnen KI-Agenten fest. Der Agent bearbeitete Support-Tickets, verarbeitete Abrechnungsanpassungen und beantwortete Kundenfragen. Er lief auf LangChain. Er hatte jeden Test im Staging bestanden und funktionierte – bis er ausfiel.

Ich habe erlebt, wie Teams Monate in Prompt Engineering und Modellauswahl investierten, nur um dann ein Wochenende mit der Behebung eines Vorfalls zu verbringen, der mit beidem nichts zu tun hatte. Die folgenden Fehler sind nicht hypothetisch. Genau so etwas passiert, wenn ein Agent zum ersten Mal in der Produktion eingesetzt wird, ohne dass die erforderliche Infrastruktur für eine ordnungsgemäße Unterstützung vorhanden ist. Und ich kenne bisher kein Framework, das diese Infrastruktur bereitstellt – die Identitätsgrenzen, Sicherheitsdurchsetzung und operative Governance, die ein Deployment in der Produktion erfordert.

43 doppelte Support-Tickets

Der Agent – ein KI-System, das eigenständig über Ziele nachdenkt, Tools auswählt und mehrstufige Aktionen ausführt – überwachte eine Support-Warteschlange. Ein Kunde reichte einen Fall ein. Der Agent rief die Ticketing-API auf, um einen Datensatz zu erstellen. Die API akzeptierte die Anforderung und erstellte das Ticket. Doch dann trat bei der Antwort eine Zeitüberschreitung auf.

Aus Sicht des Agenten schlug der Aufruf fehl. LangChain tat das, was jedes gut konzipierte Framework bei einem fehlgeschlagenen Tool-Aufruf tut: Es führte einen erneuten Versuch durch. Dieser erneute Versuch erstellte ein zweites Ticket. Bei der Antwort kam es erneut zu einer Zeitüberschreitung. Ein weiterer Versuch. Noch ein Ticket.

Um 6.00 Uhr befanden sich 43 doppelte Tickets im System. Jedes löste eine automatisierte Bestätigungs-E-Mail aus – wodurch 43 Nachrichten in den Posteingängen von Kunden landeten. Das Support-Team verbrachte den Vormittag damit, Duplikate manuell zu schließen und Entschuldigungen zu versenden, anstatt die eigentliche Arbeit zu erledigen.

Ich möchte genau darlegen, was hier schiefgelaufen ist, denn das ist wichtig. LangChain handhabte dies korrekt. Das Framework erkannte eine fehlgeschlagene Antwort und wiederholte den Aufruf. Genau dafür ist die Retry-Logik ausgelegt. Das Problem war nicht der erneute Versuch. Es lag daran, dass nichts in der Infrastruktur nachverfolgte, ob die ursprüngliche Anfrage erfolgreich war. Es gab keinen Idempotenz-Schutz (einen Mechanismus, der sicherstellt, dass eine wiederholte Anforderung dasselbe Ergebnis liefert wie das Original, und so Duplikate verhindert). Keine Deduplizierungsschicht. Keine Erkennung auf Plattformebene, dass dies ein erneuter Versuch einer bereits abgeschlossenen Operation war.

Für alle Entscheidungstragenden, die nachrechnen: Der Schaden bestand nicht nur in einem peinlichen Vormittag. Es waren Arbeitsstunden des Support-Teams, die für Bereinigungen gebunden wurden, verloren gegangenes Kundenvertrauen durch automatisierte doppelte E-Mails und ein System, dem niemand vertrauen konnte, bevor nicht jedes offene Ticket manuell geprüft worden war. Für Entwicklungsteams, die die Retry-Logik lesen, war der Code korrekt. Die Lücke lag darunter.

Das Framework erfüllte seine Aufgabe. Die umgebende Infrastruktur existierte schlicht nicht.

4.000 USD dem falschen Konto belastet

Infrastrukturlücken können stark auf sich aufmerksam machen – so wie 43 Tickets –, aber sie können auch unbemerkt bleiben. Derselbe KI-Agent verarbeitete Abrechnungsanpassungen. Er hatte Zugriff auf eine Abrechnungs-API, die beim Deployment mit einem Service-Account bereitgestellt wurde. Der Service-Account konnte auf mehrere Abrechnungskonten zugreifen, da dies der schnellste Weg war, den Agenten in der Entwicklung auszuführen. Niemand schränkte die Berechtigungen vor der Übernahme in die Produktion ein, weil niemand eine Identitätsgrenze eingerichtet hatte – die Infrastrukturebene, die steuert, auf welche Ressourcen eine bestimmte Workload basierend auf einer verifizierten Identität und nicht nur der Konfiguration zugreifen darf.

Der Agent musste eine Belastung für Konto A verarbeiten. Sein Prompt enthielt die Kontokennung. Das Modell wählte Konto B aus – ein plausibler Fehler bei Large Language Models (LLMs). Die Abrechnungs-API akzeptierte den Aufruf, und 4.000 USD wurden dem falschen Kunden in Rechnung gestellt.

Das war kein Modellfehler. LLMs liefern plausible Ausgaben, aber manchmal sind sie falsch. Die wahrscheinliche Ursache war dieselbe Abrechnungs-API mit dem falschen Kontoparameter – ein plausibler Auswahlfehler.

In traditioneller Software begrenzen 2 Schichten die potenziellen Auswirkungen eines fehlgeleiteten API-Aufrufs: Die Einschränkung des Geltungsbereichs von Zugangsdaten (Credential Scoping) grenzt ein, welche Dienste eine Workload erreichen kann, und die nachgelagerte API setzt durch, welche Parameter für einen bestimmten Aufrufenden gültig sind. Niemand im Entwicklungsteam würde eine Webanwendung bereitstellen, bei der ein einzelner Satz von Zugangsdaten in die Abrechnungsdaten aller Kunden schreiben kann – aber genau das geschah hier.

Der Agent war mit Zugangsdaten bereitgestellt worden, die weitreichend genug waren, um auf jedes Konto im System zuzugreifen. Nichts im Stack – weder die Plattform noch die nachgelagerte API – schränkte diesen Umfang ein. Derzeit bietet kein Framework Credential Scoping (Einschränkung des Geltungsbereichs von Zugangsdaten). Keines bietet eine kryptografische Workload-Identität oder setzt durch, welche Dienste ein Agent basierend auf Richtlinien auf Infrastrukturebene und nicht anhand von Prompt-Inhalten erreichen kann.

Niemand bemerkte es bis zum darauffolgenden Montag, als jemand die Rechnung prüfte. Ich habe Varianten dieses Fehlers in jeder Größenordnung beobachtet – die Details variieren, aber die Ursache bleibt stets dieselbe. Der Agent besaß Zugangsdaten, die er nicht hätte haben dürfen, und nichts im Stack setzte die Grenze durch.

Eine Erstattungsrichtlinie, die das Unternehmen nie verfasst hat

Nicht durchgesetzte Grenzen verursachten in dieser Nacht einen Fehler in Höhe von 4.000 USD, aber der dritte Ausfall kostete etwas, das sich noch schwerer beziffern lässt. Ein Kunde erkundigte sich beim Agenten nach der Rückgabefrist für einen Produktkauf. Das Modell generierte eine selbstbewusste, klare Antwort: Die Erstattungsrichtlinie erlaube Rückgaben innerhalb von 90 Tagen. Die tatsächliche Richtlinie sah 30 Tage vor. Die Antwort war eloquent, hilfsbereit und völlig falsch.

LangChain übergab die Ausgabe des Modells an den kundenorientierten Antwortkanal. Auch hier tat das Framework genau das, wofür es konzipiert war: Es leitete die Ausgabe des Modells an den nächsten Schritt in der Kette weiter. Es gab keine Leitplanke an der Inferenzgrenze – dem Punkt, an dem die Ausgabe eines Modells in die reale Welt gelangt (sei es beim Senden an Kunden, Schreiben in eine Datenbank oder Auslösen einer Aktion). Keine Validierungsebene verglich die Ausgabe mit der dokumentierten Richtlinie. Kein Mechanismus überprüfte, ob die Antwort des Agenten bekannten Fakten widersprach, bevor sie bei den Kunden ankam. Die Ausgabe gelangte auf direktem Weg vom Modell zum Kunden – ohne jede Zwischenprüfung.

Der Kunde gab an Tag 47 ein Produkt im Wert von 280 USD unter Verweis auf die Antwort des Agenten zurück. Das Team akzeptierte die Rückgabe. Der Schaden bestand nicht nur in der Rückerstattung selbst, sondern im rechtlichen Risiko: Ein KI-Agent hatte gegenüber einem Kunden eine unbefugte vertragliche Zusicherung abgegeben. Zudem verfügte das Unternehmen über keinen Audit-Trail, der belegte, welche Kontrollen eingerichtet waren, um dies zu verhindern.

Der Abrechnungsfehler lässt sich beziffern. Die doppelten Tickets lassen sich zählen. Eine erfundene Richtlinie, die an Kunden gesendet wird, lässt sich schwerer beziffern und schwerer eindämmen. Es ist ein Haftungsrisiko, das sich summiert: Jede Antwort, die der Agent ohne Validierung sendet, stellt eine weitere potenzielle vertragliche Verpflichtung dar, die Ihre Rechtsabteilung nie genehmigt hat. Jedes Unternehmen, das einen mit Kunden kommunizierenden Agenten einsetzt, ist diesem Risiko ausgesetzt – und die meisten, ohne es zu wissen.

Mit dem Agenten war alles in Ordnung

Drei Ausfälle in einer einzigen Nacht bei einem Agenten, der in der Entwicklung einwandfrei funktionierte.

Betrachten Sie das Muster. In jedem Fall funktionierte das Framework einwandfrei. LangChain orchestrierte die Tool-Aufrufe, leitete die Ausgaben weiter und unternahm bei Fehlern erneute Versuche. Der Agenten-Loop – Reasoning, Planung, Tool-Aufrufe, Orchestrierung – funktionierte wie vorgesehen.

Jeder Ausfall geschah, weil die Produktionsinfrastruktur fehlte. Der erste Fehler hätte Idempotenz und Deduplizierung auf Plattformebene erfordert. Der zweite hätte eine Identitätsgrenze mit zugewiesenen Zugangsdaten und kryptografischer Workload-Identität benötigt. Der dritte Fall erforderte Leitplanken an der Inferenzgrenze – eine Validierung der Ausgaben anhand dokumentierter Fakten, bevor die Antwort bei den Kunden ankam.

Dies sind keine Aufgaben des Frameworks. Identität, Tool-Governance (Kontrolle, auf welche Tools ein Agent unter welchen Bedingungen zugreifen kann), Observability (Tracking aller Aktionen eines Agenten zu Auditierungs- und Debugging-Zwecken) und Sicherheitsdurchsetzung sind Plattformaufgaben. Kein Framework wurde dafür konzipiert, diese zu lösen.

Ich habe mit Teams gesprochen, die Agenten auf LangChain, CrewAI, LangGraph und benutzerdefinierten Frameworks einsetzen. Die Wahl des Frameworks variiert. Die Lücke nicht. Sie stoßen alle auf dieselbe Hürde: Die Distanz zwischen „funktioniert in der Entwicklung“ und „läuft in der Produktion“ ist kein Framework-Problem. Es ist ein Infrastrukturproblem, das echtes Geld, Kundenvertrauen und wertvolle Engineering-Zeit kostet, solange es ungelöst bleibt.

Was die Lücke schließt

Dieses Infrastrukturproblem hat eine konkrete Ausprägung. Agenten-Frameworks decken den Agenten-Loop ab. Sie wurden nie dafür entwickelt, die Produktionsinfrastruktur bereitzustellen – und das müssen sie auch nicht. Niemand würde von einem Web-Framework erwarten, dass es eine eigene Zertifizierungsstelle für Transport Layer Security (TLS) mitbringt. Hierbei handelt es sich um völlig unterschiedliche Engineering-Disziplinen.

Red Hat AI bietet die Produktionsinfrastruktur, die den Frameworks fehlt. Red Hat OpenShift AI dient als Basis. Das Betriebsprinzip lautet BYOA (Bring Your Own Agent): Die Plattform operationalisiert jede Agenten-Runtime – sei es LangChain, CrewAI, LangGraph oder benutzerdefinierter Code –, ohne dass Änderungen am Agenten erforderlich sind. Ihre Investition in Frameworks bleibt erhalten. Ihr Agenten-Code bleibt unverändert. Die Plattform fügt darunter die Ebenen für Identität, Sicherheit, Governance und Observability ein.

Die Lücke, die Sie bereits haben

Der Agent, der um 6.00 Uhr ausfiel, war kein schlechter Agent. Er war ein guter Agent, der ohne tragfähigen Boden darunterlief. Jedes Framework bietet Ihnen den Reasoning-Loop, die Tool-Aufrufe und die Orchestrierung. Keines liefert Ihnen die Infrastruktur, die darüber entscheidet, ob diese Funktionen in der Praxis sicher ausgeführt werden können. Dieser Unterschied – zwischen den Aufgaben des Frameworks und den Anforderungen an die Plattform – bildet die Produktionslücke. Ihr Framework wurde nicht dafür konzipiert, diese Lücke zu schließen.

Wenn Sie derzeit Agenten in der Entwicklung haben, fehlt ihnen vermutlich derselbe feste Boden unter den Füßen. Nicht, weil Sie sie falsch aufgebaut haben, sondern weil dieses Fundament nicht mit dem Framework bereitgestellt wird. Unser nächster Artikel stellt die einzelnen Bausteine dieses Fundaments vor und zeigt, wie Sie sie implementieren.

Erste Schritte

Möchten Sie sehen, wie eine produktionsreife Agenteninfrastruktur aussieht? Starten Sie hier:

• OpenShift AI kostenlos in der Developer Sandbox testen: eine vorkonfigurierte Umgebung für Experimente mit KI-Workloads
• Interaktive Demos von Red Hat AI erkunden: praktische Einführungen in Red Hat AI
• Mit den BYO-Agent-Starterkits loslegen: vorkonfigurierte Vorlagen für LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK und mehr
• Dokumentation zu Red Hat AI lesen: vollständige Plattformdokumentation
• Operationalisierung von BYOA auf Red Hat AI: OpenClaw-Edition: ein praxisorientierter Artikel über das Deployment eines echten Agenten auf der Plattform