KI kennt dein Business nicht: Warum so viele KI-Projekte den ROI verfehlen – und wie eine souveräne Datenstrategie das ändert

Fangen wir mit der ungemütlichen Wahrheit an: KI, so beeindruckend sie wirkt, kennt weder Ihre Maschinen, noch Ihre Kunden, noch Ihre regulatorische Realität. Sie kennt nur Datenverteilungen. Sobald diese nicht exakt dem entsprechen, was Ihr Betrieb täglich lebt, bricht der ROI von KI-Projekten ein. Nicht, weil die Modelle „zu schwach“ sind, sondern weil das Problem falsch geschnitten, die Datenökonomie nicht durchdacht und die Systemintegration unterschätzt wurde.

Wir sehen das in Industrieprojekten seit Jahren – quer durch Verteidigung, Bahn, Fertigung, Bau, Textil und Luftfahrt. Was erfolgreich ist, unterscheidet sich nicht an der Technologieauswahl, sondern daran, wie präzise das Geschäftsproblem in ein technisch beherrschbares System übersetzt wurde. Problem-first, nicht Technology-first.

Teil 1: Warum so viele KI-Projekte den ROI verfehlen

Aus technischer Sicht gibt es fünf wiederkehrende Gründe.

1) Falsche Zielfunktion – das Modell optimiert das Falsche

  • Symptom: Ein Anomalie-Detektor erreicht 98% „Accuracy“ – doch die Instandhalter ziehen nach zwei Wochen den Stecker, weil die False Positives den Bereitschaftsdienst verstopfen.

  • Ursache: Die Kosten von Fehlalarmen und Ausfällen sind asymmetrisch. Wer das nicht in die Loss-Funktion, in die Datensamples (cost-sensitive sampling) und in die Metriken (Precision@Top-K, Expected Cost) einpreist, optimiert an der Realität vorbei.

  • Abhilfe: Business-Kostenmodell vor dem ersten Notebook-Cell. Explizite Fehlermatrix, die in Training und Inferenz operationalisiert ist (z. B. threshold adaptation pro Asset-Klasse, not single global threshold).

2) Prozess-Integration wird ignoriert – das Modell hat keinen Hebel

  • Symptom: Ein visuelles Prüfmodell detektiert Montagefehler zuverlässig, aber die Linie stoppt nicht automatisch, weil der SPS-Sicherheitskreis getrennt von der IT läuft. Menschen überbrücken den Alarm, weil Taktzeit vorgeht.

  • Ursache: Fehlende End-to-End-Architektur. Ein ML-Endpunkt ohne Ankopplung an MES/SCADA/SPS bleibt ein Dashboard.

  • Abhilfe: Architekturmuster „Decision in the loop“ statt „Model in the loop“. Ereignisgesteuert (Kafka/MQTT/AMQP), mit deterministischen Gateways in Richtung SPS (OPC UA, Profinet via Industrial Gateway), inklusive Safety-Konzept (Two-Man-Rule, zweiter Sensorpfad, konfigurierbare Stop-Matrix).

3) Daten sind „Projektware“, nicht „Produktware“

  • Symptom: Der POC lief im Datensumpf – CSV-Exporte aus dem Historian, händisch gepflegte Excel-Join-Keys. In Produktion bricht alles, weil Schema und Semantik nie vertraglich fixiert waren.

  • Ursache: Keine Datenverträge. Kein konsistenter Offline/Online-Feature-Lebenszyklus.

  • Abhilfe: Data Contracts an den Domänengrenzen, versionierte Schemas, CI für Datenqualität (Great Expectations/Deequ), Feature Store mit Offline/Online-Parität (Feast), sowie strikte Trennung von Raw/Curated/Serving Zonen im Lakehouse (z. B. Apache Iceberg/Delta, MinIO/S3-kompatibel on-prem).

4) Nicht-stationäre Welt – Modelle driften, Systeme nicht

  • Symptom: Nach sechs Monaten stehen die Fehlerraten Kopf, weil der Lieferant ein Bauteil mit minimaler Toleranzverschiebung liefert. Niemand merkt es, weil Model-Monitoring fehlt.

  • Ursache: Keine Telemetrie. Kein CI/CT-Prozess (Continuous Training). Keine Hypothese, was sich ändern darf.

  • Abhilfe: Drift- und Data-Quality-Monitoring (Population Stability Index, PSI; Wasserstein-Distanz; Shapley-Drift), Modellversionierung (MLflow), Canary-/Shadow-Deployments, automatisierte Retrain-Pipelines mit menschlicher Freigabe.

