3) Technische Dokumente und LLM-gestützte Fehlersuche (Aviation/MRO)

  • Ingestion:

  • Dokumente (PDF, XML, SGML, S1000D) → Parser → PII/Geheimnisscan → Chunking → Embeddings on-prem (bfloat16-fähige GPUs).

  • Speicherung:

  • Vektorindex on-prem (pgvector, Weaviate self-hosted oder Milvus), Knowledge-Source-Mapping im Katalog.

  • Prompt-/Context-Provenance und Agent-Logs für Audit und Reproduzierbarkeit.

  • Betrieb:

  • Evaluationssuiten mit synthetischen und realen Aufgaben, Guardrails (Policy-Checks), Offline- und Online-Feedbackschleifen.

  • Souveränität:

  • Kein Abfluss in US-APIs, Modellartefakte und Logs vollständig in lokaler Kontrolle.

Datensouveränität ist eine Architekturanforderung, keine Compliance-Fußnote

  • Schrems-II-Realität: Außerhalb der EU (und teils auch bei EU-Tochtergesellschaften US-amerikanischer Cloud-Anbieter) bestehen Rechtszugriffsrisiken. Konsequenz: On-Premise oder EU-rechtskonforme, kontrollierte Infrastruktur ohne US Cloud Act-Risiko für sensible Datenpfade.
  • Minimierung und Zweckbindung: Pseudonymisierung/Tokenisierung möglichst am Ingestion-Rand. Für Diagnosezwecke selektive Re-Identifikation via kontrolliertem Data Access Workflow.
  • Schlüsselmanagement:
  • Vault als zentrales KMS, idealerweise HSM-gestützt.
  • Envelope Encryption für S3-Objekte (SSE-KMS), getrennte Tenants/Keys.
  • Netzwerk und Betrieb:
  • Segmentierung (Prod/Dev/Test), mTLS durchgängig, Bastion-Hosts, Paket-Repository-Spiegel für Air-Gap.
  • Immutable Audit-Logs (WORM/Object Lock), Hash-Chaining für Lineage-Artefakte.
  • Datenverträge und Audits:
  • Data Contracts als Code (Schemas, Allowed Values, SLAs, Semantik).
  • Automatisierte Tests im CI für Schemakompatibilität (Backward/Forward), PII-Scanner in der Pipeline.

MLOps, aber für Industrie

  • Reproduzierbarkeit:
  • Datenversionierung über Iceberg-Snapshots und Content-Hashes; Trainingsmanifeste pinnen Daten, Code, Container-Digest, Feature-Definitions, Hardwareprofil (GPU-Typ, Treiber, CUDA).
  • Orchestrierung:
  • Argo Workflows/Kubeflow oder Prefect/Airflow. Für Air-Gap: lokale Container-Registry mit Spiegelung, signierte Images (Cosign), Policy-Enforcement (OPA Gatekeeper).
  • Deployment:
  • On-Prem K8s, GPU-Scheduling (NVIDIA Operator, MIG für A100/H100), Alternativ/zusätzlich Slurm für Batch-Training.
  • Canary und Shadow Deployments in Fertigungslinien mit Fallback auf „letzte gute Version“.
  • Monitoring:
  • OpenTelemetry für Inferenz-Latenz, Durchsatz, Fehlerquoten.
  • Daten- und Konzeptdrift, automatisch generierte Alarme und Retraining-Tickets.
  • Ground-Truth-Feedbackschleifen (z. B. Bedienereingaben, manuelle Prüfungen).

On-Prem GPU-Cluster vs. Cloud-Training

Wann On-Prem die richtige Wahl ist:

  • Datensensitivität/Air-Gap: Rohdaten verlassen das Werk nicht.

  • Stetige Auslastung: Kontinuierliches Training/Feintuning rechtfertigt CapEx (3–5 Jahre Amortisation).

  • Deterministische Latenz/Verfügbarkeit im Werk, keine Abhängigkeit von WAN.

  • Integration mit existierender HPC/CAE-Infrastruktur und Facility-optimierter Kühlung/Energie.

Was On-Prem erfordert:

  • Kapazitätsplanung (GPU-Generationen, VRAM, NVLink/PCIe-Topologien).

  • Betriebskompetenz: Treiber, Container-Stacks, Firmware, Thermik.

  • Cluster-Software: Kubernetes oder Slurm, Job-Queues, Fair Share, Quotas.

  • Energie- und Kühlkonzept, Monitoring auf Rack-Ebene.

