KI nachrüsten in Bestandssoftware: Integration ist der harte Teil

Die meisten KI-Projekte scheitern nicht am Modell, sondern an der Integration in bestehende Software. In der Industrie kommt noch ein Satz verschärfender Randbedingungen hinzu: Sicherheit, Datenhoheit, On-Premise-Betrieb, Offline-Fähigkeit, Wartbarkeit über Dekaden. Wer hier einfach “ein Modell” in die bestehende Architektur fallen lässt, produziert Betriebsrisiko statt Mehrwert.

Dieser Beitrag beschreibt aus der Perspektive der Softwareintegration, wie man KI-Funktionen in Bestandsprodukte nachrüstet – schrittweise, beherrschbar und ohne Souveränität aufzugeben. Er richtet sich an CTOs, VP Engineering und Leiter Digitalisierung, die konkrete Muster, Architekturen und Trade-offs sehen möchten, statt Marketingfolien.

Problemdefinition vor Technologie

Bevor das erste Modell trainiert wird, ist Präzision in drei Fragen nötig:

  • Systemgrenzen und Fehlermodi: Wo wirkt die KI? Wer trifft im Fehlerfall die Entscheidung? Welche deterministischen Fallbacks existieren?
  • Nichtfunktionale Anforderungen: Latenzbudgets, Verfügbarkeit, Durchsatz, Ressourcenprofile (CPU/GPU), DSGVO und Exportkontrollen, Air-Gap.
  • Betriebsmodell: On-Prem ohne US-Cloud, Lifecycle-Management, Auditierbarkeit, Upgrades ohne Produktionsstillstand.

Ohne diese Randbedingungen ist jede architektonische Entscheidung (z. B. Sidecar vs. zentrales Inferenzbackend, GPU-Sharing vs. dedizierte Karten) Bauchgefühl.

Referenzarchitektur für KI-Nachrüstung

In der Praxis hat sich ein dreischichtiger Integrationsansatz bewährt:

  • UI-Schicht: Mensch im Loop, erklärbare Ergebnisse, Feedback- und Korrekturfunktionen, Feature-Flags zur schrittweisen Aktivierung.
  • Service-/Domänenschicht: Klare Verträge zu KI-Komponenten (Requests, Responses, Fehlercodes), Vor- und Nachverarbeitung, Regeln als Sicherheitsnetz.
  • Daten-/Inferenzschicht: Modelle, Vektorspeicher, Prompt-/Modellversionierung, Ausführungsumgebung (K8s/Bare Metal), Observability.

Wichtige Muster im Detail

1) Vertragsgetriebene Integration der Inferenz

  • Strikte Schnittstellen: gRPC/Protobuf mit versionierten Messages, expliziten Confidence-Feldern, Erklärungs- und Telemetriedaten.
  • Idempotenz und Timeouts: Jeder Inferenzcall ist idempotent; harte Timeouts mit abgestuften Fallbacks (z. B. 60 ms: heuristische Antwort, 300 ms: Regeln).
  • Fehlerflächen reduzieren: Nur Domänenobjekte übergeben (z. B. bereits zugeschnittenes Bild; keine Rohdatenströme quer durch Systeme).

2) Sidecar vs. zentrales Inferenzbackend

  • Sidecar (pro Service oder Arbeitsplatz): Gut für niedrige Latenz, schwache Kopplung, schnelle Rollbacks. Nachteil: Flottenmanagement, Hardwareausnutzung.
  • Zentrales Backend: Gut für GPU-Batching, Auslastung, vereinheitlichte Observability. Nachteil: Netzwerklatenz, Single Point of Failure, Zonenkonzept nötig.
  • Hybrid: Häufig bestes Ergebnis. Schlanke Vorauswahl am Edge (CPU/kleines Modell), schwere Inferenz zentral mit GPU.

3) Datenhoheit erzwingen

  • On-Prem-First: Modellartefakte, Vektorspeicher, Prompt-Logs und Evaluationsdaten bleiben im eigenen Rechenzentrum oder in der Edge-Installation. Kein US-Cloud-Zwang.
  • Air-Gap-Upgrades: Signierte Artefakte (Container, Modelle, Prompts) via Offline-Transfer, reproduzierbare Builds, SBOMs für Compliance.
  • Redaktionspipeline: PII/Geheimschutz vor Persistenz maskieren; K-Anonymisierung oder Hashing bei Telemetrie.

4) Rollout-Strategie: Shadow, Canary, Gates

  • Shadow-Mode: KI berechnet, aber ohne Wirkung; Ergebnisse werden protokolliert und mit Produktionsergebnissen verglichen.
  • Canary: Aktivierung nach Linie, Werk, Flotte oder Nutzergruppe. Entscheidende Metriken: Override-Rate, Time-to-Decision, Fehlalarme/Fehl-Erkennungen, Latenz-P95/P99.
  • Gates: Qualitäts-Grenzwerte (z. B. Konfidenz > X) und Domänenregeln, die Aktionen freigeben oder blockieren. In sicherheitskritischen Systemen sind Gates Pflicht.

5) Fallbacks und Sicherheitsfälle

  • Deterministische Fallbacks: Regeln, heuristische Modelle, oder “No-Op” mit Operator-Entscheidung.
  • Unabhängige Pfade: KI darf nicht die einzige Quelle für sicherheitskritische Funktionen werden; Doppelkanal-Architekturen beibehalten.
  • Audit: Jede KI-Entscheidung mit Input, Versionen, Parametern und Erklärungen protokollieren – revisionssicher, DSGVO-konform.

6) Testing und QA für KI-Features

Klassisches Unit-/Integrationstesten reicht nicht. Ergänzende Testarten:

  • Golden Datasets: Repräsentative, versionierte Datensätze mit Ground Truth, gegen die jede neue Version validiert wird.
  • Metamorphe Tests: Invarianzen prüfen (z. B. Bildrotation sollte Klassifikation nicht verändern).
  • Adversarials und Edge Cases: Gezielt schlechte Lichtverhältnisse, Rauschen, OCR-Störungen, fehlerhafte Sensorwerte einspeisen.
  • Shadow Replays: Produktionsdatenströme in einer Staging-Umgebung wiedergeben, um Latenz- und Durchsatzverhalten zu messen.
  • Prompt-/Agent-Regression (für LLM): Jede Prompt- oder Tool-Änderung durchläuft ein kuratiertes Set an Aufgaben; Metriken sind Pass@Top-Kriterien, Tool-Aufruf-Sequenzen, Policy-Verletzungen.

7) Observability und Governance

  • Korrelierte Traces: Vom UI-Event über den Domänenservice bis zum Inferenz-Span; strukturierte Logs mit Request-ID.
  • Versionierung auf allen Ebenen: Modell, Gewichte, Pre-/Post-Prozessoren, Prompt, Tool-Config, Wissensstände im Vektorindex.
  • Policy-Enforcement: Inhaltsfilter, Tool-Gates, Kosten- und Laufzeit-Limits, Data Loss Prevention.
  • LLM-spezifisch: Prompt- und Tool-Call-Traces, Token-Latenzen, Fehlermuster. Genau hier setzen wir in der Praxis Alpi-M ein – eine On-Prem-Plattform für Observability und Governance von LLM-Agenten, die Prompts, Toolaufrufe und Qualitätsmetriken nachvollziehbar macht, ohne Daten ins Netz zu schicken.

8) Performance Engineering im Inferenzpfad

  • Batching und Priorisierung: Serviceklasse “interaktiv” vs. “Batch”; getrennte Queues, Preemption für interaktive Anfragen.
  • Quantisierung/Optimierung: INT8/FP16, ONNX/TensorRT/OpenVINO dort, wo deterministische Genauigkeitsverluste akzeptabel sind.
  • Ressourcen-Pinning: GPU/NUMA-Affinitäten, KV-Cache-Pinning für LLMs, Limits pro Namespace, um “Noisy Neighbors” zu vermeiden.
  • Spekulative Dekodierung und Streaming (LLM): Interaktive UIs profitieren von schnellem First-Token; Backend kann vollständige Antwort parallel verifizieren.
  • Budgetierung: Token-, Zeit- und Kostenbudgets pro Request/Benutzer; harte Abbrüche mit sauberen Fehlermeldungen.

9) Schrittweise Migration: Von Regeln zu ML