Das fehlende Deployment-Gate für AI-Anwendungen

Die meisten AI-Prototypen scheitern in Produktion aus langweiligen Gründen.

Das Modell ist nicht immer das Problem. Die Demo funktioniert oft. Der Prompt sieht plausibel aus. Die RAG-Antwort ist in den drei Notebook-Beispielen gut. Der Service gibt 200 zurück. Das Dashboard ist grün.

Dann trifft das System auf echten Traffic:

eine Prompt-Änderung bricht einen wichtigen Fall
Retrieval wird schlechter, ohne dass es jemand merkt
Tokenverbrauch verdoppelt sich
eine Route nutzt plötzlich das teure Modell
Traces enthalten keine Prompt-Version oder keinen Modellnamen
der Service ist up, aber Nutzer warten zu lange auf das erste Token
niemand weiß, wie Prompt, Modell, Retrieval-Konfiguration oder Provider zurückgerollt werden

Das ist kein Research-Problem. Das ist ein Production-Readiness-Problem.

Software kennt dieses Problem längst

Normale Software-Deployments haben eine reife Release-Disziplin.

Bevor Traffic verschoben wird, laufen Tests, Linter, Type Checks, Security-Scans, Smoke Tests, Health Checks, Canaries, Policy Checks und SLO-basierte Rollout-Entscheidungen. Kubernetes hat Readiness Probes. CI-Systeme haben required checks. Progressive-Delivery-Tools können ein Rollout stoppen, wenn sich die neue Version schlechter verhält als die alte.

Klassisches ML hat eine verwandte Lektion gelernt. Reife MLOps-Stacks haben Model Registries, Datenvalidierung, Modellvalidierung, Baseline-Vergleiche, Drift-Monitoring, Model-Quality-Monitoring und Approval- oder Blessing-Workflows.

Die Idee eines Deployment-Gates ist also nicht neu.

Was fehlt, ist diese Disziplin sauber auf moderne AI-Anwendungen anzuwenden: LLM-API-Calls, RAG-Systeme, Prompt-Änderungen, Model-/Provider-Routing, Tool-Calls, Tokenbudgets und AI-spezifische Observability.

Die AI-spezifische Lücke

Ein AI-Feature kann normale Deployment-Checks bestehen und trotzdem nicht bereit für Produktion sein.

Der Container startet. Der HTTP-Endpoint antwortet. CPU und Memory sehen gut aus. Die Kubernetes Readiness Probe ist grün. Die Unit Tests laufen durch.

Aber nichts davon beantwortet:

Ist die Antwortqualität schlechter geworden?
Ist die Retrieval-Qualität schlechter geworden?
Hat eine Prompt-Änderung wichtige Beispiele gebrochen?
Hat sich das Verhalten von Modell oder Provider geändert?
Sind Kosten pro Request noch im Budget?
Sind Modell, Prompt-Version, Tokenzahl, Latenz, Kosten, Request-ID und Fehlertyp beobachtbar?
Gibt es einen Rollback für Modell, Prompt, Retrieval-Konfiguration oder Provider-Route?

Das ist die Lücke, die mich interessiert.

Die Preflight-Frage

Die nützliche Frage ist nicht:

Ist der Service up?

Die nützliche Frage ist:

Ist diese AI-Änderung bereit für Production Traffic?

Dafür braucht man einen Report, nicht fünf unverbundene Dashboards.

Können wir diese AI-Änderung shippen?

Qualität/Evals      PASS oder FAIL
RAG-Verhalten        PASS oder FAIL
Latenz/TTFT          PASS oder FAIL
Fehlerrate           PASS oder FAIL
Kostenbudget         PASS oder FAIL
Observability        PASS oder WARN oder FAIL
Rollback/Runbook     PASS oder WARN oder FAIL
Gesamtverdict        PASS oder FAIL

Diese Schicht baue ich mit aipreflight.

Was aipreflight macht

aipreflight ist ein CI/CD-Readiness-Gate für AI-Anwendungen. Es prüft Eval-Qualität, LLM/RAG-Verhalten, Latenz, Fehler, Kostenbudgets, Observability und Rollout-Readiness, bevor Traffic geroutet wird.

Der Befehl ist bewusst klein:

aipreflight check --profile profiles/app.yml
aipreflight check --profile profiles/rag.yml
aipreflight check --profile profiles/inference.yml

Die Ausgabe ist bewusst hart:

Verdict: PASS
  cost           PASS  $7.69/mo across 1 call site(s), within budget
  evals          PASS  quality gate passed: pass rate 100% (min 90%)
  observability  PASS  telemetry config present with required fields
  deployment     PASS  rollback runbook present

Das Tool schreibt einen maschinenlesbaren JSON-Report für CI und einen Markdown-Report für Menschen. Der wichtigste Teil ist der Verdict. Ein Deployment-Gate muss ein Release blockieren können, ohne dass ein Mensch erst Graphen interpretieren muss.

Die Profile

aipreflight hat drei Profile, weil “AI-Anwendung” nicht nur eine Sache ist.

Das app-Profil ist für Anwendungen, die gehostete LLM-APIs verwenden. Diese Teams betreiben keine eigene Inferenz-Infrastruktur, brauchen aber trotzdem Kostenbudgets, Evals, Observability-Felder und Rollback-Dokumentation.

Das rag-Profil prüft Fehlerklassen, die Infrastruktur-Checks nicht sehen: Retrieval Precision, Antwortqualität, Citation Rate, Halluzinationsrate, Handling leerer Retrieval-Ergebnisse, Kosten und Telemetrie.

Das inference-Profil ist für selbst betriebene oder OpenAI-kompatible Inference-Endpoints. Es nutzt llmprobe für client-seitige TTFT-, Latenz-, Durchsatz- und Fehler-Probes und korreliert das optional mit Prometheus/vLLM-Metriken.

Warum llmprobe und tokentoll getrennt bleiben

Ich will nicht, dass aipreflight zu einer riesigen Plattform wird.

Das schärfere Design ist:

aipreflight  -> die Release-Entscheidung
llmprobe     -> externe User-Path-Probes
tokentoll    -> Token- und Kostenbudget-Checks
Prometheus   -> Service- und Inferenz-Telemetrie
Eval Runner  -> Qualitätsergebnisse aus pytest, promptfoo, ragas oder eigenem Code

llmprobe beantwortet:

Was erlebt der Nutzerpfad wirklich?

tokentoll beantwortet:

Was wird dieser Code kosten, wenn er läuft?

aipreflight beantwortet:

Soll diese AI-Änderung mit diesen Signalen shippen?

Diese Trennung ist wichtig. Der Wert liegt nicht darin, jedes spezialisierte Tool zu ersetzen. Der Wert liegt darin, die Signale in eine Release-Entscheidung zu übersetzen.

Was das nicht ersetzt

Das ist keine Model Registry. Keine Vector Database. Kein LLM Gateway. Kein Tracing Backend. Kein Grafana. Kein Kubernetes. Keine komplette MLOps-Plattform.

Diese Tools sollen weiter das tun, worin sie gut sind.

aipreflight sitzt an der Release-Grenze. Es stellt die Produktionsfrage, bevor ein Prompt, Modell, RAG-Pipeline, Provider-Route oder Inference-Endpoint Traffic bekommt.

Das Prototype-to-Production-Muster

Das Muster, das ich wiederholbar machen will, ist:

prototype
  -> service
  -> eval suite
  -> cost budget
  -> observability contract
  -> deployment gate
  -> rollback/runbook
  -> production traffic

Das ist der Unterschied zwischen “wir haben eine AI-Demo” und “wir können dieses AI-Feature betreiben”.

Die technische Arbeit ist nicht glamourös. Oft sind es YAML, kleine Adapter, Fixtures, Exit Codes, Reports und langweilige Checks. Aber genau diese Teile machen aus AI-Systemen keine beeindruckenden Demos, sondern Software, die ein Team besitzen und betreiben kann.

Die Positionierung

Die Behauptung ist nicht:

Ich habe Deployment-Readiness erfunden.

Die Behauptung ist:

Normale Software hat reife Deployment-Gates. Klassisches ML hat Modellvalidierung und Model Blessing. Moderne AI-Anwendungen brauchen vergleichbare Preflight-Checks für Eval-Qualität, RAG-Verhalten, Tokenkosten, Model-/Provider-Verhalten, Observability und Rollback-Readiness.

In diesem Bereich will ich arbeiten: AI Platform und Reliability Engineering für produktive AI-Systeme.

Das Modell ist wichtig. Aber nachdem der Prototyp funktioniert, entscheidet die Produktionsschicht, ob das System echte Nutzer überlebt.