Wenn LLMs Geschäftsvorgänge unterstützen, sind Observability, Reproduzierbarkeit und Policies Pflicht:

  • Retrieval-Layer trennt Datenquellen mit klaren Freigaben. Keine Schattenindizes.

  • Prompting und Kontext werden revisionssicher gespeichert, PII vor Speicherung automatisiert geschwärzt.

  • Ausgehende Netzverbindungen sind standardmäßig blockiert. Whitelists existieren nur für ausdrücklich genehmigte Endpunkte.

  • Evaluationssuites messen Output-Qualität vor Rollout, Regressionen blockieren Promotion.

  • Policy-Engines prüfen Eingaben/Ausgaben (Halluzinationsindikatoren, Sensitive Content, Output-Formate).

Diese Governance lässt sich technisch exakt so bauen, wie man es aus klassischen CI/CD-Pipelines kennt – nur, dass hier Artefakte Prompts, Policies und Modelle sind.

API-Design und Evolvierbarkeit

  • Stabile Verträge: In langlebigen Industrieumgebungen gelten APIs 5–10 Jahre. Versionieren Sie explizit (v1, v2), vermeiden Sie „magische“ Felder. Deprecations mit Fristen und Migrationspfaden.
  • Ereignis-Schemata: Event-Driven Architekturen brauchen Schema-Verträge mit Rückwärts-/Vorwärtskompatibilität. Schema-Registry on-prem, Validierung in der Pipeline.
  • Datenexporte: Legal Hold und Audit erfordern Exportfähigkeit. Kein proprietäres Dunkelfeld.

Organisationsmuster, die funktionieren

  • Zwei-Pizza-Regel für Plattformkern: Ein kleines, senioriges Team verantwortet Basistechnologien (K8s, Registry, GitOps, Observability, IdP, Secrets). Produktteams konsumieren Self-Service-Schnittstellen.
  • Gated Autonomy: Produktteams dürfen Deployments in ihren Namespaces selbst fahren – innerhalb der durch Policies vorgegebenen Leitplanken. Sicherheits- und Compliance-Gates sind automatisiert, nicht manuell.
  • Schatten-Cloud vermeiden: Verbieten ist sinnlos; stellen Sie schnelle, sichere Alternativen on-prem bereit. Ein gutes Template-Repo schlägt zehn Governance-Dokumente.

Wann Cloud sinnvoll bleibt

  • Nicht-sensible, kurzlebige Experimente, die schnelle Iteration verlangen.
  • Lastspitzen-Tests oder synthetische Daten, wo Kosten- und Zeitvorteile klar sind.
  • Trainingsjobs mit anonymisierten/öffentlichen Datensätzen, wenn rechtlich geklärt.

Worauf wir uns festlegen

  • Souveränität schlägt Bequemlichkeit in regulierten Domänen.
  • Cloud-native ist ein Betriebsmodell, kein Ort. Man kann es on-prem erfolgreich umsetzen – mit GitOps, Policy-as-Code, reproduzierbaren Builds, strengem Artefakt- und Identitätsmanagement.
  • Verkürzen Sie den Technologie-Zoo. Komplexität frisst Souveränität.
  • Bauen Sie anti-fragile Lieferketten: signiert, dokumentiert, offline aktualisierbar.

FAQ

Frage: Ist Kubernetes on-prem nicht Overkill? Reicht ein paar VMs?
Antwort: Für kleine, statische Systeme können VMs reichen. Sobald Sie aber regelmäßig deployen, mehrere Services isolieren, GPU-Workloads planen, Audits bestehen und reproduzierbar arbeiten wollen, skaliert ein orchestrierter Ansatz besser. Wichtig ist die Dosis: Ein schlankes K8s mit klaren Standards ist kein Overkill, zehn Zusatzoperatoren ohne Runbooks schon.

Frage: Wie aktualisieren wir Modelle und Software in Air-Gap-Umgebungen?
Antwort: Über signierte Air-Gap-Bundles: Container-Images, Manifeste, SBOMs, Validierungsberichte in einem versionierten Paket. Import erfolgt in ein Staging-Segment, dort vollständiger Probelauf, anschließend Promotion ins Prod-Segment via definierter, auditierbarer Transfers. GitOps-Operatoren ziehen Bundles aus internen Repos.

Frage: Ist On-Prem grundsätzlich teurer als Cloud?
Antwort: Kurzfristig ja, wegen Hardware und Plattformaufbau. Langfristig hängt es von Datenvolumen, GPU-/Storage-Bedarf und Laufzeit ab. Kontinuierliche, datenintensive Workloads mit hohen Egress-Kosten sind on-prem häufig günstiger und vor allem vorhersagbarer. Wichtig ist eine hohe Auslastung der Ressourcen und ein reifes Betriebsmodell.

Frage: Wie testen wir Sicherheit ohne Internetzugang?
Antwort: Durch interne Mirror-Repositories für Scans, regelmäßige Synchronisierung von CVE-Datenbanken, Offline-Pentest-Kits und Red-Teams im isolierten Netz. SBOM- und Signaturprüfungen laufen lokal. Für ausgewählte Prüfungen kann ein gesicherter, temporärer Prüftunnel genutzt werden – mit Protokollierung und Freigabeprozess.

Frage: Welche Hardware-Empfehlungen für LLM on-prem?
Antwort: Planen Sie GPU-Kapazität dediziert nach Inferenz- und Trainingsprofil, trennen Sie Trainingsknoten von Latenz-sensitiven Inferenzknoten. Achten Sie auf ausreichende VRAM-Kapazität pro Modell, schnelle NVMe-Backends für Embedding/Index-Zugriffe und stabile Strom-/Kühlkapazitäten. Partitionierungsfeatures moderner GPUs können helfen, aber nur, wenn das Scheduling und Monitoring entsprechend reif ist.

Schluss

Cloud-native Prinzipien sind in regulierten Umgebungen kein Widerspruch – wenn man sie entzaubert und auf das Wesentliche reduziert: reproduzierbare Lieferketten, deklarativer Betrieb, harte Verträge, klare Policies. Bauen Sie eine Plattform, keine Sammlung von Ad-hoc-Tools. Und akzeptieren Sie, dass Souveränität ein technisches Feature ist, das man aktiv entwerfen und betreiben muss. Genau dann wird On-Prem nicht zum Kompromiss, sondern zur Voraussetzung für robuste, intelligente Systeme.