KI in bestehende Software integrieren: Architektur statt Hype, Nebenläufigkeit statt Neuentwicklung, Governance statt Blindflug

Das eigentliche Problem bei KI in der Industrie ist selten das Modell. Es ist die Integration in Systeme, die seit Jahren zuverlässig laufen, regulatorisch geprüft sind und harte Nicht‑Funktionalitäten erfüllen müssen: Latenz, Verfügbarkeit, Nachvollziehbarkeit, Datenschutz, Exportkontrolle. Wer diese Randbedingungen ignoriert, landet bei Prototypen, die nie produktiv werden.

Dieser Beitrag skizziert einen technischen Fahrplan aus der Praxis: Wie rüsten wir KI in Bestandssoftware nach, ohne das System zu destabilisieren? Welche Architekturmuster funktionieren wirklich? Wie testen und betreiben wir nichtdeterministische Komponenten? Und wie integrieren wir LLM‑Funktionen souverän und DSGVO‑konform, inklusive Observability und Governance über Alpi‑M?

1) Ausgangslage klären: Was darf sich nicht ändern?

Bevor eine Zeile Code entsteht, klären wir die Systeminvarianten. In industriellen Umgebungen sind das typischerweise:

  • Bestandsgrenzen: Welche Prozesse, Feldbusse, SCADA/PLC‑Schnittstellen, ERP/MES‑Integrationen sind unantastbar?
  • Latenzbudgets: Welche Pfade sind “im Regelkreis” und dürfen keine zusätzlichen 20–50 ms erhalten? Welche sind asynchron unkritisch?
  • Ausfallmodi: Wie muss sich das System verhalten, wenn die KI nicht verfügbar ist oder zweifelt? Safe‑state, degrade‑gracefully, human‑in‑the‑loop?
  • Datenhoheit: Dürfen Daten das Werk verlassen? Falls nein: Air‑gap, on‑prem GPUs, isolierte Netze, kontrollierte Artefaktzufuhr.
  • Nachvollziehbarkeit: Welche Entscheidungen müssen auditierbar sein? Wer genehmigt Modellupdates? Welche Protokolle sind revisionssicher abzulegen?
  • Bedrohungsmodell: Prompt‑Injection bei LLMs, adversariale Inputs bei Vision, Lieferkettenrisiken bei Modellen, Tool‑Execution‑Risiken.

Diese Invarianten bestimmen die Architektur. Alles Weitere (Modellwahl, Framework, Tuning) hat sich ihnen unterzuordnen.

2) Integrationsmuster, die in Legacy‑Landschaften funktionieren

a) Anti‑Corruption Layer vor der KI
Wir entkoppeln die KI‑Logik via klar abgegrenzter Schnittstelle vom Legacy‑Domänenmodell. Das schützt das Altsystem vor ungewohnten Formaten und die KI vor historisch gewachsenem Datenchaos.

  • Eingangsadapter: Normalisieren Messwerte, Bilder, Texte, Kontexte in wohldefinierte Contracts (z. B. Protobuf/gRPC oder versionierte REST‑Schemas).
  • Ausgangsadapter: Übersetzen KI‑Outputs zurück in domänenspezifische Entscheidungen, Scores, Codes. Keine “freien Texte” in Kernprozessen.

b) Sidecar‑Service statt Inline‑Einbau
Die KI läuft in einem separaten, versionierbaren Inferenz‑Dienst mit eigenem Lebenszyklus. Vorteile:

  • Unabhängige Skalierung (z. B. GPU‑Nodepool), Rolling Upgrades, Canary Releases.
  • Klare SLAs (Latenz/Verfügbarkeit) und Rückfallverhalten pro Consumer.
  • Harte Contract‑Tests zwischen Legacy und KI.

c) Strangler‑Fig für Regel‑zu‑ML‑Migration
Wir schalten ML parallel zur vorhandenen Regelstrecke:

  • Shadow Mode: ML bewertet still mit, Ergebnisse werden geloggt und gegen die Regelstrecke verglichen.
  • Gated Rollout: Über Feature Flags/Konfiguration routen wir stufenweise: 0% → 5% → 25% → 100%. Abbruchkriterien sind vorab definiert (Qualität, Latenz, Ausfallraten).
  • Arbiter: Bei Konflikt entscheidet zunächst die Regel oder ein Human‑Gate; ML muss sein Delta konsistent erklären (siehe Explainability weiter unten).

