KI nachrüsten statt neu bauen: So integrieren wir ML und LLMs in Bestandssoftware – souverän, testbar, beherrschbar

Die meisten Industrieunternehmen brauchen keine neue „KI-Plattform“. Sie brauchen praxistaugliche Erweiterungen für vorhandene Produkte: bessere Qualitätssicherung, effizientere Wartung, schnellere Wissensabfragen, robustere Automatisierung. Das schwerste daran ist nicht das ML-Modell – es ist die Integration in bestehende Software, Prozesse und Sicherheitszonen. Wer in regulierten, sicherheitskritischen oder schlicht hochverfügbaren Umgebungen arbeitet, kennt die eigentlichen Hürden: Datenhoheit, DSGVO, On-Premises-Betrieb, Update-Restriktionen, Offline-Szenarien, lange Validierungszyklen.

Unser Grundsatz: Souveränität ermöglicht Intelligenz. Eine integrierte KI nützt nur, wenn sie kontrollierbar, rückführbar und auditierbar ist. Im Folgenden skizzieren wir konkrete Integrationsmuster aus realen Projekten – kein Technologie-Hype, sondern Architekturen, Deployment-Modelle, Teststrategien und Migrationspfade, die in Defense, Manufacturing, Bahn, Bau, Textil oder Aviation funktionieren.

1) Problem zuerst: Was ändert KI an Ihrem Softwareprodukt – und was darf sich auf keinen Fall ändern?

Bevor das erste Modell trainiert wird, sind die technischen Nicht-Funktionalen Anforderungen zu klären. Typische Vorgaben in Industrieprodukten:

  • Service-Verträge bleiben stabil: Das UI, die Feldbus-Schnittstellen, der OPC-UA-Server oder die bestehenden APIs dürfen sich nicht ändern – höchstens erweitern.

  • Uptime/Realtime-Budgets: „Max. 50 ms zusätzliche Latenz pro Zyklus“ ist eine harte Grenze, die die Architektur diktiert.

  • Datenhoheit: Keine Abflüsse in US-Clouds, kein Telemetrieversand ins Internet, nachvollziehbare Datenflüsse und Speicherorte.

  • Auditierbarkeit: Entscheidungen und ihre Inputs sind nachvollziehbar, Versionen reproduzierbar, Artefakte signiert.

  • Rollback-Fähigkeit: Jede KI-Funktion kann temporär abgeschaltet oder auf Regel-Backup zurückfallen.

Wenn diese Leitplanken klar sind, lässt sich die Integration gezielt planen – sonst wird die KI-Erweiterung zum Fremdkörper.

2) Die drei Grundmuster der KI-Integration

In Bestandsprodukten sehen wir immer wieder dieselben Integrationsmuster. Sie sind bewusst simpel gehalten, um Validierung, Betrieb und Support nicht zu überfrachten.

  • Sidecar-Service mit stabilem Vertrag
  • Das Bestandsprodukt spricht mit einem separaten Inferenzdienst (lokaler Prozess, Container oder Edge-Box) über einen klaren RPC-Vertrag (z. B. gRPC/REST). Das UI/Backend bleibt unverändert, nur ein Adapter wird ergänzt.
  • Vorteile: Entkoppelte Entwicklung, kontrollierte Ressourcen (GPU/CPU) im Sidecar, klarer Lifecycle. Rollback = Sidecar stoppen, Fallback = Regeln anwenden.
  • Event-getriebener Detektor
  • Die Applikation publiziert Ereignisse (z. B. Messwerte, Bilder, Logiken) in einen Bus; der Detektor konsumiert, reichert an und publiziert Resultate. Ideal für Asynchronität, Pufferung und Shadow-Betrieb.
  • Vorteile: Zero-Touch am Kern, gute Observability, unkomplizierte AB-/Champion-Challenger-Setups.
  • Strangler-Pattern um regelbasierte Module
  • Ein Anti-Corruption Layer kapselt das alte Regelwerk. Das ML-Modul wird parallel angesetzt, entscheidet zunächst in wenigen, klar begrenzten Fällen. Anteil wird sukzessive erhöht.
  • Vorteile: Niedriges Risiko, kontrollierte Übernahme, schrittweise Validierung.

Auf Schnittstellen-Ebene bedeutet das: Verträge frieren, semantische Versionierung, ein schmaler DTO für Inputs/Outputs, feature-toggles und deterministische Fallback-Wege.

3) On-Prem-Deployment unter Souveränitätsanforderungen

In Produktionsnetzen ist das Deployment der KI wichtiger als der Modellname. Etablierte Topologien:

  • Edge-Sidecar mit optionaler GPU
  • Ein Mini-PC oder Container neben der Anlage. Er verarbeitet Bilder/Sensorik lokal. Keine Daten verlassen die Zelle. Updates erfolgen über ein internes Registry/Repo, Artefakte sind signiert.
  • Latenzen sind minimal; ideal für visuelle Inspektion, Anomalieerkennung, NLP auf lokalen Dokumenten.
  • DMZ-Cluster für mehrere Linien/Fahrzeuge
  • Zentraler Inferenz- und RAG-Dienst in der Werks-DMZ. Daten aus Zellen laufen „nach oben“, Ergebnisse zurück. Strikte Zonen-Trennung, Protokoll-Gateways, Read-only-Mounts für Modelle/Embeddings.
  • Air-gapped mit periodischer Synchronisation
  • Kein Internetzugang. Artefakte (Modelle, Container, Prompt-Versionen) wandern via Wechseldatenträger, sind kryptografisch signiert. Telemetrie wird lokal rotiert und für Audits exportiert.

Ressourcenplanung:

  • GPU-Zuweisung strikt managen (pro Inferenzdienst), Top-K Threads begrenzen, Backpressure aktiv, Dynamic Batching nur, wenn Latenzbudget es erlaubt.

  • Tokenizer/Embedding-Versionen pinnen. Rolling Upgrades nur in Kompatibilitätsfenstern, sonst Doppelbetrieb mit Index-Neuaufbau.

Sicherheit:

  • Secrets nie im Container-Image; lokal per KMS/HSM oder OS-Keyring einspeisen.

  • SBOMs und Signaturen verpflichtend; reproduzierbare Builds, Attestierung der Artefakte.

  • Keine Telemetrie nach außen; interne Observability-Endpunkte über Mutual TLS.

4) KI in Legacy-Stacks: Beispiel HMI/Qt/C++ und Vision

Ein realtypisches Szenario: Eine C++/Qt-HMI steuert eine Station, die Kamera liefert Bilder. Anforderungen: <100 ms zusätzliche Latenz, 24/7 Betrieb, kein Internet.

Pragmatisches Pattern:

  • Ein schlanker gRPC-Adapter in C++ bindet einen lokalen Vision-Sidecar an.

  • Der Sidecar lädt das Modell bei Start, pinned Affinitäten (CPU/GPU), wärmt Pipelines.

  • Der Adapter liefert entweder einen „Defekt“-Enum mit Konfidenz und Bounding Boxes oder Nothing-Detected.

  • Fallback: Wenn Sidecar nicht erreichbar oder Konfidenz < Threshold, greift das bestehende Regelsystem (z. B. Kanten-/Helligkeitsregeln). Das UI markiert den Pfad (KI oder Regel), damit Service-Teams nachvollziehen können, „wer entschieden hat“.

Testbarkeit:

  • Ein Replay-Modus füttert den Sidecar mit gespeicherten Bildserien („golden runs“).

  • Vertragstests prüfen DTOs, Fehlermodi, Latenzgrenzen. Kein Modellwissen nötig.

  • Shadow Mode: Sidecar bewertet mit, aber Entscheidungen bleiben vorerst regelbasiert. Disagreements werden geloggt – die Grundlage der späteren Migration.

5) LLMs im Unternehmen: RAG, Tool-Use, Governance – ohne Cloud-Abhängigkeit

LLM-Integration ist kein Chatbot-Button, sondern eine Architekturfrage. On-Prem funktioniert zuverlässig, wenn man sie auf drei Bausteine reduziert:

  • Retrieval-Augmented Generation (RAG)
  • Ingestion: Dokumente in eine interne Pipeline (Extraktion, Chunking, Metadaten). PII wird vor der Vektorisierung entfernt oder pseudonymisiert.
  • Vektorindex lokal (z. B. in einer DB-Erweiterung oder dediziert). Versionen und Indizes sind nachvollziehbar.
  • Query: Die Anwendung reicht eine Nutzerfrage mit Kontext (Rollen, Berechtigungen) ein. Der Retriever filtert per ACLs. Das LLM generiert nur basierend auf freigegebenem Kontext.