• Datenlokalität und Exit: Können Sie Daten täglich extrahieren und in ein neutrales Format bringen? Gibt es eine dokumentierte, getestete Rückbau-Strategie?
  • Betriebsmodell: Lässt sich die Komponente on-prem oder in einer souveränen Umgebung mit Ihren SLOs betreiben? Gibt es Beobachtbarkeit ohne PII-Export?
  • Testbarkeit: Können Sie deterministische Tests fahren? Gibt es Mocks/Simulationsmöglichkeiten? Versionierte, testbare Schnittstellen?
  • Lieferkette: Bekommen Sie SBOMs? Signierte Artefakte? Sicherheitsupdates in Ihrer geforderten Zeit?
  • Kostentransparenz unter Last: Wie verhält sich Preis/Performance in Spitzen? Gibt es Hardware-Alternativen (z. B. GPU/CPU-Trade-offs), die Sie kontrollieren?

Für KI-Komponenten heißt das konkret: Evaluations-Harness, Golden Datasets, reproduzierbare Fine-Tuning-Pipelines, offline Model Registry, Prompt- und Output-Filter, Monitoring von Halluzinationen/Drift. Wenn Sie das nicht kontrollieren, besitzen Sie das System nicht – selbst wenn Sie die Rechnung zahlen.

On-Premise und Souveränität: was Ownership praktisch bedeutet

Viele Teams unterschätzen die Unterschiede zum Public-Cloud-Betrieb:

  • Artefakt- und Container-Registries on-prem: Kein “docker pull” aus dem Internet. Spiegeln, kuratieren, signieren. Offline-Installationspfade regelmäßig testen.
  • Identität und Geheimnisse: Kein Managed Secret Store vom Hyperscaler. Eigene PKI, Secret-Verteilung mit Rotation, Auditierbarkeit.
  • Observability ohne Datenabfluss: Logs/Metriken/Traces lokal, PII-Masking an der Quelle, mandantenfähige Dashboards für Betrieb und Audit.
  • Zeit- und NTP-Management: deterministische Zeitquellen, Abweichungserkennung. Trivial? Nicht in geschlossenen Netzen.
  • Backup/DR-Strategien: Offsite-Backups, aber unter Kontrolle der eigenen Organisation. Restore-Drills vierteljährlich, nicht nur Papier.

Qualitätssicherung in sicherheitskritischen/industriellen Systemen

Ein Testpyramidendiagramm ist nett, aber in der Praxis brauchen Sie zusätzliche Schichten:

  • Contract-Tests: Jede Schnittstelle hat Producer- und Consumer-Tests. Kein Breaking Change ohne roten Test.
  • Property-based Tests: Für Parser/Protokolleinheiten, um unerwartete Eingaben systematisch abzudecken.
  • Chaos/Fault-Injection: Netzwerkpartitions, Clock Skew, Disk-Füllstände, Prozessabstürze – regelmäßig im Staging.
  • Hardware-in-the-Loop/Simulation: Für Sensorik/Aktorik, reale Timing-Eigenschaften und Treibergrenzen testen.
  • Metamorphe Tests für ML: Wenn Eingabe transformationsäquivalent ist (z. B. Helligkeitsskalierung), sollte Ausgabe innerhalb eines Bandes bleiben.
  • Shadow/Parallel Traffic: Neue Modelle/Algorithmen erst passiv gegen Live-Daten fahren, bevor sie Entscheidungen treffen.

Lieferkette und Reproduzierbarkeit: die unbeliebten, aber entscheidenden 20%

  • Hermetische Builds: Keine Netzwerksprache zur Build-Zeit. Reproduzierbare Images (gleiche Inputs → gleicher Hash).
  • Signierte Artefakte und Policy Enforcement: Nur signierte Container dürfen laufen. Ausnahmen dokumentiert und zeitlich begrenzt.
  • SBOM-Pflicht: Für jedes Release. CVE-Scan als Gate, Risikoabschätzung mit dokumentierter Entscheidung.
  • Abhängigkeits-Updatefenster: Regelmäßige, kleine Updates statt seltener Big Bangs. Jede Aktualisierung mit Smoke- und Regressionstests.

