Datenstrategie vor KI-Strategie: KI kennt dein Business nicht

Wenn Vorstände heute “KI” sagen, meinen viele de facto “ein Modell”. Ein LLM hier, ein Vision-Modell dort. Die Realität in der Produktion ist viel profaner: Identifikatoren stimmen nicht, Sensordaten sind zeitversetzt, Datenschutz stoppt Telemetrie, und niemand kann erklären, warum ein Modell gestern eine gute Entscheidung traf und heute nicht. KI kennt Ihr Business nicht. Ihr Business steckt in Daten, Domänenlogik, Prozessgrenzen und Nebenbedingungen – und genau dort scheitern viele Vorhaben. Eine tragfähige Datenstrategie ist daher nicht Beilage, sondern Hauptgericht. Erst wenn Datenflüsse, Semantik, Qualität und Souveränität klar sind, lohnt es sich, über Modelle zu sprechen.

Worum es wirklich geht: Entscheidungen unter Nebenbedingungen

Ein industrieller KI-Use-Case hat immer dieselbe Form: Wir wollen eine wiederkehrende Entscheidung in einem Prozess verbessern – schneller, robuster, kostengünstiger, sicherer. Dafür brauchen wir:

  • eine präzise formulierte Zielgröße (z. B. Reduktion von Ausschuss um x Prozentpunkte),

  • messbare Nebenbedingungen (z. B. Taktzeit darf nicht steigen),

  • den realen Entscheidungskontext (welche Infos stehen wann wem zur Verfügung),

  • verlässliche Daten über Zustand, Aktionen und Outcomes,

  • und eine Rückkopplungsschleife, die Lernen in Betrieb ermöglicht.

Keines dieser Punkte ist ein “Modellproblem”. Es sind Daten- und Systemprobleme. Wer ohne Datenstrategie in eine KI-Strategie läuft, baut Modelle ins Vakuum.

Was eine belastbare Datenstrategie für Industrie-KI enthält

1) Domänenontologie und Identität

  • Einheitliche, versionierte Begriffe für Assets, Komponenten, Chargen, Fehlerklassen.

  • Stabile technische Identifikatoren über Systeme hinweg (ERP, MES, PLM, Instandhaltung).

  • Klare Regeln für Versionswechsel (Schema-Evolution, Deprecation-Policy).

2) Datenverträge statt “best effort”-Integrationen

  • Für jeden Datenstrom: Producer-Owner, Konsumierende, Schema, Latenz, Qualitäts-SLAs, Retention.

  • Maschinen- bzw. Systemnahe Events über einen Bus (z. B. Kafka, MQTT) mit schemagebundener Validierung.

  • Änderungsmanagement: Breaking vs. non-breaking Changes, Canarying, automatisierte Kompatibilitätschecks.

3) Ground truth first

  • Plan für Labeling und Verifikation (Wer labelt? Mit welchem Tool? Wie wird Qualität geprüft?).

  • Traceability: Jeder Label muss auf Rohdaten und Umstände referenzierbar bleiben.

  • Klare Trennung zwischen Trainings-, Validierungs- und Produktivdaten; Auditierbarkeit.

4) Datenqualität operativ managen

  • Metriken: Vollständigkeit, Freshness, Konsistenz, Plausibilität, Ausreißer.

  • Data-Quality-Monitore im Stream und im Batch; Alerting an Owner-Teams.

  • “Quality Gates” im Pipeline-Bau: Kein Modelltraining auf schmutzigen Daten.

5) Edge-to-Core-Architektur mit Souveränität als Default

  • Edge-Inferenz dort, wo Latenz oder Datenschutz es verlangen.

  • On-Premise Data-Lake/-Lakehouse (z. B. S3-kompatibel via MinIO/Ceph) statt Public-Cloud-Default.

  • Pseudonymisierung/Anonymisierung am Rand des Netzes; Datenminimierung bewusst gestalten.

6) Features und Reproduzierbarkeit

  • Feature-Berechnung versioniert (Code+Konfiguration+Upstream-Schemata).

  • Wiederholbarkeit: Offline-Training und Online-Inferenz nutzen identische Feature-Definitionen.

  • Feature Store wo sinnvoll (stabile Real-Time-Merkmale), On-Demand-Berechnung wo LLM/RAG dominiert.

