2) Datenrechte und OEM-„Überraschungen“
In Mobility/Rail/Manufacturing hängt Telemetrie oft an Lieferverträgen. Ohne explizite Datenrechte gerät die Roadmap ins Stocken.
Gegenmaßnahme: Data-Contracting frühzeitig, Rechte und Nutzungszwecke vertraglich absichern, Pseudonymisierungskonzepte vorlegen.

3) Label-Illusion
Bei visueller Prüfung ist 1% Label-Noise tödlich, bei NER in Wartungslogs erträglich. In Predictive Maintenance sind „Time-to-Failure“-Labels selten eindeutig.
Gegenmaßnahme: Label-Policies, Double-Labeling an kritischen Stellen, Weak Supervision bewusst und dokumentiert, Uncertainty-Aware-Modelle einsetzen.

4) Nichtfunktionale Anforderungen ignoriert

  • Latenz: 200 ms Budget im HMI vs. 5 s sind Welten.

  • Verfügbarkeit: OT-Systeme verlangen oft >99.9% und geordnete Degradiertheit ohne Internet.

  • Auditierbarkeit: Jede automatisch getroffene Entscheidung muss erklärbar und rückverfolgbar sein.

Gegenmaßnahme: NFRs als harte Anforderungen behandeln und früh testen.

5) Vendor-Lock-in in der Wissensinfrastruktur
Vektorspeicher, Embeddings und proprietäre Datenformate sind neue Silos.
Gegenmaßnahme: Offene Formate, Migrationspfade, Exporttests als Teil der CI.

Domänenbeispiele aus der Praxis

  • Manufacturing: Visuelle End-of-Line-Prüfung

Herausforderung: Klassenimbalance (seltene Fehler), wechselnde Lichtverhältnisse, Linienwechsel.
Architektur: Kontrollierter Bildaufnahmepfad, strikte Versionsverwaltung der Beleuchtung/Kameras, Label-Pipeline mit QA, On-Prem Training, inferenznahe Edge-Deployment mit GPU, Feedback-Loop für Fehlklassifikationen.
Metriken: False-Negative-Rate als harte Obergrenze, MTTR bei Modellrollback, Drift-Indikatoren bei Chargenwechsel.

  • Predictive Maintenance im Textil-/Prozessumfeld

Herausforderung: Sensor-Drift, Wartungen als Confounder, Multicausalität.
Architektur: CDC aus Wartungs-/Ersatzteil-Logs, Feature-Pipeline mit Lag-Features und Rolling-Stats, probabilistische Modelle neben Deep Learning, Explainability für Werkstattabnahme.
ROI-Hebel: Gezielte Ersatzteil-Dispo, reduzierte unplanmäßige Stillstände, aber nur, wenn False Alarms operativ verkraftbar sind.

  • Railway: Fleet Intelligence

Herausforderung: Edge-Konnektivität, Store-and-Forward, Flottenheterogenität.
Architektur: Bordseitige Vorverarbeitung, robuste Ingestion mit Quittungen, On-Prem Lakehouse, regel- und modellbasierte Anomaliedetektion, rollenbasierter Zugriff für Leitstelle/Wartung.
Souveränität: Datenresidenz national, klare Trennung Betriebsdaten vs. Personendaten.

  • Bauvermessung: Skalierbare Photogrammetrie

Herausforderung: Massendaten, deterministische Reproduzierbarkeit.
Architektur: GPU-Cluster On-Prem/EU-Cloud, deterministische Pipelines, Qualitätsmetriken (GSD, RMSE), versionierte Orthomosaike/3D-Modelle, Audit-Trails.

  • Defense: Air-Gapped Decision Support

Herausforderung: Kein Internet, strikte Audits, wiederholbare Builds.
Architektur: Reproducible Builds, signierte Modelle/Container, LLM-RAG auf klassifizierten Dokumenten, strikte Tool-Allowlisting, mensch-in-der-Schleife.

  • Aviation Training: EU-Cloud mit Datenminimierung

Herausforderung: Personenbezug, Protokolltransparenz.
Architektur: EU-Region-Deployments, Pseudonymisierung, feingranulare Consent-Modelle, getrennte Vektorräume pro Kunde.

Von POC zu Produktion: ein klarer Pfad

  • Definition of Done für POC

Repräsentative Datenabdeckung, definierte NFRs, erste Opex-Schätzung, Risikoanalyse (Rechtslage, Betrieb).

  • Technische Gates vor Produktion

Datenqualität: Alle kritischen Checks grün, Golden Dataset eingefroren.
Sicherheit: Threat Model, Secrets/KMS, Rollen-/Rechtekonzept, Penetrationstest soweit möglich.
Betrieb: Dashboards, Alerts, Runbooks, Rollback-Szenario, Ersatzbetrieb bei Modellausfall.
Validierung: Shadow- oder Canary-Phase, A/B-Tests mit echten Betriebsdaten, Akzeptanzkriterien erfüllt.

  • Kontinuierliche Verbesserung

Daten-/Modell-Lineage, regelmäßige Drift-Reviews, kontrollierte Re-Trainings, Post-Mortems bei Incidents.

Build vs. Buy unter Souveränitätsauflagen

  • Buy (SaaS/API), wenn:

Daten nicht sensibel, Latenz/Penetration ins OT-Netz zweitrangig, schnelle Time-to-Value wichtiger als tiefe Integration, Exit-Kosten akzeptabel.

  • Build/On-Prem, wenn:

Daten sensibel/reguliert, OT-Integration und Offline-Betrieb gefordert, LLM-RAG über proprietäre Dokumente mit ACLs, langfristige TCO durch stabile Workloads planbar.

  • Hybrid:

Nichtkritische Komponenten als Managed Service, kritische Pfade On-Prem. Wichtig: Saubere Abgrenzung und Fallbacks, falls externe Services ausfallen oder Verträge enden.

Organisation und Rollen

  • Data Product Owner: Verbindet Business-Outcome mit Datenverträgen.
  • Data Steward: Qualität, Katalog, Klassifizierung.
  • ML Engineer: Modelle, Featurization, Evaluation.
  • MLOps/Platform Engineer: CI/CD, Deployment, Observability, Security.
  • Domänenexpertinnen: Prozesswissen, Label-Definition, Akzeptanztests.
  • Security/Legal: DPIA, Datenschutz, Exportkontrolle, Policies.

Team-Topologie, die funktioniert: Stream-Aligned Teams je Domäne, unterstützt von einer Plattform- und einer Enablement-Funktion. RACI-Matrizen verhindern Lücken bei Ownership.

90–180–365-Tage-Roadmap (Beispiel)

  • 0–90 Tage

Business-Outcomes und NFRs definieren.
Dateninventur und Rechteklärung.
Pilot-Datenprodukt und Qualitätschecks als Code.
Minimaler On-Prem-Stack: Orchestrierung, Artefakte, Observability.
POC mit produktionsnahen Daten, Akzeptanzmetriken.

  • 90–180 Tage

Datenprodukte erweitern, CDC/Event-Streaming produktionsreif.
Security-Härtung: KMS, Secrets, Segmentierung, Audits.
MLOps-End-to-End: Train → Register → Deploy → Monitor → Re-Train.
LLM-RAG-Prototyp mit ACL-Respekt, Observability für Retrieval/Antworten.
Shadow-/Canary-Deployments, Runbooks, SRE-Playbooks.

  • 180–365 Tage

Produktionsfreigabe für 1–2 wertstiftende Use Cases.
Skalierung auf zusätzliche Domänen, Wiederverwendbarkeit der Bausteine.
KPI-Review und ROI-Tracking, Lessons Learned institutionalisiert.
Plan für Hardware-Kapazitäten (GPU/CPU/NPU), Lifecycle-Management.

Konkrete technische Entscheidungen, die wir in Souveränitätsprojekten häufig treffen

  • Vektorspeicher on-prem statt SaaS, weil Zugriffskontrollen, Datenresidenz und Exportpfade kontrollierbar bleiben.
  • RAG vor Fine-Tuning bei sensiblen Dokumenten, um Trainingsdaten-Leakage zu vermeiden und Wissensstände versionierbar zu halten.
  • Quantisierte Open-Weight-Modelle für Inferenz im Werk, wenn Latenz/Cost-Budgets eng sind; für komplexe Aufgaben Hybrid mit stärkeren Modellen in EU-Clouds ohne US-Rechtsrisiko.
  • Feature Store mit Online/Offline-Parität, um Serving-Skews zu vermeiden.
  • Agent-Observability und Governance als Pflicht, nicht Nice-to-have: Traces, Tool-Calls, Policy-Hits, Token-/Zeit-Budgets, Audit-Trails.

Warum „Datenstrategie vor KI-Strategie“?