Datenstrategie vor KI-Strategie: KI kennt dein Business nicht

Wenn ein Team mit einem Basismodell beeindruckende Demos zeigt, ist die Versuchung groß, das Problem als gelöst zu betrachten. Doch ein Modell kennt Ihre Prozesse, Ihre Randbedingungen, Ihre regulatorischen Pflichten und Ihre Fehlertoleranzen nicht. KI kennt Ihr Business nicht. Genau deshalb scheitern KI-Initiativen seltener an „fehlender Intelligenz“ und häufiger an fehlender Souveränität über Daten, Prozesse und Betrieb. Wer eine KI-Strategie formulieren will, muss vorher eine Datenstrategie klären – inklusive Architektur, Ownership, Sicherheitsanforderungen und einem Plan für den Übergang von POC zu Produktion.

Im Folgenden skizziere ich, wie wir in Industrieprojekten vorgehen, welche technischen Entscheidungen den ROI bestimmen und warum On-Premise- und Souveränitätsanforderungen die Architektur stark beeinflussen.

Problem vor Technologie: Von Business-Capability zu Daten-Capability

Der erste Fehltritt vieler Initiativen: Mit einem Modell oder Tool starten, bevor klar ist, welche konkrete Entscheidung, welcher Prozessschritt oder welches Risiko verbessert werden soll. Statt „Wir brauchen Generative AI im Service“ ist die zielführende Formulierung: „Wir wollen die mittlere Diagnosezeit am Prüfstand um 25% reduzieren, ohne die False-Positive-Rate über 2% zu erhöhen.“

Vorgehen, das sich bewährt:

1) Outcome definieren

  • Business-Capability: Welche Kennzahl verändern wir? Beispiele: First-Pass-Yield, MTBF, Turnaround-Time, Mean Time To Recovery, Störungsprognose-Horizont, Zeit bis zur richtigen Teilebestellung.

  • Constraint: Welche Fehler sind akzeptabel? In der Qualitätsprüfung sind False Negatives oft teurer als False Positives; im Service kann es umgekehrt sein.

2) Datenfluss kartieren

  • Welche Ereignisse, Sensoren, Dokumente und Entscheidungen spielen in den Prozess?

  • Welche Systeme sind Quelle der Wahrheit (ERP, MES, SCADA, PLM, Flotten-Telemetrie, Logistik-Events)?

  • Welche rechtlichen/vertraglichen Einschränkungen bestehen (DSGVO, Geheimschutz, OEM-Datenrechte, Exportkontrollen)?

3) Datenprodukt definieren

  • Ein Datenprodukt ist ein versioniertes, dokumentiertes, automatisiert getestetes Artefakt mit klaren Verträgen (Schema, Latenz-SLA, Qualitätsmetrik).

  • Beispiele: „Golden Assembly Dataset v3“ (Stückliste, Prozessparameter, End-of-Line-Testergebnisse, Label für i.O./n.i.O.), „Fleet Health Timeline“ (Zeitreihen mit Ausreißer-Markierungen), „Service Case Embeddings“ (Vektordarstellung kuratierter Wissensartikel mit Metadaten und Zugriffskontrollen).

Erst wenn klar ist, wie das Datenprodukt aussehen muss, ergibt sich die passende Modellarchitektur.

Architekturfragen, die den ROI entscheiden

1) Daten-Topologie: Lake, Lakehouse oder Data Mesh?

  • Zentraler Lake/Lakehouse (z. B. S3-kompatibel via MinIO + SQL-Engine): Gut für homogene Domänen, klare Governance, starke Batch-Fähigkeiten.

  • Domain-orientierte Datenprodukte (Data Mesh): Sinnvoll bei dezentraler Verantwortung (z. B. Werke, Flotten, Baulose), wenn Domänenautonomie wichtiger ist als zentraler Durchsatz.

  • Hybrid: Zentrale Infrastruktur, dezentral verantwortete Datenprodukte mit gemeinsamen Policies und Katalog.

Praxistipp: Entscheiden Sie explizit, welche Domänen „produzieren“ (Owner) und welche „konsumieren“. Ohne klare Ownership entstehen Schattenpipelines, Schema-Drift und untestbare Modelle.