7) Governance, Sicherheit, Compliance

  • Zugriff nach Need-to-know: technische Durchsetzung (RBAC/ABAC), kein “Excel-Export als API”.

  • Audit-Logs für Datenzugriffe, Modell-Entscheidungen, Overrides.

  • DSGVO- und Exportkontroll-Aspekte als Architekturanforderungen, nicht als später “Blocker”.

8) Observability für Daten und Modelle

  • Daten-Linien (Lineage) bis zur Entscheidung im Feld.

  • Drift-Detektion (Daten, Features, Modelloutputs) und Live-Evaluierung gegen Referenzregeln.

  • Für LLM/Agenten: Prompt-/Context-Logging, Policy-Checks, Tool-Use-Transparenz.

Referenzarchitekturen, die in der Praxis tragen

A) Computer Vision in der Fertigung (Defekterkennung, Montageprüfung)

  • Erfassung: Kameras an Edge-Rechner angebunden; synchronisierte Timestamps und Produktionskontext (Auftrag, Charge).

  • Preprocessing: Deterministische Pipelines (z. B. OpenVINO/TensorRT) mit versionierten Parametern.

  • Inferenz: On-Device oder Zellen-Server, um Taktzeiten zu halten; Modelle als OCI-Images.

  • Datenstrom: Metadaten in Kafka; Bildartefakte in On-Prem-Objektspeicher; Datenverträge für beide.

  • Labeling: Closed-Loop im Werker-UI (positives/negatives Feedback), gesichertes Review mit Golden-Set.

  • MLOps: On-Prem-MLflow (Registry), Trainings-Orchestrierung (Kubernetes, Argo), Canary-Deployment pro Zelle.

  • Observability: Per-Zelle-Qualitätsmetriken, Falsch-Positiv/Negativ-Quoten, automatische Rückläuferanalyse.

B) Fleet Intelligence / Predictive Maintenance

  • Telemetrie: MQTT/Kafka-Bridge, effiziente, schemagebundene Events, verlustfreie Pufferung bei Funklöchern.

  • Feature-Build: Sliding-Window-Aggregationen, Health-Indikatoren, Self-Supervision (Autoencoder für Anomalien).

  • Entscheidung: Health-Score + Regeln (z. B. Flottenweite Priorisierung), menschliche Freigabe optional.

  • Betrieb: Edge-Inferenz im Fahrzeug/Asset, Upload nur verdichteter Features, Rohdaten on demand.

  • Governance: Strikte Trennung Identität/PII vs. Telemetrie; regionale Datendomänen für Hoheitsrechte.

C) LLM-gestützte Assistenz in regulierten Domänen

  • Retrieval statt “Blindflug”: On-Prem-Vector-DB (pgvector, Qdrant), Index-Build aus geprüften Quellen.

  • Inferenz: Self-Hosted LLMs (z. B. Llama/Mistral) für sensible Inhalte; Cloud nur für nicht-sensitive Prototypen.

  • Guardrails: Prompt-Policies, Content-Filter, Tool-Use-Whitelists, deterministische Workflows für heikle Aktionen.

  • Observability & Governance: Pro Interaktion nachvollziehbar, welcher Kontext, welche Tools, welche Entscheidung. Feedback-Mechanismen mit Re-Training-/Re-Retrieval-Pipeline.

  • Datenflüsse: Keine Telemetrie in Fremd-Clouds; Red-Teaming und Freigabeprozesse vor Rollout.

Diese Architekturen sind keine “KI-Schichten”. Es sind produktionsreife Softwaresysteme, in denen Modelle austauschbare Bausteine sind. Der Engpass ist fast immer die Semantik und Qualität der Daten – nicht die Netzarchitektur eines Modells.

Der Bruch zwischen PoC und Produktion

Warum laufen viele PoCs im Lab gut und scheitern live?

  • Daten-Drift: Produktionsdaten unterscheiden sich subtil vom Lab-Set (Beleuchtung, Varianten, Nutzerverhalten).

  • Feature-Mismatch: Offline-Features lassen sich online nicht in gleicher Qualität/ Latenz erzeugen.

  • Fehlende Ground truth im Betrieb: Ohne verlässliches Feedback verschwindet Leistungsfähigkeit im Rauschen.

  • Integrationsschulden: PoC umgeht Identität, Sicherheit, Governance – in Produktion nicht zulässig.

  • Kostenmodelle ignorieren Realität: Cloud-Egress, GPU-Scheduling, Wartungsfenster – alles Posten, die PoCs ausblenden.