KI-Agenten in der Produktion bereitstellen: Von der Demo zum wiederherstellbaren, beobachtbaren und rückrollbaren Produktivbetrieb

Fahrplan für den Produktivstart: erst Grenzen definieren, dann Schritt für Schritt prüfen

Bei der Bereitstellung von KI-Agenten in der Produktion geht es nicht darum, zusätzliche Modelle einzusetzen oder die Orchestrierung komplexer zu gestalten. Entscheidend ist, dass sich Fehler bei Aufgaben beurteilen und Aufgaben wiederaufnehmen lassen sowie Änderungen überprüfbar und rückgängig zu machen sind. Empfohlen wird folgende Reihenfolge: Aufgaben und Abschlusskriterien definieren, das Bereitstellungsmodell wählen, Laufzeitumgebung und Zustandsspeicher einrichten, Sicherheitsgrenzen umsetzen und repräsentative Aufgaben evaluieren. Anschließend folgt ein schrittweiser Rollout mit einem kleinen Anteil des Datenverkehrs sowie die Planung von Bereitschaftsdienst und Rollback.

Legen Sie zunächst Auslösebedingungen, Eingaben, zulässige Tools, das abschließende Geschäftsergebnis, den Umgang mit Zeitüberschreitungen und die Stellen für menschliche Freigaben fest. Wenn feste Abläufe die Anforderungen bereits erfüllen, ist es nicht nötig, nur um eines „Agentenansatzes“ willen mehrere Agenten einzuführen. Orientierung bei der Wahl zwischen Workflows und Agenten bietet Anthropics Beitrag zur Entwicklung effektiver Agenten. Weitere Informationen zur Anbindung von Systemschnittstellen und zu Tool-Berechtigungen finden Sie unter So integrieren Sie KI-Agenten in bestehende Unternehmenssysteme.

Bereitstellungsmodell wählen: nach den Rahmenbedingungen abwägen

Die folgende Tabelle dient dem Vergleich architektonischer Rahmenbedingungen und erlaubt keine Rückschlüsse auf Leistung oder Preise. Prüfen Sie Funktionen, Kontingente und Betriebsverantwortung der infrage kommenden Plattformen anhand ihrer jeweils aktuellen Dokumentation.

Bei der Nutzung von Inferenz über eine Modell-API werden in der Regel die Anwendungslaufzeit, kontrollierte Tools und Zustandsdienste bereitgestellt. Ob eine eigene Inferenzumgebung betrieben werden sollte, ist separat anhand von Latenz, Datengrenzen, Modellverfügbarkeit und Betriebsanforderungen zu bewerten. Die Dokumentation zu Kubernetes Deployment kann als Referenz für Rolling Updates und das Zurücksetzen auf frühere Revisionen dienen. Daraus folgt jedoch nicht, dass ein Agent auf Kubernetes bereitgestellt werden muss.

Minimale Produktionsarchitektur: Anfragen, Ausführung, Zustand und Observability verbinden

调用方 → 鉴权入口/请求校验 → 任务执行器（同步短任务或异步任务 ID）
      → Agent 运行逻辑 → 模型端点/受控工具 → 状态存储与结果核验
      → 日志、指标、追踪与告警

Bei kurzen Aufgaben kann auf das Ergebnis gewartet werden. Überschreitet die Ausführung das Wartezeitfenster des Aufrufers oder muss sie prozessübergreifend wiederaufgenommen werden können, lässt sich eine Aufgaben-ID zurückgeben, über die der Client den Status abfragen oder eine Abschlussbenachrichtigung erhalten kann. Definieren Sie Aufgabenstatus, Abbruchsemantik, Timeout-Grenzen und Leseberechtigungen für Ergebnisse.

Auf die Systemanbindung wird hier nicht erneut im Detail eingegangen; siehe den zuvor genannten Beitrag KI-Agenten an bestehende Unternehmenssysteme anbinden. Als Orientierung für Zuständigkeiten im Bereitschaftsdienst und in der technischen Zusammenarbeit dient Technische Lieferverantwortung und Schnittstellen der Zusammenarbeit eines FDE. Die konkreten Verantwortlichkeiten müssen im Projekt festgelegt werden.

Release-Artefakte vorbereiten: Änderungen reproduzierbar machen

Nehmen Sie Code, Lockdateien für Abhängigkeiten, Laufzeit-Images, Umgebungskonfigurationen, Prompt-Vorlagen sowie die Versionen der Modell- und Toolkonfigurationen in die Änderungsdokumentation auf. Überprüfen Sie Abhängigkeiten während des Builds und trennen Sie Entwicklungs-, Test- und Produktionsumgebungen. Zugangsdaten werden über einen kontrollierten Konfigurationsmechanismus eingebunden und weder im Code-Repository noch in gewöhnlichen Logs gespeichert. Verwalten Sie Modell-API-Schlüssel, Zugangsdaten für Tool-Dienste und geschäftliche Identitäten getrennt.

Die Release-Checkliste sollte mindestens Folgendes bestätigen:

• Einstiegspunkt, Zustandsprüfungen, Ressourcenlimits und die Verarbeitung von Beendigungssignalen wurden überprüft;
• Abhängigkeitsversionen, Image-Digests und Konfigurationsänderungen sind nachvollziehbar;
• Prompts, Tool-Verträge, Modellkennungen und wesentliche Parameter sind versioniert dokumentiert;
• Regressionstestfälle und Evaluationsergebnisse lassen sich der jeweiligen Release-Version zuordnen;
• Die für das Rollback vorgesehene Version lässt sich starten und kann das aktuelle Zustandsformat lesen oder dessen Verarbeitung ausdrücklich ablehnen.

Lange Aufgaben wiederaufnehmen: Ein Checkpoint garantiert keine genau einmalige Ausführung von Geschäftsvorgängen

Wiederaufnehmbarkeit betrifft drei Ebenen: Aufgabendatensätze, Ausführungszustand und geschäftliche Seiteneffekte. Steht die Aufgabe in der Warteschlange, wird sie ausgeführt oder wartet sie auf einen menschlichen Eingriff? Welche Schritte wurden bereits ausgeführt? Waren Schreibvorgänge in externen Systemen erfolgreich? Das Speichern des Gesprächstextes allein reicht möglicherweise nicht aus, um den Ausführungskontext wiederherzustellen. Auch ein Checkpoint allein belegt nicht das Ergebnis externer Schreibvorgänge.

Bei LangGraph unterscheidet die Dokumentation beispielsweise zwischen einem Checkpointer, der den Ausführungszustand pro Thread speichert, und einem Store für threadübergreifend gemeinsam genutzte Daten. Für die Wiederaufnahme nach einem Prozessneustart ist ein geeignetes Persistenz-Backend erforderlich. Dabei müssen Schreiben, Lesen, Isolation, Aufbewahrung und Wiederherstellung im Fehlerfall überprüft werden; rein speicherbasierte Checkpointer bieten keine Persistenz über Neustarts hinweg. Weitere Informationen finden Sie in der Dokumentation zur Persistenz von LangGraph.

Die Wiederholungsstrategie muss zwischen dem Zeitlimit eines einzelnen Versuchs, Fehlern, bei denen ein erneuter Versuch möglich ist, und dem Vorgehen nach Ausschöpfung aller Wiederholungsversuche unterscheiden. Für Tools mit Seiteneffekten sollten Idempotenzschlüssel oder Mechanismen zur Deduplizierung vorgesehen werden. Vor einem erneuten Versuch ist zunächst das fachliche Ergebnis zu prüfen: Ein Zeitüberschreiten beim Aufruf bedeutet nicht, dass kein Schreibvorgang stattgefunden hat. Lässt sich das Ergebnis nicht bestätigen, muss eine manuelle Prüfung oder ein Kompensationsprozess eingeleitet werden; Checkpoints, Warteschlangen und Wiederholungsversuche allein gewährleisten keine Ende-zu-Ende-Verarbeitung mit Exactly-once-Garantie. Siehe die Dokumentation zur Fehlerbehandlung von LangGraph.

Sicherheitskontrollen: Sperrbedingungen für risikoreiche Aktionen festlegen

Vor der Veröffentlichung ist mindestens Folgendes zu überprüfen:

• Externe Dokumente, Webseiten und Benutzereingaben dürfen Tool-Berechtigungen nicht eigenständig erweitern;
• Tool-Dienste prüfen bei jedem Aufruf die Identität, den zulässigen Ressourcenbereich und die Parameter; Aktionen mit weitreichenden Auswirkungen erfordern eine ausdrückliche menschliche Bestätigung;
• Zugangsdaten sind nach Umgebung getrennt und können rotiert werden; Protokolle werden entsprechend der Sensibilität der Daten auf das notwendige Minimum beschränkt, von sensiblen Informationen bereinigt und mit Aufbewahrungsfristen versehen;
• Freigabeprotokolle verknüpfen die Anfrage, die handelnde Person, die geplante Aktion und das endgültige fachliche Ergebnis;
• Tests zu unzulässigen Zugriffen, Prompt-Injection, mehrfachen Übermittlungen und der Offenlegung sensibler Daten weisen jeweils die erwartete Ablehnung nach.

Die OWASP-Materialien zu Bedrohungen und Gegenmaßnahmen für agentische KI können beim Erstellen eines Bedrohungskatalogs helfen, sind jedoch kein Nachweis für die Sicherheit oder Konformität dieses Systems.

Freigabekriterien für die Evaluation: Ergebnisse und Abläufe gleichermaßen prüfen

Die Selbstauskunft eines Agenten, eine Aufgabe sei „erledigt“, darf nicht als Abnahmenachweis gelten. Definieren Sie für jede Aufgabenart Erfolgskriterien, die sich in der jeweiligen Umgebung überprüfen lassen, etwa den Status des Zieldatensatzes, das Ausgabeformat und unzulässige Aktionen. Bewahren Sie Ausführungsverläufe auf, um Fehler bei der Planung, bei Tool-Aufrufen oder bei der Ergebnisprüfung lokalisieren zu können. Als Orientierung dient Anthropics Erläuterung zur Evaluation von KI-Agenten.

Die Testfälle sollten reguläre Eingaben, fehlende Felder, widersprüchliche Informationen, Zeitüberschreitungen bei Tools, verweigerte Zugriffe, doppelte Anfragen und Manipulationsversuche durch externe Inhalte abdecken. Wichtige Testfälle können mehrfach ausgeführt werden, wobei Schwankungen der Ergebnisse dokumentiert werden sollten. Die Freigabekriterien können Aufgabenergebnisse, unzulässige Aktionen, Ausnahmebehandlung, Wiederherstellungsübungen und Wege zur manuellen Übernahme umfassen; die Schwellenwerte werden anhand des Geschäftsrisikos, bestehender Vergleichswerte und der Testergebnisse festgelegt.

Monitoring: Qualität, Latenz, Wiederherstellung und Kosten

Definieren Sie für jede Kennzahl die Berechnungsgrundlage, den Erfassungspunkt, die Alarmbedingungen und die verantwortliche Person:

Ausführungstraces dienen dazu, Abweichungen in mehrstufigen Abläufen zu lokalisieren; der endgültige Status im Geschäftssystem bestätigt den Aufgabenabschluss. Welche Felder in Protokollen maskiert werden, wer darauf zugreifen darf und wie lange sie aufbewahrt werden, ist projektspezifisch festzulegen. Beobachten Sie nach dem Produktivstart zunächst die Ausgangswerte und passen Sie anschließend die Alarmschwellen an die geschäftlichen Risiken an.

Schrittweise Einführung, Rollback und Umgang mit laufenden Aufgaben

Führen Sie vor der Veröffentlichung Regressionstests für die Kombination aus Code, Prompts, Modellkonfiguration und Tool-Schnittstellenverträgen durch. Validieren Sie diese zunächst mit begrenztem Datenverkehr oder risikoarmen Aufgaben und erhöhen Sie die Auslastung anschließend schrittweise. Legen Sie Abbruchkriterien fest, etwa auffällige Geschäftsergebnisse, fehlgeschlagene Tests auf unzulässige Berechtigungsüberschreitungen oder Fehlerquoten und Latenzen oberhalb der vom Team definierten Grenzwerte.

Nehmen Sie bei einer Störung vorübergehend keine neuen Aufgaben an oder deaktivieren Sie risikoreiche Tools. Erfassen Sie laufende, wartende und abgeschlossene Aufgaben, prüfen Sie externe Seiteneffekte und kehren Sie erst danach zu einer validierten Version zurück. Prüfen Sie, ob die alte Version mit dem bestehenden Zustandsformat kompatibel ist. Übergeben Sie Aufgaben, die nicht automatisch wiederhergestellt werden können, an die manuelle Bearbeitung oder führen Sie genehmigte Kompensationsmaßnahmen aus. Kubernetes Deployment kann bei Verwendung von Kubernetes als Referenz für den Release-Prozess dienen; ein Rollback der Anwendung macht bereits erfolgte Schreibvorgänge in Geschäftssystemen nicht automatisch rückgängig.

Schulungsübung: Wiederherstellungspfade durch Fehlerinjektion validieren

Das folgende Szenario ist als Schulungsübung konzipiert und stellt weder eine Kundenfallstudie noch tatsächlich gemessene Ergebnisse dar. Die Aufgabe lautet: „Einen Bericht erstellen und die Ergebnisse nach manueller Bestätigung speichern.“ Dokumentieren Sie bei jedem Durchlauf die Erwartungen, die tatsächlichen Ergebnisse und die zugehörigen Nachweise:

Prüfen Sie in der Übung, ob der Status im Geschäftssystem und die Ausführungsprotokolle den Erwartungen entsprechen, und legen Sie Zuständigkeiten sowie Bearbeitungswege für Aufgaben mit Fehlern fest.

Abnahmecheckliste für den Produktivstart

• Aufgabenumfang, Abschlusskriterien, verbotene Aktionen und erforderliche manuelle Bestätigungen sind schriftlich festgehalten.
• Die Bereitstellungsform passt zur Aufgabendauer, zu den Wiederherstellungsanforderungen und zu den Betriebskapazitäten des Teams.
• Abhängigkeiten, Images, Prompts, Modellkonfigurationen und Tool-Schnittstellenverträge sind nachvollziehbar dokumentiert.
• Aufgabenstatus, dauerhafte Speicherung und Seiteneffekte in Geschäftssystemen sind jeweils überprüfbar; Wiederholungsversuche sind durch Idempotenz abgesichert.
• Tests zu Berechtigungen, Prompt-Injection, sensiblen Protokolldaten und manuellen Freigaben wurden bestanden.
• Die Evaluierung deckt repräsentative Aufgaben, Ausnahmefälle, Ergebnisvalidierung und Wiederherstellungsszenarien ab.
• Kennzahlendefinitionen, Alarmverantwortliche, Abbruchkriterien für die schrittweise Einführung und Bereitschaftsabläufe sind bestätigt.
• Die Rückkehr zur vorgesehenen Rollback-Version, der Umgang mit laufenden Aufgaben, die Zustandskompatibilität und die Abläufe für geschäftliche Kompensationsmaßnahmen wurden erprobt.

Häufige Fragen zur Bereitstellung

Frage: Ist Kubernetes zwingend erforderlich? Antwort: Nein. Wenn das Team bereits eine Plattform nutzt, die die Anforderungen an Aufgabendauer, Zustandswiederherstellung, Netzwerkisolierung und Betrieb erfüllt, muss es die Infrastruktur nicht eigens für den Agenten um einen Cluster erweitern.

Frage: Muss für die Bereitstellung eines Agenten ein eigenes Modell betrieben werden? Antwort: Nein. Wenn die Inferenz über eine Modell-API erfolgt, genügt es in der Regel, die Anwendungslaufzeit, kontrollierte Tools und Zustandskomponenten bereitzustellen. Für selbst betriebene Inferenz müssen Datengrenzen, Latenz, Verfügbarkeit und Betriebsanforderungen gesondert bewertet werden.

Frage: Gehen Aufgaben nach einem Neustart des Dienstes verloren? Antwort: Das hängt von der Aufgabenprotokollierung, der Persistierung des Ausführungszustands und der Validierung des Wiederherstellungsprozesses ab. Der Prozessspeicher allein ermöglicht keine Wiederherstellung über Neustarts hinweg. Außerdem muss geprüft werden, ob externe Schreibvorgänge erfolgreich waren, um eine doppelte Ausführung zu vermeiden.

Frage: Wie lassen sich doppelte Schreibvorgänge durch Wiederholungsversuche verhindern? Antwort: Sehen Sie für Geschäftsvorgänge Idempotenzschlüssel oder Deduplizierungsdatensätze vor und prüfen Sie vor einem erneuten Versuch den Zustand des externen Systems. Lässt sich dieser nicht bestätigen, setzen Sie automatische Wiederholungsversuche aus und veranlassen Sie eine manuelle Prüfung oder einen Kompensationsprozess.

Frage: Welcher Schwellenwert für die Erfolgsquote sollte für die Produktivfreigabe gelten? Antwort: Es gibt keinen allgemeingültigen Wert. Legen Sie Freigabekriterien und Alarme anhand der Aufgabenrisiken, der betrieblichen Ausgangswerte und der Testergebnisse fest. Prüfen Sie bei der Abnahme außerdem, ob verbotene Aktionen unterbunden werden, die manuelle Übernahme und Wiederherstellung funktionieren und die Geschäftsergebnisse stimmen.