Was stehen muss, bevor ein KI-Pilot in Produktion geht

Was sich ändert, wenn das Pilotteam nicht mehr zusieht

• Fehler bemerken. Im Piloten lesen die Entwickler die meisten Ergebnisse. In der Produktion müssen Monitoring und eine stichprobenartige Prüfung finden, was schiefgeht.
• Das System ändern. Aus einem im Notebook bearbeiteten Prompt wird ein versioniertes Release, das eine Pipeline durchläuft und zurückgerollt werden kann.
• Testen. Anthropics Leitfaden zu Evaluierungen unterscheidet Capability-Evals, die mit niedriger Bestehensquote beginnen und zeigen, was zu verbessern ist, von Regressions-Evals, die fast vollständig bestanden werden sollten und schützen, was bereits funktioniert. Die Produktion braucht die zweite Art.
• Support. Aus einer Nachricht an den Entwickler wird ein Supportweg, ein Runbook und jemand, der während der Prozesszeiten erreichbar ist.
• Volumen. Aus einigen hundert Testfällen wird das volle Volumen mit Spitzen, Ratenlimits der Anbieter und gelegentlichen Ausfällen.

Ein Readiness Review nach SRE-Vorbild

Die SRE-Teams von Google führen ein Production Readiness Review durch, bevor sie die Verantwortung für einen Dienst übernehmen, mit einer Checkliste, die auf diesen Dienst zugeschnitten ist. Gefragt wird zum Beispiel, ob alle für Nutzer sichtbaren Fehler mit Alarmierung überwacht werden und ob Fehler im zentralen Logging ankommen. Für einen KI-Prozessdienst kommen Punkte hinzu, die klassische Dienste nicht haben.

1. 1

   Regressionssuite

   Zurückgehaltene Fälle plus jeder im Piloten gefundene Fehler, ausgeführt bei jeder Änderung an Prompt, Modell, Werkzeug oder Retrieval-Einstellung. Eine Regression blockiert das Release.

2. 2

   Versionen und Rollback

   Prompts, Modellkennungen und Werkzeugdefinitionen werden gemeinsam versioniert, und die vorherige Version lässt sich wieder ausrollen. Das AWS Generative AI Lens empfiehlt versionierte Prompt-Vorlagen genau aus diesem Grund.

3. 3

   Monitoring

   Fehler, Latenz und Kosten pro Fall, dazu Qualitätssignale: die Fehlerquote der Stichprobe, die Eskalationsquote und regelmäßige Läufe gegen den Referenzdatensatz, um Drift zu erkennen.

4. 4

   Zielwerte mit Konsequenzen

   Wenige Zielwerte für Qualität, Bearbeitungszeit und Kosten, mit einer vereinbarten Reaktion, wenn einer verfehlt wird. Das SRE-Buch rät, Zielwerte wenige und einfach zu halten.

5. 5

   Sicheres Scheitern

   Wenn der Modellanbieter nicht antwortet oder ausfällt, gehen Fälle in die manuelle Queue und gehen weder verloren noch bleiben sie halb bearbeitet.

6. 6

   Verantwortung und Support

   Eine benannte verantwortliche Person, ein Supportweg für die Zeiten, in denen der Prozess läuft, und ein Runbook für die bisher beobachteten Fehler.

Ein hypothetisches Go-live-Gate

Stellen Sie sich einen Piloten zur Vorsortierung von Schadenmeldungen vor, der seine Abnahmekriterien erfüllt hat. Beim Readiness Review besteht die Regressionssuite, ein Rollback wurde in Staging geprobt, die Fehlerquote der Stichprobe erscheint auf einem Dashboard, und eine Teamleitung aus der Schadenabteilung hat die Verantwortung übernommen. Ein Punkt fehlt: Niemand hat getestet, was passiert, wenn der Modellanbieter nicht erreichbar ist. Der Go-live wartet, bis ein simulierter Ausfall zeigt, dass Fälle in der manuellen Queue landen. Ein einziger offener Punkt reicht, um den Go-live zu verschieben, denn er betrifft einen Fehlerpfad, dessen Funktionieren noch niemand gesehen hat.

Übergabe an das Team, das den Betrieb übernimmt

Im Modell von Google schulen die Prüfenden das übernehmende Team mit Designübersichten, Vertiefungen in Anfrageabläufe und praktischen Übungen und übertragen die Verantwortung dann schrittweise, während die Entwickler eine Zeit lang als Rückhalt verfügbar bleiben. Bei einem KI-System sind die Übungen konkret: gemeinsam Fehlerprotokolle lesen, die Regressionssuite auf eine geplante Prompt-Änderung anwenden, ein Rollback durchführen und einen Sprung der Kosten pro Fall erklären. Definieren Sie das Ende der Rückhaltphase über ein Ereignis, etwa ein Rollback, das das Betriebsteam allein bewältigt, statt über ein Datum.

Stufenweise einschalten

Das AWS Lens beschreibt das Deployment als kontrollierten Rollout, der auf echte Daten und Nutzung skaliert. Für einen Prozess heißt das meist eine Schattenphase, in der das System läuft und Menschen die Arbeit weiter erledigen, eine assistierte Phase, in der das System vorschlägt und Menschen entscheiden, und danach jeweils ein Falltyp oder eine Region. Jede Stufe braucht vorab festgehaltene Ausstiegskriterien und einen Auslöser für das Zurückrollen. Breitere Fragen zum Betrieb vieler Agenten in einer Engineering-Organisation behandelt unser Artikel zur autonomen Software Factory.

Die autonome Software-FabrikWer nach dem Piloten für ein KI-System verantwortlich ist