KI nachrüsten statt neu bauen: Ein Integrationsleitfaden für industrielle Bestandssoftware

Die harte Arbeit bei KI in der Industrie beginnt selten im Modell. Sie liegt in der Integration in gewachsene Systeme: in Zykluszeiten eines PLC, in Berechtigungsmodelle eines DMS, in Latenzbudgets eines Inspektionssystems, in Audit-Anforderungen einer Sicherheitsabnahme. Wer hier die falschen Schnittstellen, Deploymentmodelle oder Betriebsprozesse wählt, baut sich technische Schulden – auch mit einem hervorragenden Modell. Unser Grundsatz: Souveränität ermöglicht Intelligenz. Datenhoheit, on-premises-Betrieb und kontrollierbare Integrationspfade sind die Voraussetzung, damit KI zuverlässig und verantwortbar Mehrwert in Bestandssoftware liefert.

Ausgangslage: Warum Integration die eigentliche Herausforderung ist

  • Heterogene Systemlandschaften: SCADA, OPC UA, MQTT, historisierte Zeitreihen, monolithische Fachanwendungen, selbstentwickelte ETL-Jobs, Fileshares mit 20 Jahren Historie. Es gibt keine „grüne Wiese“.
  • Harte Umweltbedingungen: Echtzeitnahe Prozesse (Millisekunden bis Sekunden), deterministische Zyklen, Safety- und Compliance-Anforderungen, teilweise luftgetrennte Netzwerke (Air-Gap).
  • Langlebige Release-Zyklen: Validierung, Abnahmen, Sicherheitsgutachten; ein Breaking Change kostet Monate.
  • Daten- und Compliance-Anforderungen: DSGVO, Exportkontrollen, branchenspezifische Normen. Daten dürfen das Werk nicht verlassen, geschweige denn in US-Clouds.
  • Betriebsrealität: IT/OT-Schnittstelle, eingeschränkter Fernzugriff, geplante Wartungsfenster, restriktive Firewall-Regeln.

Leitprinzipien für KI-Integration mit Souveränität

  • Daten-lokal-first: Modelle laufen dort, wo die Daten entstehen oder gespeichert sind. Kein Datenabfluss, keine externen API-Abhängigkeiten.
  • Minimal-invasiv: KI als zusätzliche, klar abgegrenzte Funktionseinheit neben dem Bestand, nicht als Eingriff in Kernprozesse.
  • Explizite Schnittstellenverträge: Versionierte, binär-stabile Verträge (z. B. Protobuf/gRPC) zwischen Bestandssystem und Inferenzdienst.
  • Beobachtbarkeit von Anfang an: Metriken, Traces, Audit-Logs gehören in die erste User Story, nicht in die letzte.
  • Fail-safe-Design: Fallbacks auf regelbasierte Logik, Circuit Breaker, Confidence-thresholds. „Sichere Degradation“ vor falscher Automation.
  • Schrittweise Migration: Von Assistenz über Vorschlagserstellung zu (teil-)automatisierten Entscheidungen, nie Big Bang.
  • Reproduzierbarkeit und Auditierbarkeit: Versionierte Modelle, reproduzierbare Builds, Daten-Herkunft (Data Lineage), dokumentierte Entscheidungen.

Referenzarchitektur für KI-Nachrüstung in Bestandssoftware

1) Datenerfassung und -zugriff

  • Event-getriebene Daten: OPC UA Subscriptions, MQTT Topics, Kafka Topics, Filesystem-Watcher für Bilddaten.

  • Zugriffsadapter: Spezifische Adapterprozesse, die Daten aus OT/IT-Systemen in ein standardisiertes Inferenzschema überführen (z. B. Protobuf Messages mit Zeitstempeln, Sensor-Metadaten, Benutzer-IDs).

2) Inferenzdienst (ML/LLM)

  • Prozessisolation: Containerisierte Services pro Modellfamilie. Für Computer Vision oft GPU-beschleunigt, für Tabular/Anomalie CPU-optimiert.

  • Schnittstelle: gRPC für Latenzkritik, REST für Backoffice-Flows. Strikte Schemas, keine „hässlichen“ JSON-Freitexte ohne Vertrag.

  • Betriebsmodi: Online-Inferenz (niedrige Latenz), Batch-Inferenz (Nachtläufe), Shadow Mode (Ergebnisse ohne Wirkung), Canary (Teilmenge produktiv).

  • Laufzeit: On-prem Kubernetes (k3s/microk8s/Vanilla), Nomad oder Systemd-Services in Edge-Szenarien. Air-gapped Registries für Container-Images.

3) Modell- und Wissensverwaltung

  • Modell-Registry: Versionierung, Signaturen, Freigabestati, Metadaten (Trainingsdaten, Hyperparameter, Lizenz).

  • Feature-/Embedding-Store: Konsistente Merkmalsberechnung zwischen Training und Serving; für LLM-RAG ein Vektorindex (z. B. pgvector, Qdrant) on-prem.

  • Daten-Governance: Data-Lineage und Zugriffskontrollen; Indizierung nur freigegebener Dokumente mit Attribut-basierter Zugriffskontrolle (ABAC).

4) Orchestrierung und Ressourcen

  • GPU-Zuteilung: NVIDIA Container Runtime, ggf. MIG-Partitionierung für deterministische Slices. Triton Inference Server für Batching/Ensembling.

  • Priorisierung: QoS-Klassen für Latenz-kritische Services, CPU/GPU-Pinning, isolierte I/O-Pfade für Kamera-Streams.

5) Observability, Sicherheit und Governance

  • Telemetrie: OpenTelemetry für Traces, standardisierte Metriken (Latenz, Durchsatz, Fehlerraten, Confidence), Log-Korrelation mit Request-IDs.

  • Sicherheitskontrollen: mTLS zwischen Services, Zertifikatsmanagement, Secrets in Vault, RBAC über Service Accounts, signierte Artifacts (Sigstore).

  • LLM-spezifische Governance: Prompt-/Response-Logging mit PII-Redaktion, Retrieval-Kontrollen, Ausgabefilter, menschliche Freigaben für risikoreiche Aktionen. Für diese Ebene setzen wir Alpi-M ein: on-prem Observability und Governance für LLM-Agents, inkl. Prompt-/Knowledge-Audit, Guardrails und Freigabe-Workflows.

Zwei konkrete Integrationsszenarien

Szenario 1: Visuelle Defekterkennung in einer bestehenden Linie nachrüsten

Ausgangslage:

  • Eine Montage-/Prüflinie nutzt bisher regelbasierte Bildverarbeitung (Schwellwerte, Blob-Analyse). Anbindung an das MES via OPC UA, Kamera-Trigger kommt aus dem PLC. Die aktuelle Prüflogik erzeugt zu viele Pseudoausschüsse (False Rejects).

  • Latenzbudget: max. 80–120 ms vom Kameratrigger bis zur Entscheidung (OK/NOK).