Titel: KI in Bestandssoftware integrieren: Architektur, nicht Hype

Die schwierigste Aufgabe bei KI-Projekten in der Industrie ist nicht das Modell. Es sind Latenzbudgets, Fallbacks, Datenverträge, Sicherheitszonen, Audits und ein Betrieb, der auch fünf Jahre später noch tragfähig ist. Wer KI-Funktionen in bestehende Software einführt, bewegt sich in gewachsenen Architekturen: SPS-nahe Systeme, monolithische Anwendungen, hochregulierte Domänen, air-gappte Netze, lange Release-Zyklen. In diesem Umfeld entscheidet Integrationsdisziplin über Erfolg — nicht der neueste ML-Stack.

Dieser Beitrag beschreibt Integrationsmuster, die sich in Industrieprojekten bewährt haben: von der Inferenz-Entkopplung über Datenpfade und on-prem Deployment bis hin zu QA und schrittweiser Migration von Regeln zu ML. Wir vertreten dabei eine klare Haltung: Souveränität ermöglicht Intelligenz. Für DACH-Industrien ist on-premise ohne US-Cloud-Abhängigkeit meist keine Ideologie, sondern eine Sicherheits- und Compliance-Notwendigkeit.

1) Ausgangslage: Brownfield und harte Randbedingungen

  • Software-Landschaft: Legacy-Monolithen (C++/Qt, .NET, Java), SPS- und Feldbus-Anbindung, historisch gewachsene Datenbanken ohne saubere Domänenmodelle.
  • Nichtfunktionale Anforderungen: deterministisches Verhalten, kurze Antwortzeiten an der Maschine, begrenzte Rechenressourcen am Edge, teils air-gapped Umgebungen, Auditabilität (z. B. in Defense), DSGVO-Konformität, Sicherheitszertifizierungen.
  • Release-Realität: große Regressionstests, lange Freigabeprozesse, begrenzte Möglichkeiten für „Move fast“-Iterationen.

In so einer Umgebung ist „wir hängen ein Modell dran“ kein Plan. Benötigt wird ein Integrationsarchitektur-Ansatz, der das bestehende System nicht destabilisiert und trotzdem KI-Funktionalität schnell nutzbar macht.

2) Kernprinzip: Inferenz als entkoppelte Capability

Statt KI-Logik in die Bestandsapplikation zu gießen, entkoppeln wir Inferenz als eigenständige Capability mit klaren Schnittstellen. Drei Bausteine:

  • Inference Gateway: Ein wohldefinierter Service (on-prem Container oder Prozess), der Modelle ausführt und gegenüber der Bestandssoftware eine stabile API bereitstellt. Er kapselt Modellformate, Hardware-Nuancen (CPU/GPU), Caching, Versionierung, Telemetrie und Fallbacks.
  • Feature-Extraktion als Vertrag: Keine „schnellen“ ad-hoc SQLs aus der Anwendung. Definieren Sie Feature-Schemata mit Versionen, Einheiten, Gültigkeitsbereichen. Extraktion erfolgt als wiederholbarer, getesteter Prozess (z. B. über Change-Data-Capture oder ETL), der in CI/CD validiert wird.
  • Transport passend zum Latenzbudget:
  • Inline gRPC/REST für Interaktionen <100 ms mit Circuit Breaker, Timeouts, Caches.
  • Event-getrieben (z. B. Kafka/NATS) für asynchrone Fälle wie Predictive Maintenance, bei denen Sekunden/Minuten okay sind. Die Anwendung konsumiert Ergebnisse, sobald verfügbar.

Schnittstellen-Design ist hier entscheidend. Halten Sie Input/Output schematisch stabil (z. B. Avro/Protobuf/JSON-Schema) und versionieren Sie sie unabhängig von Modellversionen. Ein Beispiel für ein robustes Vorhersage-Schema (vereinfacht, inhaltlich):

  • Request: input_id, timestamp, feature_version, features (key→value), context (tenant, asset_id)
  • Response: input_id, model_id, model_version, prediction, confidence, decision_explain (Top-Features), policy (angewandte Schwellen), trace_id

So lassen sich Modelle austauschen, ohne die Anwendung zu brechen — solange der Vertrag eingehalten wird.

3) Deployment in souveränen Umgebungen

On-prem heißt: Sie verantworten Infrastruktur, Sicherheit und Supply Chain. Ein pragmatisches Setup:

  • Orchestrierung: Kubernetes on-prem oder Bare-Metal mit Systemd-Services, je nach Reifegrad. Für GPU-Workloads: NVIDIA GPU Operator oder dedizierte Kubernetes-Nodepools; andernfalls CPU-optimierte Runtimes.
  • GitOps: Konfigurationen, Modelle und Policies als deklarative Artefakte mit signierten Releases. Keine „ssh in Prod“.
  • Artefakt- und Modell-Registry: Interne Container-Registry, Model Registry (z. B. als Artefakte mit Metadaten: Herkunft, Trainingsdatenversion, Lizenzen). Reproduzierbarkeit ist Pflicht.
  • Supply-Chain-Sicherheit: SBOMs, Signaturen (z. B. Cosign), Scan-Pipelines, Freigabe-Workflows. Für Defense/rail-Umgebungen: Air-gap-Synchronisierung mit Offline-Validierung.
  • Geheimnisse und Schlüssel: mTLS für Services, Service Accounts, KMS/HSM on-prem. Keine Klartext-Schlüssel in ConfigMaps.
  • Observability: Metriken/Logs/Traces on-prem aggregieren. KI-spezifische Telemetrie (Confidence-Drift, Input-Distributionen) gehört gleichberechtigt neben Latenzen und Fehlerraten.

4) Datenpfad: Von Legacy-DB zu robusten Features

  • Change-Data-Capture (CDC): Statt periodischer „dump-and-hope“-Exporte Ereignisse auf Tabellenänderungen, um Features quasi in Echtzeit zu aktualisieren, inkl. Schema-Versionierung.
  • Preprocessing deterministisch: Fixierte Versionen für Skalierung/Normalisierung/Encoding. Jede Modellvorhersage protokolliert Preprocessing-Versionen für Reproduzierbarkeit.
  • Feature-Cache/Store on-prem: Kein externer SaaS-„Feature Store“. Ein interner Service oder Datenbank mit Feature-Snapshots zur Vorhersagezeit, inklusive Zeitstempel und Source-Hashes.
  • PII/DSGVO: Minimierung vor Speicherung, Pseudonymisierung, Zweckbindung dokumentieren. Für Vektorindizes (LLM-Retrieval): Verschlüsselung at rest, Zugriff über RBAC, Löschkonzepte.

Für CV/Visionsysteme: Standardisieren Sie Bildpfade, Farbräume, Auflösungen und Kompressionsprofile. Preprocessing muss bitgenau stabil sein, sonst laufen offline Evaluations und Online-Verhalten auseinander.

5) Betriebsmodi und Latenzbudgets

  • Inline-Inferenz: Bedienoberflächen, Qualitätsentscheid an der Linie. Anforderungen: p50 < 50 ms, p99 < 200 ms, deterministische Preprocessing-Pfade, lokales Caching, Hardware-Budget kalkuliert.
  • Nearline/Streaming: Zustandsdiagnosen (Flotte, Bahn), p50 Sekundenbereich, Ereignis-Streams mit genau-einmaliger Semantik, Reprocessing-Pipelines.
  • Batch: Trainingsdatenaufbereitung, periodische Scorings, Reports. Planbar, nutzt nicht kritische Zeitfenster.

Cache-Strategie: Schlüssel = (input_id, feature_hash, model_version). TTL und Invalidation sind Produktentscheidungen. Wichtiger Punkt: Caches müssen sicherheitskritische Änderungen erkennen (z. B. neue Kalibrierung), sonst verfestigen sich Alt-Ergebnisse.

6) Qualitätssicherung und Governance — mehr als „Accuracy“