Eine Überprülliste für die Produktionsbereitschaft von KI-Agenten, Schritt für Schritt.

Der Übergang von einem funktionsfähigen Prototyp zu einer produktiven Implementierung eines KI-Agenten verläuft nach einem vorhersehbaren Weg, wobei jede Phase ihre eigenen Überprüfungen sowie eigene Fehlerquellen bei Auslassung aufweist. Diese Übersicht geht Schritt für Schritt voran.

Ein Prototyp hat nur eine Aufgabe: zu zeigen, dass eine Idee funktioniert – eine Maschine, der Zustand im Speicher, keine echten Benutzer. In der Produktion sind jedoch mehr Anforderungen gegeben: Der Agent muss Neustarts überstehen, mehreren Personen gleichzeitig dienen, sich nach einem fehlgeschlagenen Schritt wieder erholen und eine Aufzeichnung hinterlassen, die bei Fehlern nachvollzogen werden kann.

Ein Großteil dieser Herausforderungen betrifft nicht die KI selbst, da der Aufruf des Modells in der Regel der einfachere Teil ist. Die schwierigeren Aspekte drehen sich um die Umgebung: Wo befindet sich der Zustand? Was passiert, wenn ein Schritt zweimal ausgeführt wird? Und wie erreicht eine Änderung einen echten Benutzer, ohne Schaden zu verursachen? Nutzen Sie die untenstehenden Listen, um zu erkennen, was bereits abgedeckt ist und was noch fehlt, bevor ein Agent in Produktion geht.

Phase 1: Entwicklung und lokaler Prototyp

Das Ziel ist hier absichtlich eng gefasst – es geht darum zu beweisen, dass die Kernidee überhaupt funktioniert. Machen Sie es noch nicht produktionsreif. Wenn man das zu früh tut, bedeutet das in der Regel den Aufbau der falschen Infrastruktur für ein noch nicht festgelegtes Design.

Bringen Sie den Kernworkflow erst einmal so klein wie möglich zum Laufen. Führen Sie einen einzigen, reibungslosen Ablauf von der Eingabe bis zur korrekten Ausgabe durch, bevor Warteschlangen, Datenbanken oder die Bereitstellung ins Spiel kommen.

Warum: Frühe Entscheidungen bezüglich der Infrastruktur sind in der Regel falsch, weil die tatsächliche Struktur des Problems unbekannt ist: Laufzeit, Größe des Zustands sowie Fehlermöglichkeiten sind alles noch Schätzungen. Eine zunächst erstellte produktionsreife Version muss in der Regel ohnehin neu erstellt werden.

Beispiel: Ein Agent zur Sortierung von Support-Tickets beginnt seine Arbeit mit einem kurzen Skript: Es liest ein Ticket ein, fragt ein Modell nach einer Kategorie und gibt die Antwort aus. Es gibt weder Server noch Datenbank, und es wird manuell über eine Terminal eingestartet.

Stellen Sie das Verhalten konfigurierbar statt fest programmiert bereit. Wenn das System für unterschiedliche Eingaben – wie Kundensegmente, Dokumenttypen, Sprachen oder Tonlagen – anders handeln muss, sollten diese Fälle als Konfiguration behandelt werden und nicht als weitere Code-Branches.

Warum: Sobald Nutzer auftauchen, häufen sich die Variationen schnell („Kann es französische Tickets verarbeiten?“, „Können Unternehmenskonten einen strengeren Ton haben?“). Jede dieser Anpassungen erfordert eine Codeänderung und eine Veröffentlichung, wodurch neue Fälle in der Warteschlange der Entwickler landen; mit Konfiguration hingegen reicht eine schnelle Bearbeitung aus.

Beispiel: Anstelle von if/else-Strukturen je nach Kundenebene werden die Anweisungen für den Agenten aus kleinen Textvorlagen erstellt – einer Basisvorlage sowie einer pro Ebene. Das Hinzufügen einer neuen Ebene bedeutet das Hinzufügen einer Datei.

Notieren Sie, was das Prototyp noch nicht löst. Bevor Sie fortfahren, listen Sie absichtlich die Lücken auf: Neustarts mitten in einer Ablaufsequenz, mehrere Benutzer gleichzeitig, Protokollierung von Fehlern, Ausführung an jedem Ort außer auf dem eigenen Rechner.

Warum: Eine Lücke, die niemand notiert hat, wird später zu einer Überraschung – meist erst während eines Incidents und nicht in einer Planungssitzung. Eine notierte Lücke wird zur Checkliste für die nächste Phase.

Beispiel: Eine kurze Tabelle mit Zeilen wie „Der Zustand befindet sich in einem Python-Dictionary, daher ist eine langlebige Speicherung erforderlich“, „Nur eine Aufgabe kann gleichzeitig ausgeführt werden, daher müssen parallele Ausführungen unterstützt werden“ und „Es gibt keine Aufzeichnung dessen, was passiert ist, daher ist ein Audit-Log notwendig“. Im Moment ist noch nichts festgelegt – die Einträge werden lediglich benannt.

Phase 2: Testumgebung und Staging-Umgebung

Hier trifft das System erstmals auf die echte Infrastruktur sowie die tatsächlichen Fehlerquellen. Es läuft nun vom Laptop aus, wird neu gestartet und kann gleichzeitig von mehreren Personen genutzt werden.

Wählen Sie die Laufzeit entsprechend der tatsächlichen Arbeitslast aus. Schauen Sie sich vor der Entscheidung, wo der Agent laufen soll, konkrete Zahlen an: die maximale zulässige Laufzeit, die Kosten für den Leerlauf sowie ob ein beendeter Prozess von dort weitermachen kann, wo er aufgehört hat.

Warum: Die Arbeitslasten von Agenten ähneln selten gewöhnlichen Webanfragen. Ein einzelner Ausführungsvorgang kann mehrere Minuten dauern und muss über viele Schritte hinweg umfangreichen Kontext übertragen. Ein Laufzeitumfeld, das für kurze Anfragen konzipiert ist, wird während des Vorgangs abbrechen, während ein Umfeld für ständigen Traffic für etwas, das nur ein paar Mal am Tag läuft, zu teuer wäre.

Beispiel: Ein Agent zur Überprüfung von Rechtsdokumenten durchläuft in einem einzigen Vorgang die Abschnitte eines Dokuments nacheinander, um den vollständigen Kontext beizubehalten; ein langes Dokument kann dabei 10 bis 15 Minuten in Anspruch nehmen. Das schloss Serverless-Funktionen mit fester Zeitbegrenzung aus. Ebenso wurden immer einsatzbereite Container ausgeschlossen, da der Agent nur wenige Male am Tag läuft und die inaktive Kapazität sonst ungenutzt bliebe. Lange, unregelmäßige Ausführungsvorgänge deuteten auf ein Laufzeitumfeld hin, das nur für die tatsächlich verarbeitete Zeit abrechnet und kein Timeout kennt.

Bringen Sie den Zustand aus dem Speicher in einen dauerhaften, gemeinsam genutzten Speicher. Alles, was nach einem Neustart erhalten bleiben muss oder für mehrere Server sichtbar sein sollte – wie der Laufzustand, die Konversationshistorie und laufende Ergebnisse – gehört in einen echten Datenspeicher und nicht in eine Variable innerhalb des laufenden Prozesses. Wählen Sie ein System als Quelle der Wahrheit aus.

Warum: Zustände, die nur im Speicher gespeichert sind, verschwinden beim Neustart des Prozesses – und in der Produktion geschieht das häufiger, als die meisten erwarten, aufgrund von Bereitstellungen, Abstürzen und Skalierungen. Zustände, die über mehrere Speicher verteilt sind und keinen klaren Eigentümer haben, führen letztendlich dazu, dass zwei Systeme unterschiedliche Ansichten darüber haben, was wahr ist.

Beispiel: Hier speichert ein Dokumentbearbeitungsagent den Laufzustand, die Chat-Geschichte sowie die vorgeschlagenen Änderungen im Objektspeicher, wobei während des Anfragenverarbeitungsprozesses nichts gespeichert wird. Der Objektspeicher ist die einzige Quelle der Wahrheit, während eine Datenbank für eine einzige, spezifische Aufgabe verwendet wird: das Sperren einer Anfrage, um zu verhindern, dass zwei Prozesse denselben Lauf bearbeiten. Der allgemeine Zustand wird nicht auf beide aufgeteilt, und es gibt keine Regel, welche Variante Vorrang hat.

