• Strangler-Pattern: Bestehende Regelkomponenten nicht wegreißen, sondern entlang klarer Schnittstellen den Traffic schrittweise auf ML umleiten.
  • Hybrid-Gating: Regeln filtern Eingaben, ML löst “Grauzonen”. Nachgelagerte Regeln validieren ML-Ausgaben.
  • Feature-Parität und Metrik-Parität: Definieren, was “gleich gut” bedeutet, bevor “besser” ausgeliefert werden darf.
  • Feedbackschleifen: UI erlaubt das Korrigieren; Korrekturen fließen in Trainingsdaten ein – mit strengen Freigabeprozessen.

Konkrete Integrationsszenarien

Szenario 1: Visuelle Fehlererkennung in einer Montage-Software

Ausgangslage: Ein existierendes Qualitätsmodul mit regelbasierten Checks (Lichtschranken, Toleranzfenster). Ziel: Kameragestützte Erkennung fehlender Bauteile.

Architektur:

  • Edge-Kamera streamt in einen lokalen Message-Bus (z. B. ZeroMQ/Kafka). Ein Inferenz-Sidecar am Arbeitsplatz führt eine leichte Vorverarbeitung durch (Zuschneiden, Normalisieren).
  • Zentrales GPU-Backend bündelt Inferenzjobs im Batch für niedrige Latenz, liefert Bounding Boxes + Konfidenzen + Erklärungsheatmaps zurück.
  • Domänendienst prüft Geschäftsregeln: Nur wenn Konfidenz > X und Taktzeitbudget nicht gerissen, wird “Stop andon” an die Linie gesendet. Andernfalls vermerkt das System eine Prüfempfehlung für den Werker.
  • UI zeigt Overlays, bietet “Korrektur markieren” und “Ignorieren” mit Pflichtgrund an.

Rollout:

  • 4 Wochen Shadow-Mode parallel zum Regelmodul; Logging von Abweichungen.
  • Danach Canary pro Linie, Start mit Anzeige ohne Stopp-Signal.
  • Nachweisbare Stabilität und niedrige Override-Rate -> aktiviert Stop-Signal.

QA:

  • Golden Datasets aus repräsentativen Schichten (Schicht A/B, unterschiedliche Beleuchtung).
  • Metamorph: Rotation, Helligkeit ±20 %, Verdeckungen.
  • Latenz-P95 < 120 ms, Verfügbarkeit 99,5 % im 2-Schicht-Betrieb.

Szenario 2: LLM-gestützte Wissenssuche im CMMS

Ausgangslage: Wartungsteams suchen in Handbüchern, Tickets und Stücklisten. Ziel: Ein Assistenzmodul, das konkrete, zitierte Antworten gibt und optional Tickets erstellt.

Architektur:

  • RAG-Pipeline On-Prem: Dokumente werden segmentiert, Vektorisierung in lokalen Vektorspeicher, starke Metadaten (Gültigkeitsdatum, Versionsstand, Anlage).
  • LLM-Layer mit strikter Tool-API: Tools nur “search_kb” und “create_ticket”. Keine freien Webzugriffe.
  • Policy- und Prompt-Governance: Rollen-Prompts versioniert, Antwortformat “Antwort + Zitate + Risikohinweis bei Unsicherheit”.
  • Observability: Alpi-M als Trace-/Governance-Layer für Prompts, Tools, Tokenkosten, Policy-Verstöße. DSGVO-konforme Protokollierung mit PII-Redaktion.

Rollout:

  • Pilot mit Shadow-Mode: Antworten werden neben der klassischen Suche angezeigt; Techniker bewerten Relevanz.
  • Canary auf ein Werk, Token-Budgets pro Nutzergruppe, harte Grenzen nachts (Batch-Reindizierung).

Sicherheitsnetz:

  • Ohne Zitate keine “sicheren” Antworten, nur “Hinweis mit Unsicherheit”.
  • Ticket-Erstellung nur nach expliziter UI-Bestätigung.

Souveränität:

  • Kein Datenabfluss, keine Telemetrie an Dritte. Modelle, Embeddings, Indizes bleiben On-Prem. Updates der Prompts/Tools sind signierte Artefakte.