Wann Cloud sinnvoll sein kann:

  • Burst-Lasten, Experimentierphasen, Pretraining von Foundation-Komponenten mit unsensiblen Daten.

  • Vorsicht bei Datentransfer: Entweder synthetische/entpersonalisierte Daten oder „Compute zum Datenspeicher bringen“ (Dedicated Hosted Hardware beim Kundenstandort oder europäische Anbieter ohne US-Rechtszugriff, sofern nachweisbar).

  • TCO-Check: GPU-Stundenpreise vs. Amortisation On-Prem inklusive Personalkosten und Auslastung. Faustregel: Ab >50–60% Dauerlast tendiert On-Prem zu günstiger, sofern Kompetenzen vorhanden sind.

Ein belastbarer Startplan für ein mittelgroßes Werk

Schritt 1: Ereignis- und Speicherrückgrat

  • Event-Backbone: Kafka/Redpanda (On-Prem), Schema Registry (Avro/Protobuf), Policies für Retention und Replays.

  • Objekt-Storage: MinIO mit Erasure Coding, WORM für Audit-Daten, S3-APIs als Standard.

  • Katalog: DataHub/OpenMetadata, Source-zu-Model-Lineage als Muss.

Schritt 2: Lakehouse scharf schalten

  • Tabellenformat: Apache Iceberg (wegen agnostischer Engine-Support, Partitionsevolution, Snapshot-Isolation).

  • Engines: Trino für interaktive SQL, Spark/Flink für Batch/Streaming.

  • Standards: Partitionsstrategie, Dateigrößen (128–512 MB), Compaction-Policies, Z-Order/Sort Keys wo sinnvoll.

Schritt 3: Sicherheitsbaseline

  • Identität: Keycloak, zentrale Gruppen/Rollen, Service-Account-Management.

  • Autorisierung: OPA/Ranger-Policies (Row/Column-Level), Secrets in Vault, mTLS überall.

  • Netzwerk: Segmentierung, egress durch kontrollierte Proxys, Paketmirror.

Schritt 4: Observability by default

  • OpenTelemetry für Logs/Tracing/Metriken, Prometheus/Grafana, Alerting-Playbooks.

  • Datenqualitätschecks in der Pipeline, Metriken in den Katalog rückspielen.

Schritt 5: MLOps-Toolchain

  • Orchestrierung: Argo Workflows oder Prefect, Model-Registry mit MLflow.

  • Feature Store: Feast für wiederverwendbare Features in Online/Offline-Speichern.

  • CI/CD: GitOps (Argo CD), Policies im Build (PII-Scan, Schema-Checks).

Schritt 6: Governance und Verträge

  • Data Contracts pro Datenprodukt (Schema + Semantik + Latenz/Verfügbarkeit).

  • Change-Management: Semver für Schemas, Kompatibilitätsprüfung in CI.

  • Freigabeprozesse für produktionskritische Modelle.

Schritt 7: Richtung Mesh skalieren

  • Erst wenn 3+ Domänen zuverlässig Datenprodukte liefern, Ownership formal dezentralisieren.

  • Gemeinsame Plattform bleibt: Katalog, Security, Pipelines, Self-Service-Interfaces.

Häufige Fehlannahmen und wie man sie vermeidet

  • „Wir starten mit Data Mesh.“ Ohne tragfähiges Lakehouse und Plattformteam produziert man nur Koordinationslast. Starten Sie mit einem starken, wohldefinierten Lakehouse und klaren Datenprodukten.
  • „Cloud-first löst alles.“ Für DSGVO-sensible Industriepfade ist das Gegenteil oft richtig. Prüfen Sie Jurisdiktion, Datentransfer und technische Kontrollmöglichkeiten. Hybride Ansätze sind möglich, aber Datenhoheit ist nicht verhandelbar.
  • „Warehouse reicht, der Rest ist Hype.“ Für ML, Bilder und schnelle Iteration ist ein Warehouse allein zu eng. Nutzen Sie es gezielt für BI und Compliance-Reporting, nicht als ML-Speicher.
  • „Wir speichern nur Features, Rohdaten brauchen wir nicht.“ Ohne versionierte Rohdaten ist Reproduzierbarkeit futsch und Root-Cause-Analysen werden unmöglich. Rohdaten mit klaren Retentions und Souveränitätspolicies speichern.
  • „ACID-Tabellen sind Magie, den Rest ignorieren wir.“ Ohne Compaction, Partitionpflege und kleine-Dateien-Management kollabiert Performance. Betriebsdisziplin ist entscheidend.

Messbare Ergebnisse statt Folien