4) Sicherheit und Souveränität

  • Eigenes PKI-Root, mTLS intern, signierte Artefakte, SBOM und Reproducible Builds.

  • Kein externer Lizenzzwang zur Laufzeit, keine Telemetrie ins Internet. Updates via kontrollierten Paket- und Container-Registries On-Prem.

5) Betrieb und Qualität

  • Infrastruktur als Code, deterministische Environments, isolierte Build-Pipelines ohne Internetzugang (Spiegel-Registries).

  • Observability On-Prem: Metriken, Traces, Ereignis-Telemetrie, Audit-Logs. Alarmierung ohne externe Abhängigkeit.

6) ML/LLM-spezifische Governance

  • Versionierte Modelle, Datasets und Feature Stores. Evaluationspipelines mit reproduzierbaren Seeds.

  • Richtlinien-Engine für LLM- bzw. Agentenaktionen; Prompt-/Tooling-Versionierung, Audit-Trail, Offline-Fähigkeit der Inferenz, konfigurierbare Kontextfenster und Datenlokalität.

  • Trennung zwischen Experimentierräumen und Produktionsagenten; Freigaben via Change-Management.

Beispielhafte Anwendungspunkte aus der Praxis

  • Bahn/Fleet Intelligence: Notwendigkeit zur stabilen Datenerfassung von Fahrzeugen mit unzuverlässiger Konnektivität, zeitversetztes Hochladen, deterministisches Reprocessing von fehlerhaften Datenfenstern. Buy-Lösungen scheitern oft an Pufferung, konfliktfreien Replays und domänenspezifischer Aggregationslogik. Build ermöglicht ein kontrolliertes Datenmodell mit deterministischen Replays, Materialized Views pro Flotte und On-Prem Analytics.
  • Fertigung/Visuelle Inspektion: Inline-Inferenz mit engen Latenzbudgets, Bilddaten verbleiben in Werkshallen. Typische SaaS-Modelle kollidieren mit Bandtaktzeit und Datenabfluss. Build sichert lokale Inferenz, datengesteuerte Threshold-Strategien und Auditierbarkeit der Modellversion je Produktionscharge.
  • Defense/Sichere Plattformen: Air-Gapped Deployments, kein externer Activation- oder Telemetrieserver, definierte Updatefenster. Build garantiert, dass Update-Rollouts, Schlüsselrotationen und Artefaktprüfungen vollständig in der eigenen Supply Chain verbleiben.
  • Konstruktion/Vermessungssysteme: Offline-Fähigkeit im Feld, robuste Synchronisationsstrategien, konfliktfreie Zusammenführung von Messdaten bei später Konnektivität. Build ermöglicht domain-spezifische Konfliktauflösung statt generischer “Last Write Wins”-Heuristiken.

Quality Gates, die Off-the-Shelf selten erfüllt

  • Reproduzierbarkeit: Bytegleiche Builds und definierte Docker-/OCI-Digests. Austauschbarkeit der Basisschichten ohne Netzbezug.
  • Migrationsstrategie im Code: Strangler-Fig-Pattern, Daten-Shadowing, Read-Only-Spiegel gegen Legacy, schrittweise Umschaltung von Endpunkten über Routen/Service Mesh.
  • Testen über deterministische Orakel hinaus: Metamorphes Testen für ML, Kontrakt-Tests für Integrationen, Last- und Chaos-Szenarien in isolierten Umgebungen.
  • Notfallfähigkeit: Vollständige Backup- und Restore-Übungen unter realistischen Netzrestriktionen. Wiederanlauf plangemäß mit definierter Datenkonsistenz (z. B. “at-least-once” mit Idempotenzgarantien).
  • Dokumentierte Architekturexplizitheit: Architekturdokumente, ADRs, Sicherheitsmodell, Betriebs-Playbooks – alles versionsgeführt und lokal verfügbar.

Technical Ownership als Projektversicherung

Individuelle Entwicklung ist nur so gut wie die Ownership-Struktur. Technical Ownership bedeutet:

  • Klare Verantwortung für das Domänenmodell, die Systemgrenzen und die Qualitätskriterien.
  • Entscheidungsbefugnis, Architekturschulden zu tilgen, statt sie in Roadmap-PowerPoints zu verschieben.
  • Messbare, technische Definition of Done: Reproduzierbarer Build, messbare SLOs, dokumentierte Betriebsroutinen, belastbare Observability.
  • Keine Proxy-Ownership durch reine Integrationspartner. Entweder Inhouse-Team mit gezielter Verstärkung oder ein Partner, der nicht nur liefert, sondern die Architekturlasten sichtbar trägt.

Kalkulation: TCO mit Souveränitäts-Prämie

CAPEX vs OPEX greift zu kurz. Rechnen Sie folgende Kostentreiber ein:

  • Lock-in-Abschläge: Kosten einer erzwungenen Migration bei Roadmap-Drift (Datenexport, Neuintegration, Doppellaufzeiten).
  • Compliance-Kosten: Audits, Nachweise, zusätzliche Kontrollen wegen externer Telemetrie oder gemischter Betriebsmodelle.
  • Betriebsrisiko: Unerwartete Upgrades, Lizenzabhängigkeiten, Plattformzwänge, die in Wartungsfenstern nicht steuerbar sind.
  • Teamaufbau: Für Build benötigen Sie tragfähige Kernrollen (Architektur, DevOps, QA, Security). Das ist ein Kostenblock – aber er ist planbar und ergebniswirksam.
  • Lebensdauer: In einem 10–20-Jahres-Horizont ist Build häufig günstiger, weil er Roadmap-Risiken reduziert und Migrationskosten kontrollierbar macht.

Legacy-Migration ohne Betriebsunterbrechung

Eine robuste, bewährte Vorgehensweise:

  • Anti-Corruption-Layer zuerst: Eine saubere, sprachlich domänengetreue Schnittschicht vor das Legacy-System setzen. Keine direkten Couplings.
  • Datenverdopplung und Schattenlast: Relevante Ereignisse per CDC abgreifen, in neuen Domänenmodellen materialisieren. Shadow Traffic ermöglicht realitätsnahe Tests.
  • Strangler-Fig: Schrittweise Endpunkte vom Legacy auf das neue System umschalten. Messbar per SLOs, reversibel per Routing.
  • Rollout-Muster: In On-Prem-Umgebungen Blue/Green via parallel laufenden Instanzen; bei Edge-Geräten Rolling mit Rückfallebenen. Feature Flags lokal, nicht cloudgebunden.
  • Formale Abnahme: Messbare Kriterien pro Teilschnitt, automatisierte Regressionstests, Domänenabnahmen gemeinsam mit Fachexperten.

Souveräne KI in der Praxis: Observability und Governance für LLM-Agenten

Wenn Sie LLMs oder Agenten in Produktionsprozesse einbetten, reicht “Wir protokollieren ein paar Prompts” nicht. In regulierten Kontexten brauchen Sie:

  • Versionierte Prompts, Policies und Tool-Definitionen; Nachvollziehbarkeit jeder Entscheidung eines Agenten.
  • Telemetrie über Token, Latenzen, Nebenwirkungen von Aktionen; Korrelation mit Betriebsmetriken.
  • Policy-Enforcement vor Aktionsausführung: Welche Tools darf ein Agent nutzen, mit welchen Parametern, in welchem Kontext? Was ist offline zulässig?
  • On-Prem-Inferenz oder streng kontrollierte Gateways; keine unkontrollierten Datenabflüsse.
  • Auditierbare Freigabenpfade und automatisierte Testszenarien gegen bekannte Fehlmodi.

Eine entsprechende Plattform, die diese Governance und Observability On-Prem bereitstellt, hebt LLM-Workloads aus der Experimentierecke in den geregelten Betrieb. Aus Architektursicht ist das der notwendige Unterbau – egal ob die Modelle intern trainiert oder zugekauft werden.

Konkrete Checkliste für Ihre Entscheidung