Titel: Datenstrategie vor KI-Strategie – warum Ihr Modell scheitert, wenn Ihr Datenpfad wackelt

KI kennt Ihr Business nicht. Und doch versuchen Teams immer wieder, „KI“ als Antwort auf unklare Fragen einzusetzen: erst ein großes Modell kaufen, dann ein paar APIs verkabeln, und irgendwo zwischen Pilot und Rollout merkt man, dass die Ergebnisse in der Produktion instabil werden, die Kosten explodieren oder die Security das System zu Recht stoppt. Die Ursache ist fast nie „zu wenig KI“, sondern fast immer „fehlender Daten- und Betriebsplan“.

Dieser Artikel ist meinungsstark, weil die Realität in Industrieprojekten unforgiving ist: Ohne robuste Datenstrategie gibt es keine tragfähige KI-Strategie. Punkt. Ich zeige, wie man Problem-first statt Technology-first vorgeht, welche Systembausteine Sie on-premises benötigen, und welche konkreten Architekturen den Sprung vom POC in den Betrieb absichern – für klassische ML und für LLM-basierte Systeme.

1. Problem first: Entscheiden, bevor man modelliert

KI ist kein Selbstzweck. Starten Sie mit der zu automatisierenden Entscheidung.

  • Beispiel 1: Visuelle Defekterkennung in der Fertigung. Entscheidung: Gut/Schlecht mit Begründung und Traceability. Nichttriviale Randbedingungen: Kamerakalibrierung, Beleuchtung, Taktzeiten < 200 ms, seltene Fehlerklassen, Labeldrift durch Prozessänderungen, Auditierbarkeit.
  • Beispiel 2: Wartungsassistenz im Bahnbereich mittels LLM. Entscheidung: Welche Wartungsprozedur, mit welchen Sicherheitshinweisen, aus welchen zugelassenen Dokumenten? Randbedingungen: abgeschottetes Netz, keine Datenabflüsse, versionierte Wissensstände, Nachvollziehbarkeit der Quellen.

Diese Entscheidungen definieren harte Systemanforderungen: Latenz-SLAs, Begründungspflicht, Sicherheitszonen, Updaterythmen, Datenlebenszyklus. Erst danach kommt die Frage: Welches Modell, welche Architektur?

2. Datenstrategie: Die sechs Bausteine, die jedes Produktionssystem braucht

2.1 Daten-Domains und Data Contracts
Ordnen Sie Daten fachlichen Domains zu (z. B. Fertigung, Wartung, Qualität) und definieren Sie Data Contracts: eindeutige Verantwortliche, Schemas mit Versionierung, Qualitäts-SLAs (Vollständigkeit, Aktualität, Plausibilität), erlaubte Änderungsarten. Ohne Data Contracts zerschellen Upstream-/Downstream-Teams an impliziten Erwartungen.

Technisches Muster:

  • Schema Registry (z. B. Avro/Protobuf) mit semantischer Versionierung.

  • Automatisierte Contract-Checks in der CI/CD von Datenpipelines.

2.2 Speicherung und Zugriff: Lakehouse on-prem
Ein Lakehouse vereinigt rohe, kuratierte und servierbare Daten auf einer ACID-fähigen Storage-Schicht. On-prem praktikabel mit:

  • Objektspeicher (S3-kompatibel wie MinIO oder Ceph) für Rohdaten und Feature-Stores.

  • Tabellenschicht mit Apache Iceberg oder Delta Lake für ACID, Time-Travel, Partitionierung.

  • Spaltenformate (Parquet) für effiziente Verarbeitung.

Trade-offs:

  • Warehouse-first (klassische SQL-DWH) beschleunigt BI, ist aber bei heterogenen, unstrukturierten Daten und ML-Workloads limitiert.

  • Reines Data Lake ohne ACID führt zu Inkonsistenzen und schwerer Reproduzierbarkeit.

2.3 Ingestion: Batch, Stream und industrielle Protokolle
In der Industrie sind Datenquellen vielfältig:

  • PLC/OT via OPC UA oder Modbus; Ereignisbus via MQTT/Kafka; relational via CDC (Change Data Capture).

  • Frequenzen von Millisekunden (Sensoren) bis Stunden (ERP).

  • Time-Sync ist kritisch: NTP/PTP auf Edge-Gateways; konsequente Zeitstempel auf Ingestion-Ebene.

Technisches Muster:

  • Event-Streaming (Kafka/Redpanda) für hochfrequente Telemetrie, Schema Registry zur Evolvierbarkeit.

  • Batch-Ingestion via Airflow/Prefect, CDC aus ERP/MES (Debezium).

  • Downsampling und Aggregation (z. B. Resampling von 1 kHz auf 10 Hz), mit Verlustfreiheits- und Qualitätskennzahlen.

2.4 Datenqualität und Lineage
Daten ohne Qualität sind teure Rauschen.

  • Unit-Tests für Daten: Schema-Checks, Range-Checks, Fremdschlüssel-Konsistenz, Drift-Erkennung (z. B. jenseits von 3σ).

  • Lineage vom Report/Modell bis zur Quelle: Welche Transformationen, welche Versionen?

Technisches Muster:

  • Data Quality Frameworks (Great Expectations, Soda) im Pipeline-Lauf.

  • Lineage und Katalog (OpenMetadata/Amundsen) verbunden mit Git-Commits und Pipeline-Runs.

  • Fehlschlag = Stop der Pipeline, nicht „Warnung im Log“.

2.5 Souveränität, Zugriff und Audit
Industrieprojekte scheitern oft an Security by Afterthought. Planen Sie Security andauernd ein:

  • Netzwerkzonen (OT/IT/DMZ), Zero-Trust-Prinzipien, minimaler Egress. Standard: Kein ausgehender Internetzugang aus der Inferenz-Zone.

  • Verschlüsselung at-rest und in-transit; Schlüsselverwaltung on-prem (z. B. Vault), getrennte Admin-Rollen.

  • Zugriffskontrolle zentral (z. B. Keycloak) und Autorisierungsrichtlinien (OPA/Gatekeeper).

  • Vollständige Audit-Trails für Datenzugriffe und Modellaufrufe.

2.6 Metadaten und Wissensmodell
Ohne Begriffsklärung gibt es kein gemeinsames Verständnis.

  • Business-Glossar: einheitliche Definitionen (z. B. „Fehlerklasse A“).

  • Datenkatalog mit Ownership, Sensitivität, Verfallsdaten.

  • Domänenspezifische Ontologien oder Wissensgraphen, auf die Retrieval-Systeme (RAG) aufsetzen können.

3. Architekturentscheidungen für ML und LLM – konkret und on-prem

3.1 Klassische ML/CV-Workloads

  • Feature-Store: zentraler Ort für Feature-Berechnung und -Serving (Batch + low-latency). On-prem mit Lakehouse + dediziertem Serving-Layer.

  • Trainings-Orchestrierung: Containerisierte Jobs auf Kubernetes; reproduzierbare Umgebungen (Base-Images gepinnt, Artefakt-Caches kontrolliert).

  • Serving: NVIDIA Triton oder Bento-ähnliche Server für CV/Tabular; GPU-Sharing via MIG falls sinnvoll; Ressourcen-Quoten strikt.

Trade-offs:

  • Volle GPU-Auslastung vs. Latenz-Garantien: Planen Sie Puffer und Batch-Inferenz; messen Sie 95./99. Perzentil, nicht nur Mittelwerte.

  • ONNX/TensorRT-Optimierung kontra Portabilität: Portabilität kostet Laufzeit, Optimierung kostet Flexibilität.

3.2 LLM/Agent-Systeme on-prem

  • Modellwahl: Starten Sie mit einem soliden Open-Weight-Modell (z. B. in der 7‑13B‑Klasse) und testen Sie domänenspezifisch; Skalieren Sie erst nachgewiesenem Qualitätszuwachs. Lizenz- und Sicherheitsprüfung vor dem Pull.

  • Serving: vLLM oder Text Generation Inference für hohe Durchsatz-/Latenz-Anforderungen; Token-Throughput planen (Tokens/s pro GPU).

  • RAG als Default, Fine-Tuning als Option:

  • RAG: Versionierte Indizes, Quelle-zu-Antwort-Verknüpfung, Hartes „Antwort nur aus Quellen X“. Index-Strategie: HNSW für schnelle Top‑k; Chunking domänenspezifisch (nicht blind 512 Tokens), strukturerhaltend (Abschnitt, Norm-IDs).

  • Fine-Tuning: Stabilisiert Stil/Format, aber verschiebt Wartung in den MLOps-Prozess. Sichern Sie eval/rollback und isolieren Sie Trainingsdaten rechtlich/technisch.