Nehmen wir an: „Dies wurde zweimal ausgeführt“ und „Diese wurden gleichzeitig ausgeführt.“ Die meisten echten Messaging-Systeme können einen Auslöser mehrfach übermitteln. Eine einfache Statusüberprüfung („Starten, wenn noch nicht gestartet“) scheitert, da beide Prozesse „noch nicht gestartet“ lesen können, bevor einer von ihnen „gestartet“ speichert. Man sollte sich auf einen Mechanismus verlassen, der sicherstellt, dass genau einer von ihnen Vorrang hat.

Warum: Ohne dieses Mechanismus könnten zwei Prozesse dieselbe aufwändige Arbeit wiederholen oder widersprüchliche Ergebnisse schreiben, und der Fehler tritt erst dann auf, wenn tatsächlich Überschneidungen auftreten – was in einer ruhigen Entwicklungsumgebung selten der Fall ist.

Beispiel: Ein ursprünglicher Lock-Mechanismus funktionierte unter normalen Bedingungen, konnte aber eine Aufgabe nicht freigeben, wenn der Prozess, der ihn hielt, abstürzte oder hängen blieb. In der Produktion führte das dazu, dass zahlreiche Aufgaben tagelang im Zustand „Verarbeitung“ feststeckten, ohne dass etwas unternommen werden konnte, um sie zu retten. Die Lösung fügte einen ablaufenden Zeitrahmen hinzu, ein Token, das verhindert, dass ein wiederhergestellter Prozess fälschlicherweise als ursprünglicher Inhaber des Locks angesehen wird, sowie eine periodische Überprüfung, die alle Aufgaben zurückholt, deren Zeitrahmen abgelaufen ist, ohne dass sie abgeschlossen wurden. Das ist weitaus umfassender als ein einfaches „Einsammeln einmal“.

Fügen Sie Überwachung und Protokollierung hinzu, bevor ein Incident sie erfordert. Wenn mehr als ein Service beteiligt ist – wie beispielsweise eine Web-Schicht, eine Warteschlange, ein Worker und ein AI-Runtime – durchläuft eine Benutzeraktion jeden dieser Services. Organisieren Sie bereits jetzt eine Möglichkeit, diesen Ablauf über die verschiedenen Services nachzuvollziehen, damit Sie ihn nicht mitten im Ausfall zusammensetzen müssen.

Warum: Die Rekonstruktion von Ereignissen aus getrennten, nicht miteinander verbundenen Protokollen ist langsam und fehleranfällig, insbesondere unter Druck. Ein System, das von Anfang an nachverfolgt werden kann, verwandelt eine stressige Untersuchung in eine schnelle Abfrage.

Beispiel: Die KI-Laufzeitumgebung eines Systems verfügte von Anfang an über detaillierte Trace-Daten, doch der dem Internet zugängliche Dienst davor nicht. Daher zeigte ein Trace alles an, was der Agent ausführte, aber nicht die Anfrage, die ihn auslöste – schließlich gab es keine Verknüpfung zwischen den beiden. Die Lösung bestand darin, zum Zeitpunkt der Anfrage eine Lauf-ID zu erstellen und diese in den Logs jedes Dienstes weiterzuleiten, sodass eine einzige Suche den vollständigen Ablauf einer bestimmten Laufzeit ermöglichte, obwohl die beiden Trace-Systeme getrennt blieben.

Probieren Sie den echten Client frühzeitig aus. Wenn Nutzer über einen bestimmten Browser, eine App oder ein Gerät auf das System zugreifen, testen Sie diesen Zielkanal umgehend – verzichten Sie nicht auf einen generischen API-Client oder eine unvollständige Alternative.

Warum: Reale Kunden weisen Besonderheiten auf, wie Längenbeschränkungen, stillschweigende Abbrüche und ungewöhnliche Kodierungen, die ein allgemeines Tool nicht erkennen kann. Solche Probleme treten in der Regel erst bei echten Nutzern auf, und dann handelt es sich bereits um ein Produktionsproblem, das nicht im Staging-Umfeld entdeckt wird.

Beispiel: Die Dokumentöffnungsfunktion einer Desktop-App bestand alle automatisierten Tests, scheiterte aber gelegentlich bei Nutzern unter einem bestimmten Betriebssystem. Die App kürzte die Download-Links stillschweigend, sobald sie eine bestimmte Länge überschritten, und die temporären Sicherheitsanmeldeinformationen, die zur Signierung der Links verwendet wurden, führten dazu, dass diese Länge deutlich überschritten wurde. Die Lösung bestand darin, die Links mit einer separaten Identität zu signieren, die eine viel kürzere Signatur erzeugt, anstelle der temporären Anmeldeinformationen, die der Rest des Systems verwendete.

Stellen Sie den Netzwerkpfad der Haustür in Einklang mit der Verbindungsweise der Clients. Wenn Benutzer nur über ein privates Netzwerk, wie z. B. eine VPN-Verbindung, einen Zero-Trust-Proxy oder ein internes Netzwerk auf das System zugreifen, stellen Sie sicher, dass die von ihnen verwendete Adresse tatsächlich von Anfang bis Ende zu einem Element auf diesemselben privaten Pfad führt. Ein Domänennamen, der wie intern klingt, sich aber heimlich auf einen öffentlichen Load Balancer oder CDN auflöst, kann für einige Benutzer funktionieren und bei anderen intermittierend versagen.

Warum: Ein solcher Unterschied führt zu unzuverlässigen Fehlern: Einige Benutzer haben zu bestimmten Zeiten Probleme, wodurch es wie eine unzuverlässige Infrastruktur erscheint und nicht wie eine falsche Einstellung. Dies entgeht der Aufmerksamkeit, weil die Verbindung von einem Entwickler-Computer ausgehen kann, der oft einen anderen Netzwerkweg nutzt als ein Firmen-Laptop.

Beispiel: Ein internes Tool sollte ausschließlich über das Firmennetzwerk über einen Zero-Trust-Proxy erreichbar sein, der den Datenverkehr je nach Auswahl des jeweiligen Laptops über verschiedene Verbindungen leitet. Die Domain des Tools klang intern, wies aber auf ein öffentliches Content-Delivery-Netzwerk hin. Einige Verbindungen konnten diese öffentliche Adresse erreichen, während andere nur auf private Adressen zugreifen konnten; dadurch traten Ausfälle auf, die mit dem verwendeten Connector wieder verschwanden. Die Lösung bestand darin, die Eingangsstelle auf einem Load Balancer innerhalb des privaten Netzwerks zu hosten, der über die von echten Nutzern genutzten Routen vollständig erreichbar war, sowie einen separaten, signierten Pfad für eine Desktop-App bereitzustellen, die den Proxy überhaupt nicht nutzen kann.

Erstellen Sie einen Ersatzkunden, der jederzeit den gesamten Ablauf steuern kann. Es handelt sich um ein Skript, das über dieselbe Schnittstelle dieselben Anfragen und Nachfragen wie ein echter Benutzer stellt, sodass vollständige Abläufe ohne Wartezeit auf einen menschlichen Tester wiederholt werden können.

Warum: Agentenflüsse bestehen selten aus einer einzigen Anfrage und einer einzigen Antwort. Sie beinhalten mehrere Schritte, Toolaufrufe sowie im Laufe der Zeit übertragenen Updates, die manuell nur schwer vollständig überprüft werden können. Unit- und Integrationstests prüfen in der Regel nur einzelne Teile und nicht eine vollständige, realistische Sitzung. Mit einem Fake-Kunden wird die Frage, ob ein mehrstufiger Dialog reibungslos verlaufen ist, zu einer Überprüfung, die zu jedem Zeitpunkt durchgeführt werden kann.

Beispiel: Ein Load-Testing-Tool führt dieselben API-Aufrufe durch, die ein echter Client-Dashboard zur Startung eines Tests durchführt, und prüft anschließend eine Statustabelle, um festzustellen, wann der Test abgeschlossen ist – schließlich endet der Test später und die erste Antwort gibt keine Informationen über das Ergebnis preis. Die Anzahl der gleichzeitigen Tests steigt schrittweise an, von wenigen bis zu Dutzenden und schließlich über hundert, wobei eine Obergrenze für die Gesamtzahl der Tests sowie die damit verbundenen Kosten gilt, da jeder gefälschte Test als echter, gebuchter API-Aufruf gilt. Dadurch wurde deutlich, dass das eigentliche Engpassproblem unter Last der Modellanbieter und nicht die umgebende Infrastruktur war, was bei getrennten Tests nicht erkennbar gewesen wäre.

Wählen Sie den Zeitpunkt, zu dem eine Person den Ausgabeinhalt des Agents vor der Ausführung betrachten kann. Bieten Sie einen Ort an, an dem jemand sehen kann, was der Agent vorhat, und dies genehmigen, ändern oder ablehnen kann, anstatt zu ermöglichen, dass die Ausgabe bereits ab dem ersten Tag automatisch Wirkung zeigt.

Warum: Fehler von Agenten unterscheiden sich von gewöhnlichen Fehlern. Sie wirken plausibel, sind aber falsch – es handelt sich nicht um einen offensichtlichen Absturz. Die menschliche Überprüfung erkennt die Fehler, die alle automatischen Checks überstehen, und schafft so die notwendige Erfahrung, um später zu entscheiden, wo der Agent sicher ohne Überprüfung handeln kann.

Beispiel: Ein Dokumentbearbeitungsagent schreibt niemals direkt in das endgültige Dokument. Er bietet Vorschläge an, die ein Überprüfer einzeln akzeptiert, überarbeitet oder ablehnt; daher zählt das, was er erzeugt, erst, nachdem eine Person darauf reagiert hat.

Phase 3: Vorproduktion

Das ist die letzte Umgebung vor den echten Nutzern. Die Frage wandelt sich von „Funktioniert die Funktion?“ zu „Verhält sich der gesamte Prozessstrecken noch, wenn die Bedingungen nicht ideal sind?“ Dazu gehören wiederholte Bereitstellungen, teilweise Ausfälle sowie Abweichungen, wenn das zugrunde liegende Modell oder die Anweisung geändert wird.

Erstellen Sie eine angemessene Bewertung, denn nur Bestehen oder Scheitern reicht nicht aus. Entscheiden Sie, was „gut“ für die Ausgabe des Agenten bedeutet – was in der Regel mehrere Kriterien umfasst (Aufbereitung der richtigen Eingaben, inhaltliche Korrektheit, Konsistenz von Ausführung zu Ausführung) – und wer oder was jedes Kriterium überprüft: eine feste Regel, ein menschlicher Prüfer oder ein separates Modell als Richter.

Warum: Die Ausgabe eines Agenten ist selten einfach richtig oder falsch wie eine Prüfungsanweisung in Unit-Tests. Ein einziges Bestehen/Scheitern-Signal verdeckt, welche Aspekte schlechter geworden sind, und eine Bewertungsmethode, die niemand genau untersucht hat – insbesondere kein automatischer Richter – kann sich unbemerkt von dem entfernen, was für die Nutzer der Ausgabe wichtig ist.

Beispiel: Ein Zusammenfassungsagent wird anhand von drei Kriterien bewertet: die Abdeckung der wichtigsten Fakten, jeglicher erfundener Inhalt, der nicht in der Quelle enthalten ist, sowie das Ausmaß, in dem sich seine Ausgabe bei zwei Ausführungen mit derselben Eingabe unterscheidet. Eine Person prüft eine Stichprobe auf das Vorhandensein von „Erfundenem“, da ein Fehler in dieser Prüfung die höchsten Kosten verursacht.

Führen Sie den Agenten erneut mit einer festgelegten Sammlung von bekannten, korrekten Beispielen aus. Bewahren Sie eine kleine, unveränderliche Sammlung von Eingaben mit genehmigten Ausgaben auf und führen Sie den Agenten bei jeder Bereitstellung aus, insbesondere nach jeder Änderung an einer Anweisung oder am Modell.

Warum: Im Gegensatz zu regulärem Code kann sich das Verhalten eines Agents nach einer kleinen Änderung der Anweisung oder einem Modellupdate subtil verändern, ohne dass ein Test einen Fehler auslöst. Eine feste Beispielsammlung ist oft das Einzige, das feststellt, „dass der Agent zwar einwandfrei läuft, die Ergebnisse aber allmählich nachlassen.“

Beispiel: Ein Dokumentbearbeitungsagent wird anhand eines festgelegten Beispielsatzes auf drei Arten überprüft: ob er die richtigen Abschnitte zum Bearbeiten ausgewählt hat (im Vergleich zu einer von Menschen überprüften Lösung), ob seine vorgeschlagenen Änderungen korrekt waren (bewertet durch ein separates Bewertungsmodell) und inwieweit sich seine Ausgabe bei identischen Eingaben bei verschiedenen Durchläufen unterscheidet. Die Überwachung aller drei Aspekte über verschiedene Versionen – und nicht nur eines einzigen Erfolg-/Fehler-Werts – zeigte, dass eine bestimmte Änderung einen Wert verbesserte, während sie gleichzeitig einen anderen Wert unbemerkt verschlechterte.

