Die Lücke zwischen POC und Produktion schließen

2019 hat eine globale Privatkundenbank, die wir anonym lassen, 47 KI-Piloten in Risk, Marketing und Operations aufgesetzt. Jeder einzelne „funktionierte": die Notebooks liefen, die Accuracy-Kennzahlen lagen über der Schwelle, die Demos begeisterten das Steering Committee. Achtzehn Monate später waren genau drei davon in Produktion. Die anderen 44 starben in dem, was die Retrospektive des Teams selbst „das Tal des Bewährten-aber-Unbrauchbaren" nannte. Die Modelle waren in Ordnung. Alles drumherum fehlte.

Das ist der prägende Fehlermodus von Enterprise-KI, und es ist kein Modellierungsproblem. Die oft zitierte Zahl von Gartner, dass rund die Hälfte aller KI-Projekte nie in Produktion kommt, untertreibt den Schmerz, denn sie zählt Überleben, nicht Wert. Die eigentliche Frage für einen CDO lautet nicht „Können wir ein Modell bauen, das churn vorhersagt?" Das können Sie längst. Sie lautet: „Warum liegt ein Modell, das churn mit 84 % AUC vorhersagt, neun Monate lang in der Umgebung eines Data Scientist, während churn weiter passiert?"

Die Lücke zwischen einem Proof-of-Concept und einem Produktivsystem ist keine Lücke an Intelligenz. Es ist eine Lücke an Industrialisierung. Ein POC optimiert auf *Beweis*; Produktion optimiert auf *Wiederholbarkeit unter Randbedingungen*. Das sind unterschiedliche Disziplinen mit unterschiedlichen Ownern, und die Aufgabe des CDO ist es, vier konkrete Lücken zu schließen, die eine Demo immer verdeckt.

Die vier Lücken, die eine Demo immer verdeckt

Ein POC ist ein kontrolliertes Experiment. Er nutzt einen eingefrorenen, von Hand bereinigten Datensatz, einen Data Scientist, der jede Spalte versteht, keine Latenzanforderung, keinen nachgelagerten Consumer und keinen Auditor. Produktion nimmt jeden dieser Luxusartikel weg. Kartieren Sie den Unterschied, und Sie haben Ihr Industrialisierungs-Backlog.

Lücke 1: Die Datenlücke (vom Snapshot zur Supply Chain)

Der POC lief auf einer CSV, die jemand gezogen und über drei Tage bereinigt hat. Produktion braucht dieselben Daten frisch geliefert, in Menge, nach Zeitplan, mit derselben Verteilung, auf der das Modell trainiert wurde, und zwar dauerhaft. Hier sterben die meisten Piloten leise.

Der konkrete Fehler ist training-serving skew: Das Modell wurde auf einem Feature trainiert (sagen wir customer_tenure_days), das in einem Batch-SQL-Job auf eine bestimmte Weise berechnet wurde, aber zur Inferenzzeit wird dieses Feature anders berechnet, oder aus einer anderen Quelle, oder es ist in Echtzeit schlicht nicht verfügbar. Das Modell ist nicht falsch; es bekommt eine andere Realität vorgesetzt als die, die es gelernt hat.

Ihr Montagmorgen-Test für jeden Piloten, der Produktionsreife behauptet: Können Sie für jedes Feature, das das Modell konsumiert, die Produktions-Pipeline benennen, die es erzeugt, ihre Refresh-Kadenz und ihr SLA? Wenn die Antwort auch nur für ein Feature „das klären wir noch" lautet, ist der Pilot nicht produktionsreif, egal wie hoch die Accuracy ist. Genau das löst ein feature store, nicht als Technologie-Fetisch, sondern als Vertrag, der garantiert, dass das im Training berechnete Feature identisch ist mit dem in Produktion ausgelieferten.

Lücke 2: Die Ownership-Lücke (vom Helden zum Operating Model)

Im POC gehört einer talentierten Person alles: Daten, Modell, Evaluation und die Demo. In Produktion kann keine einzelne Person ein System verantworten, das um 2 Uhr nachts an einem Feiertag laufen muss. Die häufigste organisatorische Ursache für steckengebliebene Piloten ist, dass der Pilot einen Builder hat, aber keinen Operator.

Stellen Sie diese brutale Frage in Ihrem nächsten Review: *Wenn dieses Modell in Produktion degradiert, nicht falls, wessen Pager geht los, und welches Runbook schlägt diese Person auf?* Wenn die Antwort der Data Scientist ist, der es gebaut hat, haben Sie eine Heldenabhängigkeit, kein Produkt. Helden skalieren nicht, machen Urlaub und kündigen irgendwann.

Lücke 3: Die Integrationslücke (vom insight zum Workflow)

Eine Vorhersage, die in einem dashboard landet, das niemand von Berufs wegen öffnen muss, ist kein Produkt; sie ist ein Fakt. Wert entsteht erst, wenn die Vorhersage eine Entscheidung innerhalb eines bestehenden Workflows verändert, im CRM-Screen, den der Rep ohnehin nutzt, in der Underwriting-Queue, in der Nachbestellung. Die Integration in ein lebendes System mit eigenem Release-Zyklus, Security-Review und Product Owner ist oft schwieriger als das Modell selbst.

Lücke 4: Die Vertrauenslücke (von Accuracy zu Accountability)

In der Demo wird Vertrauen durch die Begeisterung im Raum gewährt. In Produktion muss Vertrauen *kontinuierlich verdient* und gegenüber einem Regulator, einem Kunden oder einem Business Owner verteidigt werden, dessen Bonus vom Ergebnis abhängt. Das bedeutet Monitoring, Erklärbarkeit auf Ebene der einzelnen Entscheidung, eine dokumentierte Freigabekette und einen Kill Switch. Ein Modell, dem das Business nicht traut, wird nicht genutzt, und ein ungenutztes Modell in Produktion ist nur ein teurerer POC.

Vom Backlog zum Blueprint: der Production Contract

Vier Lücken zu schließen klingt nach vier Projekten. In der Praxis industrialisieren Sie, indem Sie sich weigern, einen Piloten ohne Production Contract starten zu lassen, ein schlankes Artefakt, das die sponsernde Business Unit und das Datenteam unterschreiben, *bevor* modelliert wird. Er übersetzt die vier Lücken in explizite Zusagen und tötet aussichtslose Piloten früh, was der ROI-stärkste Einzelschritt ist, den ein CDO machen kann. Einen schlechten Piloten in Woche zwei abzuschalten spart die sechs Monate, die er sonst zum Sterben im Tal brauchen würde.

Der Contract beantwortet auf einer Seite:

Entscheidung: Welche konkrete menschliche oder automatisierte Entscheidung verändert das? (Nicht „Marketing verbessern", sondern „die Outbound-Anrufliste für das Retention-Team jeden Morgen neu sortieren".)
Consumer: Welches bestehende System oder welche Rolle erhält den Output, und wem gehört die Roadmap dieses Systems?
Datenversorgung: Jedes Input-Feature, seine Produktionsquelle, Kadenz und SLA.
Operator: Welches Team betreibt es nach dem Launch und hält den Pager.
Vertrauensschwelle: Welches Monitoring, welche Erklärung und welche Freigabe sind für diese Risikostufe erforderlich?
Baseline & Kill-Kriterien: Wie hoch ist die aktuelle Nicht-KI-Performance, und ab welchem Punkt schalten wir das ab?

Beachten Sie die Rahmung: **Der Contract ist business-getrieben, aber dem CDO gehören *Template und Vetorecht*.** Ein Pilot, der die Zeilen „Consumer" und „Operator" nicht ausfüllen kann, ist nicht förderreif, egal wie begeistert Engineering ist.

Tiering nach Risiko, nicht nach Hype

Sie können nicht auf jeden Use Case dieselbe Strenge anwenden, ohne zum Stillstand zu kommen. Staffeln Sie Ihre Governance nach dem Blast Radius der Entscheidung:

Tier 1 (geringes Risiko, reversibel): interne Empfehlungen, Content-Ranking. Leichtes Monitoring, Self-Service-Deployment.
Tier 2 (umsatzrelevant, human-in-loop): churn scoring, das an einen menschlichen Rep geht. Erfordert Monitoring, Erklärbarkeit und einen namentlich benannten Operator.
Tier 3 (reguliert / automatisierte Entscheidungen): Kredit, Pricing, alles, was eine geschützte Gruppe betrifft. Vollständiger Audit Trail, Bias-Tests, Model-Risk-Freigabe, formaler Challenger-Prozess.

Der Hebel des CDO liegt darin, diese Tiers einmal zu setzen, damit nicht 200 Use Cases ihre Governance jeweils von null neu verhandeln. So skalieren Sie Urteilsvermögen.

Das MLOps-Rückgrat (und was es Ihnen tatsächlich bringt)