5) Governance ist nachträglich aufgeflanscht – in regulierten Umgebungen unhaltbar

  • Symptom: Der Datenschutz verneint die Freigabe kurz vor Go-Live, weil Trainingsdaten PII-Leakage enthalten und Audit-Trails fehlen.

  • Ursache: DSGVO, Exportkontrollen, Betriebsratsvereinbarungen wurden zu spät adressiert.

  • Abhilfe: Privacy-by-Design (Datenminimierung, Pseudonymisierung), Data Lineage, Auditability, sowie klare Verantwortlichkeiten zwischen IT, Fachbereich und Compliance. Für LLMs/Agenten: Observability, Policy-Enforcement und Reproduzierbarkeit sind nicht „nice to have“, sondern Einlasskriterium.

Fazit dieses Teils: Es scheitert selten an „besserem Modell X“. Es scheitert an Engineering- und Governance-Arbeit, die im Hype oft als „unsexy“ ignoriert wird.

Teil 2: Datenstrategie vor KI-Strategie

Eine KI-Strategie ohne Datenstrategie ist wie ein Roboterarm ohne Greifer. Im industriellen Kontext heißt Datenstrategie vor allem: Domänenmodell, Datenprodukte, Verträge – und klare Betriebsmodelle.

Leitprinzipien einer tragfähigen Datenstrategie:

  • Domänen schneiden: Entlang echter Verantwortlichkeiten (z. B. „Antriebsstrang-Zustand“, „Fahrgastinformations-Events“, „Werkzeug-Nutzungszyklen“), nicht entlang Tool-Grenzen.

  • Datenprodukte definieren: Jedes Datenprodukt hat Owner, SLA (z. B. Latenz < 5 s, Verfügbarkeit 99,9%), Schema, Qualitätstests, Versionierung, Zugriffspolicy.

  • Datenverträge an Systemgrenzen: Maschinen liefern per OPC UA/MTConnect Events, deren Schema versioniert und rückwärtskompatibel ist. Brechen Produzenten den Vertrag, schlägt CI fehl – nicht erst der Betrieb.

  • Lebenszyklus festlegen:

  • Acquisition: Edge-Collector (OPC UA Client, CAN/Modbus Adapter), Timeseries Buffer (InfluxDB/TimescaleDB) mit Write-Ahead-Log.

  • Storage: Lakehouse on-prem (MinIO + Iceberg). Keine Blackbox-Cloud, wenn Souveränität non-negotiable ist.

  • Transformation: Declarative Pipelines (dbt/Spark), Tests als Code.

  • Serving: Feature Store und/oder dedizierte Serving-DBs (Postgres/Redis für Online-Features, Vektor-DB wie pgvector/Milvus für RAG).

  • Qualität first: Automatisierte Checks (Schema-Drift, Range, Freshness, Referential Integrity). Blockierendes Gate in die Produktions-Pipeline.

  • Semantik und Metadaten: Einheitliche Einheiten (SI), Kalibrierkurven pro Sensor, klare Definitionen („Fehler“ ≠ „Alarm“). Metastore (Hive/Glue-Äquivalent on-prem) und Data Catalog.

Strategische Entscheidung: Edge vs. Zentrales Rechenzentrum

  • Edge: Niedrige Latenz, Datenschutz, Offline-Fähigkeit. Trade-off: Flotten-Rollouts, Heterogenität. Pattern: Containerisierte Inferenz (OCI), Orchestrierung via K3s/KRM, OTA-Update via GitOps.

  • Zentrales DC: Höhere Rechenkonzentration, einfacheres Monitoring. Trade-off: Latenz, Bandbreite, Datenabflussrisiko. Pattern: On-prem Kubernetes (Rancher/OpenShift), GPU-Nodes, Netzwerksegmentierung (Prod/Inference/Train), Service Mesh mit mTLS.

Das Entscheidende: Bevor ein Modell trainiert wird, muss klar sein, welches Datenprodukt welche Entscheidungen speist – inklusive Fehlerkosten. Dann erst lohnt das Modell.

Teil 3: Souveräne KI: Datenhoheit statt Cloud-Reflex