• „Wir nehmen erstmal Cloud-Tools, On-prem kommt später“: Danach ist die Architektur voller Annahmen (Public SaaS für Registry, externe Feature Stores), die on-prem nicht replizierbar sind. Bauen Sie von Tag 1 portable Pfade.
  • Fehlende Datenklassifikation: Ohne klare Labels landet PII irgendwann im Experiment-Bucket. Automatisieren Sie die Klassifikation und blockieren Sie Egress bei Unsicherheit (default deny).
  • Lineage vergessen: Ohne maschinenlesbare Lineage bleibt jede Audit diskussionsbasiert. Erzwingen Sie Lineage-Emission in jeder Pipeline.
  • „LLM macht das schon“: Generative KI ohne RAG-Governance, Prompt/Output-Filter und Logging ist ein Compliance-Risiko. Starten Sie klein, mit dokumentiertem Policy-Set.
  • Edge-Updates unsicher: OTA ohne Signatur/Attestation führt zu Supply-Chain-Risiken. Setzen Sie TUF/Uptane-Prinzipien um.

10) Fazit

Souveräne, DSGVO-konforme KI ist kein Widerspruch zu Geschwindigkeit – wenn die Architektur stimmt. Die entscheidenden Hebel sind Reproduzierbarkeit (Lakehouse + Lineage), Durchsetzung (Policy as Code, IAM), Portabilität (on-prem-first Tooling) und messbare Qualität (DQ/Drift/Observability). Die Technologie ist verfügbar, die Herausforderung liegt in Disziplin und Ownership.

Wenn Sie die oben skizzierten Bausteine implementieren, können Sie sowohl klassische ML-Fälle (Anomalieerkennung, Prädiktive Wartung) als auch Generative KI (RAG auf internen Dokumenten, agentische Workflows) betreiben – ohne Souveränität aufzugeben.

FAQ

Frage 1: Ist on-premise heute wirklich noch sinnvoll, oder bremst es nur?
Antwort: In regulierten Industrien ist on-prem oft die einzige Möglichkeit, personenbezogene oder schutzwürdige Betriebsdaten souverän zu verarbeiten. Sie bremsen sich nur aus, wenn Sie Cloud-native Annahmen kopieren, die on-prem nicht funktionieren (z. B. Abhängigkeit von Public SaaS). Mit einem portablen Stack (K8s, S3, MLflow, Feast, Seldon/KServe, Argo/Airflow) sind Sie schnell und auditierbar.

Frage 2: Wie aufwendig ist „Löschen“ in ML-Systemen wirklich?
Antwort: Löschung ist mehrstufig: Rohdaten, Features, Trainingssnapshots, Artefakte, Vektorindizes, Caches. Sie benötigen einen zentralen Lösch-Controller, der IDs durch die Kette propagiert und Retraining triggert. Für LLM-RAG sind Index- und Cache-Invalidierung sofort möglich; bei trainierten Modellen ist Retraining auf „bereinigten“ Snapshots der robuste Weg.

Frage 3: Data Mesh oder Lakehouse – was empfehlt ihr?
Antwort: Für die meisten Industriefirmen: gut governedes Lakehouse mit klaren Domänen-Ownern. Data Mesh funktioniert erst mit reifen Domänenteams und starker Plattform. Andernfalls führt es zu Shadow-IT und inkonsistenten Policies. Domain-oriented Ownership lässt sich auch ohne Mesh umsetzen.

Frage 4: Können wir generative KI nutzen, ohne vertrauliche Daten zu riskieren?
Antwort: Ja, mit on-prem RAG, lokaler Embedding-Erstellung, LLMs unter eigener Kontrolle, Prompt/Output-Governance und Egress-Blockaden. Starten Sie mit PII-freien Korpora, führen Sie PII-Scanning/Maske in der Ingestion ein, erzwingen Sie Policy-Checks vor jedem externen Call und protokollieren Sie alles in WORM-Logs.

Frage 5: Wie plane ich Kapazitäten für einen on-prem GPU-Cluster?
Antwort: Trennen Sie drei Klassen: latenzkritische Inferenz (dedizierte MIG-Partitionen), planbare Trainingsjobs (Nacht-/Wochenendlast, Preemption möglich) und explorative Workloads (Quota-begrenzt). Nutzen Sie Topologie-bewussten Scheduler, observieren Sie NVLink/RDMA-Auslastung, und halten Sie 10–15% Puffer für ungeplante Jobs. Wachstum entlang von Strom/Kühlung/Netz planen, nicht nur entlang von GPUs.

Über den Autor
Ich baue Daten- und KI-Infrastrukturen für industrielle Systeme. Meine Erfahrung: Ohne robuste Datenpipelines, Lineage und Policy-Enforcement bleibt jedes ML-Modell eine Spielerei. Souveränität ist kein „Nice-to-have“, sondern die Voraussetzung für produktionsreife Intelligenz.