Mini-Beispiele aus Projekterfahrung (anonymisiert, abstrahiert)

  • Fertigung: Visuelle Inspektion als Sidecar-Service, der Bilddaten lokal inferiert und Ergebnisse samt Bounding-Boxes via gRPC zurückliefert. Regel-Fallback bleibt für kritische Fehlertypen aktiv; Shadow-Phase von mehreren Wochen, dann Canary per Bauteilfamilie.

  • Bahn: Fleet-Intelligence mit Ereignisbus. ML-Services für Anomalieerkennung hängen als Konsumenten dran, schicken Alerts mit Confidence und Kontext. Rückkanal erlaubt Human-Acknowledgement; Golden Datasets basieren auf bestätigten Vorfällen.

  • Bauvermessung: LLM-gestützte Assistenz für Protokollerstellung. Middleware orchestriert Retrieval aus technischen Handbüchern und Projektdokumenten; Alpi-M zeichnet Prompts/Antworten auditfest auf, Policies verhindern das Vermischen zwischen Projekten.

Konkreter Fahrplan: 8–12 Wochen bis zum ersten produktiven Pfad
Woche 1–2: Scope, Verträge, Messgrößen

  • Use-Case zuschneiden, Erfolgskriterien messbar definieren (Qualität, Latenz, Fehlertoleranz).

  • Vertrag und Schnittstellen festziehen. Fallback- und Degradationsmodi spezifizieren.

  • Datenpfade kartieren; minimalinvasive Extraktion bestimmen.

Woche 3–4: Technischer Rahmen

  • Sidecar/Middleware aufsetzen (gRPC, Schema, Health/Tracing).

  • On-prem Inferenzserver oder LLM-Middleware containerisieren.

  • Observability/Governance aktivieren (z. B. Alpi-M für LLM).

Woche 5–6: Shadow-Mode

  • Live-Traffic spiegeln; Konflikte, Latenz, Fehlerbilder sammeln.

  • Golden Datasets erstellen/erweitern; erste Regressionen etablieren.

Woche 7–8: Canary und Betriebsübergang

  • Selektive Umschaltung auf KI-Pfad für einen Teil des Traffics oder eine harmlose Domäne.

  • On-Call- und Runbooks fertigstellen; Rückrollplan testen.

Woche 9–12: Stabilisierung und Erweiterung

  • Drift-Monitoring etablieren, Retrain-/Prompt-Update-Zyklen definieren.

  • Weitere Regelpfade migrieren; Human-in-the-Loop gezielt abbauen.

Was wir bewusst nicht tun

  • Keine direkten Calls zu Public-LLM-APIs mit Produktionsdaten. Ohne Governance, Audit und Souveränität ist das in der Industrie nicht tragfähig.

  • Kein „Big Bang“-Rewrite. Migration muss reversibel sein.

  • Keine Blackbox-Modelle ohne Vertragsgrenzen. Jede KI-Integration braucht Schutzgeländer: Schema, Policies, Fallback.

FAQ
Frage 1: Unser Monolith ist alt, komplex und sicherheitskritisch. Ist eine KI-Integration realistisch, ohne die Zertifizierung zu gefährden?
Antwort: Ja, wenn Sie deterministische Integrationsgrenzen einziehen. Platzieren Sie KI-Funktionen außerhalb der zertifizierten Kernlogik (Sidecar), erzwingen Sie feste Verträge, und behalten Sie regelbasierte Fallbacks. Aus Sicht der Zertifizierung bleibt die kritische Logik unverändert; die KI-Komponente ist ersetzbar, abschaltbar und auditiert.

Frage 2: Welche Hardware brauche ich on-prem für LLMs?
Antwort: Das hängt vom Use-Case ab. Für reine Retrieval-Assistenz mit moderatem Kontext reichen oft mittelgroße Modelle auf einer einzelnen GPU oder sogar CPU-basiert mit höherer Latenz. Entscheidend ist, die Latenzbudgets, Parallelität und Qualität gemeinsam zu betrachten. Starten Sie mit einer konservativen Konfiguration, messen Sie unter Last (Shadow/Canary) und skalieren Sie gezielt. Die Middleware-Architektur erlaubt später den Modelltausch ohne Anwendungsumbau.

Frage 3: Wie testen wir etwas, das per Definition probabilistisch ist?
Antwort: Nicht mit „wahr/falsch“ allein. Kombinieren Sie Golden Datasets (Regressionsschutz), metamorphe Tests (Erwartungen über Relationen), Property-Checks (Output-Constraints) und produktionsnahe Shadow-/Canary-Phasen. Für LLMs kommen strukturierte Schemas und Retrieval-Validierungen hinzu. Wichtig ist eine Observability-Schicht, die Qualitätsmetriken langfristig verfolgt.

Frage 4: Wie stellen wir sicher, dass keine personenbezogenen Daten in Logs oder Modelle wandern?
Antwort: PII-Scrubbing ist Teil der Pipeline, nicht nachträgliche Kosmetik. Maskieren Sie PII vor Persistenz, minimieren Sie Features, erzwingen Sie Rollen-/Rechtekonzepte und betreiben Sie Observability/Governance on-prem. Für LLMs sollten Prompt-/Response-Logs durch Policies gefiltert und revisionssicher gespeichert werden. So behalten Sie die volle Datenhoheit.

Frage 5: Können wir mit Regel- und ML-Logik dauerhaft parallel leben?
Antwort: Ja, und in sicherheits- oder qualitätskritischen Domänen ist das oft sinnvoll. Regeln bleiben als Fallback und für eindeutig deterministische Fälle. ML übernimmt dort, wo Regeln brüchig sind. Mit klaren Gates, Konfidenzen und Audit behalten Sie die Kontrolle. Langfristig können Regeln abschmelzen – aber nur auf Basis gemessener Stabilität.

Schlussgedanke
KI in Bestandssoftware zu integrieren heißt, Grenzen bewusst zu setzen: Verträge, Fallbacks, Observability, Governance. So entsteht ein System, das sich schrittweise verbessert, aber nie die Souveränität verliert. Wer diese Disziplin von Anfang an einbaut, bekommt nicht nur ein Modell in Produktion – sondern eine robuste, auditierbare und erweiterbare Architektur, die Industriebetrieb und KI-Tempo sinnvoll verbindet. Genau dort liegt der Unterschied zwischen einem Experiment und einem tragfähigen Produkt.