Lassen Sie eine fehlerhafte Überprüfung die Veröffentlichung stoppen. Ein Testsuite, deren Fehler dennoch eine Veröffentlichung zulässt, ist lediglich ein Kommentar. Verbinden Sie die Ergebnisse mit dem Pipeline-System, sodass ein Fehler die Veröffentlichung stoppt und das Umgehen davon nicht die Standardlösung ist.

Warum: Wenn ein Kontrollschritt ohne Hindernisse übersprungen werden kann, wird er das in der Regel unter Zeitdruck tun – genau dann haben fehlerhafte Änderungen die größte Chance, durchzukommen.

Beispiel: Die Pipeline ist so konfiguriert, dass, falls ein Test fehlschlägt, der Deploy-Schritt niemals ausgeführt wird. Es gibt keinen „Dennoch deployieren“-Button, und um dies zu umgehen, ist eine bewusste Änderung der Pipeline-Konfiguration erforderlich – nicht nur ein Klick auf eine Warnung.

Bringen Sie den schnellen Weg absichtlich aus dem Gleichgewicht und überprüfen Sie, ob das System ordnungsgemäß abfällt. Wenn Ergebnisse normalerweise über einen schnellen Weg wie einen Cache, eine Live-Verbindung oder eine Warteschlange übermittelt werden, deaktivieren Sie diesen bewusst und prüfen Sie, ob ein langsamerer Ersatzweg weiterhin funktioniert – anstatt dass die Funktion einfach nicht mehr verfügbar ist.

Warum: Caches, Live-Verbindungen und ähnliche Abkürzungen sind die Komponenten, die in der Produktion am ehesten versagen. Ohne Ersatzweg führt ein kleiner Ausfall in einem einzelnen Komponenten dazu, dass die gesamte Funktion nicht mehr funktioniert.

Beispiel: Aktualisierungen erfolgen in der Regel innerhalb einer Sekunde über eine Push-Verbindung. Bei einem Test mit deaktivierter Verbindung prüft das System hingegen alle paar Sekunden – ein langsameres Verfahren, das dem Benutzer dennoch die Ergebnisse anzeigt.

Lassen Sie Tools die Reihenfolge sicherstellen, wenn etwas vor etwas anderem vorhanden sein muss. Wenn Teil A vor der Konfiguration von Teil B vorhanden sein muss, sollte diese Abfolge im Bereitstellungsprozess festgelegt werden und nicht im Gedächtnis einer Person.

Warum: Eine Regel wie „X vor Y bereitstellen“ gilt nur solange, bis die Person, die sie kennt, abwesend ist oder jemand den Prozess ohne Kenntnis dieser Regel automatisiert. Reihenfolgen, die wichtig sind, gehören in Tools.

Beispiel: Ein Orchestrierungsdienst benötigt die ID eines AI-Runtimes, der von einer anderen Deployment-Stack erstellt wird. Wenn jede Stack auf die andere verweisen würde, entstünde ein Kreislauf. Deshalb schreibt die Stack des Runtimes ihre ID bei der Erstellung in einen gemeinsamen Parameterspeicher, und die Orchestrierungsstack liest sie dort ab. Es ist garantiert, dass der Runtime zuerst existiert, und die Stacks verweisen niemals aufeinander.

Phase 4: Die Produktivfreigabe

Die letzte Überprülliste kommt vor dem Einsatz durch echte Nutzer. Die Korrektheit sollte zu diesem Zeitpunkt bereits festgestellt sein. Übrig bleibt die Überprüfung, dass tatsächlich genau das ausgeliefert wird, was getestet wurde, sowie dass Fehler behoben und erklärbar sind.

Liefern Sie genau das Artefakt, das getestet wurde. Verwenden Sie die Build-Version, die die Vorkontrolle bestanden hat, und versehen Sie sie mit einer neuen Kennzeichnung für die Produktivumgebung, anstatt im letzten Schritt eine neue Kopie zu kompilieren.

Warum: Ein Last-Minute-Neubau, selbst aus der „gleichen“ Quelle, kann eine andere Abhängigkeitsversion, einen anderen Zeitstempel oder unterschiedliche Umgebungsdaten enthalten. Dieser Unterschied bedeutet, dass in der Produktion etwas ausgeführt wird, das nie tatsächlich getestet wurde.

