• Anti-Corruption Layer:
  • Kapseln Sie ERP/MES/Legacy-Systeme hinter fachlichen Ports/Adapter. Fachlich saubere Domänenmodelle stehen im Zentrum, Legacy bleibt am Rand.
  • Datenpfade, die in der Praxis funktionieren:
  • Geräteschnittstellen über robuste Gateways mit lokaler Persistenz (Timeseries-Store, Write-Ahead-Logs)
  • Idempotente, wiederaufnehmbare Übertragung zur Zentrale
  • Event-Sourcing dort, wo Auditierbarkeit erste Priorität ist; klassische Transaktionen dort, wo Konsistenz dominiert
  • ML/LLM als erstklassige Bürger:
  • On-Prem-Model Registry mit Versionen, Artefakt-Signaturen und Freigaben
  • Reproduzierbare Trainings- und Evaluationspipelines, definierte Baselines und Golden Datasets
  • Inferenz lokal, mit deterministischen Budgets. Für LLM-Agenten: Werkzeuge Whitelisten, Tool-Use unter Least-Privilege, Observability- und Governance-Layer für Prompts, Ausgaben und Nebenwirkungen.
  • Human-in-the-loop-Mechanismen mit klaren Abbruch- und Eskalationspfaden
  • Beobachtbarkeit und Betrieb:
  • Metriken, Logs, Traces unter eigener Hoheit. Keine Telemetrie nach außen.
  • SLOs für Latenz, Fehlerraten, Kapazität. Lastprofile und Backpressure-Strategien definiert.
  • Runbooks, Notfallpfade, Wiederherstellungsübungen sind Teil des Releases – nicht nachträgliche Deko.

Technische Ownership als Organisationsprinzip

Architektur löst nur dann Probleme, wenn jemand sie hält. Technische Ownership bedeutet:

  • Eine verantwortliche Stelle, die Architekturentscheidungen trifft, dokumentiert und durchsetzt
  • Ein Product-Backlog, das nicht nur Features, sondern auch Architekturarbeit, technische Schulden und Sicherheitsaufgaben enthält – mit echter Priorität
  • Ein Änderungsmanagement, das die Kette Anforderung → Umsetzung → Test → Freigabe nachvollziehbar hält
  • Supply-Chain-Security: SBOMs, signierte Artefakte, reproduzierbare Builds, kontrollierte Abhängigkeiten
  • Freigaben und Releases in Stufen: Entwicklung → Integrationsumgebung → Pre-Prod → Prod, mit definierten Gates

Requirements Engineering, das den Unterschied macht

In komplexen Domänen sind nichtfunktionale Anforderungen die wahren Treiber. Ein RE-Prozess, der funktioniert:

  • Stakeholder- und Kontextanalyse: Betriebsbedingungen, Netzwerktopologie, Regulatorik, Sicherheitsziele
  • Hazard- und Risikoanalyse: Was passiert im Fehlerfall? Welche Schäden müssen ausgeschlossen werden?
  • Abgeleitete Qualitätsanforderungen: Latenzen, Verfügbarkeiten, Wiederanlaufzeiten, Auditierbarkeit
  • Verfeinerung in Szenarien und formalisierte Akzeptanzkriterien
  • Traceability bis in die Tests – automatisiert, wo möglich

Qualitätssicherung für sicherheitskritische Software

Qualität ist ein Systemattribut, nicht die Summe einzelner Tests.

  • Statische und formale Prüfungen:
  • Statische Codeanalyse, Coding-Guidelines, Architektur-Linter
  • Modell- oder Vertragsprüfungen in sicherheitsnahen Komponenten
  • Testpyramide ernst nehmen:
  • Isolierte Komponententests
  • Integrations- und Schnittstellentests mit Emulatoren/Simulatoren
  • Systemtests in realitätsnahen Staging-Umgebungen
  • Hardware-in-the-Loop, Fault Injection und Chaos-Tests, soweit sicherheitsseitig verantwortbar
  • Daten- und KI-Tests:
  • Validierte Datensätze, reproduzierbare Metriken
  • Eval-Gates vor Rollout, Regression auf Golden Datasets
  • Für LLM-Agenten: Prompt-/Tooling-Regression, Red-Teaming in isolierten Umgebungen, Audit-Logs über Agentenentscheidungen
  • Betrieb als Teil der Qualität:
  • Observability-Gates im CI/CD
  • Canary-Releases, progressive Rollouts
  • Incident-Reviews mit Ableitungen in Architektur und RE

Fall-Skizzen aus der Praxis

  • Defense-Umfeld: Air-Gap mit Einweg-Kommunikation
  • Datenaufnahme und Auswertung in einer abgeschotteten Zone
  • Artefakttransfer über dedizierte Prüfkette, keine Rückkanäle
  • Ereignisprotokollierung als primäre Datenquelle, strikte Toolchain-Validierung
  • Fertigung: Visuelle Qualitätskontrolle on-prem
  • Kameraanbindung, zeitkritische Inferenz lokal auf Edge-Hardware
  • Training mit werksinternen Daten, strikte Anonymisierung für eventuelle Analytik
  • “Human-in-the-loop” bei unsicheren Klassifikationen, verbindliche Schnittstelle zum MES
  • Bahn: Flottenintelligenz bei intermittierender Verbindung
  • Edge-Gateways sammeln Telemetrie, persistieren lokal, synchronisieren opportunistisch
  • Eventual Consistency bewusst designt, zentrale Auswertung, lokale Fallbacks
  • Update-Strategie mit Rollbacks, Staging je Fahrzeuggruppe

Migration statt Big Bang: Der Strangler-Fig-Ansatz

Viele Unternehmen sitzen bereits auf einer Mischung aus COTS und Eigenbau. Der Weg zu Souveränität ist dann schrittweise:

  • Anti-Corruption-Layer um das Bestandssystem
  • Identifizierung des “Core Domain”-Teils, der echte Abhängigkeiten erzeugt
  • Extraktion dieses Kerns in eine eigenständige, souveräne Komponente
  • Paralleler Betrieb und graduelles Umschalten
  • Frühzeitig: Aufbau der Governance (Traceability, SBOM, Signaturen) – sie wird beim Abschneiden von Legacy Ihr Sicherheitsnetz

Kosten- und Zeitrealität ohne Illusionen

Ja, Eigenentwicklung braucht Anschubkapital und Disziplin. Aber in langen Lebenszyklen wird die Rechnung anders:

  • CAPEX vs OPEX: Sie tauschen variable, schwer prognostizierbare Betriebskosten (Lizenz, Egress, API-Verbrauch) gegen kontrollierbare Investitionen und planbaren Betrieb.
  • Integrationsschuld vermeiden: Sie bauen eine Architektur, die Ihre Domäne modelliert – statt Adapterschichten um einen fremden Kern zu pflegen.
  • Updatehoheit: Sie passen die Update-Kadenz Ihrem Validierungsprozess an, nicht umgekehrt.
  • Risiko steuerbar machen: Abhängigkeiten sind bewusst gewählt und austauschbar. Das reduziert strategisches Risiko.

LLM-Agenten in der Industrie: Governance oder gar nicht

Große Sprachmodelle eröffnen neue Automatisierungspfade – zugleich verschärfen sie Governance-Anforderungen. In regulierten Umgebungen gilt:

  • Modelle und Embeddings on-prem, ohne externe Telemetrie. Keine unkontrollierten API-Aufrufe in produktiven Pfaden.
  • Werkzeuge, auf die ein Agent zugreifen darf, sind explizit und minimal. Jeder Tool-Aufruf wird auditierbar geloggt.
  • Prompts, Kontextfenster, Policies sind versioniert. Änderungen durchlaufen das gleiche Freigabeverfahren wie Code.
  • Evaluations- und Eskalationspfade sind klar: Der Agent arbeitet zu, ein Mensch gibt frei, wenn das Risiko es verlangt.

Für die Beobachtbarkeit und Steuerung solcher Agenten setzen wir eine Governance-Schicht ein, die Metriken, Policies, Freigaben und Forensik bündelt. Genau dafür haben wir Alpi-M entwickelt: eine On-Prem-Plattform für LLM-Agent-Observability und -Governance – DSGVO-konform, ohne externe Cloud-Abhängigkeit. Sie ist kein “Chatbot-Baukasten”, sondern die Kontrollinstanz zwischen Agentenlogik und produktiver Wirklichkeit.

Pragmatische Buy-Entscheidungen