Vom Notebook in die Produktion ohne „magisches“ MLOps

Teams kommen mit einem Notebook, das den Baseline auf einem Hold-out schlägt, und einer Folie „MLOps nächstes Quartal”. Die Lücke zwischen Notebook und vertrauenswürdigem System stoppt die meisten KI-Programme. Die Lösung ist keine MLOps-Einhorn-Plattform mit Logo-Folie — sondern eine minimale Evidence Chain von Rohdaten bis Score, im Besitz der Menschen, die montags um drei Uhr erreichbar sind, wenn das Modell sich falsch verhält.

Dasselbe Muster sehen wir in Nachfrageprognose, Defekterkennung und Credit Scoring: brillante Offline-Metrik, dann sechs Monate Plattform-Evaluation, während Produktion auf Cron und Pickle auf einem Share läuft. Schnell liefern diejenigen, die eng starten: eine Entscheidung, die das Business ohnehin manuell trifft, eine Metrik und ein Rollback. Alles andere folgt dem Beweis, nicht davor.

Minimale Produktionskette

Produktions-ML ruht auf fünf Gliedern. Erstens ein Datenvertrag: Schema, Freshness-SLA, PII-Regeln, Owner und Eskalation bei verzögerten Feeds. Zweitens ein versionierter Trainingssatz — unveränderliche Snapshot-ID in jeder Model Card und jedem Deployment-Record. Drittens eine reproduzierbare Trainingspipeline: Container, Seed, Git-SHA, Dependency-Lockfile. Viertens ein Model-Registry-Eintrag mit Metriken, Limits, Approver und Artefakt. Fünftens Serving mit Observability: Latenz, Fehler, Input-Verteilung, Feedback bei späten Labels. Fehlt ein Glied, zahlen Sie später — meist im Incident, wenn niemand weiß, welche Daten das heute aktive Modell trainiert haben.

Ein Logistikkunde schaffte diese Kette in elf Wochen: nächtliche Features in Parquet, Training im Schedule, Promotion nach Hold-out und Schema-Checks, API-Serving mit Drift-Dashboards. Kein Feature Store, kein Kubernetes fürs Training. Das Modell war langweilig; das Business vertraute, weil Operatoren forensische Grundfragen beantworten konnten.

Was bewusst warten kann

Feature Stores, Streaming und AutoML-Marktplätze warten, bis zwei oder mehr Modelle Features wirklich teilen oder Sub-Minuten-Latenz mit messbarem Batch-Kostenüberhang. Bis dahin ist ein strukturierter Batch mit nächtlichen Features und Promotion-Gates oft zuverlässiger — und leichter für Risk Committees, die fragen „was passiert, wenn das Modell falsch liegt?”

Wir raten zu einer Deferral List mit Triggern: „Feature Store, wenn Modell B über dreißig Prozent Features mit A teilt” oder „Streaming, wenn p95-Batch-Latenz Revenue blockiert”. Das verhindert Plattform-Tourismus — sechs Monate Vendor-Evaluation ohne Produktion.

Governance ohne Meeting-Flut

Model Cards brauchen keine vierzig Seiten. Eine Seite: Intended Use, Out-of-Scope, Trainingsdaten-Zusammenfassung, Fairness/Limits, Owner, Rollback. Promotion über automatische Checks — Schema, Performance-Floor, Bias-Schwellen — plus Human Sign-off für Produktions-Namespaces. Governance akzeptieren Engineers, wenn sie schlechte Deploys blockiert, statt Meetings über das, was CI hätte fangen können.

Governance bedeutet auch wer promote drücken darf. Trennung Trainer/Approver wie Change Control. Ein Credit-Team lernte das nach einem Fehl-Deploy im Deadline-Crunch — Rollback dauerte länger als der Fix, weil niemand sonst Kontext hatte.

Drift vor den Nutzern

Kovariate Shift auf Top-Inputs und verzögerte Labels überwachen. Alert bei Verteilungsänderung, auch wenn Accuracy stabil wirkt — stale Accuracy, wenn sich die Welt vor drei Wochen änderte, Labels aber nachziehen. Ein Händler vertraute einem Nachfragemodell durch Mix-Shift; Überbestände in Kategorien mit neuen Volumina.

Technische Drift-Signale mit Business-KPIs paaren: Retouren, Override-Rate, Margenimpact. Häufigeres manuelles Override ist oft schnelleres Drift-Signal als jeder Statistiktest. Overrides instrumentieren — kostenlose Labels über Modellvertrauen.

Szenario: Fraud Scoring vs Predictive Maintenance

Zwei Modelle, eine Firma, unterschiedliche Reifebedürfnisse. Fraud braucht niedrige Latenz, Explainability für Ermittler und sofortigen Rollback — die Kette umfasst Shadow Mode vor voller Promotion und Kill Switch per Feature Flag. Predictive Maintenance auf Batch-Telemetrie toleriert nächtliches Scoring, betont Datenvertrag mit OT und dokumentiert Safety-Implikationen bei verpassten Alerts.

Ein generisches „AI Platform”-RFP verzögerte beide. Fraud zuerst — höhere regulatorische Sichtbarkeit — baute Registry-, Monitoring- und Access-Control-Muscle, das Maintenance sechs Monate später erbte. Ein Plattformteam, zwei gestaffelte Lieferungen, null Magie.

Nächster Schritt

Wählen Sie ein Modell, das dieses Quartal eine echte Entscheidung beeinflusst. Schreiben Sie den Datenvertrag, snapshotten Sie letzten Monat, containerisieren Sie Training, registrieren Sie das Artefakt, fügen Sie drei Charts hinzu: Latenz, Fehler, Top-Feature-Verteilung. Kette unvollständig — RFP pausieren. Unsere Praxis Data-Science-Modelle liefert zuerst die minimale Kette — nicht wenn eine Vendor-Broschüre es sagt.