d) Ereignisgesteuerte Kopplung
Anstatt synchrone Tiefenintegration: Ereignisse über einen Message‑Bus (Publish/Subscribe). KI reichert Ereignisse an (“Enrichment”) oder erzeugt Folgetasks.

  • Vorteile: Entkopplung, Backpressure, Replay für Re‑Scoring bei Modellupdates.
  • Anforderungen: Idempotenz, Ordering‑Strategie pro Schlüssel, Schema‑Registry für Versionierung.

e) Deployment‑Topologien

  • On‑Prem Cluster: Kubernetes mit isoliertem GPU‑Pool. Inferenz‑Dienste als Container, Artefakte aus internem Registry, Air‑gap‑fähige Updates.

  • Edge‑Inferenz: Für Vision/Inference nahe an der Quelle (Industrie‑PC), mit periodischer Synchronisation zum Rechenzentrum.

  • Hybrid nur, wenn Souveränität unkritisch: Dann trotzdem mit Pseudonymisierung und strikten Data Contracts.

3) Operationalisierung: Modelle sind nur ein Artefakt

a) Containerisierte Inferenz mit Version‑Pinning

  • Jede Modellversion als unveränderliches Artefakt (Image + Model Bundle).

  • Versionierung auf API‑Ebene (v1/v2) und Modell‑Ebene (1.3.5). Kein “latest” in Produktion.

  • Traffic‑Shaping: Routing nach Version, Canary, A/B, Feature Flag.

b) Feature‑Pipelines konsistent halten

  • “Single Source of Truth” für Feature‑Berechnung: gleiche Logik für Training und Inferenz.

  • Streaming‑Features: Sliding Windows, Ausreißerbehandlung, späte Ereignisse; deterministische Aggregation.

  • Batch‑Features: Planungsfenster, Backfills, Repro‑Stempel (Commit‑Hash, Datenzeitraum).

c) Caching und Determinismus

  • Kalte Starts vermeiden: Warmup beim Deploy, Precomputed Cache für teure Features.

  • Nichtdeterminismus kontrollieren: Zufallssamen, feste Temperatur/Top‑p bei LLM, feste Präprozessoren.

d) Governance‑Artefakte

  • Model Cards: Zweck, Datenbasis, bekannte Grenzen, Risikoklassen, zulässiger Einsatz.

  • Lineage: Wer hat was wann ausgerollt? Reproduzierbarkeit über Build‑Hashes, Signaturen, Prüfsummen.

  • Freigabeprozesse: Vier‑Augen‑Prinzip für produktive Modellwechsel.

4) LLM‑Integration ohne Kontrollverlust

LLMs sind mächtig – und unstrukturiert. In einer Unternehmensanwendung gilt: Erst der Ordnungsrahmen, dann die Generierung.

a) Geeignete Einsatzmuster

  • Wissensabfrage: RAG statt “freier” Antworten. Nur Wissen verwenden, das aus einem kuratierten, versionierten Dokumentenkorpus stammt.

  • Vorgangszusammenfassungen: LLM extrahiert strukturierte Felder (JSON‑Schema) aus Freitexten/Logs.

  • Planungsassistenz: Vorschläge mit Zitationspflicht (Referenzen auf Quellen), nie automatische Ausführung ohne Gate.

b) RAG on‑prem

  • Ingestions‑Pipeline: Dokumente → Chunking → Embeddings → Vektorspeicher. Alles in der eigenen Infrastruktur.

  • Multi‑Mandanten‑Isolation: Indexe/Namespaces je Werk/Abteilung, Berechtigungen aus IAM übernommen.

  • Prompt‑Assembly: Strikte Templates, JSON‑Schemas, maximale Kontextgröße begrenzen, deterministische Parameter für reproduzierbare Tests.

c) Tool‑Use unter Aufsicht

  • Exponierte Funktionen sind strikt schematisiert, mit Allow‑List und Ressourcenlimits (Zeit, Token, IO).

  • Keine Shell/Netzwerkzugänge aus dem LLM heraus; Tools sind Gateways mit Validierung und Audit.

  • Policy Engine: Welche Tools darf welches Szenario/Benutzer verwenden?

d) Observability & Governance mit Alpi‑M
Alpi‑M ist unsere Plattform zur Beobachtbarkeit und Steuerung von LLM‑Agenten in regulierten, on‑prem Umgebungen. Sie adressiert die zentralen Betriebsrisiken: