Titel: KI in Bestandssoftware nachrüsten: Architektur- und Integrationsmuster aus der Praxis – mit LLM-Governance on-prem

Wenn wir in Industriebetrieben KI-Funktionen nachrüsten, ist das eigentliche Problem fast nie das Modell. Der Engpass liegt in Latenzbudgets, Schnittstellen, deterministischen Fallbacks, Zertifizierbarkeit, Betriebsmodellen und Governance. In sicherheits- und geschäftskritischen Umgebungen darf KI nicht “magisch” agieren, sondern muss sich präzise in bestehende Systeme einfügen – technisch, organisatorisch und regulatorisch.

Als Team, das KI-Funktionen in reale Industrieprodukte integriert (Defense, Fertigung, Bahn, Luftfahrt, Bau, Textil), vertreten wir eine klare Haltung: Souveränität ermöglicht Intelligenz. Das heißt konkret: On-premise-Deployment, DSGVO-konforme Datenpfade, keine Abhängigkeit von US-Cloud-APIs, strikte Observability und ein Migrationspfad, der die bestehende Wertschöpfung respektiert.

Dieser Beitrag zeigt erprobte Integrationsmuster, typische Fallstricke und konkrete Designentscheidungen – mit besonderem Fokus auf:

  • Nachrüsten von ML in Legacy-Systeme

  • LLM-Integration mit Observability/Governance (Alpi-M)

  • Testing/QA in KI-erweiterten Produkten

  • Schrittweise Migration von regelbasiert zu ML-basiert

1) Ausgangslage und Randbedingungen in der Industrie

Bevor irgendein Modell in Produktion geht, klären wir vier nicht verhandelbare Randbedingungen:

  • Latenz und Jitter: Zykluszeiten im Bereich 10–200 ms sind üblich (z. B. visuelle Prüfung, Taktstraßen). KI darf nicht blockieren. P50, P95, P99 und Worst-Case sind zu planen – und zwar für Hardware unter Last, nicht im Labor.

  • Deterministische Fallbacks: Bei Ausfall, Zeitüberschreitung oder Unsicherheit muss das System reproduzierbar und sicher reagieren (Fail-Safe/Fail-Operational). Regeln verschwinden nicht; sie werden Guardrail.

  • Datenpfad-Souveränität: Daten verlassen das Werk nicht “zum Prompten”. On-prem-Modelle, lokale Vektorindizes, eigene Observability. Telemetrie muss auditierbar sein, nicht “somewhere in the cloud”.

  • Zertifizierbarkeit/Haftung: In regulierten Domänen (z. B. Bahn, Luftfahrt) gehört KI entweder nicht in den sicherheitskritischen Pfad – oder sie wird von deterministischen Hüllen abgesichert. Jede Entscheidung braucht Herkunft und Begründung.

2) Architekturpatterns zum Nachrüsten von ML

Es gibt keine Einheitslösung. Drei Muster haben sich bewährt:

A. In-Process Library

  • Beschreibung: Das Modell läuft als lokal geladene Bibliothek (z. B. ONNX Runtime, OpenVINO) direkt im Host-Prozess (C++/C#/Rust).

  • Vorteile: Minimale Latenz, einfache Deployments, keine Netzabhängigkeit.

  • Nachteile: Sprach- und ABI-Kopplung, Lifecycle von Modellen und Treibern mischt sich mit Applikationsrelease, Memory-Isolation gering.

  • Einsatz: Kleinere Modelle, harte Latenzbudgets, embedded/edge-nahe Integrationen.

B. Sidecar-Inferenzdienst

  • Beschreibung: Separater Prozess auf derselben Maschine (oder demselben Knoten), Anbindung via gRPC/Unix-Socket/Shared Memory.

  • Vorteile: Klare Prozessisolation, eigenes Lifecycle für Modell-Updates, GPU-Sharing möglich, Crash-Isolation.

  • Nachteile: Geringe IPC-Overheads, Schnittstellenpflege notwendig.

  • Einsatz: Bild-/Zeitreihenmodelle, die GPU nutzen; strikte Trennung zwischen Host-App (z. B. Qt/C++) und ML-Stack (z. B. Python/CUDA).

C. Service-Bus/Streaming-Integration

  • Beschreibung: Asynchrones Publish/Subscribe über Kafka/MQTT/AMQP; Batch- oder Streaming-Inferenz.

  • Vorteile: Entkopplung, horizontale Skalierung, Lastglättung, Reprocessing möglich.

  • Nachteile: Höhere End-to-End-Latenz; komplexere Observability; Eignung für “near real-time”, nicht “hard real-time”.

  • Einsatz: Flottenintelligenz, Vorhersagen, die Sekunden statt Millisekunden vertragen; Werksweite Analytik.

Die Entscheidung fällt entlang der Achsen Latenz, Isolation, Release-Frequenz, Ressourcen und Safety Case. In vielen Brownfield-Szenarien ist Sidecar das beste Verhältnis aus Pragmatismus und Robustheit.

Konkretes Beispiel: Visuelle Prüffunktion in C++/Qt-Anlage

  • Ausgangslage: Bestehende Qt-Anwendung steuert Kameras und Werkstückhandling. Zykluszeit 120 ms, CPU-Budget knapp, GPU vorhanden.

  • Architektur:

  • C++ Host-App erzeugt Ringpuffer in Shared Memory (YUV/RGB Frames).

  • Sidecar-Inferenzdienst (Python/CUDA) liest Frames über Zero-Copy, führt Inferenz durch (z. B. Segmentierung, Klassifikation).

  • Ergebnis-Interface per gRPC Async: score, bbox/maske, reason_codes, version, latency_ms.

  • Watchdog im Host überwacht Sidecar Heartbeats; Zeitbudget 80 ms. Bei T≥80 ms: deterministischer Fallback (konservative Regelprüfung).

  • Betriebsdetails:

  • Graceful Degradation: Wenn GPU unter Last, schaltet Sidecar auf leichtere Pipeline (z. B. nur Klassifikation ohne Segmentierung).

  • Canary-Modelle: 5% der Teile werden zusätzlich mit neuem Modell bewertet (nur Logging), Vergleichsmetriken online berechnet.

  • Artefakt-Signaturen: Modelle sind signiert, Host prüft Signatur und Kompatibilitäts-Manifest (Input-Shape, Preprocessing-Hash).

Schnittstelle (beispielhaft, .proto stark vereinfacht):
message Frame { bytes shm_key = 1; uint64 frame_id = 2; uint64 ts_ns = 3; }
message InferenceRequest { Frame frame = 1; string pipeline = 2; }
message InferenceResult {
uint64 frame_id = 1;
float score = 2;
repeated Box boxes = 3;
repeated string reason_codes = 4; // z. B. “edge_crack”, “color_shift”
string model_version = 5;
uint32 latency_ms = 6;
bool fallback_applied = 7;
}

Warum reason_codes? Weil existierende QS-Prozesse und Reklamationscodes weiterleben. ML-Ergebnisse müssen in diese Welt “übersetzt” werden – sonst bleiben sie ein Fremdkörper, den Operations nicht akzeptiert.

3) LLM-Integration in Unternehmensanwendungen – mit Governance by Design

LLMs sind in der Industrie nützlich, wenn sie lokal domänenspezifisches Wissen nutzen: Wartungsanleitungen, Schaltpläne, Störungsmeldungen, Change-Logs. Integration heißt hier: nicht Chatfenster ankleben, sondern kontrollierte, nachvollziehbare Automatisierung.

Grundprinzipien:

  • Retrieval-augmented, nicht copy-paste: LLM beantwortet nur mit fundierten, lokal referenzierten Quellen. Jeder Satz ist auf Dokument-Offsets zurückführbar.

  • Tools statt Allmacht: Das LLM ruft wohldefinierte Tools auf (z. B. Ersatzteil-Suche, Ticket-API, Historienabfrage). Tools sind per striktem JSON-Schema gebunden, Timeouts und Quotas hart.

  • Ask/Act-Trennung: Planen (Text) und Ausführen (Tools) getrennt loggen. Kein “freies” Shell-Kommando, kein Internetzugang. In Industrienetzen sind Agenten Sandboxed.

  • On-prem-Modelle: Offene Gewichte oder lokal bereitgestellte Modelle, Vektorindizes im Firmennetz. Keine Telemetrie an Drittanbieter.