MLOps im deutschen Mittelstand: Warum 80% der Projekte im POC stecken — und was die anderen 20% anders machen

Ein CTO aus der Automobilzulieferer-Branche schreibt uns im März. Neun Monate ML-Projekt, vier Data Scientists fest im Team, zwei weitere extern. Modelle: viele. In Produktion: null. Budget aufgebraucht: 380.000 Euro. Die Frage in seiner Mail ist nicht „wie machen wir das fertig", sondern „wie erklären wir das dem Vorstand".

Das ist nicht der Ausnahmefall. In unseren Erstgesprächen bei NeuralMedic sehen wir das in etwa 4 von 5 Fällen — Mittelständler, die ML-Initiativen gestartet haben, oft mit Top-Talent und solidem Budget, und die irgendwo zwischen POC und Produktion festhängen. Dieser Artikel beschreibt die drei strukturellen Gründe, warum das passiert, und die fünf Dinge, die die anderen 20% systematisch anders machen.

Warum MLOps im Mittelstand anders aussieht als bei Big Tech

Die meiste MLOps-Literatur kommt aus Umgebungen, die mit der Realität eines deutschen 800-Mitarbeiter-Unternehmens wenig zu tun haben. Wenn Netflix über Modell-Deployment schreibt, reden wir über ein Team von 40 Plattform-Engineers, die nichts anderes machen. Wenn ein mittelständischer Maschinenbauer in Bayern eine Predictive-Maintenance-Pipeline produktiv setzen will, hat er zwei Data Scientists, einen halben DevOps und keine dedizierte ML-Plattform.

Der Unterschied ist nicht graduell, sondern strukturell. Big Tech löst MLOps mit dedizierten Teams und gewachsener Plattform-Infrastruktur. MLOps Mittelstand bedeutet: produktionsreife Pipelines mit minimalem Personal, ohne eigene Plattform-Abteilung, mit DSGVO als Default und mit IT-Abteilungen, die historisch SAP und Active Directory betreuen, nicht Kubernetes-Cluster.

Daraus folgen drei Konsequenzen, die viele Beratungen ignorieren. Erstens: jede zusätzliche Komponente im Stack ist Betriebslast. Zweitens: jede Abhängigkeit von US-Hyperscalern ist eine Compliance-Diskussion mit dem Datenschutzbeauftragten. Drittens: das Team, das die Pipeline baut, ist meist auch das Team, das sie nachts betreut. Wer das nicht in seine Architektur einrechnet, baut für ein Unternehmen, das es nicht gibt.

Die drei strukturellen Gründe, warum MLOps-Projekte im POC stecken bleiben

Wir haben in den letzten 18 Monaten 14 MLOps-Audits bei mittelständischen Unternehmen durchgeführt. Die Symptome sind unterschiedlich, die Ursachen erstaunlich konsistent.

Grund 1: Keine klare Ownership der Übergabe Data Science → Plattform

In der Theorie übergibt das Data-Science-Team ein trainiertes Modell an die Plattform-/DevOps-Seite, die es deployt. In der Praxis gibt es bei den meisten Mittelständlern weder ein klares Plattform-Team noch einen definierten Übergabepunkt. Das Modell läuft im Jupyter-Notebook von Dr. Schneider, die Daten kommen aus drei verschiedenen Quellen (eine davon ein Excel-Sheet), und niemand ist offiziell zuständig, daraus ein deploybares Artefakt zu machen.

Was wir konkret sehen: in 11 von 14 Projekten gab es keine in einem Confluence- oder Notion-Doc dokumentierte Antwort auf die Frage „wer ist verantwortlich, dass dieses Modell nächstes Quartal Requests beantwortet". Wenn diese Rolle nicht in Sprint 0 definiert ist, wird sie nie definiert. Das Modell bleibt im Notebook.

Grund 2: Security-Review kommt zu spät (Sprint 12 statt Sprint 1)

Ein typisches Muster: Data Science baut sechs Monate lang Modelle, dann kommt die Frage „wie bringen wir das in Produktion", dann fällt jemandem auf, dass der CISO und der Datenschutzbeauftragte das auch noch absegnen müssen. Antwort der Security: „Bitte alle Trainingsdaten dokumentieren, Pseudonymisierung nachweisen, Auftragsverarbeitungsverträge prüfen." Vier weitere Monate vergehen. Das Modell ist inzwischen veraltet.

Wir haben das in einem Healthcare-Projekt 2024 gesehen, wo der erste Architektur-Review mit der Konzern-Security in Sprint 14 stattfand. Ergebnis: kompletter Re-Architektur-Zyklus, weil die ursprüngliche Lösung Patientendaten in einer US-Region verarbeitet hätte. Sechs Monate Arbeit für die Tonne. In MLOps Beratung Deutschland ist Security kein Audit am Ende, sondern eine Architektur-Constraint von Sprint 1.

Grund 3: Senior Data Scientists sind keine MLOps Engineers

Das ist die unbequeme Wahrheit. Ein Data Scientist mit zehn Jahren Erfahrung in Modellierung kann hervorragende Features bauen und solide Cross-Validation machen. Er hat in der Regel keine Erfahrung mit Container-Orchestrierung, mit CI/CD-Pipelines für Modelle, mit Inferenz-Latenz-Tuning oder mit Observability-Stacks. Das ist kein Vorwurf — es ist ein anderes Berufsbild.

Die meisten gescheiterten MLOps-Projekte, die wir sehen, haben eines gemeinsam: das Data-Science-Team sollte auch die Produktion verantworten, weil „die kennen den Code am besten". Sie kennen den Code. Aber sie kennen nicht den Stack drumherum. Wer ein Modell in Produktion bringen will, braucht mindestens einen Engineer im Team, der schon mal einen Production-Outage um 3 Uhr morgens debugt hat.

Was Mittelstand-Teams brauchen — und was sie nicht brauchen

Mehr Tools sind selten die Antwort. Wir sehen regelmäßig Stacks mit acht ML-Plattform-Produkten gleichzeitig: MLflow, Kubeflow, Airflow, Seldon, Weights & Biases, DataRobot, ein selbstgebautes Feature-Store-Layer und SageMaker. Niemand im Haus versteht den Gesamtstack. Wenn der Senior Engineer kündigt, ist die Pipeline ein Mysterium.

Was Mittelstand-Teams stattdessen brauchen, ist ein begrenzter, wartbarer Stack. Unsere Default-Empfehlung für Greenfield-Projekte umfasst sechs Komponenten: dbt für Datentransformationen, Dagster oder Airflow für Orchestrierung, MLflow für Experiment-Tracking und Model Registry, ein Serving-Layer (Triton, BentoML oder ein managed Endpoint), Prometheus plus Grafana für Observability, und Git plus eine CI/CD-Lösung wie GitLab CI. Das reicht für 80% der Use Cases im Mittelstand.

Bei der Orchestrierung: Airflow ist der etablierte Standard, mit großem Ökosystem und vielen Engineers am Markt, die es kennen. Der Trade-off: die Abstraktionen sind alt, das Konzept „DAG als Python-Datei" passt schlecht zu modernen Software-Engineering-Praktiken. Dagster ist jünger, hat bessere Typisierung und ein besseres Asset-Modell, aber die Community ist kleiner. Für ein Team, das gerade anfängt und keine bestehende Airflow-Investition hat, würden wir 2026 Dagster wählen. Für ein Team mit existierender Airflow-Codebasis und Engineering-Kapazität: bleibt bei Airflow.

Bei Serving: NVIDIA Triton ist die richtige Wahl, wenn ihr On-Prem-GPUs habt und Latenz unter 50ms braucht. Amazon SageMaker oder Google Vertex AI sind richtig, wenn ihr in der Cloud lauft und die Total-Cost-of-Ownership inklusive Personal rechnet. Wir haben 2024 ein Projekt gesehen, wo ein Mittelständler 47.000 Euro pro Monat für SageMaker zahlte, weil niemand die Endpoint-Konfiguration optimiert hatte. Nach drei Wochen Optimierung: 11.000 Euro pro Monat, gleicher Durchsatz. Das ist der Punkt, an dem MLOps Mittelstand-Erfahrung sich amortisiert.

Was sie nicht brauchen: einen eigenen Feature Store ab Tag 1, Multi-Cloud-Deployment, A/B-Test-Infrastruktur für drei Modelle pro Jahr, oder eine eigene LLM-Inferenz-Infrastruktur, wenn der Use Case mit einem Azure OpenAI Endpoint und vernünftigem Caching gelöst ist.

5 Praxis-Lektionen aus produktiven MLOps-Implementierungen

Aus den Projekten, die es bei uns oder bei Kunden in Produktion geschafft haben, kondensieren sich fünf wiederkehrende Lektionen.

1. Production-Handoff-Owner in Sprint 0 definieren.

Bevor die erste Zeile Code geschrieben wird, muss namentlich feststehen, wer dafür verantwortlich ist, dass das Modell am Ende Requests beantwortet. Nicht „das Team", nicht „die Plattform". Eine Person. Diese Person sitzt in den ersten Architektur-Meetings, auch wenn noch nichts deploybar ist. In unseren erfolgreichen Projekten war das in jedem Fall ein Senior Engineer mit Production-Erfahrung, nicht der lead Data Scientist.

2. Compliance-Review parallel zur Architektur, nicht danach.

Der CISO und der Datenschutzbeauftragte gehören in Sprint 1, nicht in Sprint 12. Konkret: ein 90-Minuten-Architektur-Review in Woche 2 mit beiden Funktionen am Tisch. Output: ein dokumentiertes Constraint-Set für Datenflüsse, Speicherorte, Logging-Anforderungen. Wenn diese Constraints später kommen, kostet jede Änderung das Zehnfache.

3. Model Registry und Experiment Tracking ab Tag 1.

MLflow oder ein vergleichbares Tool gehört in den Stack, bevor das erste Modell trainiert wird. Nicht „wir fügen das später hinzu". Später bedeutet, dass die ersten 60 Trainingsläufe nicht reproduzierbar sind. Wir haben Teams gesehen, die nach acht Monaten nicht mehr wussten, mit welchen Hyperparametern ihr bestes Modell trainiert wurde. Das ist keine Disziplinfrage, das ist Tooling-Versagen.

4. Inferenz-Audit-Logs als Default, nicht als Add-on.

Jeder Inferenz-Request wird mit Timestamp, Input-Hash, Output, Modell-Version und User/System-Identifier geloggt. Das ist nicht „nice to have", das ist die Grundlage für Debugging, für Compliance-Nachweise und für Model-Drift-Detection. Die Speicherkosten sind vernachlässigbar (S3-Glacier oder vergleichbares Cold-Storage), die Kosten des nachträglichen Einbaus sind enorm.

5. Senior Engineer mit Plattform-Erfahrung im Team.

Nicht im Lenkungskreis. Nicht als Berater auf Abruf. Im Team, mit Code-Commit-Rechten, in den Stand-ups. Bei einem Drei-Personen-ML-Team ist das eine der drei Personen. Wenn ihr keinen findet oder leisten könnt, ist Embed (siehe unten) die ehrliche Option. Aber kein Senior Plattform-Engineer im Team bedeutet: ihr werdet im POC stecken bleiben.

DSGVO im MLOps-Stack: was wirklich kritisch ist

Die meisten DSGVO-Diskussionen im MLOps-Kontext sind entweder oberflächlich („wir nutzen ja AWS Frankfurt") oder paranoid („wir können kein Cloud-ML machen"). Beides ist falsch.

Was wirklich zählt, sind fünf Punkte. Erstens: Data Residency in EU-Regionen, nachweisbar konfiguriert auf Storage-, Compute- und Logging-Ebene. Das ist keine triviale Checkbox — viele managed Services replizieren Logs oder Metriken außerhalb der gewählten Region, wenn man das nicht explizit verhindert. AWS, Azure und GCP haben dazu jeweils mehrseitige Dokumente, die man lesen muss.

Zweitens: Pseudonymisierung VOR dem Training, nicht danach. Personenbezogene Daten dürfen ein Modell-Trainings-Cluster nur in pseudonymisierter Form erreichen. Der Pseudonymisierungsschlüssel wird in einem separaten System gehalten (ein dedizierter Key-Vault, idealerweise mit anderem Berechtigungsmodell als der Trainings-Cluster). Wer den Schlüssel und die pseudonymisierten Daten im selben System hat, hat de facto nicht pseudonymisiert. Dazu gibt es klare Vorgaben in Art. 25 DSGVO zu Privacy by Design und Privacy by Default (EUR-Lex Art. 25 DSGVO).

Drittens: Audit-Trails auf Inferenz-Ebene. Wer hat wann welche Anfrage gestellt, welches Modell hat geantwortet, welche Datenklassen waren involviert. Das ist kein DSGVO-Spezifikum — das brauchst du auch für ISO 27001, für IT-Forensik und für jeden ernsthaften Incident-Response-Prozess.

Viertens: Auftragsverarbeitungsvertrag mit dem Cloud-Provider und allen Sub-Auftragsverarbeitern, inklusive Standardvertragsklauseln. Das macht in der Regel die Rechtsabteilung — euer Job ist, sicherzustellen, dass die technischen Maßnahmen im Vertrag der tatsächlichen Architektur entsprechen. Wir haben mehr als einmal gesehen, dass im AV-Vertrag Maßnahmen stehen, die die Pipeline nicht implementiert.

Fünftens: Cloud-Security-Baseline. Das BSI hat dazu praxisnahe Vorgaben veröffentlicht — der BSI C5-Katalog ist der De-facto-Standard für Cloud-Sicherheit in Deutschland und für viele regulierte Branchen Pflicht.

Für Healthcare-spezifische Aspekte (MDR, IEC 62304, Risk-Class-Klassifikation) haben wir einen separaten Leitfaden geschrieben: Medical AI: DSGVO und MDR in der Architektur. Wer im regulierten Umfeld arbeitet, sollte beide Artikel lesen.

Build vs. Buy vs. Embed: drei Lieferansätze ehrlich verglichen

Wenn ein Mittelständler heute ein MLOps-Vorhaben startet, hat er drei strukturelle Optionen. Wir verkaufen alle drei nicht mit gleicher Begeisterung, aber wir nennen sie ehrlich.

Build bedeutet: internes Team baut alles selbst. Stärken: maximale Kontrolle, Wissen bleibt im Haus, langfristig günstig. Schwächen: dauert lange (12–18 Monate bis Produktion ist normal), erfordert Senior-Personal, das am Markt teuer und rar ist, und das Team muss Fehler machen, die andere schon gemacht haben. Sinnvoll, wenn ihr ein bestehendes Plattform-Team mit Headcount-Spielraum habt und ML strategisch zentral ist.

Buy bedeutet: managed Plattform wie Databricks, DataRobot, Dataiku, Vertex AI Pipelines. Stärken: schnell live (3–6 Monate), wenig internes Senior-Personal nötig, klare Vertragsbasis. Schwächen: Lock-in, oft signifikante laufende Kosten (sechsstellig pro Jahr ist normal), und das Tool diktiert die Architektur. Wir sehen das oft als Default-Empfehlung, aber es passt nicht zu jedem Use Case. Wenn ihr drei Modelle und einen Use Case habt, ist Databricks Overkill. Wenn ihr 40 Modelle und zwölf Use Cases plant, ist es vernünftig.

Embed bedeutet: ein externer Senior Engineer arbeitet 6–12 Monate im internen Team mit, baut die Plattform, dokumentiert sie, übergibt sie. Stärken: schneller als Build, weniger Lock-in als Buy, Wissenstransfer ist explizites Projektziel. Schwächen: Qualität hängt stark an der einen Person, gute Embeds sind selten, und ihr braucht ein internes Team, das aufnahmefähig ist. Das ist der Modus, in dem wir bei NeuralMedic die meisten Projekte machen — nicht weil es immer richtig ist, sondern weil es für regulierten Mittelstand mit kleinem Team meist die beste Ratio aus Geschwindigkeit, Kontrolle und Total-Cost ist.

Welcher Ansatz richtig ist, hängt von drei Variablen ab: wie viele Use Cases ihr in den nächsten 24 Monaten plant, wie viel Senior-Personal ihr intern habt und halten könnt, und wie regulatorisch sensibel eure Daten sind. Wer ehrlich auf diese drei Fragen antwortet, kommt meist zu einer klaren Empfehlung.

Wann ihr externe Unterstützung holen solltet — und wann nicht

Externe MLOps Beratung Deutschland ist kein Selbstzweck. Wir sagen Kunden regelmäßig ab, weil ihr Bedarf besser intern gelöst wird.

Externe Unterstützung ist sinnvoll in drei Konstellationen. Wenn ihr kein vollständig internes Team habt — speziell wenn der Senior Plattform-Engineer fehlt, der das Ganze zusammenhält. Wenn ihr eine harte Compliance-Deadline habt (Audit in sechs Monaten, MDR-Submission im Q3), bei der ein Lernkurven-Fehler das ganze Projekt killt. Und wenn es euer erstes ernstes ML-Projekt ist — die ersten zwei Pipelines macht jeder falsch, das muss nicht euer Lehrgeld sein.

Externe Unterstützung ist nicht sinnvoll, wenn ihr ein starkes Plattform-Team habt, das ML als nächste Disziplin dazunimmt. Wenn euer Datenvolumen klein ist (unter 100 GB pro Use Case) und die Inferenz-Last niedrig — dann reicht oft ein Skript plus Cron. Wenn das Projekt explizit exploratorisch ist und es noch gar nicht klar ist, ob ihr in Produktion gehen wollt — investiert nicht in Plattform, bevor der Use Case validiert ist.

Die ehrlichste Frage ist: wenn der externe Partner morgen weg wäre, kann das interne Team weitermachen? Wenn nein, war das Engagement falsch aufgesetzt. Bei NeuralMedic ist das übrigens das primäre Erfolgskriterium für unsere Embed-Engagements — wir messen, wie viele Pull Requests am Ende des Projekts vom internen Team kommen, nicht von uns.

FAQ

Was kostet ein MLOps-Setup im Mittelstand realistisch?

Für eine produktive Pipeline mit einem Use Case (Daten-Ingestion, Training, Serving, Monitoring) sehen wir typische Gesamtkosten von 180.000 bis 350.000 Euro im ersten Jahr, inklusive Personal, Tooling und Cloud-Infrastruktur. Laufende Kosten danach liegen bei 4.000 bis 15.000 Euro pro Monat, abhängig von Inferenz-Volumen und Cloud-Provider. Wer deutlich darunter angeboten bekommt, sollte fragen, was nicht enthalten ist.

Wie lange dauert es von POC zu Produktion?

Mit erfahrenem Team und ohne Compliance-Überraschungen: 4–6 Monate. Realistisch im Mittelstand, beim ersten Projekt, mit normalem Compliance-Prozess: 8–12 Monate. Wenn euch jemand 8 Wochen verspricht, redet er entweder von einem Demo-Endpoint oder er übersieht das halbe Backlog.

Brauchen wir Kubernetes für MLOps?

Nein, nicht zwingend. Wenn ihr 1–3 Modelle in Produktion habt und kein internes Kubernetes-Know-how, sind Managed Serving Endpoints (SageMaker, Vertex AI, Azure ML) die ehrlichere Wahl. Kubernetes lohnt sich ab etwa 10 parallel betriebenen Services, oder wenn ihr ohnehin schon einen Cluster für andere Workloads betreibt.

Wie verhält sich der EU AI Act zu MLOps?

Für Hochrisiko-Systeme (Healthcare, Kreditvergabe, HR-Screening) müsst ihr ab 2026 Anforderungen an Risk-Management, Daten-Governance, technische Dokumentation und Post-Market-Monitoring erfüllen. Praktisch heißt das: dokumentierte Trainingsdaten-Herkunft, Modell-Karten, Audit-Logs und ein Prozess für Incident-Meldungen. Vieles davon ist saubere MLOps-Praxis ohnehin — der AI Act formalisiert es.

Können wir Open Source statt managed Plattform nutzen?

Ja, technisch. Die Frage ist, was der Betrieb intern kostet. Ein selbst betriebener MLflow plus Airflow plus Triton Stack braucht etwa 0,5 bis 1 FTE pro Jahr für Wartung, Updates, Security-Patches. Wenn ihr diese Kapazität habt, ist Open Source günstiger. Wenn nicht, zahlt ihr den Aufwand woanders — meist in Form ungepatcher Systeme und Ausfällen.

Was, wenn unsere Data Scientists kein Git nutzen?

Ehrliche Antwort: das ist das erste Problem, das gelöst werden muss, bevor MLOps Sinn ergibt. Code, Konfigurationen und Daten-Definitionen in Git, mit Pull Requests und Code Review, sind die Grundvoraussetzung. Wer da nicht ist, sollte zwei Monate in diesen Schritt investieren, bevor das nächste Tool dazukommt.

Nächster Schritt: Wenn ihr in einer der drei strukturellen Fallen steckt, machen wir kostenlose 30-Min Architektur-Reviews. Kein Sales-Deck, kein Vertragsdruck — wir gehen ehrlich durch, wo eure Pipeline gerade steht und was als nächstes sinnvoll ist. → Termin buchen

Jonas Heinzmann ist Gründer und Geschäftsführer der NeuralMedic GmbH in Ingolstadt. Das Unternehmen entwickelt produktionsreife Daten- und KI-Plattformen für den deutschen Mittelstand — mit besonderer Erfahrung in regulierten Industrien wie Healthcare. → Profil ansehen