MLOps ist kein Tool, das Sie kaufen; es ist die Menge automatisierter Garantien, die es Ihnen erlauben, viele Modelle ohne viele Helden zu betreiben. Die Grundlagen zu pipelines und CI/CD kennen Sie aus dem Architekturmodul, hier geht es um das, was die Produktionslücke konkret schließt.

Die tragenden Fähigkeiten, nach Priorität:

Ein feature store, um training-serving skew zu eliminieren (Lücke 1).
Ein model registry, damit jedes deployte Modell versioniert, auf die Daten und den Code zurückführbar und rollback-fähig ist (Lücken 2 und 4).
Automatisiertes Monitoring für operative Gesundheit (Latenz, Fehler) *und* statistische Gesundheit, data drift und Performance-Verfall des Modells (Lücke 4).

Drift-Monitoring ist das, was die meisten Teams auslassen und am meisten bereuen. Ein Modell fällt nicht mit einer Fehlermeldung aus; es scheitert stillschweigend, während die Welt von seinen Trainingsdaten wegdriftet. Ihre Monitoring-Konfiguration sollte eine Verteilungsverschiebung als erstklassigen Alert behandeln, nicht als Quartalsanalyse:

yaml

monitor:
  model: churn_scorer_v3
  drift_detection:
    feature: customer_tenure_days
    method: population_stability_index
    threshold: 0.25          # PSI > 0.25 = signifikante Verschiebung
    window: 7d
  performance:
    metric: auc
    baseline: 0.84
    alert_below: 0.78        # löst Retrain-Review aus
  action_on_breach: page_operator + open_retrain_ticket

Der Punkt an diesem Snippet ist nicht das YAML, sondern die Disziplin, die es kodiert: eine definierte Baseline, eine definierte Überschreitungsschwelle und eine definierte menschliche Handlung. Ein Modell in Produktion ohne diese drei Dinge ist unüberwacht, was heißt: ungetrustet, was heißt: Es wird abgeschaltet, sobald es das erste Mal jemanden blamiert.

MLOps Explained: From Model to Production

Watch on YouTube

Bauen Sie die befestigte Straße einmal

Der strategische Fehler ist, jedes Produktions-Deployment als individuelles Engineering-Projekt zu behandeln. Das Gewinnmuster, das jedes Unternehmen nutzt, das KI über eine Handvoll Modelle hinaus skaliert hat, ist die paved road: ein standardisierter, meinungsstarker Weg vom registrierten Modell zum deployten, überwachten Service, den ein Data Scientist gehen kann, *ohne* ein Ticket beim Plattformteam aufzumachen.

Wenn das Deployment von Modell Nummer 12 genauso maßgeschneidert ist wie Modell Nummer 1, haben Sie keine Plattform; Sie haben eine Serie von Heldentaten. Der Investment Case des CDO für eine MLOps-Plattform ist genau das: Sie senkt die Grenzkosten des *nächsten* Produktionsmodells von Monaten auf Tage. Das ist die Zahl für den CFO, nicht „KI-Reifegrad", sondern Deployment-Geschwindigkeit und die Operator-Stellen, die Sie *nicht* besetzen müssen.

Wissenscheck

1. Was ist laut der Lektion die grundlegende Natur der Lücke zwischen POC und Produktion in der Enterprise-KI?

2. Die Lektion merkt an, dass Gartners Zahl zu KI-Projekten, die es nicht in Produktion schaffen, „den Schmerz untertreibt". Warum?

3. Ein Pilotteam behauptet, sein churn-Modell sei „produktionsreif". Was sollte ein CDO nach dem Montagmorgen-Test der Lektion zuerst prüfen?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die „training-serving skew" so beschreiben, wie es die Lektion darstellt.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE „Luxusartikel", die ein POC laut Lektion genießt und die Produktion wegnimmt.

Wählen Sie alle richtigen Antworten aus.

Die Industrialisierung sequenzieren

Die vier Lücken und das Rückgrat zu kennen, ist kein Plan. An der Sequenzierung scheitern CDOs, sie bauen entweder eine vergoldete Plattform, bevor es einen einzigen Produktions-Use-Case gibt (die „Field of Dreams"-Falle), oder sie liefern ein Dutzend maßgeschneiderter Piloten und ersaufen in operativen Schulden.

Die richtige Reihenfolge ist bewusst unglamourös:

Erstens: Bringen Sie einen Tier-2-Use-Case end-to-end in Produktion, ruhig schlecht. Wählen Sie einen Use Case mit einem echten, willigen Business Owner und schieben Sie ihn bis in die Produktion, mit so viel Gaffer Tape wie nötig. Das Ziel ist nicht das Modell; es ist, jede Lücke in *Ihrer konkreten Organisation* sichtbar zu machen, welche Teams blockieren, welche Datenquellen lügen, welcher Security-Review elf Wochen dauert. Sie kartieren das Gelände, Sie gewinnen nicht den Krieg.

Zweitens: Befestigen Sie die Straße, die Sie gerade gegangen sind. Bauen Sie jetzt Plattformfähigkeit gegen die Reibung, die Sie tatsächlich erlebt haben, nicht gegen die, die Sie sich vorgestellt hatten. War der Security-Review der Engpass, standardisieren Sie ein vorab freigegebenes Deployment-Muster. Waren die Features das Problem, stellen Sie den feature store auf. Das hält Plattforminvestitionen kompromisslos an beobachtetem Schmerz fest.

Drittens: Industrialisieren Sie das Operating Model. Hier investieren CDOs zu wenig. Bauen Sie die Operator-Funktion auf, ob Sie sie ML Platform Engineering, MLOps oder produktorientierten Pod nennen, und machen Sie den Production Contract zur Förderbedingung. Das Organisationsdesign ist hier das Deliverable: Der Pilot hat einen Builder, aber Produktion braucht einen Builder *und* einen Operator, und jemand muss die Grenze dazwischen verantworten.

Das Antipattern, das explizit benannt gehört: das Innovation Lab ins Nirgendwo. Ein glänzendes KI-Lab, das Piloten fährt, aber keinen Vertrag mit und keine Verpflichtung gegenüber dem operativen Geschäft hat, wird unbegrenzt Demos erzeugen und niemals produktiven Wert. Wenn die Erfolgskennzahl Ihres Labs „gestartete Piloten" ist statt „in Produktion veränderte Entscheidungen", finanzieren Sie das Tal des Bewährten-aber-Unbrauchbaren. Ändern Sie die Kennzahl am Montag.

Noch eine Ermessensentscheidung: Stilllegen, und zwar konsequent. Ein Produktionsmodell hat auf Dauer Wartungskosten. Wenn ein deploytes Modell seine Kill-Kriterien nicht erfüllt oder von seinem Business Owner stillschweigend umgangen wird, schalten Sie es ab. Ein Portfolio aus 40 Produktionsmodellen, von denen 15 unüberwacht und ungenutzt sind, ist kein Reifezeichen; es ist eine Verbindlichkeit mit Monitoring-Rechnung.

Die wichtigsten Erkenntnisse

Behandeln Sie die Lücke zwischen POC und Produktion als vier konkrete Lücken, Datenversorgung, Ownership, Integration und Vertrauen, nicht als Modellierungsproblem. Eine Demo verdeckt alle vier by design; Ihr Review-Prozess muss jede einzelne explizit sichtbar machen.

Führen Sie einen einseitigen Production Contract ein, den jeder Pilot vor der Finanzierung unterschreibt. Wenn er die veränderte Entscheidung, das Consumer-System, die Feature-Quellen mit SLAs und den Operator mit dem Pager nicht benennen kann, wird er nicht gebaut. Aussichtslose Piloten früh abzuschalten ist Ihr ROI-stärkster Schritt.

Staffeln Sie Governance nach dem Blast Radius der Entscheidung, nicht nach Hype, damit Use Cases mit geringem Risiko schnell laufen und regulierte Entscheidungen volle Audit- und Bias-Kontrollen bekommen, ohne dass jedes Team Governance von null neu verhandelt.

Begründen Sie die MLOps-Plattform in der Sprache von Deployment-Geschwindigkeit und vermiedenen Operator-Stellen, nicht mit „Reifegrad". Die paved road existiert, damit Modell Nummer 12 Tage statt Monate braucht und um Heldenabhängigkeit zu beseitigen.

Sequenzieren Sie bewusst: einen Use Case end-to-end liefern, um Ihre echte Reibung zu kartieren, dann genau diese Straße befestigen, dann das Operating Model verbindlich machen und ungenutzte Modelle konsequent stilllegen, bevor sie zur stillen Verbindlichkeit werden.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

Jeden Pilot verpflichten, einen einseitigen Production Contract zu unterschreiben

Vollständiges Action Playbook ansehen →