KI in Bestandssoftware nachrüsten: Integration statt Neubau – mit Souveränität als harte Randbedingung

Die schwierigste Aufgabe an KI-Projekten in der Industrie ist selten das Modell. Es sind die Systeme, in die das Modell eingebettet wird: monolithische Anwendungen mit langen Release-Zyklen, heterogene Feldgeräte, Domänenlogik, die über Jahre gewachsen ist, strenge Qualitäts- und Compliance-Anforderungen, air-gapped Rechenzentren. Genau dort entscheidet sich, ob KI im Betrieb zuverlässig, auditierbar und wartbar läuft – oder ob sie im PoC-Status stecken bleibt.

Dieser Beitrag skizziert einen erprobten Integrationsansatz für Industrieunternehmen, die KI-Funktionen in bestehende Softwareprodukte nachrüsten wollen. Leitlinie ist Souveränität: On-Premise-Deployments, DSGVO-Konformität, keine Abhängigkeit von US-Clouds. Und: Wir starten immer mit dem konkreten Engineering-Problem, nicht mit dem Modell.

Ausgangslage in Industrie-Stacks

Typische Randbedingungen in unseren Projekten:

  • Langelebige Kernsysteme: SCADA/MES/PLM, z. T. mit C++/Qt-Frontends, proprietären Protokollen und festen Datenbank-Schemata.

  • Safety-/Regulatory-Kontext: Eisenbahn, Luftfahrt, Defense mit klaren Nachweis- und Freigabeprozessen. Jede Änderung am System muss auditierbar sein.

  • Geteilte Infrastrukturen: Vom Embedded-Edge-Gerät bis zum zentralen Rechenzentrum, oft ohne Internetzugang, mit segmentierten Netzen.

  • SLA-getriebene Prozesse: Harte Latenzbudgets in der Fertigung, hohe Verfügbarkeit, deterministische Fallbacks.

Daraus folgt: KI muss sich wie eine gut erzogene Bibliothek verhalten – sauber gekapselt, versioniert, mit klaren Verträgen und vorhersehbarem Laufzeitverhalten. Das Modell ist nur ein Baustein in einer integralen Architektur.

Architekturmuster für die Nachrüstung

1) Strangler-Pattern an der Funktionsgrenze

  • Identifizieren Sie eine konkrete, abgegrenzte Funktion (z. B. visuelle Fehlerklassifikation oder Freitext-Suche in technischen Dokumenten).

  • Kapseln Sie diese Funktion in einem neuen, externen Dienst, der die alte Schnittstelle respektiert.

  • Routingschicht vorschalten: Altsystem-Layer entscheidet, wann es den neuen Dienst aufruft (z. B. Shadow Mode, Canary, Confidence-Threshold).

  • Vorteil: Minimale Invasivität, klare Rollback-Option.

2) Sidecar-Inferenzdienst statt Embedded-Model

  • Statt das Modell in den Monolith zu linken, läuft es als separater Prozess/Container auf derselben Maschine oder im selben Segment.

  • Kommunikationen über eine schmale, versionierte API (gRPC/Protobuf für binäre Effizienz oder REST/JSON, falls menschliche Debugbarkeit wichtiger ist).

  • Vorteil: Unabhängige Releasbarkeit des Modells, Ressourcentrennung (CPU/GPU), Crash-Isolation.

3) Asynchron, wo es geht – synchron, wo es muss

  • Synchron für user-facing Interaktionen mit hartem Latenzbudget (z. B. 100–300 ms für UI-Feedback).

  • Asynchron für rechenintensive Analysen (z. B. stündliche Flottenauswertung): Event-Queue, Ergebnis-Callback, Re-Try-Strategien mit Backoff.

  • Entkopplung über Message Bus: Vermeiden Sie enge Kopplung in Prozessketten, die sonst kaskadierende Fehler auslösen.

4) Minimalinvasive Datenzugriffe

  • Keine tiefen Eingriffe in Kerndatenbanken. Exponieren Sie lesende Views (Read-Replicas, CDC-Streams) und definieren Sie Datenverträge.

  • Schreiben Sie Ergebnisse nur in explizit dafür vorgesehene Ergebnis- oder Audit-Tabellen. Niemals in kritische Transaktionstabellen ohne Guardrails.

