• Tool-Use/Function Calling
  • Das LLM darf nur whitelisted Tools aufrufen: z. B. SAP-Query, DMS-Suche, Ticketanlage. Adapterschicht führt strikte Contract-Validierungen durch, Timeouts, Circuit Breaker.
  • Kein direkter Zugriff auf Produktionsschalter; nur lesende oder streng genehmigungspflichtige Aktionen.
  • Policy- und Observability-Schicht
  • Prompt-/Response-Logging mit PII-Maskierung, Prompt-Versionierung, Content-Filter, Konformitätsregeln (z. B. keine personenbezogenen Daten im Prompt).
  • Evaluationshaken: Offline-Bewertungen auf Golden-Queries, Canary-Traffic, Rollback bei Metrikverletzung.
  • Genau dafür setzen wir Alpi-M ein: ein Observability- und Governance-Layer für LLM-Agenten, der On-Prem läuft, DSGVO-konform ist und ohne US-Cloud auskommt. Er stellt u. a. Traceability, Prompt-/Tool-Versionen, Richtlinienenforcement, Offline-Evals und Audit-Trails bereit. Für die Fachdomäne genügt es zu wissen, dass jede LLM-Interaktion nachvollziehbar, überprüfbar und abschaltbar ist.

Wesentliche Engineering-Details:

  • Prompt-Templates sind versionierte Artefakte mit SemVer, eingebettet in CI/CD.

  • Response-Caching nur kontextsensitiv; Cache-Key umfasst Prompt-Version, Retrieval-Ergebnisse, Tool-Output-Hashes.

  • Streaming-Antworten mit frühzeitigem Stopp bei Policy-Verstößen („early cutoff“).

  • Kontexte strikt access-controlled: Der Retriever darf nur Dokumente liefern, die die Nutzerrolle lesen darf. Keine Autorisierung erst im LLM.

6) Observability und Governance: Was muss messbar sein?

Ohne Messbarkeit keine Freigabe. In der Praxis bewähren sich diese Telemetrie- und Governance-Punkte:

  • Eingangs- und Ausgangsartefakte
  • Welche Daten hat das Modell gesehen (nach PII-Maskierung)? Welche Entscheidung kam heraus? Welche Konfidenz, Scores, Top-K Evidenzen?
  • Versionierung
  • Modellversion, Tokenizer/Embedding-Version, Prompt-/Retriever-Version, Tool-Adapter-Version. Jede Entscheidung ist auf exakte Artefakte rückführbar.
  • Metriken und Budgets
  • Latenzbetrag je Pfad, GPU/CPU-Auslastung, Fehlerraten, „No-Answer“-Rate bei LLMs, Anteil Fallback-zu-Regeln, Disagreement-Quoten im Shadow.
  • Drift-Detektion
  • Eingangsdaten-Distribution, Embedding-Ähnlichkeitsdrift, „Out-of-Distribution“-Marker. Bei Abweichung in Canary-Modus oder auf Regel zurückschalten.
  • Policies
  • PII-Durchsatz: maskiert vs. unmaskiert, Blocklisten-Treffer, Tool-Use-Whitelists, Red-Team-Events. Enforcement muss technisch, nicht nur prozessual erfolgen.

Alpi-M deckt diese Anforderungen on-prem ab: Sammeln/Maskieren der Traces, Evaluations-Jobs offline, Policy-Checks im Request-Path, Audit-Trails und sichere Exporte für QS/Compliance. In streng getrennten Netzen wird die Telemetrie lokal gehalten und nur bei Freigaben exportiert.

7) Testen und Qualitätssicherung für KI-erweiterte Software

Klassische Unit-Tests reichen nicht. Praxistaugliche QA-Layer:

  • Contract-Tests am Interface
  • Prüfen der DTOs, Fehlverhalten, Timeouts, Latenzbudgets. Stabil, unabhängig vom Modell.
  • Golden Sets und Offline-Evaluierung
  • Repräsentative Datensätze pro Produktlinie. Fixierte Tokenizer/Preprozessoren. Evaluationsjobs in CI/CD. Kein Internet nötig.
  • Shadow-/Canary-Strategien
  • Shadow: ML/LLM entscheidet „nebenher“, nur Log. Canary: kleiner Live-Anteil mit harten SLOs und sofortigem Rollback bei Budget-Verletzung.
  • Deterministische Stubs
  • Seedbare Pseudo-Modelle, die synthetische, aber reproduzierbare Antworten liefern – für Systemtests ohne GPU/Modell.
  • Red Teaming und „Safeties“
  • Missbrauchsszenarien gezielt testen: Prompt-Injektionen, PII-Leaks, Tool-Missbrauch. Policies und Filter müssen diese Fälle abfangen – testbar, nicht nur dokumentiert.
  • Regression- und Kompatibilitätstests
  • Bei Wechsel von Embeddings oder Prompt-Versionen Vergleich gegen Golden-Traces. Kein „Silent Degradation“.

Erfolgskriterien sind vorab festzulegen: z. B. „95% korrekte Zitationsnachweise im RAG“, „<50 ms Median-Inferenz“. Ohne solche Budgets lassen sich Deployments in kritischer Umgebung nicht verantworten.

8) Schrittweise Migration: Von Regeln zu ML – sicher, nachvollziehbar, rückbaubar

Die produktive Umstellung gelingt am besten in vier Schritten:

  • Beobachten
  • Bestehendes Regelwerk instrumentieren: Wann feuern Regeln? Wo sind Grenzfälle? Disagreements mit einem Shadow-ML generieren und labeln.
  • Ergänzen
  • ML entscheidet nur in Niedrigrisiko-Fällen, die klar definiert sind (z. B. bestimmte Werkstückklassen). Regeln bleiben Default.
  • Umschalten
  • Champion-Challenger: ML wird Champion in enger Produkt-/Anlagenmenge. Regel bleibt als Challenger und wird verglichen. Rollback jederzeit möglich.
  • Entfernen
  • Erst wenn die Disagreement-Rate niedrig, SLOs stabil und Drift im Griff sind, wird das Regelwerk segmentweise stillgelegt – oder als Safety-Net mit hartem Override belassen.

Operativ unterstützt man das mit Feature-Toggles, Konfigurationsgates pro Kunde/Anlage und klaren Metrikschwellen. Juristisch relevante Entscheidungen (z. B. Qualitätsfreigaben) sollten länger dual geführt werden, bis genügend Evidenz für die Audits vorliegt.

9) Betriebsaspekte: Wenn KI zur Produktfunktion wird

Mit der Inbetriebnahme fängt die eigentliche Arbeit an:

  • Monitoring und Alerting
  • Technische SLOs (Latenz, GPU/CPU, Speicher), Funktionsmetriken (Trefferquoten, No-Answer-Raten, Fallback-Anteil), Driftindikatoren. Alerts mit sinnvoll gewählten Zeitfenstern, um Flattern zu vermeiden.
  • Incident-Runbooks
  • Was passiert bei: GPU-Ausfall, Index-Korruption, Modellprozess abgestürzt, Policy-Verstoß? Standardisierte Playbooks, getestete Rollbacks.
  • Upgrades
  • Blue/Green auf Sidecar-Ebene, Index-Neuaufbau parallel, Hash-basierte Validierung, datenbankseitige Migrationsskripte mit Re-Index-Fallback.
  • Sicherheit und Compliance
  • Signaturprüfung bei jedem Start, Audit-Export on demand, Rotationspläne für Logs/Traces. Kein PII in Langzeittraces; Maskierung vor Persistenz.
  • Kostenkontrolle on-prem
  • GPU-Auslastung konsolidieren, Off-Peak-Batchjobs, Quantisierung/Fusion nur, wenn SLOs es erlauben. Nicht jedes Projekt braucht eine A100 – die Architektur entscheidet.

10) 90-Tage-Fahrplan: Minimal-invasiv zum Nutzen

  • Tage 0–30: Schnittstellenaufnahme und Verträge
  • DTO-Definition, Latenzbudgets, Security-Zonen, Datenflüsse. Sidecar-Skelett, deterministischer Stub, erste Contract-Tests. Telemetrie-Pfade mit Maskierung.
  • Tage 31–60: Shadow und Golden-Evals
  • Shadow-Betrieb in Testumgebung oder kontrollierten Produktionsfenstern. Golden Sets bauen, Offline-Evals automatisieren. Drift-Baselines setzen. RAG-Indizes initial befüllen, Policy-Checks aktivieren.
  • Tage 61–90: Canary in Produktion
  • 5–10% Traffic, harte SLOs, Feature-Toggles. Runbooks testen, Blue/Green-Upgrade durchspielen. Entscheidung: Hochskalieren, nachschärfen oder vorerst im Shadow belassen.