KI nachrüsten statt neu bauen: Wie wir AI-Funktionen in Bestandssoftware integrieren – ohne den Betrieb zu zerreißen

Die meisten produktiven Softwaresysteme in Industrie, Bahn, Aviation oder Bau haben eins gemeinsam: sie laufen länger als jede aktuelle Hype-Kurve. Sie hängen an SPS/SCADA-Ketten, sprechen OPC UA, verschachteln Altsysteme mit Monolithen, und sie erfüllen harte Echtzeitanforderungen, Safety- und Compliance-Regeln. Genau in diese Landschaft sollen heute KI-Funktionen hinein – nicht als Greenfield-App, sondern als Erweiterung. Die härteste Aufgabe ist dabei nicht das ML-Modell. Es ist die Integration.

Dieser Beitrag beschreibt, wie man KI in bestehende Produkte integriert, ohne Verfügbarkeit, Sicherheit oder Souveränität zu kompromittieren. Mit konkreten Architekturmustern, QA-Strategien und einem migrationsfähigen Fahrplan von regelbasiert zu ML-basiert. Unser Blickwinkel: on-premise, DSGVO-konform, ohne US-Cloud-Abhängigkeit. Souveränität ermöglicht Intelligenz – nicht umgekehrt.

1) Systemgrenzen zuerst: Vertrauenszonen, Latenz, Determinismus

Bevor ein einziges Modell trainiert wird, braucht es eine präzise Kartografie:

  • Vertrauenszonen: Wo darf probabilistische Logik hinein? Was bleibt deterministisch? In industriellen Umgebungen gehört die Aktorik-Sicherheitskette (Not-Aus, Safety PLC) in eine eigene, unverhandelbar deterministische Zone. KI gehört vor diese Grenze, nie hinein.

  • Datenpfade vs. Steuerpfade: Trennen Sie Datenveredelung (KI) vom Steuerpfad. KI liefert Empfehlungen, Scores, Anomalieindikatoren. Die Entscheidung, die Anlage zu stoppen, trifft weiterhin die deterministische Logik.

  • Latenzbudgets: Viele KI-Funktionen sind latenzsensibel, aber nicht echtzeitkritisch. Beispiel: Visuelle Fehlererkennung in 80–200 ms ist meist ok, 5 ms nicht. Definieren Sie Budgets je Use Case, sonst wählen Sie unnötig komplexe Deployments.

  • Wiederanlauf und Degradierung: Was passiert beim Ausfall des KI-Teils? Definieren Sie einen „Graceful Degradation“-Modus zurück auf Regeln oder manuelle Bestätigung.

2) Integrationsmuster für ML in Legacy-Systeme

Kein Muster ist universell. Wählen Sie je nach Latenz, Isolierung, Rollout-Sicherheit und Betrieb.

  • Sidecar-Inference neben dem Monolithen
  • Idee: Ein separater Inferenzprozess (Container/Service) läuft auf demselben Host wie der Monolith. Kommunikation per gRPC/UNIX-Socket.
  • Vorteile: Geringe Latenz, Ressourcenisolation, Crash-Isolation.
  • Nachteile: Komplexere lokale Orchestrierung, Versionskoordination.
  • Einsatz: Bildklassifikation im Maschinen-Takt, OCR/Parsing, Anomalie-Score-Generator.
  • Coprozessor über Message Bus
  • Idee: Legacy publiziert Ereignisse (Sensorfenster, Seriennummern, Telemetriedeltas) an Kafka/MQTT/OPC UA PubSub. Der KI-Coprozessor konsumiert, rechnet, publiziert Ergebnis-Topics zurück.
  • Vorteile: Lose Kopplung, natürliche Pufferung/Backpressure, einfache Shadow-Deployments.
  • Nachteile: Höhere Latenz, mehr Infrastruktur.
  • Einsatz: Zustandsdiagnosen, Prädiktive Wartung, Batch-/Mikro-Batch-Anreicherungen.
  • In-Process-Bibliothek
  • Idee: ML-Laufzeit als Bibliothek in den Monolithen laden (C++ Inference Engine).
  • Vorteile: Null Netzwerklatenz, einfache Transaktionskopplung.
  • Nachteile: Hohe Risiken für Stabilität, Memory/GPU-Contention, schwer rollbar.
  • Einsatz: Nur bei strengen Latenzbudgets und wenn deterministische Fallbacks robust vorhanden sind.
  • Batch-Enrichment Pipeline
  • Idee: Offline- oder Nearline-Jobs erzeugen Features/Scores in einer Datenbanktabelle. Die App liest synchronisiert daraus.
  • Vorteile: Minimalinvasiv für das Produktivsystem, ideal für POCs ohne Betriebsrisiko.
  • Nachteile: Keine Echtzeit, komplexe Datenfrische-Logik.
  • Einsatz: Ersatzteilbedarf-Prognosen, Risiko-Scores, Wartungspriorisierung.
  • Edge/On-Prem-Hybrid
  • Idee: Edge-Inferenz nahe an der Maschine, periodische Synchronisierung mit einem On-Prem-Cluster für Retraining/Monitoring.
  • Vorteile: Latenz- und Bandbreitenoptimierung, Souveränität bleibt bestehen.
  • Nachteile: Zwei Betriebsdomänen, Artefakt-Distribution (Airgap) nötig.

Entscheidend ist, dass Sie den deterministischen Kern nicht mit probabilistischer Logik verunreinigen. KI darf empfehlen, markieren, priorisieren – aber nicht die Safety-Kette übernehmen.

3) Datengewinnung im Brownfield: ohne Produktivlast und ohne DSGVO-Verstoß

Training und Monitoring benötigen Daten, ohne die Primärsysteme zu belasten:

  • Read-Replicas und CDC: Nutzen Sie Datenbank-Read-Replicas oder Change-Data-Capture-Streams. Niemals produktive OLTP-Workloads mit Trainingsjobs teilen.

  • Datenverträge: Definieren Sie schematisch, welche Felder für KI zulässig sind. Fixieren Sie Einheit, Semantik, Gültigkeitsbereiche. Jede Änderung ist ein Version-Bump, kein „stilles“ Feld.

  • Pseudonymisierung und Minimierung: Personendaten für KI vermeiden. Wenn unvermeidbar, pseudonymisieren – und das Mapping strikt separiert. Halten Sie die Verarbeitung on-premise; Cloud-Dienste mit extraterritorialen Zugriffsrisiken vermeiden.

  • Zeitreihen und Fensterung: Legen Sie einen Standard für Fensterbildung (z. B. 5 s Sliding Window, 50% Overlap) fest. Inkonsistente Fenster sind ein leiser Qualitätskiller.

  • Labeling-Strategien im Bestand: Nutzen Sie vorhandene Alarme/Fehlerinformationen als schwache Labels. Regeln von heute sind Trainingssignale für morgen.

4) Modell-Lifecycle in produktiven Umgebungen

Integration heißt: kontrollierte Veränderung.

  • Versions- und Vertragsmanagement

  • API-Verträge der Inferenz: Eingabefelder, Normalisierung, Einheiten, Output-Schema. Maschinenlesbar versionieren.

  • Rollback-Fähigkeit: Jedes Modell-Artefakt ist immutabel, mit reproduzierbarer Build-Pipeline (Seed, Preprocessing-Version, Feature-Transform-Version).

  • Deployment-Strategien

  • Shadow Mode: Ergebnisse berechnen, aber nicht verwenden. Telemetrie sammeln, Drift erkennen, Operator-Feedback einbeziehen.

  • Canary: Prozentualer Traffic auf neues Modell, automatischer Rollback bei SLA-Verletzung.

  • Blue/Green: Vollständiges Umschalten mit schneller Rückkehr.

  • Artefakt- und Lieferkette

  • Airgapped Registries: Container- und Modell-Registry on-prem (z. B. mit signierten Artefakten). Kein „curl von irgendwo“ in kritischen Netzen.

  • SBOMs auch für Modelle: Hashes, Trainingsdaten-Schnappschuss, Code-Versionen, Lizenzlage der Laufzeitbibliotheken.

  • Reproduzierbarkeit

  • Fixierte Seeds reichen nicht. Auch Daten-Schnitte, Determinismus der Operatoren (z. B. bei GPU-Kernels), Preprocessing-Libraries müssen eingefroren sein.

5) Observability für KI: nicht nur Logs, sondern Verhalten