• Transparenz: Pro Prompt die verwendeten Quellen, Retrieval‑Qualität, Antwort‑Metriken, Latenzen, Token‑Bilanzen.
  • Groundedness‑Checks: Automatische Plausibilisierung, ob die Antwort durch die gelieferten Quellen gedeckt ist; bei Unsicherheit: Degradierung oder Eskalation.
  • Policy‑Durchsetzung: PII‑Redaktion, Mandanten‑Abgrenzung, Tool‑Berechtigungen, Antwortformate (JSON‑Schema), Timeouts.
  • Änderungsmanagement: Versionierte Prompts/Tools/Workflows, Staging‑Umgebungen, Regressionstests auf Gold‑Sets vor Freigabe.
  • Betrieb in Eigenregie: On‑prem Deploy, ohne US‑Cloud‑Abhängigkeit, DSGVO‑konform.

Wichtig: LLMs nicht “im Regelkreis” ohne Fallback platzieren. Entweder asynchron (Tasks, Drafts) oder synchron mit klaren Grenzen: Zeitbudget, Output‑Schema, Abbruch mit Defaultantwort.

5) Testen und Qualitätssicherung für KI‑erweiterte Software

Klassische Tests reichen alleine nicht; wir ergänzen sie um robuste Strategien für nichtdeterministische Komponenten.

a) Contract‑ und Integrationstests vor den Modellen

  • Strenge Schemas an allen KI‑Schnittstellen. Tests prüfen: Akzeptanzgrenzen, Fehlerszenarien, Zeitouts, Idempotenz.

  • Replay‑Tests: “Golden Traces” von realen Produktionsflüssen, reproduzierbar durchziehbar über neue Versionen.

b) Golden Datasets und Schwellen

  • Für Vision/Tabular: Kuratierte Datensätze mit Label‑Qualität. Metriken und Akzeptanzschwellen (z. B. Fehlerrate pro Klasse, Falsch‑Negativ‑Budget).

  • Für LLM: Gold‑Fragen mit Referenzantworten und Toleranzregeln (z. B. muss Felder A/B korrekt, Feld C optional). JSON‑Schema validiert Struktur.

c) Metamorphe Tests

  • Invarianten statt exakte Antworten: Wenn Eingang X um eine irrelevante Formattierung variiert, darf sich die Entscheidung nicht ändern.

  • Adversarial Inputs: Bewusst gestörte, grenzwertige oder bösartige Eingaben (Prompt‑Injection‑Muster, korrodierte Bilder).

d) Nichtdeterminismus eindämmen

  • In Tests Temperatur=0, feste Seeds, identische Pre/Post‑Prozesse.

  • Output‑Vergleich über Normalisierung (z. B. Whitespace, Sortierung von Arrays).

e) Laufzeit‑Überwachung als Teil der Qualität

  • Drift‑Signale: Verteilung der Eingänge, Score‑/Konfidenz‑Verschiebungen, Retrieval‑Trefferqualität.

  • SLOs: Latenz, Verfügbarkeit, Fehlerraten, Anteil “Unsicher” mit Eskalation.

  • Alarm‑Runbooks: Wer tut was bei Ausfall, Drift, Qualitätsabfall?

6) Schrittweise Migration: Von Regelwerken zu ML ohne Big Bang

a) Dual‑Run mit Arbiter

  • Regel und ML laufen parallel; ML liefert Score und Begründung.

  • Arbiter entscheidet: Ab Score‑Schwelle und Unkritikalität darf ML entscheiden; sonst Regel oder Mensch.

  • Protokollierung: Alle Abweichungen werden geloggt und erklärt (Feature‑Attributionen, Quellen, Konfidenz).

b) Erklärbarkeit praktikabel machen

  • Kein “magisches” LLM im Kernprozess. Stattdessen: strukturierte Gründe (Top‑Features, Quelle, Gegenbeispiele).

  • Kontrafaktische Checks: “Welche kleine Eingangsänderung hätte die Entscheidung umgekehrt?” – hilfreich für Operatoren.

c) Stilllegung planen

  • Wenn ML stabil ist, frieren wir die Regelbasis ein, behalten sie als Fallback und für Regressionsvergleiche.

  • Notfall‑Umschaltung bleibt möglich (Feature Flag).

7) Souveränität ist ein Architekturmerkmal, kein Vertragstext

On‑prem ist kein Selbstzweck. Es ist eine Antwort auf konkrete Anforderungen: Daten dürfen das Werk nicht verlassen, Entscheidungen müssen lokal nachvollziehbar sein, Lieferketten müssen kontrollierbar bleiben.

Praktische Konsequenzen:

  • Artefakt‑Supply‑Chain: Interne Registry, signierte Images/Modelle, SBOMs, Viren-/Malware‑Scans, Freigabeworkflows. Kein Pull direkt aus dem Internet.
  • Air‑gapped Updates: Offline‑Medien mit Prüfsummen, getrennte Staging‑Zone, automatisierte Promotion.
  • Secrets & Schlüssel: Interner KMS, kurze Lebenszeiten, kein Hardcoding in Pipelines.
  • Zugriff: RBAC nach Mandant/Anlage, keine gemeinsamen Service‑Konten für KI/Legacy.
  • Telemetrie lokal: Logs/Metriken/Traces im eigenen Monitoring‑Stack; Export nur aggregiert/entpersonalisiert, wenn überhaupt.

8) Ein 90‑Tage‑Plan für die Nachrüstung

Woche 1–3: Aufnahme & Verträge

  • Systemkarten: Pfade, Latenzbudgets, Kritikalität, Datenflüsse.

  • Data Contracts: Ein-/Ausgänge für die KI, Versionierung, Fehlerverhalten.

  • Gold‑Sets definieren: Relevante Fälle, Negativbeispiele, Bewertungsregeln.

  • Threat‑Modell: Missbrauchspfade, Injection, Tool‑Risiken, Datenabflüsse.

Woche 4–6: Technische Hülle

  • Sidecar‑Inferenzdienst aufsetzen (Container, API, Observability).

  • Anti‑Corruption Layer implementieren; Contract‑Tests grün.

  • Shadow‑Mode integrieren; vollständiges Logging (Eingang, Ausgang, Latenz, Konfidenz).

  • Für LLM‑Use‑Cases: RAG‑Pipeline minimal aufbauen, on‑prem Vektorspeicher, Prompt‑Templates.

Woche 7–9: Qualität & Governance

  • Golden‑Runs, Schwellentuning, metamorphe Tests automatisieren.

  • Alpi‑M deployen: Prompt/Tool‑Versionierung, Groundedness‑Checks, Policies aktivieren.

  • Runbooks und SLOs definieren; Dashboards für Operatoren.

Woche 10–12: Inkrementeller Rollout

  • Canary auf 5–10% in unkritischen Pfaden, Monitoring engmaschig.

  • Lessons learned einarbeiten, zweite Canary‑Stufe, Operator‑Training.

  • Formale Freigabeprozesse finalisieren, Dokumentation/Model Cards vervollständigen.

Konkrete Integrationsbeispiele aus der Praxis

  • Visuelle Qualitätsprüfung in einer Montageanlage:
  • Kamera‑Streams bleiben am Edge; Inferenzdienst läuft auf einem Industrie‑PC mit GPU.
  • Ereignisbus koppelt die Prüfergebnisse an das MES. Safe‑state: Bei Unsicherheit oder Ausfall bleibt die Linie stehen oder fordert manuelle Prüfung an.
  • Regel‑zu‑ML‑Migration über Shadow‑Mode und Klassenspezifische Fehlerraten; ML gewinnt schrittweise Autonomie je nach Risikoklasse.
  • Wissensassistenz für Wartungsteams:
  • RAG auf internen Handbüchern, Ersatzteillisten, Vorfalltickets. LLM liefert strikt JSON mit Teile‑IDs, Arbeitsanweisungen und Quellen.
  • Alpi‑M erzwingt Groundedness, limitiert Tools (z. B. Teile‑Lookup) und protokolliert jede Antwort für Audits.
  • Offline‑First: Mobile Clients cachen gesicherte Auszüge, Synchronisation im WLAN der Werkshalle.

Typische Stolperfallen – und wie man sie meidet

  • Inline‑LLM ohne Guardrails: Freitext im Kernprozess führt zu unvorhersehbaren Kantenfällen. Lösung: Schema‑Outputs, Fail‑fast, Arbiter.
  • Datenvertrags‑Drift: “Nur ein zusätzliches Feld” bricht Inferenz. Lösung: Versionierte Schemas, Backward‑Kompatibilität, Contract‑Tests im CI.
  • Vermischung von Trainings‑ und Produktionspipelines: Leckagen erzeugen Scheinqualität. Lösung: Trennung, deterministische Feature‑Berechnung, reproduzierbare Läufe.
  • Kein Fallback: KI‑Ausfall legt Linie lahm. Lösung: Safe Defaults, Graceful Degradation, Manuelle Gates.
  • Observability als Nachgedanke: Ohne Telemetrie keine Kontrolle. Lösung: Metriken/Logs/Traces von Anfang an, Alpi‑M für LLM‑Workflows.

Warum “on‑prem, DSGVO‑konform, ohne US‑Cloud” kein Dogma, sondern Design ist