Titel: KI nachrüsten statt neu bauen: Wie Sie ML und LLMs sauber in bestehende Industriesoftware integrieren

Hinweis zur Quellenlage: Für diesen Beitrag wurden keine verifizierten externen Quellen bereitgestellt. Der Text basiert auf erprobten Integrationsmustern aus der industriellen Softwareentwicklung und praxisnahen Projekterfahrungen in DACH/BENELUX/Nordics. Umsetzungsdetails sind bewusst konkret gehalten; technologische Beispiele dienen als Muster, nicht als Produktempfehlungen.

Warum dieser Artikel nicht mit dem Modell beginnt
Wenn Sie KI-Funktionen in ein bestehendes Produkt integrieren, ist das ML-Modell selten die Engstelle. Das Risiko liegt an den Schnittstellen: Latenzbudgets, deterministisches Verhalten, Datenflüsse, Governance und Betrieb in souveränen Umgebungen (on‑prem, air‑gapped, DSGVO). Der eigentliche Engineering-Job ist, ein neues probabilistisches Subsystem in eine bestehende deterministische Welt zu setzen, ohne das Systemverhalten zu zerbrechen. Und das unter echten Nebenbedingungen: Safety, Zertifizierung, Hardwarelimits, Schichtbetrieb, Works Council, Offline-Vorgaben, kein US‑Cloud‑Zwang.

Dieser Beitrag beschreibt bewährte Integrationsmuster, die wir in Industrieprojekten einsetzen – mit Fokus auf KI-Nachrüstung in Bestandssoftware, LLM-Einbindung inklusive Observability/Governance (Alpi‑M), Testing/QA und schrittweiser Migration von Regelwerken zu ML.

1) Bestandsaufnahme: Erst die Systemgrenzen, dann die KI
Bevor ein Byte KI-Code in die Codebasis wandert, klären Sie vier harte Rahmenbedingungen:

  • Latenz- und Durchsatzbudgets: Wo liegt das echte Zeitbudget? Zykluszeiten in der Linie? Round-Trip in HMI-Interaktionen? Bei LLMs: max Tokens pro Sekunde, Antwortlatenz pro User, Maximalparallelität im Peak.
  • Determinismus und Reproduzierbarkeit: Wo ist deterministisches Verhalten Pflicht (z. B. SPS-nahe Steuerung, sicherheitskritische Workflows)? Wo darf probabilistisches Verhalten existieren, und welche Fallbacks braucht es?
  • Datensouveränität und Betriebsort: On‑prem/Edge, air‑gapped, Datenminimierung. Muss Inferenz 100 % offline laufen? Sind externe Endpunkte kategorisch ausgeschlossen? DSGVO-Verarbeitungszwecke, Löschkonzepte, Audit.
  • Lebenszyklus und Zertifizierung: Wie ändern wir das System, ohne bestehende Zertifizierungen zu verlieren? Welche Artefakte und Evidenzen benötigt QA/Compliance? Wie handhaben wir Modellwechsel als regulierte Releases?

Dokumentieren Sie diese Antworten als nicht-funktionale Anforderungen. Sie sind der rote Faden für Architekturentscheidungen.

2) Die richtige Integrationsnaht wählen
Der größte Fehler ist, das Modell an die falsche Schnittstelle zu setzen. Drei typische “Nähte” haben sich bewährt:

  • Beobachternaht (Shadow Mode): Die KI beobachtet Datenströme (z. B. Bilder, Telemetrie) passiv, produziert Predictions, die zunächst nicht ins Kerngeschäft eingreifen. Perfekt für erste Produktiviterationen.
  • Empfehlung mit menschlicher Bestätigung: KI schlägt Aktionen oder Diagnosen vor, Operator bestätigt. Ideal bei mittlerem Risikoprofil und wenn Bediener sowieso im Loop sind (z. B. visuelle Prüfung, Störungsdiagnose).
  • Autonome Entscheidung mit Guardrails: KI agiert selbstständig, aber nur innerhalb klar definierter Constraints. Außerhalb dieser Leitplanken fällt das System auf Regeln zurück.

Die gewählte Naht muss zur Fehlertoleranz passen. Die Kostenmatrix (FP/FN) bestimmt Thresholds, Fallbacks, Eskalationswege.

3) Architekturpatterns für KI-Nachrüstung
Es gibt kein One‑Size‑Fits‑All. Diese Muster decken 90 % der Fälle ab:

  • Sidecar-Inferenzdienst: Das Legacy-System spricht über Unix Domain Sockets oder gRPC mit einem lokalen KI‑Dienst. Vorteile: klare Prozessgrenzen, Crash-Isolation, unabhängiger Deploy-Zyklus, saubere Ressourcenkontrolle. Gut für C++/Qt, .NET oder Java-basierte Kernanwendungen, die eine stabile API möchten.
  • In‑Process‑Inference: Eingebettete Inferenzbibliothek (z. B. ONNX Runtime, OpenVINO, TensorRT) direkt im Prozess. Vorteil: niedrigste Latenz, keine IPC. Nachteil: gemeinsames Schicksal bei Abstürzen, kniffligeres Packaging, ABI-Kompatibilität.
  • Batch-/Stream-Pipeline: Events gehen über einen Bus (z. B. NATS, Kafka/Redpanda) in einen Inferenz-Worker-Pool. Vorteil: Elastizität, Backpressure, Wiederholbarkeit. Gut für Flotten-Telemetrie, Anomaliedetektion, Reporting.
  • RAG‑Dienst für LLMs: LLM bleibt generisch; Fachwissen kommt über Retrieval (z. B. FAISS, Qdrant, Vespa) aus on‑prem Dokumenten. Vorteil: keine Cloud-Abhängigkeit, kontrollierbare Wissensbasis, bessere Aktualität.
  • Agent-Orchestrierung mit Werkzeugzugriff: LLM agiert als Controller, ruft definierte Tools/APIs auf (z. B. SQL-Abfragen, Ticketanlage). Pflicht: harte Policy‑Engine und Observability, sonst unvorhersehbares Verhalten.

Entscheidend sind Schnittstellenverträge: definierte Protobuf/FlatBuffers‑Schemas, klare Rückgabeklassen, Fehlercodes, Confidence‑Scores, Trace‑IDs.

4) Datenpfad und Verträge: Stabilität vor Tempo

  • Schemas festschreiben und versionieren: Backwards‑ und Forwards‑Kompatibilität, Schema‑Registry, klare Deprecation‑Policy. Keine „JSON‑nach‑Gefühl“‑Payloads.

  • Pre-/Post‑Processing als eigene, deterministische Bibliotheken: Keine stillen “Preprocess”-Skripte im Notebook – sie sind Teil des Produkts. Einheitliche Normalisierung, Farb-/Kanalreihenfolge, Einheiten, Zeitsynchronisierung.

  • Zeit und Ordnung: Für Bild- oder Sensorfusion brauchen Sie konsistente Timestamps (PTP/NTP, z. B. chrony), definierte Toleranzen, Verluststrategien bei Out‑of‑Order.

  • Payloadgrößen und Durchsatz: Für Bild-/Video-Pfade Zero‑Copy bevorzugen (Shared Memory, DMA), komprimierte Formate nur, wenn Verlustfolgen beherrschbar sind. LLM‑RAG: Chunking-Strategie, Overlap, Embedding‑Versionierung.

5) Performance- und Ressourcenengineering

  • Latenzbudget allokieren: Beispiel Inline-Visionsprüfung: 40 ms gesamt; 5 ms Acquire, 8 ms Preprocess, 20 ms Inferenz, 5 ms Postprocess, 2 ms Puffer. Ohne Budget explodiert Tail‑Latenz.

  • Warmup und Pinned Resources: Modelle beim Start laden, Heuristiken/Allocator konfigurieren, Threads pinnen, NUMA beachten. Für GPU: MIG/MPS nutzen, um Interferenzen zu dämpfen.

  • Quantisierung/Batches bewusst wählen: INT8/FP16 kann 2–4x bringen, aber nur mit sauberer Kalibrierung. Micro‑Batching für LLMs erhöht Durchsatz, verschlechtert aber p95‑Latenz – passend zum Interaktionsmuster entscheiden.

  • Degradation-Strategien: Wenn Ressourcen eng werden, schalten Sie kontrolliert herunter: kleinere Modelle, geringere Bildauflösung, weniger RAG‑Dokumente, striktere Timeouts – niemals unkontrolliertes Hängen.

  • Timeouts/Kaskaden vermeiden: Jedes KI‑Call bekommt harte Deadlines. Verfehlt? Fallback. Keine Kaskaden über mehrere Dienste; sonst verrecken Operatoren auf Spinnern.