AI und ML im Enterprise — Wo anfangen und worauf achten

„Wir wollen AI.” Diesen Satz hören wir von Kunden immer häufiger. Das Problem ist, dass die meisten nicht genau wissen, was sie wollen, ihre Daten nicht bereit haben und Wunder erwarten. Nach zwei Jahren Aufbau von ML-Capability in unserem Unternehmen haben wir eine realistische Perspektive darauf, wo AI im Enterprise funktioniert — und wo nicht.

Wo anfangen — Use Cases, nicht Technologie¶

Beginnen Sie nicht mit der Auswahl eines Frameworks (TensorFlow vs. PyTorch). Beginnen Sie mit der Frage: Welches Geschäftsproblem löse ich? Unsere ersten erfolgreichen Use Cases:

• Churn-Vorhersage: Versicherungsunternehmen — welche Kunden werden abwandern? Gradient-Boosting-Modell, 82 % Genauigkeit. ROI: 15 % Churn-Reduktion = Millionen CZK jährlich.
• Anomalieerkennung: Bank — verdächtige Transaktionen. Isolation Forest, 40 % Reduktion der False Positives.
• Dokumentenklassifikation: Versicherungsunternehmen — automatische Sortierung eingehender Dokumente. NLP + Klassifikator, 91 % Genauigkeit.

Data Readiness — 80 % der Arbeit¶

Ein ML-Modell ist nur so gut wie seine Daten. Und Daten in einem typischen tschechischen Enterprise-Unternehmen sind… suboptimal. Duplikate, fehlende Werte, inkonsistente Formate, Datensilos. Bevor Sie mit dem Modellieren beginnen, brauchen Sie:

1. Daten-Audit — was Sie haben, wo es ist, wie die Qualität ist
2. Datenpipeline — ETL/ELT in ein analytisches Repository
3. Feature Engineering — Transformation von Rohdaten in Modell-Features
4. Governance — wer besitzt die Daten, GDPR-Compliance, Zugangskontrolle

Für die Churn-Vorhersage beim Versicherungsunternehmen haben wir 3 Monate mit Datenbereinigung und -aufbereitung verbracht, 2 Wochen mit dem Training des Modells. Das Verhältnis spiegelt die Realität wider.

MLOps — Ein Modell in Produktion ist erst der Anfang¶

Ein Modell in einem Jupyter Notebook zu trainieren, schafft jeder Data Analyst. Dieses Modell in die Produktion zu bringen und dort zu halten — das ist ein Engineering-Problem. Unser MLOps-Stack:

• MLflow für Experiment-Tracking und Model Registry
• Airflow für die Orchestrierung der Training-Pipeline
• Docker + Kubernetes für Serving (Flask API im Container)
• Prometheus + Grafana für Prediction-Monitoring

Model Drift ist ein reales Problem. Ein Churn-Modell, das auf Pre-COVID-Daten trainiert wurde, funktionierte nach COVID nicht mehr — das Kundenverhalten hatte sich geändert. Automatisches Retraining mit Accuracy-Monitoring ist eine Notwendigkeit.

Erwartungen vs. Realität¶

Das Management erwartet: „AI löst unser Problem in einem Monat.” Realität: Datenaufbereitung 3 Monate, PoC 1 Monat, Produktionalisierung 2 Monate, Iteration laufend. Insgesamt 6–9 Monate bis zum Mehrwert. Und nicht jeder Use Case lohnt sich.

Build vs. Buy¶

Für Standard-Use-Cases (OCR, Sentimentanalyse, Übersetzung) — Cloud-AI-Dienste (Azure Cognitive Services, AWS Comprehend). Günstiger und schneller als ein eigenes Modell. Für domänenspezifische Probleme (Churn bei einem tschechischen Versicherer) — eigenes Modell bauen, weil vortrainierte Modelle lokale Besonderheiten nicht verstehen.

AI ist ein Werkzeug, keine Magie¶

Beginnen Sie mit einem klaren Geschäftsproblem. Investieren Sie in Daten vor Modellen. Planen Sie MLOps von Anfang an. Und vor allem — haben Sie realistische Erwartungen. AI im Enterprise ist keine ChatGPT-Demo — es ist ein Engineering-Projekt wie jedes andere.