Datenstrategie vor KI-Strategie: Ohne belastbare Datenarchitektur bleibt jedes LLM ein teurer Prototyp

These: KI kennt dein Business nicht. Modelle sind austauschbar, Ihre Daten und Prozesse nicht. Wer ohne saubere Datenarchitektur in KI investiert, produziert PoCs, aber selten Produktionsnutzen. In Europa ist das doppelt wahr, weil Souveränität (DSGVO, Lieferkette, Exportkontrollen, Vendor-Lock-in) keine Variable ist, sondern Randbedingung.

Warum? Weil die wirtschaftliche Wirkung von KI nicht aus “Intelligenz” entsteht, sondern aus deterministischen Verbesserungen von Durchsatz, Qualität und Zeit—und die hängen an Datenverfügbarkeit, -qualität, -fluss und -governance. Darum: Datenstrategie zuerst. Der Rest wird einfacher und messbar.

Was eine KI-Strategie in der Praxis voraussetzt (und was fast immer fehlt)

  • Geklärte Zielgröße: Nicht “KI-Assistenz für Techniker”, sondern “Mean Time To Resolution -20% im Instandhaltungsprozess X”, “Erstlösungsquote in Ticket-Typ Y +15%”, “Stillstandsminuten je Linie -10%”.
  • Nichtfunktionale Anforderungen: Latenz, Verfügbarkeit, Datendurchsatz, Nachvollziehbarkeit, Auditierbarkeit. Beispiel: “Antwort < 800 ms P95, Entscheidungspfad reproduzierbar, vollständiges Logging ohne PII-Leakage.”
  • Datenverantwortung: Wer owned welches Schema, welche Semantik, welche Version? Ohne Data Contracts zwischen Quellsystemen und KI-Plattform ist jede Modellpipeline ein Kartenhaus.
  • Betriebsmodell: On-Prem? Air-gapped? EU-Cloud? Wer patcht Treiber? Wer rotiert Zertifikate? Wer revokiert Keys? Fehlt das, skaliert kein Prototyp.

Die vier Ebenen einer belastbaren Datenstrategie

1) Datenerzeugung: Instrumentierung statt Datensammeln

  • Data Contracts an der Quelle: Für ERP/MES/SCADA/Sensorik explizit festlegen, was geliefert wird (Felder, Einheiten, Zeitzonen, Kardinalitäten, Versionierung).

  • Zeitbasis und Identitäten: PTP/NTP konsistent, Monotonic Timestamps, stabile Primärschlüssel über Systeme hinweg. Ohne eindeutige IDs werden Join-Operationen zur Glückssache.

  • Qualität an der Quelle messen: Vollständigkeit, Gültigkeit, Wertebereiche. Wenn ein Drehmoment-Sensor nur 0/1 liefert, hilft später kein “AI Cleanup”.

  • Ereignisse statt Snapshots: Event-getriebene Architektur (OPC UA Events, CDC via Debezium, Webhooks) reduziert Latenzen und Batch-Abhängigkeiten.

  • Datenschutz-by-Design: Pseudonymisierung im Quellsystem, Purpose-Binding und Retention Policies technisch erzwingen.

2) Datentransport: Robust, versioniert, rekonstruierbar

  • Streaming-Backbone: Kafka/Redpanda mit Schema Registry (Avro/Protobuf, Apicurio) für versionierte Events. Genau-einmal-Verarbeitung ist teuer—oft reicht mindestens-einmal + Idempotenz.

  • CDC aus Legacy: SAP (ODP/SLT), SQL-basierte Systeme via Debezium, Filesystem-Watcher für Edge-Standorte. Bei SCADA/PLC: OPC UA als Standard, ansonsten MTConnect/Modbus mit Gateway.

  • Backpressure und Dead Letter Queues: Wenn Downstream hängt, dürfen Quellen nicht implodieren. Hardening > fancy ML.

  • Transportverschlüsselung und AuthN/Z: mTLS, mTLS-Rotation, Topic-Level-RBAC. Key-Management über Vault/HSM.

3) Datenmanagement: Ein Lakehouse, das Governance ernst nimmt

  • Speicherebene: On-Prem Object Storage (MinIO, Ceph) mit Bucket-Policies. Für Timeseries: TimescaleDB oder Influx (Enterprise-Policy beachten). Für Logs: OpenSearch.

  • Table-Format: Delta Lake oder Apache Iceberg für ACID, Time-Travel, Schema-Evolution. Ohne ACID werden Retrains zur Lotterie.

  • Katalog und Lineage: Hive-Metastore/Nessie + Data Catalog (OpenMetadata/Amundsen). Lineage von Quelle → Feature → Modell → Entscheidung.

  • Zugriffssteuerung: Apache Ranger/OPA für Tabellen/Spalten. Masking/Row-Level-Security für DSGVO.

  • Data Products statt zentraler Sumpf: Verantwortliche Teams liefern kuratierte, versionierte Domänen-Datensätze mit SLAs (Verfügbarkeit, Aktualität, Genauigkeit).

