Titel: KI-Funktionen in bestehende Industriesoftware integrieren – ohne das Produkt zu zerreißen

Einleitung: Das Modell ist selten das Problem
Wenn wir KI in Bestandssoftware nachrüsten, ist das eigentliche Risiko selten das ML-Modell. Die echte Komplexität liegt in Integrationsgrenzen, Latenzbudgets, Robustheit, Testbarkeit, Betrieb und Compliance. In industriellen Umgebungen kommen weitere Randbedingungen hinzu: On-Premise-Betrieb ohne Abhängigkeit von US-Clouds, Datenhoheit, deterministische Fallbacks, lange Produktlebenszyklen und Sicherheitsanforderungen. Diese Realität verträgt sich schlecht mit dem üblichen „schnell mal ein API-Experiment“ – gefragt sind Architekturentscheidungen, die Ihre bestehende Software respektieren, schrittweise migrieren und jederzeit rückbaubar sind.

In diesem Beitrag fokussiere ich auf die Integration. Keine Modelltheorie, keine Hypes. Sondern Muster, die sich in Projekten in Verteidigung, Fertigung, Bahn, Bau, Textil und Luftfahrt bewährt haben – jeweils mit Blick auf Souveränität, Wartbarkeit und testbaren Betrieb.

Typische Ausgangslage und Randbedingungen

  • Monolithische Kernanwendungen (häufig C++/Qt oder .NET), langlebig, mit deterministischen Workflows und klaren SLAs.

  • Daten leben in proprietären Formaten oder Legacy-Datenbanken, teils fragmentiert über Subsysteme.

  • Sicherheitszonen und Air-Gap-ähnliche Netzsegmente, in denen kein externer API-Call zulässig ist.

  • Anforderungen an Nachvollziehbarkeit und Audit: Warum hat die Software X entschieden? Welche Datenbasis? Welche Modellversion?

  • Team-Setup ohne dediziertes MLOps-Team – Integration muss von Softwareingenieurinnen und -ingenieuren tragbar sein.

Daraus folgt: Wir müssen KI-Funktionen als gut abgegrenzte, austauschbare Bausteine einführen, mit klaren Verträgen zum Legacy-System, mit deterministischen Fallbacks und nachvollziehbarem Betrieb – on-premise, DSGVO-konform und ohne externe Cloud-Abhängigkeiten.

Architekturprinzipien für die KI-Nachrüstung
1) Contract-first statt Modell-first
Definieren Sie zuerst, was das Legacy-System zuverlässig und stabil von der KI-Erweiterung erwartet:

  • Datenvertrag (Input-/Output-Schema, Einheiten, Grenzfälle)

  • Latenzbudget und Timeout-Strategie

  • Fehlerklassen und Fallback-Pfade (z. B. „No Decision“, „Low Confidence“, „Degraded Mode“)

  • Idempotenz und Wiederholbarkeit (gleiche Eingabe → gleiche Entscheidung bzw. definierte Stochastik)

2) Strikte Entkopplung
Kapseln Sie ML-Logik in isolierten Services, die über klar definierte Schnittstellen angebunden sind (gRPC/Protobuf oder stabiles HTTP/JSON). Keine tiefen Verflechtungen in den Monolithen. So bleiben Austausch, Upgrades und Abschaltungen beherrschbar.

3) Deterministische Grenzen
An den Berührungspunkten zur Bestandsanwendung müssen deterministische Entscheidungen möglich sein: Confidence-Thresholds, Regel-Fallbacks und harte Guards gegen Nicht-Determinismus (Seeds fixieren, Batching steuern, Quantisierung bewusst wählen).

4) Schattenbetrieb vor Umschaltung
Neue KI-Pfade laufen zunächst „Shadow“ mit – ohne Entscheidungen zu beeinflussen, aber mit Telemetrie. Erst wenn Qualität und Stabilität belegt sind, wird der KI-Pfad schrittweise aktiv (Canary).

5) Observability und Governance von Tag 1
Ohne Sichtbarkeit ist jede KI-Integration ein Blindflug. Tracing, Metriken, strukturiertes Logging, Prompt-/Response-Auditing (für LLMs), Modellversionierung – alles on-prem, revisionssicher und DSGVO-konform.

Bewährte Integrationsmuster
Sidecar-Inferenz neben dem Monolithen

  • Wann: Wenn die Kernanwendung hart an Echtzeitgrenzen operiert oder nicht umgebaut werden darf.

  • Wie: Ein co-lokaler Prozess (Container oder Dienst) übernimmt Feature-Extraktion, Modellinferenz und Post-Processing. Kommunikation per gRPC mit Zeitbudgets.

  • Vorteile: Geringe Latenz, isolierte Ressourcenverwaltung (z. B. dedizierte GPU), unabhängige Deployments, schnelle Rollbacks.

  • Praxis-Hinweis: Für C++/Qt-Clients lohnen sich generierte gRPC-Stubs. Für Python-Modelle ist der Sidecar in Python oder als ONNX-Runtime/Triton-Server sinnvoll, je nach Hardware.

Strangler-Pattern für schrittweise Migration von Regeln zu ML

  • Wann: Wenn bestehende regelbasierte Pipelines teils gute Ergebnisse liefern, teils an Grenzen stoßen (Heuristiken, schlecht skalierbar).

  • Wie: Der ML-Service übernimmt schrittweise Teilpfade mit klaren Kriterien:

  • Niedrige Kritikalität → ML bevorzugt

  • Hohe Kritikalität → Regel-Fallback bleibt Master

  • Confidence-Gates und Whitelists/Blacklists für Domänenfälle

  • Vorteile: Reversibel, auditierbar, überschaubare Risiken.

  • Praxis-Hinweis: Messen Sie kontinuierlich die Überschneidungsmenge „ML widerspricht Regel“. Diese Konflikt-Menge ist das wichtigste Triage-Signal für weitere Migration oder Feature-Engineering.

Event-getriebene Entkopplung

  • Wann: Wenn mehrere Subsysteme (z. B. Sensorik, Planung, Qualitätssicherung) KI-Funktionen nutzen sollen.

  • Wie: Ein Message-Bus (on-prem) entkoppelt Produzenten (Datenquellen) von Konsumenten (Inferenz-Services, Post-Processor, Auditor). Befähigt Replays, Backfills und parallele ML-Experimente.

  • Vorteile: Geringere Kopplung, bessere Fehlertoleranz, Drosselung und Backpressure steuerbar.

  • Praxis-Hinweis: Legen Sie Event-Schemata versionierbar an und nutzen Sie Schema-Validierung im CI.

LLM-Integration als Middleware-Schicht

  • Wann: Für Wissensabfragen, Prozedurenassistenz oder semistrukturierte Texteingaben.

  • Wie: Keine direkten Aufrufe aus der Kernanwendung in ein LLM. Dazwischen liegt eine LLM-Middleware, die:

  • Retrieval-Augmentation (on-prem Vektor-Store) übernimmt,

  • Prompts versieht (Kontext, Rollen, Policies),

  • Ausgaben normalisiert und validiert (Schemas, Tokens, Allowed Actions),

  • Governance/Audit sicherstellt (Prompt-/Response-Logs, Policies).

  • Vorteile: Einhaltung der Datenhoheit, klare Kontrollen, Austauschbarkeit der Foundation-Modelle.

  • Praxis-Hinweis: Für on-prem Vektorspeicher sind Postgres mit pgvector oder Suchsysteme mit Vektor-Erweiterung praktikabel. Für LLMs kommen lokal betreibbare Modelle in Frage; die Auswahl richtet sich nach Qualität vs. Hardwarebudget.

Datenpfade mit Datenhoheit

  • Extraktion: Change-Data-Capture aus Legacy-DBs (z. B. über Log-basierte Replikation oder Trigger), exportierbare Schnittstellen oder Fileschnittstellen, die robust und dokumentiert sind.

  • Transformation: Feature-Pipelines als wiederholbare, versionierte Jobs. Keine „Notebook-only“-Pfadabhängigkeiten.

  • Speicherung: On-prem Artefakt- und Modell-Registry. Klare Lebenszykluspolitik (Training, Staging, Production).

  • Zugriff: Rollenbasiert, minimalprinzip. Keine unkontrollierten Datenwege aus sicherheitsrelevanten Zonen heraus.