KI in Bestandssoftware integrieren: Architektur statt Hype

Die meisten Industrieunternehmen stehen heute nicht vor der Frage, welches Machine-Learning-Modell “am besten” ist. Das reale Problem ist Integration: Wie erweitere ich ein bestehendes, oft sicherheitskritisches Softwaresystem um KI-Funktionalität, ohne Verfügbarkeit, Compliance und Wartbarkeit zu gefährden? Wie halte ich Daten souverän unter eigener Kontrolle? Und wie stelle ich nach dem Go-live sicher, dass das System beobachtbar, testbar und auditierbar bleibt?

Dieser Artikel beschreibt konkrete Integrationsmuster, Test- und Governance-Strategien für KI-Erweiterungen in Bestandssoftware. Er richtet sich an CTOs, VP Engineering und Leiter Digitalisierung, die produktive Systeme verantworten – von C++/Qt-Desktopanwendungen über SCADA-Installationen bis zu cloudartigen On-Premise-Plattformen. Unser Blickwinkel: Integration first, Modell second.

1) Ausgangspunkt: Den Integrationsschnitt suchen, nicht das Modell

Bevor ein Modell ausgewählt wird, müssen drei Fragen beantwortet werden:

  • Wo greift KI ins bestehende System ein?
  • Entscheidungspunkte (z. B. Qualitätsfreigabe OK/NOK)
  • Arbeitsabläufe (z. B. Assistenz beim Ticket-Triage)
  • Datenflüsse (z. B. Kamera-Stream → Feature-Extraktion → Alarm)
  • Welche Systemqualitäten sind zwingend?
  • Latenz (Echtzeit vs. Batch)
  • Verfügbarkeit (Redundanz, Failover)
  • Nachvollziehbarkeit (Audit, Erklärungen, Reproduktion)
  • Datenschutz/DSGVO und Geheimschutz
  • Welche Freiheitsgrade existieren?
  • Dürfen wir das UI anpassen?
  • Darf ein externer Prozess/Service angebunden werden?
  • Ist Containerisierung/Kubernetes möglich, oder nur ein monolithischer Installer?

Diese Analyse liefert den Integrationsschnitt: in-process (Bibliothek), out-of-process (Service), über Bus/Events oder als Sidecar.

2) Integrationsmuster für ML in Legacy-Systeme

a) Out-of-Process Inference Service (gRPC/REST)

  • Wann einsetzen:
  • Wenn Sie Sprachenmix haben (z. B. Host in C++/C#, Modell in Python)
  • Wenn Skalierung separat erfolgen soll (GPU/CPU, Batching)
  • Wenn Stabilität gegen Modellabstürze benötigt wird (Crash-Isolation)
  • Architektur:
  • Host-Applikation ruft gRPC/REST-Endpunkte auf (Synchronous Request/Response)
  • Schema als Contract (Protobuf/OpenAPI) mit versionierten Messages
  • Health-Checks, Timeouts, Circuit Breaker, Retries
  • Trade-offs:
  • + Isolation, Skalierung, einfache Rollbacks
  • – Overhead durch Serialization, Netzwerk, mehr Komponenten
  • Praxis-Hinweis:
  • Für Video-/Bilddaten: Zero-Copy/Shared-Memory oder kompaktes Zwischenformat (z. B. NV12/FP16-Tensors), sonst explodieren die Latenzen.

b) In-Process Inference (eingebettete Runtime)

  • Wann einsetzen:
  • Harte Latenz- und Offline-Anforderungen
  • Air-gapped Systeme ohne Container
  • C++/Qt/Embedded-Software mit deterministischen Echtzeitanforderungen (so weit KI das zulässt)
  • Architektur:
  • ONNX Runtime, TensorRT oder OpenVINO als native Bibliothek
  • Model-Files als signierte Artefakte mit Versionsprüfung
  • Trade-offs:
  • + Niedrigste Latenz, keine Netzabhängigkeit
  • – Komplexere ABI/Paketierung, knifflige Treiber-/Runtime-Kompatibilität
  • Praxis-Hinweis:
  • Python-Abhängigkeiten vermeiden; wenn unvermeidbar, dann als separater Prozess bridgen (gRPC/IPC), um GIL/Interpreter-State zu isolieren.

c) Sidecar-Pattern

  • Wann einsetzen:
  • Wenn die Host-Anwendung nicht verändert werden darf
  • Wenn man bestehende Schnittstellen “umleiten” kann (HTTP Proxy, File Watcher, Message Tap)
  • Architektur:
  • Sidecar lauscht auf Events/Daten, führt Inferenz aus, liefert Anreicherungen/Entscheidungen zurück
  • Trade-offs:
  • + Minimale Invasion in Legacy-Code
  • – Indirekte Kontrolle, begrenzte Sichtbarkeit in interne Zustände

d) Event-Driven Integration (Message Bus)

  • Wann einsetzen:
  • Lose Kopplung, asynchrone Verarbeitung (z. B. Flottenintelligenz, Predictive Maintenance)
  • Architektur:
  • MQTT/Kafka/AMQP als Backbone
  • Topics: raw, features, inference, decisions
  • Schema-Registry, versionierte Events
  • Trade-offs:
  • + Entkopplung, Reprocessing möglich, gut für Batch/Streaming
  • – Ende-zu-Ende-Latenz komplexer, Backpressure-Handling erforderlich

e) Edge vs. Zentrale

  • Edge-Inferenz:
  • + Geringe Latenz, Datenschutz lokal, robust gegen Netz
  • – Ressourcenbeschränkt, Verteilung/Update komplexer
  • Zentrale Inferenz:
  • + Stärkere Hardware, vereinfachte Verwaltung
  • – Abhängigkeit von Netzwerk, Bandbreite/Vertraulichkeit beachten
  • Hybride Muster:
  • Pre-Filtering am Edge, tiefe Inferenz zentral; asynchrone Rückkopplung

3) LLM-Integration in Unternehmensanwendungen: kontrolliert statt chaotisch

Große Sprachmodelle bringen neue Klassen von Risiken (Halluzinationen, PII-Leaks, nichtdeterministische Antworten). Für produktive Workflows gilt:

a) Use-Case-Selektion und Begrenzung

  • Klassifizieren/Extrahieren: Formulare auslesen, Codes mappen → deterministische Prompts, klare Output-Schemas
  • Suche/Antwort (RAG): Wissensdatenbank mit Retrieval-Augmentation → strenger Kontext, kein offenes “Weltwissen”
  • Agenten/Tool Use: Nur mit klaren Policies, Tools mit Idempotenz und Zeitouts, Approval-Gates für irreversible Aktionen
  • Vermeiden:
  • Freitext-Chat ohne Kontext und ohne Guardrails in produktiven Prozessen

b) Souveräne RAG-Architektur

  • Datenhaltung:
  • On-Premise Vector Store (z. B. PostgreSQL mit Vektor-Extension oder spezialisierter Vektor-DB)
  • DSGVO-konforme Speicherung, Verschlüsselung at-rest und in-transit
  • Indexierung:
  • Offline-Pipeline mit Chunking, Embeddings, Metadaten (Quelle, Version, Gültigkeit)
  • Rebuild-fähig, reproduzierbar (gleiche Embedding-Version → gleicher Index)
  • Inferenz:
  • On-Prem-LLM-Runtime (z. B. vektorisiertes Serving mit GPU/CPU), keine US-Cloud-Abhängigkeit
  • Quantisierung/Batching zur Kostendämpfung
  • Prompting:
  • Strikte Templates, XML/JSON-Ausgabe-Constraints, Validierung gegen Schemas

c) Observability, Governance, Policy Enforcement

LLM-Integration ohne Telemetrie ist Blindflug. Wir beobachten in Projekten die folgenden Essentials:

  • Tracing:
  • End-to-End-Trace vom Nutzer-Event bis zur Antwort inkl. Retrieval-Dokumente und Tool-Aufrufe
  • Token-, Latenz- und Kostenmetriken je Schritt
  • Daten- und Prompt-Logging:
  • PII-Redaktion vor Persistenz (regelbasiert + ML-Detektor)
  • Versionsstempel für Prompts, Modelle, Embeddings
  • Evaluationshaken:
  • Offline-Evals (z. B. Genauigkeit bei Extraktion), Online-Metriken (Klick-Through, Korrekturquote)
  • Metamorphe Tests (robust bei Paraphrasen)
  • Guardrails:
  • Policies für Output (z. B. nur Wertebereiche), Blacklists, Tool-Rate-Limits, Abbruchkriterien
  • Freigabeprozesse:
  • Mensch-in-der-Schleife für riskante Aktionen, Vier-Augen-Prinzip