LLM-Betrieb: Von der Demo zum verantwortbaren Lauf

Ein Prototyp braucht einen API-Key und einen Endpunkt. Das reicht für die Demo. Für den Betrieb fehlt: wer den Prompt ändern darf, wie ein Rollback aussieht, wo die Secrets liegen, und wer nachts ans Telefon geht, wenn das Modell anfängt, Unsinn zu antworten.

Ich sehe das in fast jedem Projekt an derselben Stelle kippen. Die Demo überzeugt, der Prototyp geht „vorläufig" live, und sechs Wochen später hat niemand mehr den Überblick, welche Prompt-Version gerade läuft.

Prompts sind Code

Ein Prompt, der in einem Chat-Fenster beim Anbieter liegt oder in einer Konfigurationstabelle ohne Historie, ist nicht versioniert. Er ist ein Zustand, den niemand reproduzieren kann.

Was ich stattdessen aufsetze:

Prompt-Dateien im Repo, mit Commit-Historie wie jeder andere Code

Eine Versionsnummer, die im Log jedes Laufs mitgeschickt wird

Review vor dem Merge, genau wie bei einer Funktionsänderung

Das klingt nach wenig. Der Unterschied zeigt sich, wenn eine Antwort schiefgeht und jemand fragt: welcher Prompt lief zu dem Zeitpunkt. Ohne Versionierung ist die Antwort ein Schulterzucken.

Die Pipeline, nicht der einzelne Call

Ein LLM-Call ist nie allein. Davor: Retrieval, Filterung, Zusammenbau des Kontexts. Danach: Parsing, Validierung, manchmal ein zweiter Call zur Prüfung. Jeder Schritt kann brechen, unabhängig vom Modell.

Für einen MCP-Server, der einem Chatbot Tools bereitstellt, heißt das konkret: der Server muss laufen, muss neu deploybar sein ohne den Chatbot mit runterzureißen, und jemand muss wissen, wer ihn beim nächsten Vorfall neu startet. Ein Modell-Update auf der Anbieterseite darf nicht bedeuten, dass die ganze Pipeline neu getestet werden muss, weil niemand weiß, welche Version wo hängt.

Secrets, die nicht im Standard-Repo-Pfad landen

API-Keys im .env, das versehentlich doch im Repo landet. Ein Key, der für mehrere Projekte gilt, weil das Anlegen eines neuen zu viel Aufwand war. Rotation, die theoretisch möglich ist, praktisch aber nie passiert, weil niemand weiß, wo der Key sonst noch verwendet wird.

Das ist kein KI-spezifisches Problem, aber LLM-Projekte verschärfen es. Ein Key hängt oft an einem Abrechnungskonto mit echtem Limit. Wird er kompromittiert, ist der Schaden nicht nur ein Datenleck, sondern eine Rechnung.

Ein Rollback, konkret durchgespielt

Ein Modell-Update auf der Anbieterseite ändert das Antwortverhalten. Die Fehlerquote in der Evaluation steigt. Ohne einen vorbereiteten Rollback-Pfad heißt das: jemand muss unter Zeitdruck herausfinden, welche Prompt-Version vor dem Update lief, ob sie noch mit dem aktuellen Retrieval-Stand kompatibel ist, und wie man den Traffic dorthin zurückführt, ohne laufende Sitzungen zu zerreißen.

Mit vorbereitetem Pfad ist das ein Deployment mit einem alten Tag, kein Notfall. Der Unterschied entsteht nicht im Vorfall selbst, sondern Wochen davor, als jemand entschieden hat, dass ein Rollback ein getesteter Ablauf ist und keine Bastelaktion.

Wer den Lauf verantwortet

Die Frage, die in Reviews am häufigsten unbeantwortet bleibt: Wenn das System um 3 Uhr morgens falsche Antworten gibt, wer bekommt den Alert, und was darf diese Person allein entscheiden? Rollback auf die letzte Prompt-Version? Modell abschalten? Nutzer informieren?

Ohne eine Antwort auf diese Frage ist der Betrieb ein Prototyp mit Produktionslast. Das hält, bis es nicht mehr hält, meistens an einem Freitagabend.

In kleinen Teams ist die Antwort oft: derjenige, der es gebaut hat. Das funktioniert, solange diese Person erreichbar ist und die einzige bleibt, die den Prototyp verstanden hat. Sobald ein zweites System dazukommt oder die Person im Urlaub ist, ist „ich weiß schon, wie das geht" keine Betriebsstrategie mehr, sondern ein Single Point of Failure mit Namen.

Die Pipeline für die Pipeline

Ein Prompt-Wechsel sollte durch dieselbe CI laufen wie ein Code-Wechsel: Evaluation-Set gegen die neue Version, Diff gegen die alte Version, erst dann Merge. Das klingt nach Overhead für „nur einen Text", ist aber genau die Stelle, an der die meisten Regressionen entstehen. Ein Prompt, der in einer Sitzung besser wirkt, kann in einem anderen Kontext still schlechter werden, und ohne automatisierten Vergleich merkt das niemand vor dem Nutzer.

Wo ich das aufsetze, läuft das Evaluation-Set als eigener CI-Job, der vor jedem Merge auf einem Prompt- oder Retrieval-Branch feuert. Rot heißt: kein Merge, unabhängig davon, wie gut die Demo im Slack-Kanal aussah.

Was ich in einem Review dafür prüfe

Liegt der Prompt versioniert im Repo, mit Historie?

Lässt sich ein Lauf einer Version zuordnen, im Log, nicht nur in der Erinnerung?

Gibt es einen Rollback-Pfad, der in unter einer Stunde ausführbar ist?

Weiß eine konkrete Person, dass sie im Vorfall zuständig ist?

Das hängt eng an Observability: ohne Logs zur Version lässt sich ein Vorfall nicht rekonstruieren. Und an Evaluation: ein Rollback ohne ein Set, das die alte Version gegen die neue misst, ist ein Sprung ins Dunkle.

Was der Readiness-Check daraus macht

An Tag 4 des LLM-Readiness-Checks frage ich nach genau diesen Punkten: Prompt-Versionierung, Rollback, Verantwortlichkeit. Die Antwort „das machen wir dann, wenn es live ist" zählt als Fund, nicht als Plan. Ein Prototyp ohne diese Antworten ist kein Go-Live, egal wie gut die Demo war.

Die Leistung dahinter sitzt unter KI-Engineering. Verwandt: Antworten rekonstruieren, Evaluation in Produktion.