Titel: Datensouveränität in der Industrie: Wie man eine DSGVO-konforme KI-Infrastruktur baut, die auch in 5 Jahren noch tragfähig ist

Die meisten Gespräche über „KI in der Industrie“ drehen sich um Modelle und Metriken. In der Praxis scheitert der Großteil der Projekte deutlich früher: an einer fehlenden, souveränen Daten- und KI-Infrastruktur. Wenn Produktionsdaten, Wartungsprotokolle, CAD-Zeichnungen, Zuliefererinformationen und personenbezogene Daten (Schichtpläne, Trainingsdaten mit Audio/Video etc.) zusammenkommen, stehen Sie vor einem Infrastrukturproblem – nicht vor einem Modellproblem.

Dieser Beitrag beschreibt, wie eine DSGVO-konforme, on-premise-fähige KI-Plattform für industrielle Umgebungen aufgebaut wird. Der Fokus liegt auf konkreten Architekturmustern, Trade-offs und Komponenten, die in hochregulierten Branchen funktionieren. Das ist kein Plädoyer gegen die Cloud, sondern für Souveränität: Sie entscheiden, welche Workloads wo laufen, und behalten zu jeder Zeit Hoheit über Datenflüsse, Modelle und Logs.

1) Anforderungen aus der Realität: Was muss die Plattform leisten?

Starten wir nicht bei Tools, sondern bei Anforderungen, die wir in Defense, Bahn, Fertigung und Bau immer wieder sehen.

  • Datenschutz und DSGVO-Compliance
  • Datenminimierung (Art. 5 DSGVO), Privacy by Design/Default (Art. 25), Sicherheit der Verarbeitung (Art. 32).
  • Rechtmäßigkeit/Vertragliche Grundlagen (Art. 6), Auftragsverarbeitung (Art. 28), Verarbeitungsverzeichnis (Art. 30), DPIA (Art. 35).
  • Nachweisbarkeit: Wer hat wann worauf zugegriffen? Welche Daten flossen in welches Training? Wie setze ich Löschanfragen durch?
  • Souveränität und Lieferkettenrisiko
  • Keine Abhängigkeit von US-Clouds, kontrollierte Ausleitung von Daten, klare Datenlokalität.
  • Reproduzierbarkeit: Build-, Trainings- und Deploy-Pfade müssen deterministisch nachvollziehbar sein.
  • Betriebsbedingungen industrieller IT
  • Edge-Standorte mit intermittierender Konnektivität, Luftspalt-Umgebungen, heterogene Sensorik.
  • Längere Wartungszyklen, zertifizierte Softwarestände, kontrollierte Updates.
  • KI-spezifische Anforderungen
  • MLOps-Ende-zu-Ende: Datenaufnahme, Labeling, Feature Pipeline, Training, Evaluation, Deployment, Monitoring, Retraining.
  • Für Generative KI: RAG (Retrieval-Augmented Generation) mit sensiblen Dokumenten, LLM-Governance (Prompt/Output-Logging, Policy Enforcement, Halluzinationsschutz).

Die Architektur muss diese Punkte nicht nur „irgendwie“ erfüllen, sondern so, dass Auditoren in zwei Jahren immer noch nachvollziehen können, warum ein bestimmtes Modell im Januar 2026 eine Entscheidung X getroffen hat.

2) Referenzarchitektur: Souveräne KI-Plattform on-premise

Im Kern brauchen Sie drei Schichten: Datenebene, Orchestrierung/Compute, Governance/Observability. Ergänzt durch sichere Netz- und Identitätsdienste.

2.1 Datenebene (Lakehouse, Katalog, Lineage, Qualität)

  • Speicher
  • Objektspeicher mit S3-API on-prem: MinIO oder Ceph RGW für skalierbare, kosteneffiziente Datenhaltung.
  • Block/File je nach Workload: Ceph RBD, ZFS, NetApp; für Low-latency Features ggf. NVMe-Tiers.
  • Datenformate und ACID
  • Lakehouse-Parquet mit Iceberg oder Delta Lake für Schema-Evolution, Time Travel, ACID-Transaktionen. Warum? Auditierbarkeit. Sie können den exakten Datenstand eines Trainings reproduzieren.
  • Katalog und Lineage
  • Data Catalog (z. B. OpenMetadata oder Amundsen) als zentrale Quelle für Schemas, Ownership, DSGVO-Klassifikation.
  • Lineage via OpenLineage/Marquez; jedes Pipeline-Run erfasst: Quelle → Transformation → Ziel, inklusive Commit-IDs und Container-Digests.
  • Datenqualität
  • Assertions/Tests mit Great Expectations oder Soda. Ergebnisse als Artefakte versionieren; nur „grüne“ Datenschnitte dürfen in Trainingsjobs.
  • PII-Handling
  • Pseudonymisierung/Tokenisierung in Ingestion-Pipelines (z. B. Hash+Salt für IDs; reversible Token in HSM-gestütztem Vault).
  • PII-Scanner (regelbasiert + ML) mit Quarantänepfad. Klassifikation als Tag im Katalog, erzwingbar via Policy.