4) Datennutzung: Produktisierte ML- und LLM-Dienste

  • Feature-Store: Feast (online/offline Parität), Featurerezeptur versioniert, Training-Serving-Skew minimieren.

  • Modelllebenszyklus: MLflow/Weights & Biases für Artefakt- und Experiment-Tracking; Argo/Airflow für Re-Train-Pipelines mit Backfills.

  • Serving: KServe/Triton für Modelle; separate Pfade für Batch, Streaming, Online. SLOs und HPA (Horizontal Pod Autoscaler) definiert.

  • LLM-spezifisch: RAG statt “Fine-Tunen zuerst”. Vektor-DB on-prem (pgvector, Qdrant, Weaviate). Embeddings lokal (bge/e5), Prompt-Templates versioniert, Guardrails, Audit-Logs der Konversationen.

  • Observability und Governance: Telemetrie für Daten- und Modell-Drift, Qualitätsmetriken, Entscheidungserklärbarkeit, reproduzierbare Evals. Ohne Metriken keine Steuerbarkeit.

Zwei Referenzarchitekturen, die in der Industrie funktionieren

A) RAG im regulierten Betrieb: Technische Dokumente, Richtlinien, Wartungsanweisungen

Ziel: Techniker erhalten präzise, zitierfähige Antworten aus genehmigten Dokumenten. Keine Halluzinationen, keine Datenabflüsse, auditierbar.

  • Ingestion
  • Quellen: DMS/SharePoint, Fileshares, PLM, PDF/Docx, Scans (OCR: Tesseract/TrOCR).
  • Parser: Parser-Kette mit Layout-Analyse (LayoutParser), Tabellenextraktion, Bildanhänge als separate Chunks mit Referenzen.
  • Versionierung: Jede Doku ist ein Objekt mit Version und Gültigkeitszeitraum. Rückverweise im Katalog.
  • Processing
  • Chunking nach semantischen Grenzen (Überschriften, Abschnitte), nicht nur Tokens.
  • Embeddings lokal: e5-base, bge-large, quantisiert auf GPU/CPU je nach Budget.
  • Metadaten: Quelle, Version, Klassifikation (öffentlich/intern/vertraulich), Gültigkeitsdatum.
  • Storage
  • Vektor-DB: Qdrant on-prem mit HNSW; Metadatenfilter (z. B. Freigabestufe, Werk).
  • Langtext-Store: Object Storage; Retrieval liefert Chunks + vollständige Quelle.
  • Serving
  • LLM: Mistral/LLama3 on-prem, ggf. 8-bit/4-bit quantisiert; Prompt: “Antwort nur mit Zitatstellen, wenn nicht sicher → ‘Nicht genug Kontext’.”
  • Policy Enforcement: Guardrails (PII-Filter, Zugriffskontrolle per ABAC), Antwort nur, wenn Score > Schwellwert, sonst Fallback an Mensch.
  • Governance
  • Audit-Log: Prompt, retrieved Chunks, Modellversion, Antwort, Nutzerrolle. Unveränderlich (WORM-Bucket).
  • Evals: Golden-Set-Fragen mit Akzeptanzkriterien (Precision@K, Faithfulness, Groundedness). Regression-Tests vor Rollout.
  • Deployment
  • Air-gapped möglich: Alle Modelle und Indizes on-prem. Updates über signierte Artefakte. Kein US-Cloud-Zwang.

B) Predictive Maintenance in der Fertigung: Streaming first

Ziel: Frühzeitige Ausfälle erkennen, Fehlalarme unter 5%, latenzsensitiv.

  • Ingestion
  • OPC UA Subscriptions, Pufferung am Edge (Industrial PC), Time-Sync per PTP.
  • Topic-Design: machine/{id}/signal/{type}, QoS und Rate-Limits.
  • Processing
  • Feature-Engineering im Stream (Flink/Spark Structured Streaming): Rolling-Stats, FFT, Spectral Features; Fenstergrößen strikt versioniert.
  • Kontext-Join: Schichtplan, Materialcharge, Auftrags-ID via CDC-Joins.