KI-Engineering · Tag 8: KI in den Betrieb bringen

Willkommen zu Tag 8 unserer Serie KI-Engineering. Heute geht es um den Teil, den fast jeder unterschätzt: den KI Betrieb. Ein KI-Feature ist nicht fertig, wenn es im Release-Branch liegt und die Demo überzeugt hat. Es ist fertig, wenn es an einem Dienstagmorgen um 9 Uhr, unter echter Last, mit echten Nutzereingaben und einem Anbieter, der gerade sein Modell aktualisiert hat, immer noch das tut, was es soll. Genau da beginnt die eigentliche Arbeit. Klassische Software läuft nach dem Deploy ziemlich vorhersehbar weiter. Ein KI-Feature dagegen lebt in einer Umgebung, die sich unter dir verändert: Modelle bekommen neue Versionen, Prompts driften mit den Daten, Kosten schwanken, und die Qualität einer Antwort ist kein Boolean, sondern ein Graubereich. Wer das nicht aktiv überwacht, merkt einen Qualitätsabfall erst, wenn der Kunde anruft.

In den letzten sieben Tagen haben wir Ideen validiert, Prompts strukturiert, Retrieval gebaut, Evaluierung eingeführt und die ersten Features ausgeliefert. Heute schließen wir den Kreis: Wie sorgst du dafür, dass all das im echten Betrieb stabil bleibt? Es geht um Observability, um Fallback-Strategien, um den Umgang mit Modell- und Anbieterwechseln und um ein bisschen Self-Healing. Ehrlich gesagt: Das ist der unspektakulärste, aber wichtigste Tag der Serie.

Warum KI-Features im Betrieb weiterleben müssen

Traditionelle Software ist deterministisch. Gleiche Eingabe, gleiche Ausgabe. Ein KI-Feature bricht mit dieser Annahme an drei Stellen gleichzeitig, und jede davon ist ein Grund, warum der KI Betrieb eine Daueraufgabe ist und kein einmaliges Setup.

Das Modell unter dir bewegt sich

Du hast dein Feature gegen ein bestimmtes Modell entwickelt und getestet. Ein paar Wochen später veröffentlicht der Anbieter eine neue Version, deprecatet die alte oder ändert still das Verhalten hinter demselben Namen. Antworten werden plötzlich ausführlicher, ein Format bricht, ein Tonfall verschiebt sich. Nichts in deinem Code hat sich geändert — trotzdem verhält sich dein Produkt anders. Ohne Überwachung siehst du das nicht.

Die Daten driften

Deine Nutzer stellen im Januar andere Fragen als im März. Ein neues Produkt kommt dazu, eine Marketingkampagne bringt eine andere Zielgruppe, ein Feiertag verschiebt die Themen. Dein Prompt und dein Retrieval waren für die alte Verteilung optimiert. Der Datendrift ist schleichend und darum tückisch: Es gibt keinen Crash, nur langsam schlechter werdende Ergebnisse.

Kosten und Latenz sind Teil der Qualität

Ein KI-Feature kann funktional korrekt sein und dich trotzdem ruinieren, wenn ein Nutzer durch einen ungünstigen Prompt zehntausend Tokens pro Anfrage erzeugt. Oder wenn die Latenz von 800 Millisekunden auf vier Sekunden steigt, weil der Anbieter überlastet ist. Im KI Betrieb sind Kosten und Antwortzeit keine Nebenmetriken, sondern harte Betriebsgrößen, die du genauso überwachen musst wie die Fehlerrate.

Observability: Du kannst nur verbessern, was du siehst

Observability ist die Grundlage für alles Weitere. Bei klassischer Software loggst du Fehler und Latenzen. Bei KI musst du deutlich tiefer gehen, weil das interessante Verhalten nicht in Exceptions steckt, sondern in unauffälligen, aber schlechten Antworten. Ein 200-OK mit einer halluzinierten Antwort ist gefährlicher als ein sauberer 500er.

Ein- und Ausgaben protokollieren

Logge für jede KI-Anfrage die vollständige Kette: die Nutzereingabe, den finalen Prompt inklusive der eingesetzten Retrieval-Kontexte, das verwendete Modell mit exakter Version, die Rohantwort und die daraus abgeleitete Ausgabe. Ohne diese Kette kannst du einen Fehler später nicht reproduzieren. Wichtig ist dabei der Datenschutz: Personenbezogene Daten gehören maskiert oder mit klaren Löschfristen versehen, und sensible Inhalte dürfen nicht ungefiltert in Application-Logs landen. Observability entbindet dich nicht von der DSGVO — sie verschärft die Anforderung eher.

Qualitäts- und Kostenmetriken erfassen

Neben dem reinen Logging brauchst du aggregierte Metriken, die einen Trend sichtbar machen. Konkret: durchschnittliche und maximale Tokenzahl pro Anfrage, Kosten pro Anfrage und pro Feature, Latenz als p50 und p95, Rate der leeren oder abgeschnittenen Antworten und — wenn möglich — ein automatisierter Qualitäts-Score. Diesen Score kannst du über heuristische Prüfungen bilden (Hat die Antwort das erwartete Format? Enthält sie eine Quelle? Ist sie plausibel lang?) oder über ein zweites Modell als Bewerter, wie wir es an Tag 6 beim Thema Evaluierung besprochen haben. Das Monitoring läuft dann nicht nur auf technischen Signalen, sondern auf inhaltlichen.

Tracing über die ganze Kette

Ein modernes KI-Feature ist selten ein einzelner Aufruf. Es ist oft eine Kette: Anfrage klassifizieren, Kontext abrufen, Prompt bauen, Modell aufrufen, Ausgabe validieren, eventuell ein Tool ausführen, nachbessern. Tracing verbindet diese Schritte zu einem durchgehenden Vorgang mit einer gemeinsamen Trace-ID. So siehst du bei einem Problem sofort, an welchem Glied die Kette gerissen ist — ob das Retrieval leer war, das Modell zu langsam oder die Validierung fehlgeschlagen. Ohne Tracing rätst du.

Fallbacks: Was passiert, wenn die KI nicht liefert

Die zweite Säule im KI Betrieb ist die Fallback-Strategie. Anders als bei einer klassischen API gibt es hier zwei Ausfallarten: den harten Ausfall (der Anbieter antwortet nicht oder mit einem Fehler) und den weichen Ausfall (der Anbieter antwortet, aber die Antwort ist unbrauchbar). Beide brauchen eine geplante Reaktion.

Harter Ausfall: Timeout, Rate-Limit, Anbieterstörung

Behandle jeden KI-Aufruf wie einen unzuverlässigen Netzwerkaufruf, weil er genau das ist. Setze ein striktes Timeout, damit ein hängender Aufruf nicht deine ganze Anfrage blockiert. Nutze Retries mit exponentiellem Backoff, aber begrenzt — endloses Wiederholen macht eine Überlastung nur schlimmer. Ein Circuit Breaker hilft, damit du bei einer Anbieterstörung nicht weiter in ein totes Loch feuerst, sondern kurz aussetzt und dann vorsichtig wieder öffnest. Und dann brauchst du eine Antwort für den Fall, dass wirklich nichts kommt: eine sinnvolle Standardausgabe, ein Verweis auf einen menschlichen Kontakt oder eine ehrliche Meldung. Ein Fallback auf ein zweites, unabhängiges Modell eines anderen Anbieters ist oft die robusteste Variante, weil zwei Anbieter selten gleichzeitig ausfallen.

Weicher Ausfall: die Antwort taugt nichts

Der schwierigere Fall. Das Modell antwortet, aber die Antwort ist leer, im falschen Format, unplausibel oder verstößt gegen eine Regel. Hier greift eine Validierungsschicht direkt nach dem Aufruf: Prüfe das Format hart, prüfe fachliche Plausibilität, prüfe auf verbotene Inhalte. Fällt die Antwort durch, kannst du gestuft reagieren — einmal mit angepasstem Prompt neu anfragen, dann auf ein stärkeres Modell eskalieren, und wenn auch das scheitert, auf die deterministische Standardausgabe zurückfallen. Das Ziel ist, dass der Nutzer nie eine kaputte Antwort sieht, sondern im schlimmsten Fall eine ehrliche.

Modell- und Anbieterwechsel abfangen

Binde dein Produkt nie fest an einen einzigen Modellnamen im Code. Führe stattdessen eine Abstraktionsschicht ein, hinter der das konkrete Modell und der konkrete Anbieter konfigurierbar sind. Das kostet am Anfang etwas Disziplin und zahlt sich mehrfach aus: Du kannst auf eine Deprecation reagieren, ohne Code zu ändern, du kannst A/B zwischen zwei Modellen fahren, und du kannst bei einem Ausfall den Anbieter umschalten. Genauso wichtig ist es, die Modellversion zu pinnen, wo der Anbieter das erlaubt — sonst ändert sich dein Produkt ohne dein Zutun. Wenn eine neue Version ansteht, lässt du sie erst gegen dein Evaluierungs-Set aus Tag 6 laufen, bevor du sie in Produktion drehst. So wird ein Modellwechsel zu einer kontrollierten Entscheidung statt zu einer Überraschung im Monitoring.

Self-Healing: Qualitätsabfall automatisch erkennen

