KI nachrüsten statt neu bauen: Wie man ML- und LLM-Funktionen sicher in bestehende Industriesoftware integriert

Problem zuerst: Die härteste Aufgabe ist nicht das Modell
In der Industrie scheitert KI selten am Modell, sondern an der Integration: harte Latenzbudgets, deterministische Steuerkreise, Zertifizierungspflichten, getrennte OT/IT-Netze, DSGVO und kein US-Cloud-Zugriff. Wer versucht, “irgendwo eine Python-Box mit einem Modell” an ein bestehendes System zu kleben, produziert typischerweise eines von drei Problemen: unvorhersehbare Laufzeiten, unprüfbare Entscheidungen oder Governance-Lücken (Datenabfluss, fehlende Auditierbarkeit). Unser Standpunkt ist klar: Souveränität ermöglicht Intelligenz. Deshalb beschreiben wir im Folgenden konkrete Integrationsmuster und -entscheidungen, wie man ML und LLMs in bestehende Systeme nachrüstet, ohne das Produkt zu zerreißen.

Kontext erfassen: Architektur-Aufnahme vor Modellwahl
Bevor ein Byte Modellcode produziert wird, muss die Integrationsfläche klar sein:

  • Datenfluss: Welche Ereignisse, Takte und Protokolle existieren? Zykluszeiten? Batch-Fenster?

  • Determinismus: Welche Teile des Systems sind sicherheitskritisch und brauchen harte Deadlines? Wo sind Soft-Realtime- und Best-Effort-Zonen?

  • Schnittstellen: IPC, Shared Memory, Feldbusse (z. B. PROFINET), gRPC/REST, proprietäre SDKs.

  • Ressourcen: CPU/GPU-Verfügbarkeit am Edge, Strom-/Thermalbudgets, Platz für Beschleuniger.

  • Sicherheitszonen: Air-Gap? Strict outbound deny? Welche Zulassungen/Zertifikate sind tangiert?

  • Betriebsfenster: Wartungsfenster, Rollout-Mechanismen, Patch-Politik, Offline-Fähigkeit.

Das Ergebnis ist eine Integrationsmatrix: welche Funktionalitäten dürfen wo laufen, unter welchen Zeit-/Sicherheitsauflagen, mit welchen Daten und Protokollen. Erst danach ergibt sich, welche Modellklasse und welcher Deploymentschnitt praktikabel sind.

Integrationsmuster für ML in Bestandssoftware
Es gibt keine Einheitslösung. In der Praxis setzen sich fünf Muster durch:

1) Sidecar-Inference-Service

  • Architektur: Das bestehende System ruft über gRPC/Protobuf (oder FlatBuffers für strengere Latenzanforderungen) einen lokalen Inferenzdienst auf derselben Maschine auf.

  • Vorteile: Prozessisolation, reproduzierbare Ressourcenzuteilung, unabhängiges Update des Modells, klare Verträge.

  • Nachteile: IPC/Netzwerk-Overhead, härtere Anforderungen an Verfügbarkeit (Orchestrierung, Watchdog).

  • Einsatz: Visuelle Prüfungen neben C++/Qt-UI, Anomalieerkennung im Maschinenleitstand.

2) In-Process-Inference-Library

  • Architektur: Das Modell läuft als native Bibliothek im Host-Prozess. Typisch: ONNX Runtime, TensorRT, OpenVINO, mit C/C++-Bindings.

  • Vorteile: niedrigste Latenz, keine Netzwerkpfade, deterministischer planbarer Footprint.

  • Nachteile: Memory/Thread-Sicherheitsrisiken im Host, komplexere Zertifizierung/QA, Update nur via Host-Release.

  • Einsatz: Safety-nahe Pfade mit harten Deadlines; air-gapped Defense-/Rail-Umgebungen.

3) Asynchrone Message-Bus-Scoring

  • Architektur: Events werden auf Kafka/Redpanda/MQ publiziert, ein Inferenz-Consumer verarbeitet asynchron, Ergebnisse fließen als Rückkanal-Events.

  • Vorteile: Entkopplung, Backpressure, Reprocessing, robuste Skalierung.

  • Nachteile: Keine Inline-Entscheidungen unter harten Latenzen, zusätzliches Betriebs-Ökosystem.

  • Einsatz: Fleet-Intelligence, Condition Monitoring, Planungs-Optimierungen.

4) Batch-Scoring/ETL

  • Architektur: Periodische Extraktion aus Datenbank/Data Lake, Offline-Inferenz, Rückschreiben von Scores.

  • Vorteile: Minimal-invasiv, gut auditierbar, ideal für Reporting und Entscheidungsunterstützung.

  • Nachteile: Keine Echtzeit, Datenlatenz.

  • Einsatz: Qualitätsberichte, Planwartung, Supply-Chain-Analysen.

5) Edge-Container mit Toolchain-Brücken

  • Architektur: Das Modell wird als OCI-Container mit festen Ressourcenlimits ausgeliefert. Bindings über gRPC/REST, Shared Memory, oder Datei-basierte Schnittstellen.

  • Vorteile: Saubere Isolierung, reproduzierbare Builds, einfache Rollbacks.

  • Nachteile: Container-Overhead auf älterer Hardware, Sicherheitsfreigaben für Container-Layer nötig.

  • Einsatz: Heterogene Feldlandschaften, unterschiedliche Betriebssysteme, mehrere OEMs.

Die Wahl entscheidet sich an Latenz und Determinismus:

  • <10 ms Ende-zu-Ende, Safety-Pfad: In-Process oder Shared Memory mit FlatBuffers.

  • 10–200 ms Soft-Realtime: Sidecar gRPC, evtl. Zero-Copy/UDS.

  • >200 ms / Best Effort: Message-Bus oder Batch.

Datenpfade unter Souveränitätsauflagen
Ohne US-Cloud entsteht oft der Reflex “dann geht KI hier nicht”. Das ist falsch – aber man braucht bewusst gewählte On-Prem-Bausteine:

  • Objekt-Storage: S3-kompatibel (z. B. MinIO) für Rohdaten, Artefakte, Modellversionen. Vorteil: einheitliche API, simple Versionierung, Air-Gap-Sync via Signaturen.

  • Streaming: Kafka/Redpanda on-prem für Ereignisse; Schema-Registry zur evolvierbaren, validierbaren Eventstruktur.

  • Feature Store light: Postgres/TimescaleDB mit klaren Materialisierungsjobs; deterministische Feature-Builds per Commit-Hash.

  • Artefaktverwaltung: Modelle als OCI-Images oder tarred Bundles mit Hash/Signatur; CI/CD über GitLab Runner, Argo Workflows, ohne Internetzugang.

  • Datenversionierung: LakeFS/DVC-ähnliche Patterns – wichtig ist der Prozess: “Experimente sind reproduzierbar, Artefakte sind referenzierbar, Datenzugriffe sind protokolliert.”

  • Verschlüsselung: KMS on-prem, Encryption-at-Rest überall, feingranulare Zugriffsrollen.

Damit entsteht ein souveränes, prüfbares Datenfundament, auf dem ML- und LLM-Funktionen leben können – ohne Cloud-Abhängigkeit.

LLM in Unternehmensanwendungen: andere Risiken, andere Telemetrie
LLMs sind keine “normale” ML-Funktion. Drei Dinge unterscheiden sie in der Integration:

  • Nichtdeterminismus über viele Layer: Prompt, Kontext, Werkzeuge, Temperatur, Modellversion.

  • Potentielle Aktionsreichweite bei Tool-Use: Wenn ein Agent Funktionen aufruft, brauchen Sie strikte Guardrails.

  • Compliance- und Datenschutzrisiken durch freie Texteingaben und -ausgaben.

Technische Grundprinzipien bei der Integration:

  • RAG statt “allwissend”: Retrieval-augmented Generation mit lokalem Vektorindex (pgvector, Milvus). Explizite Wissensbasis, explizite Quellen.

  • Kontextbudget-Management: Chunking, Query-Planer, Dedup, Token-Budgets pro Anfrage, Streaming-Antworten.

  • Modellwahl on-prem: Für interne Anwendungsfälle oft Mistral/Llama-Derivate mit Quantisierung (z. B. int4/int8) ausreichend. Für härtere Jobs gibt es Adapter (LoRA), Distillation, oder spezialisierte kleinere Modelle pro Funktion.

  • Tool-Aufrufe whitelisten: Funktionssignaturen versionieren, Argumente schemavalidieren, Side-Effects nur in Sandboxes erlauben.

  • PII-Redaktion: Vor Prompt-Logging und Persistenz sensible Felder deterministisch maskieren. Retentionszeiten technisch erzwingen.