2.2 Orchestrierung und Compute (Kubernetes/Slurm, Airflow/Argo, Feature Store)

  • Container-Orchestrierung
  • Kubernetes on-prem (RKE2, OpenShift oder Upstream K8s mit Cilium) für Inferenz und Pipeline-Orchestrierung.
  • Für Heavy Training optional Slurm-Cluster; Interconnect via RoCEv2, NVLink-Topologie beachten.
  • Workflow-Orchestrierung
  • Argo Workflows oder Apache Airflow; Air-gapped-Varianten sind verfügbar.
  • Pipelines definieren Artefaktflüsse explizit (DVC/MLflow Artifacts), damit Reproduzierbarkeit gewährleistet ist.
  • Feature Store
  • Feast on-prem (Postgres/Redis) als Quell der Wahrheit für Features, mit Offline/Online-Store-Trennung. Versionierung von Feature-Views.
  • Model Registry und Serving
  • MLflow Model Registry, Seldon Core oder KServe für Inferenz-Deployments. Canary/Blue-Green auch on-prem möglich.
  • LLM-Serving: vLLM oder TensorRT-LLM mit MIG-Partitionierung auf A100/H100 für Mandantenfähigkeit.

2.3 Governance, Sicherheit, Observability

  • Identity & Access Management
  • Keycloak für SSO/OIDC, Attribute-based Access Control (ABAC) mit Gruppen/Rollen und Datenklassifikations-Tags.
  • Kurzlebige, signierte Tokens (mTLS zwischen Diensten); Secrets in HashiCorp Vault, Keys in HSM/CloudHSM-Äquivalent on-prem.
  • Policy as Code
  • OPA/Gatekeeper erzwingt: keine Pulls aus dem Internet, signierte Container (Sigstore Cosign), kein Privileged-Mode, Netzwerk-Policies mandatory.
  • Data Policies: „PII darf Rechenzone X nicht verlassen“, erzwungen über Gateways und Data Egress Controller.
  • Observability
  • Prometheus + Grafana; für Daten/Modelle zusätzlich: Data Drift/Concept Drift via Evidently/Alibi Detect.
  • Immutable Audit Logs (WORM-Buckets im Objektspeicher), korreliert mit IAM-Events.
  • Supply-Chain-Sicherheit
  • SBOMs (Syft), Scans (Grype/Trivy), signierte Builds, Reproducible Builds wo möglich. Interne Container-Registry mit Admission-Kontrollen.

2.4 Netzwerktopologie

  • Zero-Trust-Grundsätze: Jede Kommunikation ist mTLS, identitätsgebunden, minimaler Scope.
  • Air-gapped-Fähigkeit: Update-Pipeline via signierte Offline-Medien; Outbound-Proxy mit Data-Diode-Charakter für reine Telemetrie, wo gefordert.
  • Segmentierung: Datenzonen (PII-Zone, Engineering-Zone, Sandbox). Policies verhindern „Daten-Creep“ zwischen Zonen.

3) Zwei Betriebsmodi: Air-Gapped vs. Connected Souverän

3.1 Strikt air-gapped

  • Nutzung, wenn Verteidigung/Geheimschutz oder Zulieferauflagen es erzwingen.
  • Artefaktfluss
  • Externe Komponenten (Open-Source, Firmware) kommen nur über einen geprüften Importpfad mit SBOM, Signaturprüfung, Virenscan.
  • Datenflüsse sind intern; Export nur über Freigabeprozesse und irreversible Pseudonymisierung/Anonymisierung.
  • MLOps
  • GitLab Self-Managed, MLflow, Argo, Seldon – alles offline-betriebsfähig.
  • Pre-built Embeddings/LLMs nur, wenn Lizenz und Sicherheitsprüfung bestanden sind; ideal: lokal trainierte/feinjustierte Modelle.