Luftfahrt/Defense: Trainings-/Missionssoftware

  • Strikte Isolation: Missionsdaten in Air-Gap-Zone, Media-Transfer via geprüfte Datendioden, sämtliche Modelle mit reproduzierbaren Builds.

  • Nachweisführung: Lückenloses Änderungs- und Testprotokoll, deterministische Random-Seeds, Dokumentation von Konfigurationsräumen als Teil des Safety Cases.

  • HIL/SIL: Hardware-in-the-Loop und Software-in-the-Loop für kritische Komponenten, bevor eine Funktion in den Flug-/Einsatzkontext darf.

Build vs. Buy – die typischen Fehlannahmen entkräften

  • „Buy ist schneller.“ Nur, wenn Integrations- und Sicherheitsauflagen trivial sind. In der Praxis verschieben sich 80% der Zeit in Anpassung, Compliance, Schnittstellenhärtung. Eine fokussierte Eigenentwicklung mit klaren Boundaries und erprobten Bausteinen ist oft schneller lieferfähig – vor allem in Iteration 2+.

  • „Buy ist günstiger.“ Lizenzkosten sind selten das Problem. Teuer wird Lock-in (z. B. proprietäre Modellformate), Datenmigration und die Unmöglichkeit, Roadmap-Lücken zu schließen, wenn der Vendor nicht liefert.

  • „Wir können nicht alles selbst bauen.“ Sollen Sie auch nicht. Bauen Sie das, was Sie differenziert – und zwar so, dass die restlichen Bausteine austauschbar bleiben. Kaufen Sie bewusst dort zu, wo echte Commodity existiert, die Sie on-prem kontrollieren können.

Technical Ownership: Der Unterschied zwischen Projekt und Produkt
Individuelle Entwicklung scheitert nicht an Code, sondern an Ownership. Technische Eigentümerschaft heißt: Eine verantwortliche Einheit hat Mandat und Pflicht für Architektur, Code, Betrieb, Qualität und Security.

Elemente wirksamer Technical Ownership

  • Klare Verantwortlichkeit: RACI auf Komponentenebene. Wer bricht Build-Regeln? Wer genehmigt Schnittstellenänderungen? Wer trägt Produktionsalarme?

  • SLOs und Error Budgets: Nicht zu Marketing-KPIs, sondern zu Betriebswahrheiten (z. B. Inferenz-Latenz P95, Bilddurchsatz pro Linie, Mean Time to Recovery bei Edge-Ausfällen).

  • Runbooks und Notfallübungen: Ein Pager ohne dokumentierte Prozedur ist wertlos. Trockenübungen für Netzwerkisolation, Zertifikatsabläufe, Storage-Vollausslastung.

  • RFC-Prozess: Jede relevante Architektur-/API-Änderung durchläuft einen technischen Review mit Versionierung. Entscheidungen werden begründet, nicht „aus dem Bauch“.

  • Build- und Lieferkette: Signierte Commits, signierte Container, reproduzierbare Builds, interne Artefakt-Repositories mit Freigabestufen.

Requirements Engineering in komplexen Domänen
In regulierten Branchen sind die „Anforderungen“ oft eine Mischung aus Normen, Betriebsrealität und implizitem Wissen bei den Technikern. Drei Praktiken helfen, „Scheinanforderungen“ zu vermeiden:

  • Szenarien statt Wunschlisten: Beschreiben Sie reale Abläufe, Störungen, Randfälle. Was passiert, wenn das Kamerakabel sporadisch Verbindungsfehler hat? Was, wenn die Öltemperatur-Sensorik driftet?
  • Kontraindikationen explizit machen: Was darf das System niemals tun? Beispiele: Kein automatischer Stopp ohne doppelte Absicherung; keine Daten-Ausleitung jenseits definierter Zonen; niemals autonome Befehle an Aktoren ohne menschliche Bestätigung.
  • Abnahmekriterien objektivieren: Metriken vorab definieren (z. B. Falsch-Positiv-Rate unter X bei Goldenset Y; Inferenz-Latenz P95 unter Z ms bei Datenlast L). Diese werden CI/CD-integriert getestet – nicht nur bei der Abnahme, sondern bei jedem Build.

Qualitätssicherung für sicherheitskritische und KI-Systeme
QS ist kein finales Tor, sondern eine Architektur-Eigenschaft.

  • Testpyramide erweitert um Daten/Modelle:
  • Unit/Contract-Tests für Services.
  • Property-based Tests für Parser/Adapter.
  • Simulations-/HIL-Tests für OT-Interaktionen.
  • Datentests: Schema-Drift, Feature-Drift, Out-of-Distribution-Detektion.
  • Modell-Regression: Jede neue Modellversion gegen Goldensets, mit akzeptiertem Delta-Spielraum.
  • Traceability:
  • Jede Vorhersage ist auf Code-Hash, Modell-Hash, Daten-Snapshot und Konfiguration rückführbar.
  • Audit-Logs schreibgeschützt, mit Aufbewahrungsfristen abgestimmt auf regulatorische Vorgaben.
  • Security-by-Design:
  • Zero-Trust-Prinzipien intern (mTLS, kurzlebige Zertifikate, Least Privilege).
  • Abgesicherte Tool-Use bei Agenten (Whitelists, Sandboxing, Output-Filter).
  • Software Supply Chain Security (Signaturen, SBOM, Policy-Gates in der CI).

Legacy-Migration ohne Betriebsunterbrechung
Der „Big Bang“ ist in Produktionsumgebungen untragbar. Bewährtes Muster: Strangler-Fig-Pattern mit kontrollierter Entkopplung.

Vorgehen in Phasen

  • Schnittstellenfront: Stellen Sie eine API-/Event-Fassade vor das Legacy-System. Neue Verbraucher sprechen nur mit der Fassade.

  • Daten-Schatten: Führen Sie Change Data Capture (CDC) ein, um Lesezugriffe auf neue Stores zu spiegeln. So bauen Sie parallel neue Services auf echten Daten.

  • Shadow-Mode: Neue Funktionalität mitlaufen lassen, Ergebnisse mit Legacy vergleichen (Diffs loggen), aber noch nicht „vorne“ schalten.

  • Dual-Write mit Guardrails: Für eine Übergangszeit schreiben beide Systeme, mit Konflikt-Policies und Monitoring für Divergenzen.

  • Inkrementeller Cutover: Pro Endpunkt/Use-Case „umschalten“, Backout-Plan dokumentiert, Testkriterien vorab festgelegt.

OT-kompatible Deployments

  • Rolling Updates auf Edge-Knoten nur innerhalb geplanter Wartungsfenster, mit Hot-Standby-Knoten.

  • Blue-Green für Inferenzdienste, damit die HMI/PLC gegen eine stabile Endpoint-Adresse zeigt und Sie die aktive Gruppe wechseln können.

  • Feature-Flags für riskantere Funktionen, aktivierbar pro Linie/Standort.

KI in der Praxis: RAG und Agenten on-prem, ohne Cloud-Abhängigkeit
Viele Unternehmen wollen Wissensarbeitern KI-Funktionen bereitstellen, ohne Daten aus dem Haus zu geben. Dafür braucht es eine On-Prem-Referenzarchitektur:

  • Retrieval-Augmented Generation (RAG):
  • Dokumentenaufnahme: interne Crawler/Connectors, Rechteübernahme, Chunking mit Domänen-spezifischen Tokenizern.
  • Vektorstore on-prem, verschlüsselt, mit Mandantenfähigkeit.
  • Inferenz: Self-hosted LLM mit quantisierten Modelleinstellungen für gewünschte Latenz/Genauigkeit; GPU-Planung in Kubernetes.
  • Guardrails: Prompt- und Output-Filter, Klassifizierer für sicherheitsrelevante Inhalte, Logging mit Redaction.
  • Agenten mit Tool-Use:
  • Tools als klar definierte, side-effect-free Aufrufe mit Typenprüfung.
  • Policy Engine, die pro Rolle Tools freischaltet oder blockiert.
  • Human-in-the-Loop für irreversible Aktionen.
  • Observability und Governance:
  • Pro Prompt/Antwort: Trace-ID, Policy-Resultate, Tool-Calls, Latenz, Modellversion.
  • Freigabeprozesse für neue Modelle/Prompts: Evaluationsberichte und Risikoeinstufung.

Diese Bausteine ergeben eine Plattform, die Sie kontrollieren. Ob Sie dafür ein eigenes Governance-Produkt entwickeln oder ein vorhandenes On-Prem-Tool nutzen, ist zweitrangig; entscheidend ist die vollständige Betriebshoheit.