Self-Healing klingt nach Magie, ist in der Praxis aber vor allem konsequent zu Ende gedachte Observability. Der Kern: Das System erkennt selbst, wenn seine Ausgaben schlechter werden, und reagiert, bevor ein Mensch eingreifen muss. Definiere Schwellenwerte für deine Qualitäts- und Kostenmetriken — etwa eine maximale Rate an Formatfehlern oder eine obere Kostengrenze pro Anfrage. Wird ein Schwellenwert über ein Zeitfenster gerissen, löst das eine automatische Reaktion aus: einen Alarm an das zuständige Team, ein automatisches Zurückschalten auf die zuletzt stabile Modellversion oder das Aktivieren eines konservativeren Prompts. Ein einfacher, aber wirksamer Mechanismus ist ein kontinuierlicher Canary: Ein kleiner Satz repräsentativer Testanfragen läuft periodisch gegen das Live-System, und die Ergebnisse werden bewertet. So bemerkst du einen Qualitätsabfall in Minuten statt in Tagen. Echtes Self-Healing bleibt aber ehrlicherweise begrenzt: Es fängt bekannte Fehlermuster ab, ersetzt aber nicht das menschliche Nachschärfen bei neuen Problemen. Wartung bleibt eine Daueraufgabe.

So gehst du vor

Wenn du ein KI-Feature betriebsfest machen willst, arbeite dich in dieser Reihenfolge vor, statt alles auf einmal zu wollen.

• Erst sehen: Logge Ein- und Ausgaben mit Modellversion, Trace-ID und Kosten. Ohne Sichtbarkeit ist jeder weitere Schritt Ratespiel.
• Dann messen: Baue ein Dashboard mit Latenz, Kosten, Tokenverbrauch und einem Qualitäts-Score. Definiere, was „normal“ ist.
• Dann absichern: Ergänze Timeout, begrenzte Retries, Circuit Breaker und eine Validierungsschicht mit gestuften Fallbacks.
• Dann entkoppeln: Ziehe Modell und Anbieter hinter eine Konfiguration, pinne Versionen und verbinde jeden Wechsel mit deinem Evaluierungs-Set.
• Dann automatisieren: Setze Schwellenwerte, richte Alarme ein und lass einen Canary periodisch die Qualität prüfen.
• Und dann bleib dran: Plane feste Wartungsfenster ein, in denen du Logs sichtest, Prompts nachschärfst und Modellupdates evaluierst. KI Betrieb ist kein Projekt mit Enddatum.

Ein konkretes Praxisbeispiel

Ein Kunde von uns betreibt einen KI-Support-Assistenten, der eingehende Anfragen automatisch kategorisiert und Antwortentwürfe erstellt. Zwei Wochen nach dem stabilen Start meldete das Team, die Antworten seien „irgendwie schlechter“ geworden — mehr nicht, kein Ticket, kein Fehler. Weil wir jede Antwort mit Modellversion und einem heuristischen Qualitäts-Score geloggt hatten, war die Ursache in einer Stunde gefunden: Der Anbieter hatte still eine neue Modellrevision hinter demselben Namen ausgerollt. Der Score für „Antwort enthält eine konkrete Handlungsanweisung“ war messbar um etwa zwölf Prozent gefallen, und die durchschnittliche Antwortlänge war deutlich gestiegen, was zusätzlich die Kosten hochtrieb. Weil Modell und Version über die Abstraktionsschicht konfigurierbar waren, konnten wir sofort auf die vorherige, gepinnte Version zurückschalten — die Qualität war innerhalb weniger Minuten wieder auf dem alten Niveau. Danach haben wir die neue Version in Ruhe gegen das Evaluierungs-Set geprüft, den Prompt angepasst und den Wechsel kontrolliert nachgeholt. Ohne Observability wäre dieser Qualitätsabfall wochenlang unbemerkt geblieben und hätte langsam das Vertrauen der Support-Mitarbeiter in das Feature untergraben. Genau darum ist Monitoring hier keine Kür.

Fazit

Damit schließen wir die Serie KI-Engineering. Über acht Tage haben wir den Weg von der ersten Idee bis in den stabilen Betrieb gezeichnet: von der ehrlichen Validierung eines Anwendungsfalls über sauberes Prompt-Design, Retrieval und Kontext, systematische Evaluierung bis hin zur ersten Auslieferung. Der heutige Tag war die logische Konsequenz aus allem davor — denn ein KI-Feature ist erst dann wirklich fertig, wenn es überwacht, abgesichert und wartbar im echten Betrieb läuft. Die Kernbotschaft der ganzen Serie lässt sich in einem Satz zusammenfassen: KI-Engineering ist zu neunzig Prozent solides Software-Engineering und zu zehn Prozent Modellzauber — und der KI Betrieb mit Observability, Fallbacks und ehrlicher Wartung ist der Teil, der über Erfolg oder Enttäuschung entscheidet. Wer nur die Demo baut, hat den einfachen Teil erledigt. Wer das Feature Monate später noch verlässlich am Laufen hält, hat verstanden, worum es geht.

Die gesamte Serie findest du in unserer Serien-Übersicht. Wenn du ein KI-Feature nicht nur bauen, sondern betriebsfest und wartbar in Produktion bringen willst, schau dir unsere KI-Engineering-Leistungen an. Und wenn du ein konkretes Vorhaben hast oder ein bestehendes KI-Feature stabilisieren möchtest, dann lass uns direkt darüber sprechen — nimm einfach Kontakt mit uns auf.