Ein produktionsreifes AI-Produkt besitzt ein validiertes Nutzerergebnis, explizite Verhaltens- und Datengrenzen, getestete Fehlerbehandlung, beobachtbaren Betrieb und benannte Owner für Release, Support, Änderung und Stopp.
Ein Prototyp zeigt Möglichkeit unter ausgewählten Bedingungen. Produktion bringt mehrdeutige Fragen, fehlenden Kontext, Rechte-Randfälle, feindliche Inhalte, Provider-Ausfälle, Modelländerungen, lange Inputs, Parallelität, Kostensprünge und unerwartete Nutzungsweisen. Ein Team kann einen guten Modellscore besitzen, während das Gesamtprodukt unsicher, unwirtschaftlich oder unbetreibbar bleibt.
Produktionsreife ist weder eine Modelleigenschaft noch ein letzter Security Review. Sie ist ein evidenzbasierter Release-Entscheid über das vollständige sozio-technische System. Das Team erklärt, wem es nützt, welches Verhalten akzeptabel ist, was bei Ausfällen passiert, wie Wirkung beobachtet wird und wer eingreifen darf.
Produktvertrag
Mit Nutzerergebnis und begrenztem Verhaltensversprechen beginnen
“Beantwortet Fragen mit AI” ist keine Produktionsanforderung. Benennen Sie Nutzer, zu erledigende Aufgabe, verfügbare Inputs, verbleibenden Entscheid und Systemeffekt. Ein Vertragsassistent kann Klauseln finden und Themen vorschlagen, während eine qualifizierte Person die Rechtsposition entscheidet. Diese Grenze bestimmt Tests und Kommunikation der Oberfläche.
Schreiben Sie unakzeptable Resultate explizit: Daten eines anderen Tenants zeigen, Quellen erfinden, irreversible Aktionen ohne Freigabe ausführen oder eine unvollständige Analyse still als vollständig liefern. Ergänzen Sie Sprachen, Dokumenttypen, Volumen und Accessibility. Marketing, Hilfe und Produkt-Hinweise müssen zum getesteten Scope passen, damit kein unvertretbares Verhalten eingeladen wird.
| Bereich | Evidenz vor Release | Owner |
|---|---|---|
| Nutzerwert | Beobachteter Abschluss eines wertvollen Jobs | Produkt |
| Verhalten | Versionierte Evaluation und kritische Fehler | Produkt und Engineering |
| Daten und Security | Geprüfte Datenflüsse, Rechte und Threat Controls | Security und Privacy |
| Zuverlässigkeit | Last-, Ausfall-, Fallback- und Recovery-Tests | Engineering und Operations |
| Release | Rollout-Grenzen, Support, Rollback und Incident-Plan | Service Owner |
Evaluation
Gesamten Workflow und jede wesentliche Änderung evaluieren
Modellbenchmarks beantworten nützliche, aber enge Fragen. Produktevaluation umfasst Retrieval, Promptaufbau, strukturierte Outputs, Tools, Rechte, Nutzerreview und Downstream-Status. Nutzen Sie deterministische Checks für exakte Regeln, Expertenrubriken für echtes Ermessen und Outcome-Metriken für Verhalten. Erfassen Sie Herkunft, erlaubte Datennutzung, Sollverhalten und Schwere.
Der Evaluationssatz ist Teil des Produkts und keine einmalige Hürde. Versionieren Sie ihn und schützen Sie Fälle vor täglichem Tuning. Eine Änderungsmatrix definiert Suites: Ein neuer Parser braucht Extraktions- und Rechtetests. Ein Modellupdate braucht Verhalten, Kosten und Latenz. Ein Tool-Schema braucht Side-Effect- und Idempotenztests. Prüfen Sie Fehler einzeln, bevor ein besserer Durchschnitt angenommen wird.
- Erfassen Sie Verweigerung und Eskalation als erwartete Erfolge.
- Testen Sie fehlenden, widersprüchlichen, alten und bösartigen Kontext.
- Trennen Sie kritische Fehlerraten von durchschnittlicher Qualität.
- Sichern Sie genug Konfiguration zur Reproduktion des Releases.
- Definieren Sie Akzeptanz vor der Sichtung neuer Resultate.
Engineering
Modelloutput als fremden Input einer zuverlässigen Anwendung behandeln
Ein Modell darf seine effektiven Rechte nicht selbst entscheiden. Lösen Sie Nutzeridentität und Ressourcenscope in Code, bieten Sie nur nötige Tool-Operationen und validieren Sie jedes Argument. Halten Sie abgerufenen Inhalt als fremde Daten, damit Instruktionen in Dokumenten keine Autorität umdefinieren. Encodieren Sie Output für sein Ziel und geben Sie generierten Code, Queries oder Markup nie direkt an privilegierte Ausführung.
Zuverlässigkeitsengineering umgibt die probabilistische Komponente. Setzen Sie Fristen, Cancellation, begrenzte Wiederholung und Idempotenz. Nutzen Sie Circuit Breaker oder reduzierte Modi bei Provider-Ausfall. Unterscheiden Sie eine sicher klingende Antwort von einer bestätigten Aktion. Nutzer sehen, ob etwas vorgeschlagen, freizugebend, angenommen, fehlgeschlagen oder wiederhergestellt ist. OWASP zu Output Handling und Agency gilt direkt für Tool-Nutzung.
- Minimieren Sie Tool-Fähigkeit und an das Modell zurückgegebene Daten.
- Lassen Sie folgenreiche Aktionen von der betroffenen Person bestätigen.
- Prüfen Sie Typen, Werte, Ressourceneigentum und Policy vor Ausführung.
- Machen Sie Wiederholungen sicher oder erkennen Sie doppelte Operationsschlüssel.
- Bieten Sie einen Nicht-AI-Pfad für zeitkritische Arbeit.
Betrieb
Das Produktionsteam braucht Sichtbarkeit, Autorität und Ausstieg
Überwachen Sie Servicegesundheit und Produktverhalten getrennt. Verfügbarkeit und Latenz können gesund sein, während Nutzen sinkt. Verbinden Sie Infrastrukturereignisse mit Qualitätsstichproben, Nutzeränderung, Eskalation, Verweigerung, Kosten und abgeschlossenem Job. Segmentieren Sie nach Modell, Prompt, Sprache, Aufgabe und Kontext, ohne Observability zur unbegrenzten Datensammlung zu machen.
Definieren Sie Support und Incident Playbooks vor breitem Zugriff. Die Triage trennt Modellverhalten, falsche oder fehlende Daten, Rechte, Integration, Oberfläche und Nutzerverständnis, weil andere Owner nötig sind. Rollen Sie schrittweise aus und dokumentieren Sie maximale Autorität. Das Team kann Modell halten, Tool deaktivieren, Autonomie reduzieren, Review erzwingen oder das Feature entfernen, ohne den Geschäftsprozess einzusperren.
- Alarmieren Sie kritisches Verhalten und Verteilungswechsel statt jeden schwachen Satz.
- Ordnen Sie Inferenz-, Retrieval-, Tool- und Reviewkosten abgeschlossenen Jobs zu.
- Geben Sie Support reproduzierbaren Kontext mit minimierten sensitiven Werten.
- Üben Sie Rollback und reduzierte Autorität vor einem Incident.
- Definieren Sie Stilllegung, Datenlöschung und Ersatzverantwortung.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für Checkliste produktionsreife AI-Produkte
- Der Release-Entscheid stützt sich auf einen messbaren Nutzerjob und explizit unzulässige Ergebnisse.
- Repräsentative Evaluation deckt normale, schwierige, fehlende, feindliche und veränderte Bedingungen ab.
- Identität, Daten, Tools und Freigaben werden ausserhalb von Modellinstruktionen erzwungen.
- Fehler führen zu verständlicher Verweigerung, Fallback, Wiederherstellung oder Eskalation statt stiller Korruption.
- Qualität, Latenz, Kosten, Sicherheit und Nutzerwirkung werden im kontrollierten Rollout sichtbar.
- Ein benanntes Betriebsteam besitzt Incidents, Modell- und Datenwechsel, Support und Stilllegung.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Produktionsvertrag definieren
Beschreiben Sie Zielnutzer, unterstützten Job, beabsichtigten Entscheid oder Aktion, Betriebsumfeld und ausgeschlossene Nutzung. Definieren Sie erfolgreichen Abschluss, akzeptable Streuung, kritischen Fehler und nötige menschliche Autorität. Der Vertrag verbindet Geschäftswert, Evaluation, Oberfläche und Release-Scope.
- 02
Verhalten mit repräsentativen Fällen belegen
Erstellen Sie versionierte Fälle aus echter Aufgabenvariation, inklusive unvollständigem Kontext, mehrdeutigen Weisungen, widersprüchlichen Quellen, feindlichem Inhalt und Downstream-Fehlern. Definieren Sie Sollresultat oder Rubrik vor dem Tuning. Messen Sie das End-to-End-System und schützen Sie einen Regressionstest.
- 03
Grenzen und Wiederherstellung entwickeln
Erzwingen Sie Identität, Berechtigung, Tenant-Scope, Datenklassifikation, Aufbewahrung und Tool-Rechte in deterministischem Anwendungscode. Validieren Sie strukturierte Outputs. Ergänzen Sie Timeouts, Ratenlimiten, Idempotenz, begrenzte Wiederholungen, Bestätigung wesentlicher Aktionen und einen sicheren Zustand bei Ausfall.
- 04
Produktionsbetrieb vorbereiten
Versionieren Sie Modelle, Prompts, Retrieval, Tools, Policies und Evaluation. Definieren Sie Events, Qualitätsstichproben, Kostenverteilung, Support-Triage, Incident-Schwere, Rollback und Providerwechsel. Geben Sie dem Betrieb genug Trace-Kontext für Diagnose, ohne sensitive Payloads unnötig offenzulegen.
- 05
Autorität schrittweise freigeben
Starten Sie mit begrenzten Nutzern, Daten und Aktionen. Vergleichen Sie Beobachtung mit dem Produktionsvertrag und analysieren Sie Fehler nach Schwere statt nur im Mittel. Erweitern Sie Scope erst mit Evidenz. Erhalten Sie einen manuellen oder deterministischen Pfad und eine Notfallmöglichkeit zur Reduktion der AI-Autorität.
Bewertung
Fragen, die den Entscheid verändern
- Welches Nutzerergebnis beweist Wert jenseits von Neuheit oder Output-Präferenz?
- Welche Fehlerklassen sind tolerierbar, wiederherstellbar, reviewbar oder release-blockierend?
- Welche Daten darf jeder Nutzer- und Modellpfad lesen, speichern, loggen und übertragen?
- Welche externen Aktionen brauchen Bestätigung und wie werden doppelte Effekte verhindert?
- Welche Modell-, Prompt-, Quellen-, Tool- oder Policy-Änderung verlangt Regressionstests?
- Wer darf das Feature pausieren, zurückrollen und einen Incident kommunizieren?
Fehlermuster
Wo Teams die Kontrolle verlieren
Optimierung auf kuratierte Demos kann Fehler bei alltäglichen unordentlichen Inputs verstecken.
Eine Berechtigung im System Prompt kann ignoriert oder manipuliert werden, wenn Code sie nicht erzwingt.
Automatische Wiederholung eines nicht idempotenten Tools kann Zahlungen, Nachrichten oder Records duplizieren.
Vollständiges Prompt-Logging kann einen zweiten unkontrollierten Speicher für sensitive Daten schaffen.
Provider- oder Modellupdates können Verhalten ohne Release des Anwendungscodes verändern.
Nutzer erweitern einen Assistenten auf nicht unterstützte Entscheide, wenn Grenzen unklar bleiben.
Die Durchschnittsqualität kann steigen, während seltene kritische Fehler häufiger werden.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- End-to-End-Aufgabenabschluss und akzeptiertes Ergebnis nach repräsentativer Fallklasse
- kritische Fehler, Verweigerung, Eskalation, menschliche Korrektur und Wiederherstellung
- p50- und p95-Latenz für vollständige Nutzerjobs unter erwarteter Parallelität
- variable Gesamtkosten je akzeptiertem Resultat inklusive Wiederholung und Review
- Berechtigungsverweigerungen, erkannte feindliche Inputs und blockierte unsichere Aktionen
- Produktionsdrift zwischen freigegebenen und aktuellen Evaluationsergebnissen
- Supportfälle und Incidents nach Modell-, Daten-, Integrations- und Produktursache
Fragen
Häufige Fragen
Wann ist ein AI-Prototyp produktionsreif?
Er ist bereit für einen begrenzten Release, wenn Zielnutzer das Ergebnis erreichen, kritisches Verhalten und Datengrenzen getestet sind, Fehler sicher recovern, Betrieb sichtbar ist und benannte Owner Support, Änderung und Stopp verantworten. Eine gute Demo genügt nicht.
Was gehört in eine Evaluation für produktive AI?
Sie testet den vollständigen Workflow mit normalen, schwierigen, fehlenden und feindlichen Fällen. Gemessen werden Jobresultat, Evidenz oder Tool-Richtigkeit, kritische Fehler, menschliche Korrektur, Latenz und Kosten. Erwartete Verweigerungen zählen als richtige Ergebnisse.
Sollen AI-Produktrechte durch Prompts gesteuert werden?
Nein. Prompts beschreiben Verhalten, aber Identität, Berechtigung, Ressourcenscope, Tool-Fähigkeit und Freigabe werden deterministisch im Anwendungscode erzwungen. Modelloutput und abgerufener Inhalt gelten an privilegierten Grenzen als nicht vertrauenswürdig.
Braucht Produktionsreife ein bestimmtes AI-Modell?
Nein. Sie braucht Evidenz, dass das gewählte Gesamtsystem den Produktionsvertrag erfüllt. Die Architektur sollte Modellabhängigkeiten versionieren und möglichst isolieren, damit Vergleiche, Halten, Ersatz und Rollback ohne Neubau des Prozesses möglich sind.
Quellen
Primärquellen
- NIST AI Risk Management Framework National Institute of Standards and Technology
- LLM05:2025 Unsichere Output-Verarbeitung OWASP Gen AI Security Project
- LLM06:2025 Übermässige Agency OWASP Gen AI Security Project
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Zeke
AI Product Engineering, das aus einem Software-Briefing ein zuverlässiges Produkt im Betrieb macht.
Produktverantwortliche, Gründungsteams und Software-Engineering-Teams. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.
Zeke ansehen→