KI kennt dein Business nicht: Warum viele KI-Projekte scheitern – und wie eine souveräne Datenstrategie den Unterschied macht

Unternehmen investieren in KI, weil sie Produktivität heben, Qualität sichern oder Risiken reduzieren wollen. Dennoch landen viele Initiativen in der Schublade oder schaffen es nie über den POC hinaus. Die Ursache liegt selten im „falschen Modell“. Es ist fast immer das falsche Problem, die fehlende Datenstrategie oder die fehlende Produktionstauglichkeit. Und: Ohne Souveränität über Daten, Betrieb und Risiken bleibt KI ein Spielzeug.

Was folgt, ist eine technische Sicht auf KI-Strategie aus realen Industrieprojekten – problem-first, nicht technology-first. Keine Versprechen, sondern Muster und Trade-offs, die in der Praxis tragen.

Problem statt Hype: Wenn ROI an der falschen Stelle gesucht wird

Viele Projekte beginnen mit der Technologie („Wir brauchen ein LLM“ oder „Wir setzen auf Vision-Transformer“). Der sichtbare Fortschritt im POC täuscht: Ein Modell erreicht gute Offline-Metriken, aber der Prozess gewinnt keinen Takt, die Fehlerraten verschieben Kosten nur, oder Compliance blockiert das Go-Live. Typische Ursachen:

  • Falsches Zielsystem: Optimiert wird eine Metrik (z. B. AUC), die nicht mit dem betriebswirtschaftlichen Nutzen korreliert. Die Kosten einer Fehlklassifikation sind asymmetrisch, aber die Loss-Funktion ignoriert das.
  • Fehlende Baselines: Es wird nicht gemessen, ob eine einfache Regel, ein Schwellwert auf Sensoren oder ein Vier-Augen-Prinzip 80% des Nutzens günstiger liefern würde. Ohne No-Regret-Baseline ist der ROI unklar.
  • Versteckte Betriebskosten: Labeling, Datenpflege, Drift-Handling, GPUs, Change-Management und Audits werden im POC nicht gerechnet. In der Produktion dominieren diese Kosten.
  • Integrationslücke: Ein gutes Modell nutzt nichts, wenn es nicht robust an SCADA/PLC, MES, DMS, Ticket-Systeme oder Cockpits angebunden ist. Die Latenz, die Verfügbarkeit und das Fehlermanagement entscheiden.
  • Prozesspassung: Wo Menschen mitentscheiden müssen, braucht es sinnvolle Abstimmungspunkte. Modelle ohne Abstain-Mechanismus zwingen Nutzer in Workarounds.
  • Sicherheits- und Souveränitätsanforderungen: Wenn Datenräume, Betriebsorte und Audit-Anforderungen erst spät adressiert werden, endet das Projekt in rechtlichen und betrieblichen Sackgassen.

Wie man es besser macht:

  • Formulieren Sie eine Nutzenfunktion anstelle einer reinen Modell-Metrik. Definieren Sie eine Kostenmatrix: Kosten(False Negative), Kosten(False Positive), Bearbeitungskosten für Abstain, und messen Sie Expected Utility statt Accuracy.
  • Führen Sie harte Kill-Kriterien ein. Beispiel: „Wenn die No-Regret-Baseline ≥ 70% des Nutzens erreicht und die ML-Lösung > 3x teurer ist, stoppen wir.“
  • Legen Sie SLOs für das System fest, nicht nur fürs Modell: Latenz P95, Verfügbarkeit, Reproduzierbarkeit, Auditierbarkeit, mittlere Zeit bis Recovery bei Datenfehlern.
  • Integrieren Sie Human-in-the-Loop bewusst: Definieren Sie Schwellenwerte, bei denen ein Fall an den Menschen eskaliert. Tracken Sie Lernsignale systematisch (aktive Lernschleife).

Datenstrategie vor KI-Strategie

Ohne kontrollierbare, zuverlässige Datenströme wird jede Modellidee zur Wette. Eine tragfähige KI-Strategie ist immer eine Datenstrategie mit folgenden Bausteinen:

1) Datenverträge statt Datenwunschzettel

  • Producer/Consumer-Vertrag je Datenquelle: Schema, zulässige Wertebereiche, Zeitauflösung, Zeitsynchronisation, Semantik (z. B. ist 0 ein Messwert oder ein Kommunikationsfehler?), Qualitäts-SLOs.

  • Schema-Evolution geregelt: Versionierung, Deprecation-Zeiten, Rückwärtskompatibilität, automatisierte Validierungen (z. B. bei jedem Deploy).

2) Daten-Pipelines, die auditierbar und reproduzierbar sind

  • Rohdaten bleiben unverändert erhalten; Transformationen sind deklarativ, versioniert und nachvollziehbar.

  • Feature-Berechnung ist deterministisch und wird einmalig definiert (Train/Serve-Parität). Keine divergierenden Implementierungen in Python-Notebook und Produktionsservice.

  • Lineage sichtbar: Von Modellvorhersage zurück bis zur Sensorquelle. Das ist essenziell für Fehleranalysen und Audits.

3) Labeling und Ground Truth als strategische Investition

  • Goldstandard-Datensätze kuratieren, nicht nur Sammeln „was anfällt“. Halten Sie Balanced Sets für jede wichtige Betriebsregion vor.

  • Aktives Lernen nutzen: Das Modell markiert unsichere Beispiele, Routing an Domänenexperten, anschließender Retrain.

  • Weak Supervision und programmatische Labels ermöglichen schnelle Skalierung; am Ende entscheidet kuratierte Qualität über Produktionsreife.

4) Daten-Governance als Enabler, nicht als Bremse

  • Rollenbasierter Zugriff, klare Zwecke, protokollierte Nutzung. Minimierung und Pseudonymisierung dort, wo möglich.

  • Retentions- und Löschkonzepte, die in Pipelines technisch durchgesetzt werden.

  • Getrennte Zonen: Roh, kuratiert, Feature, Trainings- und Inferenzdaten, jede mit eigenen Policies.

5) Architektur, die Souveränität abbildet

  • On-Premise Lakehouse mit offenen Formaten (spaltenorientiert, ACID-fähig), plus Message-Bus für Streaming-Sensordaten.

  • Feature Store on-prem, um Train/Serve-Parität sicherzustellen.

  • Sichere Replikationspfade zwischen Edge/Factory und Rechenzentrum, auch für Air-Gap-Szenarien.

  • Backup/Restore regelmäßig getestet; Desaster-Szenarien (z. B. Sensorausfall, Netzwerksegmentierung) durchgespielt.

Ein Praxisdetail aus der Industrie: Zeit ist alles. Ohne harte Zeitsynchronisation zwischen Maschinen, Kameras und Steuerung sind eventgetriebene Modelle blind. Planen Sie Sensor-Clock-Drift, Resampling und Interpolation explizit ein. Und dokumentieren Sie, welche Verzögerungen im Prozess tolerierbar sind.

Souveräne KI: Kontrolle über Daten, Betrieb und Risiko

„Souveränität ermöglicht Intelligenz“ ist keine Parole, sondern eine Betriebsanforderung. In kritischen Industrien entscheidet die Fähigkeit, Systeme unter eigenen Rahmenbedingungen zu betreiben, über Wirtschaftlichkeit und Sicherheit.

Warum das für KI zentral ist:

  • Verfügbarkeit und Latenz: Qualitätsentscheidungen am Band oder sicherheitskritische Funktionen im Feld brauchen vorhersagbare Latenzen und Ausfallsicherheit – nicht „best effort“.

  • Änderungs- und Auditfähigkeit: Sie müssen erklären können, warum ein System gestern anders entschied als heute. Das bedingt Versionskontrolle für Daten, Features, Modelle, Prompts und Policies.

  • Datenabflüsse vermeiden: Trainingsdaten, Prompts, Kontexte und Tool-Aufrufe von LLM-Agenten enthalten Fachwissen. Unkontrollierte Logs oder Telemetrie gefährden dieses Wissen.

  • Haftung und Nachvollziehbarkeit: Entscheidungen von ML/LLM müssen rückverfolgbar sein – wann, mit welchem Input, mit welcher Version, und welcher Mensch bestätigte oder übersteuerte.