Beispiel: Die als Paket bereitgestellte Anwendung, die alle Vortestprüfungen bestanden hat, wird einfach als Produktionsversion neu benannt und in ihrem aktuellen Zustand versandt – es handelt sich dabei um dasselbe Datei, nicht um einen Neubau aus demselben Code.

Entscheiden Sie im Voraus, wohin fehlerhafte Versuche geleitet werden sollen und wie lange sie aufbewahrt werden. Legen Sie eine klare Anzahl an Wiederholungsversuchen fest, entscheiden Sie, wohin alles gelangen soll, was diese Grenze überschreitet, und legen Sie fest, wie lange es aufbewahrt werden soll.

Warum: Ohne Limit kann eine fehlerhafte Aufgabe endlos wiederholt werden, wodurch Ressourcen stillschweigend verbraucht oder eine Warteschlange blockiert wird. Ohne Zielort verschwindet eine fehlgeschlagene Aufgabe einfach, und niemand kann auf einen Fehler reagieren, den er nicht sehen kann.

Beispiel: Eine Aufgabe, die dreimal fehlschlägt, wird automatisch in einen separaten Pufferbereich gelegt und nicht endlos erneut versucht. Sie wird zwei Wochen lang aufbewahrt, damit ein Ingenieur Zeit hat, sie zu entdecken und zu untersuchen.

Planen Sie den Audit-Trail bereits jetzt. Falls die Entscheidungen des Systems später einem Benutzer, Prüfer oder Kollegen erläutert werden müssen, klären Sie im Voraus ab, was aufgezeichnet wird und wie darauf zugegriffen werden kann.

Warum: „Wir fügen später eine ordentliche Protokollierung hinzu“ passiert fast nie, sobald echte Fristen anstehen, und wenn das Bedürfnis offensichtlich wird, kann die fehlende Historie nicht mehr nachträglich rekonstruiert werden.

Beispiel: Jede automatische Entscheidung wird als eigenständige, mit Zeitstempel versehene Aufzeichnung gespeichert. Wenn später jemand fragt, warum das System in einem bestimmten Fall so gehandelt hat, gibt es eine schriftliche Antwort, auf die man verweisen kann, anstatt nur zu raten.

Berichten Sie über jeden tatsächlichen Vorfall, nicht nur über den Patch. Nach einem unerwarteten Ausfall sollten die Ursache sowie die Korrektur aufgezeichnet werden, damit das Team sie später finden kann – das bedeutet mehr als nur ein abgeschlossenes Ticket oder ein Chat-Thread.

Warum: Eine undokumentierte Korrektur muss von jemand anderem von vorne erledigt werden, meist unter größerem Druck. Eine kurze Notiz ist oft der günstigste Schutz davor, eine mehrstündige Untersuchung erneut durchführen zu müssen.

Beispiel: Eine Gruppe von Ausführungen blieb einmal tagelang halbverarbeitet, weil nichts sie automatisch wieder aufnahm. Die Ursache, die Lösung sowie die dahinterstehenden Überlegungen wurden in einem eigenen Dokument festgehalten, zusätzlich zum Code-Update. Später führte eine erneute Prüfung dazu, dass eine frühere Schlussfolgerung, die dem Modell vorwarf, Dinge zu erfinden, überdacht wurde – bei genauerer Betrachtung stellte sich heraus, dass die eigentliche Ursache subtiler war, als ursprünglich angenommen. Auch diese Erkenntnis wurde dokumentiert, sodass die ursprüngliche, weniger genaue Schlussfolgerung nicht mehr Bestand hatte.

Muster hinter der Checkliste

Fast nichts davon ist spezifisch für KI. Es handelt sich um Gewohnheiten, die jedes verteilte System benötigt: eine dauerhafte Zustandsverwaltung, sicheres Umgang mit Wiederholungen, Transparenz darüber, was passiert ist und warum, sowie ein Veröffentlichungsprozess, der nur das ausliefert, was getestet wurde.

Der Agent verändert die Lage des Risikos. Die Ausführungen sind länger und enthalten mehr Kontext, weshalb die Rechenleistung diesem entsprechen muss. Eine Ausführung kann auf Weise fehlschlagen oder abweichen, die ein gewöhnlicher Test übersehen würde, daher sind Regressionstests anhand bekannt guter Beispiele umso wichtiger. Früher oder später wird jemand fragen „Warum hat es das getan?“, und die Audit-Trail muss in der Lage sein, darauf zu antworten.