Änderungssteuerung ohne Bürokratiemonster

  • ADR-First: Architekturänderungen starten mit einem ADR-Entwurf. Review durch Tech Leads, dann Implementierung. Vermeidet “Refactor by Surprise”.
  • Pipeline-Gates als lebende Checks: Metrik-Budgets (Latenz, RAM), Testabdeckung, Security-Checks, Linters. Rot heißt: kein Merge.
  • Safe Deploys on-prem: Blue/Green mit getrennter Datenbank-Replica, Contract-Migrationen (Expand → Migrate → Contract), Rollback-Pfade geübt.
  • Feature Flags mit Ablaufdatum: Flags sind Schulden. Automatisches Ticket/Alert, wenn das Datum erreicht ist.

Fallbeispiel aus der Praxis: Flottenintelligenz in einer Multi-Vendor-Bahnumgebung

Ausgangslage:

  • Mehrere Hersteller liefern Diagnosedaten mit proprietären Formaten.

  • Leitstellen wollen innerhalb weniger Sekunden kritische Events sehen.

  • Netzsegmente sind isoliert; Internetzugang ist strikt beschränkt.

  • Audits fordern Nachweis, dass keine personenbezogenen Daten das Segment verlassen.

Technical Ownership Hebel:

  • Capability Map und Mission Threads definieren Latenz- und Zuverlässigkeitsziele: “<5 s End-to-End für Alarm X, P95”.

  • ICDs pro Herstellerfeed, inklusive Feldsemantik, Einheiten und Fehlercodes. Contract-Tests sichern die Einhaltung.

  • Edge-Ingestion-Services mit idempotenter Verarbeitung, Backpressure und garantierter Reihenfolge; Event-Store mit Zeitfenster-Index.

  • Observability lokal: Metriken/Logs/Traces im Segment, PII-Masking an der Quelle; Freigabeprozess für Export von Metrikaggregaten.

  • Reproduzierbare Builds, private Container-Registry, signierte Deployments.

  • Rollout-Strategie: Shadow Mode der neuen Normalisierungspipeline über 6 Wochen, Abweichungsanalyse, dann schrittweise Aktivierung.

Ergebnis:

  • Keine “Big Bang”-Migration, sondern risikoorientierte Aktivierung pro Feed.

  • Audit-fähige Nachweise für Datenlokalität und Reaktionszeiten.

  • Betriebsstabilität, weil Runbooks und Observability vor Inbetriebnahme fertig waren – nicht “später”.

AI-spezifische Ownership: Modelle sind Code, aber auch Daten und Verhalten

Für KI-Anteile gelten zusätzliche Regeln:

  • Daten-Governance: Jede Trainings-/Eval-Datenquelle ist katalogisiert, Versionen sind fixiert, PII ist technisch ausgeschlossen oder rechtlich und technisch kontrolliert.
  • Evaluations-Harness: Golden Datasets, adversariale Tests, Drift-Detektion. Scorecards sind Release-Gates, nicht nur Berichte.
  • Reproduzierbare Fine-Tunes: Containerisierte Pipelines, deterministische Seeds, Fixierung von Tokenizer/Preprocessing.
  • Inferenz-Governance: Prompt-/Output-Filter, Rechtsschutz (PII/PHI), Logging ohne sensible Inhalte, Feedback-Schleifen mit Review.
  • Observability: Halluzinationsraten, Regressionsmetriken, Latenz unter Last, Ressourcenbudgeteinhaltung.
  • Exit-Strategie: On-Prem-Inferenzpfad vorhanden, auch wenn heute ein externer Dienst genutzt wird. Modelle und Tokenizer werden lokal registriert.

Als Hersteller von industrieller KI-Software haben wir dafür eigene Observability-/Governance-Werkzeuge etabliert, um Agenten/LLMs messbar, nachvollziehbar und auditierbar zu machen – on-prem, DSGVO-konform, ohne US-Cloud-Abhängigkeit. Entscheidend ist nicht das Tool, sondern dass Metriken, Policies und Nachweise integraler Bestandteil des Systems sind.

Betrieb: SRE-Praktiken ohne Hyperscaler

SRE funktioniert auch in Rechenzentren und Edge-Umgebungen: