Vorteil: Maximale Kontrolle. Nachteil: Höherer Betriebsaufwand, längere Lead-Zeiten für Updates.

3.2 Verbunden, aber souverän

  • Für Szenarien, in denen Nicht-PII-Workloads oder rechenintensives Experimentieren in europäischen Cloud-Regionen sinnvoll ist.
  • Egress-Kontrolle
  • Datenklassifizierung im Katalog: Nur „Green-Lane-Daten“ (synthetisch, PII-frei, aggregiert) dürfen zur Cloud.
  • Entkopplung über Message Broker/Export-Services mit eingebauter Maskierung.
  • Hybrid-Workload-Zuteilung
  • On-prem: Inferenz in der Produktion, PII-Verarbeitung, Langzeitarchiv, RAG mit internen Dokumenten.
  • Cloud: Kurzlebiges Experimentieren, Hyperparameter-Search auf anonymisierten Datasets oder synthetischen Daten.

Vorteil: Flexibilität und schnelle Iteration. Nachteil: Höhere Governance-Komplexität; klare Beweisführung erforderlich, dass keine verbotenen Daten ausgeleitet wurden.

4) DSGVO in Architektur übersetzen: Konkrete Patterns

  • Datenminimierung (Art. 5)
  • Default-Ingestion extrahiert nur benötigte Felder; PII-Defaults sind „opt-out“, nicht „opt-in“.
  • Retention Policies auf Bucket-Ebene (z. B. 90 Tage für Rohdaten, 2 Jahre für Trainingsdaten mit Compliance-Begründung).
  • Privacy by Design/Default (Art. 25)
  • Pseudonymisierung im ersten Schritt der Pipeline; menschliche Reviewer sehen nur Pseudonyme.
  • „Least Privilege“ erzwingen: Entwickler sehen keine Klartext-PII, es sei denn, genehmigt und protokolliert.
  • Sicherheit der Verarbeitung (Art. 32)
  • Ruhende Verschlüsselung (dm-crypt, LUKS auf Worker-Nodes; S3-SSE mit KMS/HSM-Schlüsseln).
  • Transportverschlüsselung mit mTLS und Hardware-Roots of Trust, wo verfügbar.
  • Härtung: SELinux/AppArmor, regelmäßige CIS-Benchmarks, eBPF-basierte Netzwerk- und Prozessüberwachung.
  • Auskunfts- und Löschrechte
  • Personbezug über Token Service auflösbar; Deletion Request propagiert bis in Feature Store, Offline-Store, Artefakte, Vektorindizes.
  • Dokumentierte „Machine Unlearning“-Strategien: Retraining auf Snapshots ohne gelöschte Subjekte; bei LLM-RAG: Entfernung aus dem Index plus Cache-Invalidierung.
  • DPIA und Nachweisführung
  • Jede Pipeline hat maschinenlesbare Datenverarbeitungsregister-Einträge (Owner, Zweck, Rechtsgrundlage, Kategorien).
  • Lineage + WORM-Logs liefern Audit-Trail; Dashboards verdichten pro Modell und Version die verwendeten Datenschnitte.

5) Generative KI on-prem: RAG, Feintuning, Governance

Wenn interne Dokumentation, Instandhaltungshandbücher oder Ticket-Daten genutzt werden, ist RAG meist der pragmatische erste Schritt.

  • RAG-Architektur on-prem
  • Dokument-Pipeline: Parsen (z. B. Tika), Chunking, PII-Maskierung, semantische Tags.
  • Vektorstore: pgvector, Qdrant oder Milvus on-prem; Indexe versionieren und pro Datenklassifikation separieren.
  • Embeddings: lokale Modelle (bge, e5) mit quantisierten Varianten für Inferenzgeschwindigkeit auf Edge-GPUs/CPUs.
  • LLM: Lokal laufend (Llama- oder Mistral-Familie) mit Policy-Adapter (z. B. Guardrails) und sichere Prompt-Templates.
  • Feintuning vs. rein promptbasiert
  • Feintuning erhöht Domänenkompetenz, erhöht aber Compliance-Komplexität (Trainingsdaten müssen sauber und nachweisbar sein).
  • Für viele Industriefälle genügt Adapter-Tuning (LoRA) auf synthetischen/entpersonalisierten Daten, kombiniert mit starkem RAG.
  • Governance/Observability für LLM-Agents
  • Prompt/Response-Logging mit PII-Redaktion vor Persistierung.
  • Policy-Prüfungen: Keine Weitergabe klassifizierter Inhalte, kein externer Call ohne Freigabe. Rollback bei Policy-Verstoß.
  • Metriken: Retrieval-Hitrate, Halluzinationsrate via evals, PII-Leak-Checks; Drift im Dokumentenkorpus wird getrackt.

6) Edge und Flotte: KI am Rand des Netzes

In Werkshallen, Zügen oder Baustellen-Setups ist Edge-Inferenz Standard. Wichtige Bausteine:

  • Hardware
  • Industrielle Rechner mit GPU/TPU je nach Modell; planbare Energie- und Kühlkonzepte.
  • Remote Attestation (TPM), Signaturprüfung vor Start; Over-the-Air-Updates mit TUF/Uptane-ähnlichen Mechanismen.
  • Update- und Rollout-Strategie
  • Staged Rollouts (1%, 10%, 50%), Health Checks, automatisches Rollback bei Qualitätsminderung.
  • Synchronisationsfenster, wenn Konnektivität vorhanden; sonst Store-and-Forward.
  • Telemetrie
  • Minimal und PII-frei; Metriken/Logs in verdichteter Form. Rohdaten bleiben lokal, es sei denn, es gibt eine genehmigte Fehlersammelphase.

7) Betrieb und Kosten: Realistische Trade-offs

  • On-prem GPU-Cluster
  • CAPEX-lastig, aber OPEX-predictable. Ab ~60–70% Auslastung über 24 Monate rechnet es sich gegenüber On-Demand-Cloud oft – vorausgesetzt gute Kapazitätsplanung.
  • Scheduling: Topologie-bewusste Zuweisung, MIG für Multi-Tenant, Preemption für lange Trainings vs. latenzkritische Inferenz.
  • Team und Prozesse
  • Plattformteam (5–8 Personen) betreibt K8s, Storage, CI/CD, Security. Domänenteams bauen Datenprodukte/Modelle darauf.
  • Incident-Response mit Playbooks: Datenvorfall, Model Drift, Qualitätsabfall, Security-Event.
  • Data Mesh vs. Lakehouse
  • Kleine/mittlere Organisationen fahren besser mit einem stark governeden Lakehouse plus klaren Domänenverantwortlichkeiten.
  • Data Mesh lohnt sich erst, wenn mehrere Domänenteams dauerhaft Datenprodukte mit eigenen Pipelines liefern können und ein reifes Plattformangebot existiert (Self-Service mit Guardrails).

8) Minimal Viable Governance: In 12 Wochen zur auditierbaren Basis

Wenn Sie starten, brauchen Sie nicht alles perfekt. Aber diese Minimalmenge muss stehen:

  • Daten
  • S3-kompatibler Objektspeicher, Lakehouse-Format (Iceberg/Delta), Katalog mit Klassifikation, erste DQ-Tests.
  • Compute
  • K8s-Cluster, Argo/Airflow, MLflow Registry, Seldon/KServe, Feast als Feature Store.
  • Sicherheit
  • Keycloak, Vault, OPA/Gatekeeper, signierte Container, interne Registry, mTLS.
  • Observability
  • Prometheus/Grafana, WORM-Audit-Logs, OpenLineage, Drift/Quality-Monitoring.
  • Prozesse
  • DPIA-Template, Change-Management für Daten/Modelle, Löschprozess bis in Indizes/Artefakte, Onboarding-Policy für neue Datensourcen.

Mit dieser Basis können Sie ein erstes Modell DSGVO-fähig trainieren, deployen und überwachen – und Auditoren zeigen, wo welche Daten geflossen sind.

9) Häufige Fehler und wie man sie vermeidet