2) Zweischichtige CI/CD

  • Schicht A (Entwicklungsnetz) hat volle Internetnähe, lädt Upstream-Dependencies, baut, testet, signiert.

  • Schicht B (Produktions-/Werksnetz) ist offline, repliziert nur die signierten Ergebnisse. Dependency-Auflösung findet nie in B statt.

Trade-off: Etwas mehr Infrastrukturpflege (Mirrors, Signaturverwaltung), dafür geringes Supply-Chain-Risiko im Produktionsnetz.

3) Modularer Monolith statt 20 Microservices

  • In streng regulierten Umgebungen sind Change-Approval-Prozesse teuer. Jeder zusätzliche deploybare Service vergrößert Oberflächen und Audit-Aufwand.

  • Ein modularer Monolith mit klaren Bounded Contexts und internen Modulen erlaubt stabile öffentliche Schnittstellen, minimiert aber Betriebsrisiko (eine Deploy-Einheit, weniger Netzkomplexität).

Trade-off: Weniger feinkörnliche Skalierung, dafür weniger Netzwerkfehler, leichteres Debugging, konsistente Transaktionen.

4) Ereignisgetriebene Datenpipelines mit Append-only-Log

  • Für Nachvollziehbarkeit ist ein append-only Event-Log wertvoll. Modelle können asynchron neu rechnen, Korrekturen erfolgen mit Korrektur-Events, nicht Retro-Edits.

  • In on-prem-Umgebungen ist die Retention bewusst zu dimensionieren; Speicher ist endlich. Kompaktierung (Snapshots + Event-Trimming) einplanen.

Trade-off: Entwicklerdisziplin erforderlich; Lernen im Team, dass sich Zustände aus Events rekonstruieren.

5) Datentransfer über definierte Quarantäne

  • Kein „mal eben“ SFTP ins Produktionsnetz. Stattdessen definierte Quarantäne-Zone (Dioden-Pattern oder striktes Gatekeeping), in der Artefakte und Daten geprüft und signiert werden.

  • Für Metriken/Logs: Batch-Exporte als signierte, verschlüsselte Bundles, die in ein Analyse-Backend in einem weniger restriktiven Netz importiert werden.

Trade-off: Weniger Live-Transparenz, dafür forensische Sicherheit.

6) Schlüssel- und Secret-Management unter eigener Hoheit

  • Interne HSM/KMS-Instanzen oder softwarebasierte KMS mit strikter Schlüsselrotation. Verschlüsselung at-rest und in-flight ist Standard; wichtiger ist der Backup- und Recovery-Pfad für Schlüssel.

  • Secrets nie in Container-Images; Auslieferung über deklarative Mechanismen mit kurzlebigen Tokens.

Trade-off: Betrieb eines KMS verlangt Prozessreife; lohnt sich ab dem ersten Audit.

Observability ohne SaaS: so geht’s

  • Metriken: Fokus auf SLO-relevante Kennzahlen; hohe Kardinalität vermeiden. Aggregation an der Quelle spart Storage.
  • Logs: Strukturierte Logs mit festen Schemata; WORM-ähnliche Speicherung für Audit-Trails.
  • Traces: Sampling, definierte Spans an kritischen Schnittstellen; Trace-IDs in Audit-Events mitschreiben.
  • Korrelation: Einheitliche Korrelations-IDs über Services/Module hinweg.
  • Offline-Analytics: Regelmäßige Exporte in ein Analyse-Netz; dort Dashboards und Langzeitauswertungen. In der Produktionsdomäne nur so viel Visualisierung, wie für Operabilität nötig.

Typische Anti-Patterns und wie man sie vermeidet

  • SaaS-Heartbeat-Abhängigkeiten: Eine Lizenz- oder Telemetrieprüfung gegen das Internet macht die Anlage abhängig von fremder Verfügbarkeit. Lösung: Lizenzpakete zeitlich begrenzt offline aktivieren; Telemetrie als Batch.
  • „Microservice-Friedhof“: 30 kleine Dienste in einer Umgebung mit engen Change-Fenstern multiplizieren den Audit-Aufwand. Lösung: Modularer Monolith oder wenige gut begrenzte Services, die echte unabhängige Skalierungsprofile haben.
  • „Lift-and-Shift“ von Cloud-Tooling: Ein Observability-Stack, der in der Cloud durch Managed Services getragen wird, bricht on-prem an Storage- und Pflegeaufwand. Lösung: Schlank starten, Metriken und Logs bewusst auswählen, Retention begrenzen, Kompression und Rollups früh einplanen.
  • Externe Identitätsanker: Workloads, die beim Start gegen externe OIDC-/STS-Provider telefonieren, stehen im Air-Gap. Lösung: Lokale Identitätsprovider spiegeln oder eigenständig betreiben; Trust-Ketten klar definieren.

Fallbeispiel: Visuelle Inspektion in der Fertigung

Problem: Kameras überprüfen Teile am Band. Entscheidungen müssen in <10 ms fallen. Bilder sind sensibel, Rückschlüsse auf Taktzeiten und Prozessqualität unerwünscht. Ein Cloud-Roundtrip ist ausgeschlossen.

Lösungsskizze:

  • Datenebene: Kamerastreams landen in einem Edge-Knoten mit GPU. Inferenz-Engine läuft containerisiert, Modelle sind versioniert, checksum-verifiziert. Cache für zuletzt N Modelle, um Rollbacks in Sekunden zu ermöglichen.

  • Kontrollebene: Release-Agent zieht signierte Artefakt-Bundles aus einer Quarantäne-Zone. Rollout erfolgt Blau/Grün; Shadow-Modus speist Live-Bilder in das neue Modell, vergleicht Entscheidungen, schreibt Abweichungen ins Audit-Log.

  • Identitätsebene: Interne PKI stellt Zertifikate für Edge-Knoten und Workloads aus. mTLS zwischen Kamera-Gateway, Inferenz-Engine und Qualitätssystem.

  • Observability: Lokaler Metrics-Store mit SLOs (Latenz-P50/P99, Dropped Frames), strukturierte Logs mit Modell-ID und Trace-ID. Wöchentlicher Export der Statistiken zur zentralen Analyse.

  • Modellpflege: Trainingsdaten werden on-prem kuratiert. Wenn Cloud-Compute gewünscht ist, dann nur mit synthetischen/entschärften Daten. Fine-Tuning auf Originaldaten findet on-prem statt. Modelle kommen als signiertes Paket zurück.

Trade-offs: Cloud wird nur für elastische Vorarbeiten genutzt; Produktionsentscheidungen und sensible Daten bleiben vor Ort. Betriebsaufwand steigt moderat (PKI, Registry, Artefaktfluss), dafür hohe Robustheit und Auditierbarkeit.

LLM/GenAI in regulierten Netzen: realistisch gedacht

Sprachmodelle und Agenten sind nützlich – solange die Steuerung stimmt. Zwei Grundprinzipien:

  • Modelle als Artefakte: Kein Laufzeit-Streaming in fremde APIs für produktionskritische Aufgaben. Stattdessen Modelle paketieren, hashbasiert versionieren, Ressourcenprofil messen (RAM, VRAM), und on-prem inferieren.

  • Governance und Observability: Prompts, Tool-Aufrufe, Kontextfenster und Ausgaben müssen nachvollziehbar sein. Agenten dürfen nur definierte Tools nutzen, Policies entscheiden deterministisch, wann was erlaubt ist.

Wir haben dafür Alpi-M gebaut – eine Plattform, die LLM-Agenten beobachtbar und steuerbar macht, speziell für on-prem Deployments. Wichtige Mechanismen:

  • Agent-Execution-Log: Jede Entscheidung, jedes Tooling, Entitäten im Kontext. Exportierbar als Audit-Artefakt.

  • Policy durchsetzbar: Tool- und Datenzugriffe sind explizit genehmigt/abgelehnt, nicht „best effort“.

  • Deployment-agnostisch: Funktioniert in air-gapped Netzen; Bundles werden wie andere Software-Artefakte gehandhabt.

Wichtig: Ein LLM ist kein Freifahrtschein. In regulierten Netzen zählt die Schnittstelle zum Rest der Welt. Agenten ohne harte Guardrails sind ein Risiko, on-prem wie in der Cloud.

Wie man die Technologieauswahl problemorientiert trifft