KI-Funktionen in bestehende Industriesoftware integrieren: Architektur statt Alchemie

Problem zuerst: Die meisten Industrieunternehmen haben keine Greenfield-Landschaft. Produktionsleitsysteme, Qt-basierte HMIs, C++-Services, alte .NET-Frameworks, SPS-Anbindungen über OPC UA – und dazu strikte Netzsegmente, Offline-Standorte, DSGVO-Vorgaben und Lieferkettenanforderungen. In so einer Umgebung ist „Wir bauen mal schnell einen KI-MVP in der Cloud“ kein Plan, sondern ein Risiko. Die schwierigste Aufgabe ist nicht das ML-Modell, sondern die Integration: eine saubere Systemgrenze definieren, deterministisch ausrollen, überwachen, zurückrollen und auditieren.

In diesem Beitrag zeige ich, wie wir KI-Funktionen pragmatisch in existierende Softwareprodukte nachrüsten – ohne Big-Bang-Umbau, ohne Cloud-Abhängigkeit, aber mit technischen Guardrails, die in regulierten, industriellen Umgebungen funktionieren.

Ein Grundsatz vorweg: Souveränität ermöglicht Intelligenz. Wenn das System nicht nachvollziehbar, nicht kontrollierbar und nicht rücksetzbar ist, ist jede ML-Genauigkeit wertlos. Deshalb: Architektur, Observability, Governance – erst dann das Modell.

Typische Integrationsszenarien

  • Visuelle Qualitätsprüfung ergänzen: Ein bestehendes HMI (Qt/C++) und eine Kamerakette liefern Bilddaten. Wir integrieren eine inferenzfähige Pipeline als separaten Prozess, der synchron (für Inline-Prüfung) oder asynchron (für Stichproben) angebunden wird. Ergebnis: „OK/Fehler“-Labels plus Heatmaps, ohne die HMI neu zu bauen.
  • Wissensassistenz für Techniker: Ein On-Prem LLM beantwortet Fragen zu Wartungsdokumenten. Die Integration erfolgt als RAG-Service (Retrieval-Augmented Generation) mit lokalem Vektorindex und strengen Policy-Gates. Keine Verbindung zu US-SaaS, keine Datenabflüsse.
  • Regelbasierte Systeme schrittweise migrieren: Historisch gewachsene Heuristiken laufen stabil, aber sind schwer pflegbar. Wir schalten ML zunächst im Schattenmodus zu, sammeln Telemetrie, kalibrieren Konfidenzen und übernehmen nur einen Teil der Entscheidungen – mit Fallback zum Regelwerk.

Architekturprinzipien, die in Brownfield-Umgebungen funktionieren

1) Trenne die KI von der Hauptapplikation auf Prozess- oder Serviceebene

  • Warum: Speicher- und GPU-Management, Crashes durch native Bibliotheken, und unterschiedliche Release-Kadenz sprechen gegen statische Einbindung.

  • Wie: Ein „Inference Service“ läuft als separater Prozess oder Container. In C++/Qt-Anwendungen spawnen wir z. B. via QProcess einen Child-Prozess, kommunizieren über gRPC/REST oder ZeroMQ. In Windows-Umgebungen ohne Containerisierung notfalls per Named Pipes.

  • Vorteil: Isolierung, kontrollierbare Ressourcen, einfaches Rollback, reproduzierbare Builds.

2) Asynchronität als Default, Synchronität nur wo echt nötig

  • Inline-Entscheidungen an der Linie brauchen harte Latenzbudgets. Alles andere profitiert von Queues.

  • Muster:

  • Inline: Shared-Memory oder gRPC mit harten Timeouts, Prioritätsklassen auf GPU, deterministische Backoffs.

  • Asynchron: Message-Bus (z. B. NATS/Redis Streams), Job-IDs, idempotente Verarbeitung, Dead-Letter-Queues. Der Nutzer sieht einen Fortschrittsstatus, nicht „Spinner forever“.

3) Strangler-Pattern statt Big Bang

  • Setzen Sie eine „Decision Facade“ vor das bestehende Regelwerk. Die Fassade ruft je nach Konfidenz ML oder Regeln oder beide auf.

  • Routing-Strategie:

  • Shadow: ML bewertet im Hintergrund, Entscheidungen kommen weiter vom Regelwerk.

  • Assist: ML liefert Vorschläge, Mensch bestätigt.

  • Gate: Ab Konfidenz-Schwelle übernimmt ML automatisch, darunter fallback.

  • Damit bleibt die alte Logik intakt, während ML-Teile organisch „die Mauer hochwachsen“.