Häufige Fallstricke und wie man sie vermeidet

  • Einmal-PoC ohne Integrationsplan: Ein Notebook mit 98 % Accuracy ist wertlos ohne Latenz-, Drift- und Rollback-Strategie. Gegenmaßnahme: Von Tag 1 an Schnittstellen, Metriken und Beobachtbarkeit definieren.
  • Cloud-first Reflex: Schneller Start, später Compliance-Hölle. Gegenmaßnahme: Klare Souveränitätsanforderungen, On-Prem-Architektur, erst dann evaluieren, ob Teile sicher ausgelagert werden dürfen.
  • Fehlende Versionierung: Prompt-/Modelländerungen “unter der Hand” machen Analysen unmöglich. Gegenmaßnahme: Registries für Modelle, Prompts, Tools; alles signiert und nachvollziehbar.
  • Keine Fallbacks: ML-Komponente hängt, ganze Linie steht. Gegenmaßnahme: Zeitbudgets und deterministischer Degradationspfad.
  • Messen falscher Metriken: “Genauigkeit” ohne Betriebskontext. Gegenmaßnahme: Domänenmetriken (Override-Rate, First Time Right, P95-Latenz, Incident-Rate).

Security- und Compliance-Aspekte

  • Software Bill of Materials (SBOM) für jeden Build; CVE-Scans, reproduzierbare Builds.
  • Modellartefakte signieren, verifizieren beim Deploy. Hashes in Auditlog.
  • Geheimnisse über dedizierten Secret-Store, kein Env-File-Sprawl.
  • Rechte- und Rollenkonzept bis zur Prompt-/Tool-Ebene. Wer darf was ändern? 4-Augen-Prinzip.
  • DSGVO: Zweckbindung, Datensparsamkeit, Pseudonymisierung bei Logs. Aufbewahrungsfristen technisch durchsetzen (Retention Policies).

Betriebsmodell und Ownership

  • Produktteamsown die KI-Komponenten wie Microservices – inklusive On-Call, Dashboards, SLOs.
  • Incident Response: Runbooks für ML-spezifische Ausfälle (Drift, Token-Exhaustion, GPU-Overcommit).
  • Daten-Feedback-Loop: Korrekturen aus dem Feld fließen kuratiert in Datasets. Kein “Auto-Training” ohne Governance.
  • Release-Disziplin: Canary, Feature-Flags, progressive Rollouts. Keine Big-Bang-Migration.

Pragmatische Checkliste zum Start

  • Klarer Use Case mit begrenzter Wirkungssphäre und definierter Erfolgsmetrik.
  • Datenerhebung unter realen Betriebsbedingungen, nicht nur Labor.
  • Schnittstellenvertrag entwerfen (Requests, Responses, Fehler, Zeitbudgets).
  • Observability-Plan: Welche Spans, welche Logs, welche Metriken, welche Retention?
  • Rollout-Plan: Shadow-Phase, Canary-Kriterien, Fallback-Design.
  • Governance: Versionierung, Signaturen, Policy-Regeln, Rechteverwaltung.
  • On-Prem Deploy: Ressourcenplan (CPU/GPU), K8s/Bare Metal, Update-Mechanismus, Air-Gap-Option.

Warum On-Prem und Souveränität keine Option, sondern Voraussetzung sind

Industriesoftware lebt im Spannungsfeld aus Vertraulichkeit, Verfügbarkeit und Sicherheit. KI verschärft das Spannungsfeld: Trainings- und Promptdaten sind oft sensibel, Agenten können unvorhersehbare Pfade gehen. Wer die Telemetrie seiner Wissenssuche oder die Bilder seiner Fertigung an Dritte sendet, gibt nicht nur Daten aus der Hand, sondern die Fähigkeit, Fehler zu analysieren und zu beheben. Ohne vollständige Observability und Governance On-Prem ist jeder KI-Einsatz ein Blindflug. Deshalb setzen wir auf lokale Deployments, nachvollziehbare Ketten von der Eingabe bis zur Entscheidung und Produkte wie Alpi-M, die LLM-Agenten im eigenen Perimeter beobachtbar und steuerbar machen.

Kurz zu Trade-offs, die man bewusst treffen sollte

  • Genauigkeit vs. Latenz: 2 % mehr Trefferquote sind wertlos, wenn die Taktzeit reißt. Budgetieren Sie Latenz per Klasse und priorisieren Sie Interaktivität.
  • Zentralisierung vs. Resilienz: Zentrale GPUs steigern Auslastung, aber brauchen Zonen, Redundanzen und Degradationspfade.
  • Modellgröße vs. Betriebskosten: Ein kleines, gut integriertes Modell mit starkem Sicherheitsnetz schlägt oft den SOTA-Riesen mit unklarer Governance.
  • Autonomie vs. Kontrolle (LLM): Agenten sind mächtig, aber nur mit harten Tool-Gates, Richtlinien und Observability vertretbar.