2) Ingestion und Änderungsverfolgung

  • Event-Streaming (Kafka/Redpanda) für Prozess- und Telemetriedaten.

  • Change Data Capture (CDC) aus ERP/MES/PLM für Zustandsänderungen ohne Produktionsstörung.

  • Time-Series-Store (z. B. VictoriaMetrics/Timescale) für hochauflösende Sensorik.

  • Visuelle Daten: Verlustarme Formate (PNG, TIFF), klare Versionierung, Label-Schema, Annotation-Toolkette, Label-Policies.

  • Dokumente: Parser für strukturierte Extraktion, Fortführung von Metadaten und Zugriffsrechten.

3) Datenqualität als Code

  • Schemaverträge mit Versionierung und Abwärtskompatibilität.

  • Automatisierte Checks (z. B. Range-, Freshness-, Consistency-Checks) als Teil der Pipeline.

  • Reproduzierbare Backfills mit fixierten Transformationen.

  • Golden Datasets für Trainings- und Akzeptanztests, eingefroren und auditierbar.

4) Sicherheit und Souveränität
Souveränität ermöglicht Intelligenz. Wenn Daten nicht beherrscht, nachweisbar geschützt und revisionssicher verarbeitet werden, ist jede KI-Strategie ein Risiko.

  • On-Premise- oder EU-Only-Deployments, Air-Gap im Verteidigungs-/OT-Kontext.

  • Schlüsselverwaltung (KMS/HSM), Secret-Management, feingranulare IAM, Netzsegmentierung.

  • Datenresidenz und -klassifizierung (z. B. personenbezogen, exportkontrolliert, geschäftskritisch).

  • Trainings- und Inferenz-Logs mit Pseudonymisierung/Anonymisierung wo nötig, revisionssicher mit Retention-Policies.

5) MLOps on-prem: Produktionsreife ohne Public Cloud

  • Orchestrierung: Kubernetes mit GPU-Scheduling, Argo/Airflow für Pipelines.

  • Artefakte: On-Prem Container Registry, Artifact Store (S3/MinIO), Model Registry (z. B. MLflow).

  • Feature Store: z. B. Feast/Feathr, mit Online/Offline-Parität.

  • Observability: Prometheus/Grafana für Metriken, Loki/ELK für Logs, OpenTelemetry für Traces.

  • Air-gap-Betrieb: Geplante Image-Updates, CVE-Scanning, Repro-Builds, signierte Artefakte.

  • Compliance: Nachvollziehbare Trainingsläufe, Datenherkunft (Lineage), Freigabeprozesse.

6) LLM-spezifische Architektur unter Souveränitätsauflagen
Viele kopieren Web-RAG-Beispiele und scheitern, sobald Governance, Zugriffskontrollen und Betriebsauflagen greifen.

  • Retrieval: On-Prem-Vektorspeicher (Qdrant/pgvector/Weaviate), Datenkonnektoren zu SharePoint On-Prem, Confluence self-hosted, PLM/DPDM, Dateifreigaben; ACLs werden im Retrieval respektiert.

  • Chunking/Indexing: Domainspezifische Segmentierung (z. B. nach Baugruppen, Änderungsständen), strukturerhaltende Indizes, Resolver für Versionen.

  • Modelle: Für sensible Inhalte bevorzugt Open-Weight-Modelle On-Prem; Fine-Tuning nur mit kuratierten, rechtlich geprüften Datensätzen; ansonsten RAG statt Fine-Tuning zur Wissenseinspritzung.

  • Guardrails: Policy-Filter vor/nach dem Modell (PII-Redaktion), Tool-Allowlisting, Funktionsgrenzen, Abbruch bei Regelverstößen.

  • Observability: Agent-Traces, Token-/Latenzbudget, Retrieval-Recall/Precision, Antwort-Red-Flags (z. B. Quellenlosigkeit), Drift-Erkennung bei Wissensständen.

  • Kosten-/Leistungsplanung: On-Prem-Compute-Budget ersetzt API-Kosten; Kapazitätsplanung in Tokens/s, Latenz-SLOs, Kontextfenster, Quantisierungseffekte.

Typische Fallstricke und wie man sie vermeidet

1) POC-Blindheit
Warum POCs glänzen: kuratierte Daten, vereinfachte Randbedingungen, Experten in der Schleife. Warum Produktion ernüchtert: Datenlücken, wechselnde Versionen, Operator-Handoffs, Latenzbudgets.
Gegenmaßnahme: POC-Design mit produktionsnahen Daten, repräsentativen Störfällen, realistischen SLAs; Pflichtkriterien für Produktionsreife definieren.