• Rechtsgrundlage und Zweckbindung: Jedes Dataset im Katalog trägt seine Rechtsgrundlage (z. B. Vertrag, berechtigtes Interesse, Einwilligung) und den Zweck. Pipelines prüfen zur Laufzeit, ob ein geplanter Verarbeitungsschritt diese Kombination erlaubt.
  • Datenminimierung und Privacy by Design: Standardpfad anonymisiert/pseudonymisiert früh im ETL. Freitextfelder werden vor Indexierung tokenisiert/klassifiziert und – falls nicht nötig – verworfen. Bild- oder Videoverarbeitung entfernt identifizierende Bereiche, die für den Use-Case irrelevant sind.
  • Pseudonymisierung vs Anonymisierung: Pseudonymisierte Daten bleiben personenbezogen. Daraus folgt: strenge Zugriffskontrollen, separate Schlüssel, keine unkontrollierte Weitergabe. Anonymisierte Daten dürfen keine Re-Identifikation mehr ermöglichen; bei technischen Datasets ist das selten wirklich nötig und schwer zu garantieren – also vorsichtig damit werben.
  • Betroffenenrechte: Auskunft, Berichtigung, Löschung. Technisch heißt das: Detaillierte Lineage, gezielte Löschmarkierung und Neuberechnung abgeleiteter Artefakte. Für Modelle praktisch: Re-Training aus einem Datasetsnapshot, der den Datensatz nicht enthält. Dafür braucht es:
  • Versionierte Trainingsdaten
  • Reproduzierbare Trainings-Jobs
  • Sharding/Chunking, um selektiv zu ersetzen statt „alles“ neu zu rechnen, wo möglich
  • Schlüsseltrennung und -rotation: Schlüssel nie mit Daten gemeinsam speichern; Rotation testen wie Releases; Notfallszenarien regelmäßig üben.

On-Prem GPU-Cluster vs. Cloud-Training: Entscheidung mit klaren Kriterien

On-Prem ist nicht „romantisch“, sondern oft zwingend:

  • Daten dürfen rechtlich das Haus nicht verlassen (z. B. Produktionsdaten, Verteidigung, Fahrgastdaten).

  • Deterministische Latenz, Exfiltrationsschutz und physische Kontrolle sind Anforderungen.

  • Stabile, vorhersehbare Workloads mit hoher Auslastung machen CapEx wirtschaftlich.

Cloud kann sinnvoll sein, wenn:

  • Kurzfristige Spike-Lasten auftreten, die sich wirtschaftlich nicht on-premisieren lassen.

  • Nur synthetische oder vollständig anonymisierte Daten verwendet werden.

  • Zusätzliche Maßnahmen greifen: privater Netzwerkpfad, striktes Logging, Verschlüsselung, klarer Vertrag zur Unterauftragsvergabe.

Technische Überlegungen für On-Prem-Training:

  • Scheduler und Quotas: Jobs bekommen feste GPU-Kontingente; Preemption für hohe Prioritäten.

  • Sharing: GPU-Partitionierung (wo verfügbar) für Inferenz/Training parallel.

  • Storage: Lokaler NVMe-Cache pro Node für IO-lastiges Training, plus dedizierter Durchsatz vom Objektspeicher.

  • Energie/Kühlung/Platz: Früh in die Kapazitätsplanung. Monitoring bis zur Stromschiene hilft, böse Überraschungen zu vermeiden.

  • Desaster-Recovery: Geografisch getrennte, verschlüsselte Backups im eigenen Besitz. Regelmäßig Wiederherstellungen testen.

Data Lake vs. Data Mesh vs. Data Warehouse: Was taugt wofür?

  • Data Warehouse: Stark für standardisierte, strukturierte BI-Analysen mit stabilen Schemas. Für explorative ML/LLM und vielfältige unstrukturierte Daten schnell zu eng oder teuer, wenn man alles hineinpresst.
  • Data Lake: Flexibel für Rohdaten, unstrukturierte Daten, schnelle Iteration. Ohne ACID-Tabellenformate und Governance aber ein Minenfeld.
  • Lakehouse: ACID-Tabellen auf dem Lake vereinen Flexibilität und Strukturiertheit – ideal als Kern für ML/LLM, Streaming und auch BI.
  • Data Mesh: Organisationsprinzip – Domänen verantworten „Data Products“ mit klaren SLAs und Schnittstellen. Funktioniert nur, wenn die Plattform (Lakehouse + Governance + Self-Service) zuerst steht. Sonst skaliert man Chaos.

Für Industrieumgebungen bewährt sich:

  • Lakehouse als technische Basis (ACID, Time-Travel, Versionierung).

  • Domänenorientierte Data Products auf dieser Basis (z. B. Fertigung, Qualität, Flotte, Instandhaltung).

  • Zentrale Governance und Policy-Engine, dezentrale Verantwortung für Datenqualität und -produktivität.

  • Vermeidung von Kopien: Eine Version, mehrere Sichten (raw/curated/feature) und Rollenrechte.

LLM unter Souveränitätsanforderungen: die zusätzlichen Stolpersteine

  • Prompt-Daten sind oft personenbezogen: Support-Tickets, Wartungsprotokolle, interne Memos. Sie gehören nicht in US-APIs. Entweder on-prem LLM oder ein klar vertraglich gesicherter EU-Anbieter – und selbst dann: Egress standardmäßig sperren.
  • RAG statt unnötigem Fine-Tuning: Unternehmenswissen per Retrieval einbinden, nicht ins Modell „einbacken“. So bleibt Wissen versionierbar, widerrufbar und zweckgebunden.
  • Embeddings und Indizes: Keine PII in Embeddings, wenn möglich. Trennung nach Mandant und Zweck. Verschlüsselung at rest. Regelmäßige Rebuilds, wenn Löschanfragen eintreffen.
  • Halluzination und Haftung: Output-Filter, Quellenzitierung bei RAG, Confidence-Signale. Mensch-in-der-Schleife für kritische Entscheidungen.
  • Observability und Governance für LLM: Prompt- und Antwort-Telemetrie, Blocklisten, PII-Scanner, Policy-Hooks vor und nach Inferenz, Retention-Policies. Ohne das ist jede LLM-Einführung blind.

Pragmatischer 90-Tage-Plan

Tage 0–30: Bestandsaufnahme und sichere Basis

  • Dateninventur: Quellen, Schemata, Sensitivität, Rechtsgrundlagen, heutige Kopien.

  • Minimal-Plattform: Kubernetes, Objektspeicher, KMS, Secrets, zentrale AuthN/AuthZ.

  • Tabellenformat und Katalog etablieren; Data Contracts für die Top-3-Quellen definieren.

  • DLP-Pipeline: PII-Erkennung und Pseudonymisierung in den Ingestion-Flow integrieren.

Tage 30–60: Produktive MLOps-Grundlagen

  • Orchestrator, Metadaten-Store, Registry, Dataset-Versionierung aufsetzen.

  • Policy as Code: ABAC mit Zweckbindung und erste Zugriffspfade in Produktion.

  • GPU-Knoten integrieren; Trainings-Container und Reproduzierbarkeit sicherstellen.

  • Observability: Data- und Model-Metriken, Audit-Logs, Governance-Events.

Tage 60–90: Erster End-to-End-Use-Case unter Governance

  • Beispiel 1 (klassisch): Visuelle Qualitätsprüfung mit versionierten Datasets; Training und Serving in getrennten Zonen; Governance-Gate vor Go-Live.

  • Beispiel 2 (LLM/RAG): Wartungsleitfäden als kuratierte Wissensbasis; Embeddings ohne PII; on-prem Vector-DB; Prompt-Logging mit Redaktionen; Egress=aus.

  • Betroffenenrechte testen: synthetische Löschanfrage durch die Pipeline inkl. Re-Training aus Snapshot.

  • Review: Lessons Learned dokumentieren, Policies nachschärfen, Skalierung auf weitere Domänen planen.

Häufige Fallstricke und wie man sie vermeidet

  • „Wir anonymisieren später“: Später kommt nie. Pseudonymisierung gehört in die erste Meile der Pipeline.
  • „Wir brauchen sofort Mesh“: Ohne stabile Lakehouse-Plattform und Governance wird Mesh zu verteiltem Wildwuchs.
  • „Cloud für alles, On-Prem ist tot“: Für sensible Industrie-Workloads oft schlicht falsch. Souveränität ist kein Stimmungsbild, sondern eine Anforderung.
  • „Modellebene reicht für Löschanfragen“: Ohne Datenversionierung und reproduzierbares Training ist „Löschen aus dem Modell“ eine leere Aussage.

Fazit