Titel: KI kennt dein Business nicht – warum Datenstrategie, Souveränität und Produktionsreife wichtiger sind als das nächste Modell

Wenn KI-Projekte scheitern, liegt es selten an der Mathematik und fast nie am „falschen“ Modell. Sie scheitern an falscher Problemwahl, fehlenden Datenverträgen, ignorierten Nichtfunktionalen Anforderungen und an der Illusion, ein hübscher PoC wäre schon halbe Produktionsreife. KI kennt Ihr Business nicht. Und wenn die Architektur, die Prozesse und die Verantwortlichkeiten das nicht kompensieren, verbrennen Sie Budget – egal wie beeindruckend die Demo wirkt.

Dieser Artikel ist meinungsstark, weil die Praxis nüchtern ist: Wer industrielle KI baut, hat es nicht mit „Chatbots“ und PowerPoint-Roadmaps zu tun, sondern mit Schichtplänen, Regressansprüchen, Messrauschen, Haftung, DSGVO, RF-Störungen, Safety Cases und Audits. Und mit der strategischen Frage, ob Sie Ihre Daten und Modelle souverän betreiben – oder fremden Plattformrisiken aussetzen.

Worum es geht:

  • Warum viele KI-Initiativen den erwarteten ROI verfehlen – technisch und organisatorisch

  • Warum eine Datenstrategie der KI-Strategie vorausgehen muss

  • Souveräne KI: On-Prem- und EU-first-Architekturen statt US-SaaS-Abhängigkeiten

  • Von PoC zu Produktion: Der steinige Übergang und wie man ihn plant

1) Warum KI-Projekte den erwarteten ROI verfehlen

Es gibt wiederkehrende Muster des Scheiterns. Keines davon wird durch einen Modellwechsel gelöst.

  • Falsches Zielsystem: „Mehr Genauigkeit“ ist kein Business-KPI. Relevante Zielgrößen sind Durchsatz, Ausfallminuten, Nacharbeitsquote, First-Pass-Yield, Mean Time To Repair, Claim Rate. Ohne Kostenmatrix (Kosten von False Positives/False Negatives) optimieren Teams für eine Metrik, die operativ keinen Hebel hat.
  • PoC-Theater statt Produktionspfad: Ein Notebook-PoC ignoriert Latenz, Verfügbarkeiten, Edge-Beschränkungen, Sicherheitszonen, Traceability und operativen Betrieb. Das Ergebnis: ein Dutzend hübscher Demos – und Null produktive Deployments.
  • Daten ohne Verträge: Wenn ein Modell von „Rohdaten“ lebt, für die es weder Schema-Verträge (Data Contracts) noch Quality-SLAs gibt, ist jede neue Geräte-Firmware oder SPS-Änderung ein unbeabsichtigter A/B-Test mit Produktionsrisiko.
  • Ground-Truth-Illusion: Für Überwachung, Retraining und Audit brauchen Sie verlässliche Labels und Prozess-Events (Reparatur, Ausschuss, Nacharbeit). Ohne annotierte, versionierte Datensätze ist jedes „Verbesserungsversprechen“ nicht verifizierbar.
  • Nichtfunktionale Anforderungen vergessen: Latenz-Budgets, deterministische Reproduzierbarkeit, Energie-/GPU-Kosten, Sicherheitszonen (z. B. Air-Gap), Auditpflichten und Datenminimierung sind kein „nice to have“. Sie sind primäre Architekturtreiber.
  • Vendor-Lock-in und Souveränitätsrisiko: US-SaaS für zentrale Modelle, Vektorspeicher und Observability klingt verlockend – bis Datenschutz, Exportkontrolle, Kundenvorgaben oder Sicherheitsprüfungen den Stecker ziehen. Was bleibt von der Lösung ohne diese Dienste?
  • Keine saubere Betriebsübergabe: Wer betreibt das System? Wer rollt Modelle zurück? Wer priorisiert Fehlalarme? MLOps ohne klare Ownership endet in „Zombie“-Systemen, die niemand mehr zu verantworten wagt.

Kurz: Der Engpass ist Systems Engineering, nicht nur Data Science.

2) Datenstrategie vor KI-Strategie

KI ist eine Funktion Ihrer Datenlogistik und -governance. Ohne Datenstrategie ist die KI-Strategie eine Hülle.

Kernbausteine einer tragfähigen Datenstrategie:

  • Datenprodukte statt Datenhalden:
  • Definieren Sie domänenspezifische Datenprodukte (z. B. „Pressenzyklus v2“, „Kamerastream Linie 4 unkomprimiert“, „Wartungsereignis normalisiert“).
  • Jedes Datenprodukt hat einen Owner, ein Schema, Quality-SLAs (Vollständigkeit, Latenz, Ausreißerregeln), Versionierung und eine Änderungsprozedur.
  • Data Contracts:
  • Formale Verträge zwischen Produzenten (Maschine, Subsystem) und Konsumenten (Modelle, Dashboards).
  • Strikte, versionierte Schemas; Breaking Changes nur über neue Versionen, koexistierende Pipelines, Deprecation-Plan.
  • Ereignisorientierte Architektur:
  • Nutzen Sie Change Data Capture (CDC) und Event-Bus (z. B. Kafka) für zeitnahe, robuste Datenströme.
  • Batch hat seinen Platz, aber Fehlererkennung, RUL-Schätzung oder adaptive Steuerung profitieren von Events mit garantierter Zustellung und Replays.
  • Semantische Schicht:
  • Einheitliche Definitionen (z. B. was exakt ist „Ausschuss“), Kalibrierstand, Aggregationslogik, Einheiten. Entfernt Wildwuchs und vermeidet „DataFrame-fu“ in jedem Notebook.
  • Labeling- und Feedback-Strategie:
  • Planen Sie den Ground-Truth-Budgetposten von Anfang an. Ohne industrielle Annotation (operator-verified) keine belastbare kontinuierliche Verbesserung.
  • Human-in-the-loop-Interfaces für schnelle Bestätigung/Korrektur, speziell bei Grenzfällen.
  • Datenresidenz, Datenschutz, Exportkontrolle:
  • Klären Sie Rechtsgrundlagen (DSGVO, Betriebsrat), Pseudonymisierung, Datenminimierung, Aufbewahrungsfristen, Zugriffsschichten.
  • Dokumentieren Sie Datenflüsse und Aggregationsgrade – essenziell für Audits und für spätere Freigaben.

Die Reihenfolge ist nicht verhandelbar: Erst Daten- und Ereignisarchitektur, dann Modellidee.

3) Souveräne KI: Architekturen ohne Abhängigkeit von US-SaaS

Souveränität ist kein politisches Schlagwort, sondern ein technischer Architektur-Constraint:

  • Daten dürfen das Werk/das eigene Rechenzentrum nicht verlassen (DSGVO, Kundenvorgaben, Exportkontrolle).
  • Keine Cloud-Abhängigkeiten, deren Compliance Sie nicht steuern können.
  • Volle Auditierbarkeit und Reproduzierbarkeit.

Praktische Souveränitätsmuster: