KI nachrüsten statt neu bauen: Wie Sie ML und LLMs in bestehende Industriesoftware integrieren – ohne Souveränität zu verlieren

Die Integration ist die eigentliche Ingenieursaufgabe, nicht das Modell. Die meisten Fehlschläge bei KI-Projekten entstehen nicht, weil das ML-Modell unlösbar wäre, sondern weil es nicht sauber in bestehende Software, Betriebsprozesse und Sicherheitsanforderungen passt. In Industrieumgebungen – Defense, Fertigung, Bahn, Bau, Textile – sind die Leitplanken klar: deterministische Latenzen, Air-Gap-Betrieb, Zertifizierungen, DSGVO, keine US‑Cloud-Abhängigkeit. Unser Grundsatz: Souveränität ermöglicht Intelligenz. Wer Datenflüsse, Versionen und Laufzeitumgebung nicht souverän beherrscht, bekommt die KI nie stabil in die Fläche.

Im Folgenden zeige ich erprobte Integrationsmuster für ML und LLMs in Bestandssoftware, typische Fallstricke und eine schrittweise Migrationsstrategie von Regelwerken zu ML – mit Fokus auf robusten Betrieb on‑premise. Marketingfloskeln gibt es woanders; hier geht es um Architektur, Schnittstellen und Trade-offs.

1) Ausgangslage in der Industrie: Randbedingungen vor Technik

Bevor Sie über Modelle sprechen, klären Sie die Betriebsrealität:

  • Systemlandschaft: C++/Qt-Desktops, .NET‑Services, SPS/SCADA, Embedded Linux, proprietäre Feldbusse, OPC UA/MQTT-Brücken, gemischte Windows-/Linux-Umgebungen.

  • Netz: Segmentiert, oft air‑gapped; Proxies, Bastion Hosts, eingeschränkte Paketfilter. Keine ausgehenden Verbindungen ins Internet.

  • Betrieb: LTS‑Kernel, Change-Fenster quartalsweise, signierte Artefakte, Zulassungen. Ausfallzeiten kosten real Geld.

  • Nichtfunktionale Anforderungen: Latenzbudgets in Millisekunden, deterministisches Verhalten, Fail‑Safe bei Störungen, Nachvollziehbarkeit (Audit).

  • Datenhaltung: PII und Betriebsgeheimnisse, Datenlokalität in der EU, Lösch- und Zweckbindungspflichten (DSGVO).

  • Organisationsrealität: Teams ohne dedizierten MLOps‑Stack, aber mit starker Software- und QA‑Kultur.

Wer hier „einfach mal einen Cloud‑LLM“ einbaut, scheitert spätestens beim Security Review. Ziel ist eine Integrationsarchitektur, die diese Zwänge als erste Klasse berücksichtigt.

2) Integrationsmuster für ML in Legacy-Systemen

Zentral ist die Entkopplung zwischen Anwendungslogik und Inferenz. Bewährte Muster:

  • Sidecar/Co‑Process: Das ML‑Modul läuft als separater Prozess neben dem bestehenden Service. Kommunikation via gRPC/Protobuf oder ZeroMQ über localhost. Vorteile: Prozessisolation, Crash-Schutz, saubere Ressourcenlimits (cgroups). Nachteil: etwas IPC‑Overhead, aber in der Praxis vernachlässigbar.
  • In‑Process Inferenz: Für extrem enge Latenzbudgets kann ein optimierter ONNX/TensorRT‑Runner direkt in C++/.NET eingebunden werden. Vorteil: minimaler Overhead. Risiko: Stabilität des Hostprozesses bei GPU/Allocator‑Fehlern, schwierigeres Rollback.
  • Message‑Bus (asynchron): Bei Bulk‑Inferenz (z. B. Bildbatches) oder entkoppelten Pipelines eignen sich Kafka/NATS/MQTT. Producer publiziert Jobs, Worker ziehen, Ergebnisse gehen in Ergebnis-Topics. Vorteil: Pufferung, Retry, Backpressure. Latenz höher, aber steuerbar.
  • Edge vs Zentrale: Bild-/Sensor-Preprocessing am Edge (Jetson, x86+iGPU via OpenVINO), schwere Modelle zentral auf A100/L40S. Faustregel: Bandbreite ist teurer als FLOPs; extrahieren Sie deterministische Features am Rand, übertragen Sie nur kompakte Repräsentationen.
  • Strangler‑Fig für Legacy‑Ablösung: Hängen Sie das neue ML‑Modul parallel an die bestehende Regelkomponente. Leiten Sie schrittweise Teilmengen des Traffics um. Alte Komponente bleibt Fallback bis Parität/Überlegenheit bewiesen ist.

Engineering‑Details, die Integration stabil machen:

  • Feature‑Contracts: Definieren Sie ein explizites Schema (z. B. Protobuf) für Features, inklusive Einheit, Skalierung, Version. Versionieren Sie die Feature‑Extraktoren separat vom Modell. „Feature Drift“ ist der Hauptgrund für Produktionsfehler, nicht „Model Drift“.

  • Modellpaketierung: Standardisieren Sie auf ONNX oder TensorRT Engine für Vision/Tabular. Für CPU‑Targets OpenVINO/oneDNN. Containerisieren Sie Inferenzserver mit strikt gepinnten CUDA/CUDNN/TensorRT‑Versionen. Modellhash im Image-Label, nicht nur im Dateinamen.

  • Ressourcenisolierung: Nutzen Sie Kubernetes/Nomad mit GPU‑Device‑Plugin; auf NVIDIA Servern MIG‑Profile, wenn mehrere Workloads eine GPU teilen. Setzen Sie harte Zeitouts + Circuit Breaker. „Fail‑Closed oder Fail‑Open“ muss bewusst entschieden werden: in der Qualitätsprüfung eher Fail‑Closed, in der Anomalie‑Erkennung ggf. Fail‑Open mit Alarm.

  • Datenpfad‑Härtung: Keine losen Dateipfade. Nur signierte Artefakte (Cosign). SBOM für Images. Nur lesender Zugriff auf Produk­tionsdaten wo möglich.

3) LLMs in Unternehmensanwendungen: RAG, Governance und Grenzen

Geeignete Industrie‑Use Cases:

  • Wartungsunterstützung: Fragen zu Handbüchern, Schaltplänen, Störungscodes.

  • Qualitätsberichte: Aggregation von Befunden, Abweichungsbegründungen in natürlicher Sprache.

  • Prozessdokumentation: Zusammenfassungen von Schichtprotokollen, generierte Übergabenotizen.

  • Entwickler‑Enablement in Domänenplattformen (z. B. erklärende Metrik‑Zusammenfassungen).

Weniger geeignet ohne harte Governance:

  • Autonome Steuerung von Anlagen, Bestell- oder Dispositionsentscheidungen. Hier nur mit menschlicher Freigabe und engen Policies.

Architekturbausteine für souveräne LLM‑Integration:

  • On‑Prem Inferenz: Offene Modelle (z. B. Llama 3, Mistral, Mixtral, Qwen) auf vLLM/TGI/llama.cpp je nach Hardware. Quantisierung (8‑/4‑Bit) bringt Durchsatz, kostet Accuracy – messen, nicht schätzen.

  • Retrieval Augmented Generation (RAG): Postgres + pgvector als Vektor‑Store genügt häufig, statt exotischer Datenbanken. Chunking mit Dokumentmetadaten (Anlage, Gültigkeitszeitraum, Klassifikation). Zugriffskontrollen spiegeln das DMS: Row‑Level Security über Tenant/ACL‑Tags. Kein „globaler“ Vektorraum für alle, wenn Mandantentrennung wichtig ist.

  • Tool‑Use/Agenten: Funktionale Fähigkeiten streng whitelisten. Funktionen mit JSON‑Schema definieren, Ergebnisse typisiert validieren. Keine frei formulierten Shell-/DB‑Zugriffe. Ephemere Credentials pro Aufruf. Sandbox für Nebenwirkungen. Mensch‑im‑Loop für Aktionen.

  • Prompt‑Management als Code: Prompt‑Templates versionieren, mit Parametern (z. B. „role“, „style“, „guardrails“). Token‑Budgetierung und Temperatur als Konfig. Output‑Schemas erzwingen (strict JSON Mode oder DSL), Downstream‑Parser robust bauen.

  • Observability und Governance: LLM‑Interaktionen sind nicht deterministisch – ohne durchgängige Nachvollziehbarkeit sind sie nicht auditierbar.