4) Datenverträge statt „wir nehmen, was da ist“

  • Definieren Sie explizite Input-/Output-Schemata für ML-Dienste. Versionieren Sie die Verträge (z. B. v1, v1.1) und schreiben Sie strikte Parser.

  • Nie lose CSVs „aus dem Maschinenraum“ einlesen – das rächt sich bei der ersten Schemaänderung.

  • Validate at the edge: Bevor Daten ins ML gelangen, validieren, normalisieren und mit Kontext versehen (z. B. Sensorkalibrierung, Teil-Seriennummer, Temperaturfenster).

5) Monitoring, aber für ML spezifisch

  • Klassische App-Metriken reichen nicht. Für ML brauchen Sie:

  • Input-Drift-Indikatoren (Verteilungskennzahlen auf Features/Embeddings).

  • Confidence- und Rejection-Raten.

  • Error-Buckets mit Beispielen (nicht nur Zähler).

  • LLM-spezifisch: Prompt-/Kontextgröße, Tool-Calls, Policy-Verstöße, Antwortkategorien.

  • Ohne diese Telemetrie ist jede Fehlersuche reines Raten.

6) On-Premise first für sensible Domänen

  • In Defense, Bahn, Fertigung mit Lieferantenschutz geht es selten ohne On-Prem.

  • Setzen Sie auf lokale Inferenz-Server, Vektorindizes und Artefakt-Repositories. Deployment über Container registries im Firmennetz, optional air-gapped mit signierten Offline-Bundles.

  • Plan B: CPU-Fallback-Pfade, wenn keine GPU verfügbar ist. Für LLM: kleineren quantisierten Checkpoint als Degradationsstufe bereithalten.

Konkret: Drei Referenzmuster

A) CV-Inferenz am Edge (Qualitätsprüfung)

  • Setup:

  • Kamera liefert Bilder an eine Capture-Komponente (bestehend).

  • Neuer Prozess „cv-infer“ lädt ein TensorRT/OpenVINO-optimiertes Modell.

  • Kommunikation: ZeroMQ/gRPC, shared memory für Pixel.

  • Ergebnis: JSON mit Klasse, Score, optionale Heatmap als komprimiertes Overlay.

  • Latenz:

  • Budget fixieren (z. B. <100 ms). Wenn überschritten, liefert der Service „no-decision“ – die Förderstrecke stoppt nicht wegen eines hängenden Modells.

  • Robustheit:

  • Warmup beim Start.

  • Graceful Degradation: Bei GPU-Fehler schaltet auf CPU mit geringerem Durchsatz; HMI zeigt Status an.

  • Testbarkeit:

  • Golden-Set aus realen Bildern, reproduzierbare Seeds, deterministische Engine-Versionen.

  • Hardware-Hashing: Loggen Sie GPU-Treiber- und Engine-Build-IDs mit.

B) Wissensassistenz On-Prem (LLM + RAG)

  • Setup:

  • Dokumenten-Ingestor extrahiert Text (PDF, CAD-Notizen, Wartungspläne), chunked und gehashed.

  • Lokaler Embedding-Service (z. B. kleiner deutschsprachiger Embedding-Encoder).

  • Vektorindex On-Prem (z. B. Qdrant/Milvus) mit Mandanten- und Zugriffsregeln.

  • LLM-Inferenz lokal (z. B. vLLM) oder auf Edge-Servern; keine externe API.

  • Pipeline:

  • Anfrage -> Retrieval -> Prompt-Konstruktion mit zitierten Quellen -> Antwort.

  • Tool-Aufrufe (z. B. ERP-Tickets erstellen) erfolgen nur über whiteliste Funktionen mit strengen Parametern.

  • Governance:

  • Prompt- und Antwort-Logging mit PII-Redaktion vor Speicherung.

  • Policies: Keine freie Internetrecherche, keine nicht-freigegebenen Datenquellen.

  • Evaluations-Hooks: automatische Checks auf Antwortformat, Quellenbezug, verbotene Inhalte.

  • Beobachtbarkeit:

  • Session-Tracing, Token-Statistiken, Antwortclassifications, Benutzerfeedback-Schleife.