ML-Engineering in Deutschland: Warum viele KI-Projekte scheitern und wie man es besser macht

Die stille Krise im deutschen Machine Learning

In deutschen Tech-Unternehmen passiert etwas Paradoxes: Teams investieren Hunderttausende Euro in Machine-Learning-Projekte, trainieren aufwendig Modelle mit großen Datenmengen – und scheitern dann beim Deployment oder in den ersten Wochen der Produktion. Der Grund ist selten ein schwaches Modell, sondern mangelndes Engineering.

Ein bekanntes deutsches Fintech-Unternehmen musste 2023 sein Kreditrisiko-Modell nach drei Monaten in Produktion zurückziehen. Nicht weil die Accuracy schlecht war (93%), sondern weil niemand korrekt gemessen hatte, wie sich das Modell unter realen Bedingungen verhielt. Das kostete mehrere Millionen Euro und beschädigte die Reputation.

Das Problem liegt nicht an den Data Scientists – es liegt an der fehlenden Infrastruktur und den fehlenden Prozessen rundherum.

Was ML-Engineering von reiner Data Science unterscheidet

Data Science konzentriert sich auf Modelle: Welcher Algorithmus funktioniert? Wie optimiere ich die Accuracy? Das ist wichtig, aber nur die halbe Miete.

ML-Engineering fragt anders:

• Wie lädt das System täglich automatisch neue Daten?
• Was passiert, wenn die Eingabedaten sich plötzlich ändern?
• Wer bekommt eine Alert, wenn die Modell-Performance um 5% sinkt?
• Kann ein Junior-Developer das Modell reproduzieren, das vor 6 Monaten deployt wurde?

Diese Fragen klingen unsexy, aber sie bestimmen, ob ein Modell in Produktion überlebt oder nicht.

Die drei kritischen Fehler bei deutschen KI-Projekten

1. Keine dokumentierte Baseline und Monitoring-Strategie

Viele Teams starten das Monitoring erst, wenn das Modell live läuft. Das ist zu spät. Ein etabliertes Energieversorgungsunternehmen merkte erst nach zwei Monaten Produktion, dass sein Lastprognose-Modell systematisch bei Wochenenden falsch vorhersagte – weil im Training zu wenig Wochenendaten waren. Das hätte man vorab testen können.

Richtig gemacht:

• Baseline festlegen: Wie gut ist das alte System oder die einfache Heuristik? Das ist der Vergleichsmaßstab.
• Test-Sets definieren: Nicht nur Overall-Accuracy, sondern auch die Performance in kritischen Subgruppen (z.B. kleine Kundensegmente, seltene Events).
• Monitoring-Metriken vor dem Launch: Welche 3–5 Metriken werden täglich gemessen?

2. Keine Versionierung von Daten und Modellen

Ein Consultant bei einem DAX-Unternehmen fand 47 verschiedene Versionen eines Modells auf dem Sharepoint-Server: model_final.pkl, model_final_v2.pkl, model_final_WIRKLICH.pkl. Niemand wusste, welche Version in Produktion war.

Das führt zu:

• Irreproduzierbaren Ergebnissen
• Versteckten Abhängigkeiten (welche Python-Version? Welche Library-Versionen?)
• Unmöglichem Rollback, wenn etwas schiefgeht

Mindeststandards:

• Git für Code und Modell-Konfigurationen
• Zentrale Artifact Registry (MLflow, Hugging Face Model Hub, oder einfach ein strukturiertes S3-Bucket)
• Jedes Modell hat eine eindeutige ID und dokumentierte Trainings-Parameter

3. Data Drift wird ignoriert

Die Realität ändert sich. Kundenverhaltens-Modelle wirken anders, wenn eine Wirtschaftskrise kommt. Fraud-Detection-Systeme scheitern, wenn Kriminelle ihre Taktik ändern.

Ein deutsches Versicherungsunternehmen deployete 2022 ein Claims-Prognose-Modell. Es funktionierte perfekt auf den 2019–2021 Daten. Aber 2023, nach Inflation und verändertem Schadensverhalten, rutschte die Accuracy auf 78% ab – und die Geschäftsführung wusste monatelang nichts davon.

Konkrete Maßnahmen gegen Data Drift:

• Wöchentliche oder tägliche Metriken-Reports: Automated Monitoring ist nicht optional
• Retraining-Trigger: Wenn die Performance unter einen Schwellwert fällt, startet automatisch ein Retraining
• A/B-Tests für neue Modell-Versionen: Nicht sofort zu 100% deployen

Praktische Roadmap für solides ML-Engineering

Phase 1: Fundament (2–4 Wochen)

• Dokumentation: Trainings-Daten, Feature-Definitions, Modell-Architektur in einem Wiki oder GitBook
• Reproduzierbarkeit: requirements.txt, Docker-Container, Seed-Setzung für Randomness
• Code-Struktur: Nicht alles in einem 500-Zeilen-Notebook, sondern geteilte Funktionen und Tests

Phase 2: Monitoring und Testing (3–6 Wochen)

• Unit-Tests für Feature-Engineering (Die wichtigsten 3 Features werden getestet)
• Integration-Tests für die ganze Pipeline
• Dashboard für Modell-Performance (mit Evidently AI oder Grafana)
• Automatisierte Alerts bei Anomalien

Phase 3: Automation (4–8 Wochen)

• Feature Store oder ähnliches (Tecton, Feast, oder selbst gebaut)
• Automated Retraining Pipeline
• Canary Deployment: Neues Modell geht erst zu 5% der User

Tools, die in Deutschland funktionieren

Für deutsche Unternehmen mit Datenschutz-Anforderungen:

MLflow – Open Source, lokal deploybar, keine Cloud-Abhängigkeit. Perfekt für Teams, die ihre Infrastruktur behalten möchten. Kostenlos.

Weights & Biases – Cloud-native, aber mit DSGVO-konformem EU-Server in Frankfurt. Automatisiertes Experiment-Tracking. Ab ca. 30€/Monat für kleinere Teams.

Evidently AI – spezialisiert auf Data Drift Detection. Open Source oder gehostete Version. Sehr gutes German-language Community.

Grafana + Prometheus – Klassisches Monitoring, auch für ML-Metriken nutzbar. Keine Überraschungen.

Das wichtigste: Das Tool ist weniger entscheidend als die konsistente Nutzung einer Monitoring-Strategie. Ein billiges Tool mit disziplinierten Prozessen schlägt ein teures Tool, das niemand nutzt.

Der Return on Investment

Richtige ML-Engineering kostet Zeit. Eine typische Umstellung eines bestehenden Projekts braucht 4–6 Wochen für die Basics, 3–4 Monate für vollständiges Reengineering.

Aber der ROI ist konkret messbar:

• Weniger Bugs in Produktion: Gute Tests fangen 70–80% der Fehler vorher ab
• Schnellere Updates: Statt "Wir müssen das Modell neu trainieren und hoffen, dass es funktioniert" → strukturiertes Retraining in Minuten
• Weniger Feuerwehr-Einsätze: Monitoring erspart nächtliche Notfall-Calls
• Skalierbarkeit: Mit guten Prozessen kann ein Junior in den Code einsteigen, statt dass nur der ursprüngliche Developer alles weiß

Ein großes deutsches Logistik-Unternehmen sparte