Datenwege und Data Contracts

Das meiste Scheitern passiert vor dem Modell: fehlerhafte Felder, implizite Semantiken, unerwartete Nulls, creeping scope. Abhilfe schafft ein expliziter Datenvertrag zwischen Legacy-System und KI-Dienst.

  • Schemastrenge: Definieren Sie Protobuf/JSON-Schemata mit semantischer Versionierung (MAJOR.MINOR.PATCH). MAJOR-Brüche sind bewusst und selten, MINOR nur additive Felder, PATCH rein intern.
  • Deterministische Featurisierung: Jede abgeleitete Eigenschaft ist eine reine Funktion der Eingabedaten, mit fixierten Parametern. Featurisierer haben eigene Unit-Tests.
  • Datenqualitäts-Gates: Vor Inferenz: Pflichtfelder vollständig? Wertebereiche plausibel? Zeitstempel konsistent? Andernfalls: definierter Fallback-Pfad.
  • Drift-Signale: Loggen Sie Feature-Statistiken (Mittelwert, Varianz, Kategorienhäufigkeiten) und vergleichen Sie Online gegen Train-Distribution. Drift ist ein Betriebsereignis – mit Ticket und Runbook.

Deploymentmodelle unter Souveränitätsauflagen

On-Prem bleibt der Default. Aber On-Prem ist nicht gleichbedeutend mit „manuell und fragil“.

  • Containerisierte Dienste: Isolieren Sie Runtime-Abhängigkeiten. Nutzen Sie eine interne Registry. Image-Signaturen und SBOMs gehören in die Compliance-Mappe.
  • Orchestrierung: Ob Sie eine Orchestrierungsplattform nutzen oder systemd plus Supervisor – entscheidend sind Wiederanlauf, Health-Checks, Rolling Updates und Ressourcenlimits.
  • Ressourcenplanung: GPU/CPU-Quoten, Batching-Strategien (Trade-off Latenz vs. Durchsatz), NUMA-Affinität bei High-Throughput-Systemen.
  • Air-Gapped Updates: Signierte Artefakte, offline Promotion (Dev → Staging → Prod) via Transfer-Medium mit Prüfsummen. Einhaltung der Freigabeprozesse.
  • Edge-Varianten: Falls Bandbreite/Privacy erzwingt, läuft die Inferenz direkt am Gerät. Gleiches API-Contract, aber kleineres Modell, quantisiert, ohne Remote-Abhängigkeiten.

Migration: von Regeln zu ML – ohne Kontrollverlust

Regelwerke sind explizit, deterministisch und auditierbar. ML ist adaptiv, probabilistisch. Die sichere Brücke dazwischen:

  • Dual-Run (Shadow Mode): ML läuft im Hintergrund, trifft aber keine Entscheidungen. Ergebnisse werden geloggt, gegen Regelwerksergebnisse verglichen und mit Outcomes (Feldrückmeldungen) gelabelt.
  • Risiko-Budgets und Confidence-Thresholds: Legen Sie Grenzwerte fest, ab denen ML die Entscheidung übernehmen darf. Unterhalb: Fallback zu Regeln oder Human-in-the-Loop.
  • Schrittweise Autorisierung: Erst Empfehlungen, dann Soft-Overrides, dann Hard-Decision für Low-Risk-Subfälle.
  • Feature-Parität: Stellen Sie sicher, dass das ML dieselben Inputsignale sieht, die Regeln nutzen. „Green Feature Gaps“ führen zu Phantomverbesserungen im PoC, die in der Produktion kollabieren.
  • Änderungsnachweis: Jede Modellversion hat Release Notes mit Verhaltensänderungen gegenüber Schlüssel-Szenarien. Das gehört in die Freigabeunterlagen.

LLM-Integration in Unternehmensanwendungen – mit Observability und Governance

Große Sprachmodelle sind nützlich für Wissensarbeit in Engineering-Prozessen: Suche in Betriebshandbüchern, Assistenten für Wartungsprozeduren, Generierung strukturierter Reports. Die Hürden in der Industrie sind Sicherheit, Nachvollziehbarkeit und Offline-Betrieb.