• Retrieval-Abdeckung: Anteil der Antwort, der durch zitierte Quellen gedeckt ist (z. B. gemessen über Overlap/Entailment-Checks).
  • Tool-Kohärenz: Erfolgsrate, Fehlerklassen, Retry-Quoten pro Tool, Latenzen. Frühindikator für API-/Schnittstellenprobleme.
  • Policy-Verletzungen: Rate der Content-/Data-/Tool-Policy-Hits, manuelle Overrides.
  • Unsicherheits-Proxy: Auftreten von Selbst-Widersprüchen, niedrigen Evidenz-Quoten, Eskalationen zum Menschen.
  • Nutzer-Interaktion: Akzeptanzrate, durchschnittliche Bearbeitungszeit, Korrekturgründe aus dem HITL-Interface.

Kontrolle durch Policies und Ausführungsmodi

  • Guardrails auf drei Ebenen: Content (z. B. keine personenbezogenen Ausgaben), Tool (welche Parameterbereiche, Retry-Limits, Timeout), Data (welche Quellen erlaubt, maximale Kontexte).
  • Kill-Switch und Backpressure: Falls Metriken kippen (z. B. Tool-Error-Rate > x%), drosseln oder auf „Nur Vorschlag“-Modus zurückfallen.
  • Dry-Run/Shadow: Neue Agentenversionen laufen parallel, erzeugen Empfehlungen ohne Wirkung, werden gegen Ground-Truth/Operator-Entscheidungen evaluiert.
  • Change Management: Prompt-/Policy-/Code-Versionierung, Freigabeprozesse (Vier-Augen-Prinzip), Release-Notes. „Prompt-as-Code“ statt Copy-Paste im Wiki.

Alpi-M als Observability- und Governance-Schicht

Wir haben diese Anforderungen in Alpi-M gebündelt – eine On-Premise-Plattform für LLM-Agenten in industriellen Umgebungen. Sie deckt u. a. ab:

  • Vollständige Lauftraces und Artefakte im eigenen Rechenzentrum, DSGVO-konform.
  • Policy-Engine für Content-, Tool- und Data-Regeln mit deklarativer Konfiguration.
  • Experiment- und Versionsmanagement für Prompts, Policies und Agenten-Graphen.
  • Evaluationspipelines mit Regressionstests auf realen, kuratierten Szenarien.
  • Rollen, Rechte, Audit-Logs und Freigabe-Workflows, die zu ISO-ähnlichen Prozessen passen.

Wir integrieren dabei bewusst in bestehende Orchestratoren oder Eigenentwicklungen, statt Werkzeuge zu diktieren. Das Ziel: Souveränität über das Verhalten und die Nachvollziehbarkeit jedes Agentenlaufs.

Governance: Wer ist verantwortlich, wenn die KI falsch liegt?

„Die KI hat’s gesagt“ ist kein Freifahrtschein. Verantwortung ist gestaltbar – durch klare Zuständigkeiten, Artefakte und Prozesse.

Rollen und RACI

  • Fachverantwortung (A): Trägt die inhaltliche Verantwortung für die getroffene Entscheidung in einem Prozessschritt. Bei Autonomiebetrieb ist das ein definierter Systemverantwortlicher.
  • Operative Verantwortung (R): Trifft Entscheidungen im HITL-Interface, leitet Eskalationen ein.
  • Technische Verantwortung (R): Modell-, Daten- und Agentenbetreuer; hält die technischen Freigaben, betreibt die Observability.
  • Konsultation (C): Rechts-/Compliance, Qualitätsmanagement.
  • Information (I): Stakeholder, die Ergebnisse konsumieren.

Entscheidungsakte und Auditfähigkeit

  • Jede Entscheidung (automatisch oder manuell) erzeugt einen „Record of Decision“: Input-Artefakte, Modell-/Agenten-Versionen, Policies, Metriken, Erklärungen, menschliche Begründungen bei Overrides.
  • Reproduzierbarkeit: In Tests deterministisch, im Betrieb durch vollständiges Logging nachvollziehbar.

Änderungs- und Rollout-Prozesse

  • Datenänderungen: Kuratierte Datasets mit Herkunft, Nutzungsrechten, Versionen. Keine stillen Updates.
  • Modell-/Agentenänderungen: Canary/Shadow, definierte Abnahmekriterien, gestaffelter Rollout mit Metrik-Gates.
  • Incident Response: P0-P3-Klassen, On-Call, Runbooks (z. B. auf „Nur Mensch“ zurückfallen), Post-Mortems mit Korrekturmaßnahmen.

Rechtliche Aspekte werden dadurch nicht trivial, aber operational beherrschbar: Wer hat wann auf welcher Basis was entschieden – und war das gemäß der freigegebenen Policies?

On-Premise-Architektur: Souveränität ist ein Design-Constraint

In unseren Branchen ist On-Premise nicht Nostalgie, sondern Notwendigkeit: Schutz geistigen Eigentums, regulatorische Anforderungen, Exportkontrollen. Das prägt die Architektur:

  • Isolierte Ausführung: Air-gapped oder segmentiertes Netzwerk mit minimalem Egress. Modelle, Vektordatenbanken, Observability-Backends lokal.
  • Datenfluss-Kontrolle: Gateways mit Protokollumsetzung, erlaubte Systeme explizit whitelisten, PII-/IP-sensitive Felder frühzeitig maskieren.
  • Lieferkette und SBOM: Komponenten-Bills-of-Materials, reproduzierbare Builds, regelmäßige Scans, Notfall-Patches ohne Cloud-Abhängigkeit.
  • Update-Mechanik: Offline-Updates über signierte Artefakte, Umgebungspinning (Container/VMs), Rollback-fähig.

Referenzarchitektur für industrielle HITL-KI mit LLM-Agenten

Gedanklich teilen wir in vier Ebenen plus die Mensch-Maschine-Schnittstelle:

  • Data Plane: Sensor-/Systemdaten, Dokumentquellen, Vektorstore, Feature-Stores. Datenveredelung on-prem, einheitliche Semantik.
  • Execution Plane: Klassische Modelle (z. B. Vision), LLMs, Tools (ERP/MES/SCADA-Schnittstellen), Orchestrator (Zustandsmaschine/Graph).
  • Policy/Control Plane: Guardrails, Konfigurations- und Feature-Flags, Freigabe- und Rollenmodelle, Secrets.
  • Observability/Governance Plane: Tracing, Artefakt-Store, Metrikaggregation, Evaluationsjobs, Audit-Logs, Incident-Flow. Hier sitzt Alpi-M.
  • Human Console: HITL-UI mit Entscheidungskontext, Evidenzen, Erklärungen, Aktionsknöpfen, SLA-Anzeigen, Feedback-Kanälen.

Integration in bestehende Systeme (MES/SCADA/PLM) erfolgt über wohldefinierte Adapter, nicht durch direkte Tool-Steuerung aus der LLM-„Fantasie“. Werkzeuge laufen in Sandboxes mit klaren I/O-Verträgen, Timeouts und Rückfallwerten.

Fallbeispiele skizziert

  • Visuelle Montageprüfung: Klassifikator + Segmentierer liefern Befunde mit Konfidenz und Regionenvorschlägen. Schwelle a: autonom freigeben; Schwelle b: HITL. Bediener sieht Bild, fehlerhafte Region, alternative Hypothesen. Override-Gründe fließen zurück ins Labeling.
  • Dokumenten-Assistenz für Wartung: Retrieval-Augmented LLM mit strengem Quell-Corpus. Antwort nur mit belegter Passage. Geringe Evidenzabdeckung? HITL. Tool-Calls (Ersatzteilverfügbarkeit) nur mit validierten Parametern und Rate-Limits.
  • Flottenintelligenz Bahn: Zeitreihen-Anomalie → LLM erklärt in Klartext, welche Sensoren ausschlugen und welche Checks als Nächstes. Hohe Kritikalität? Mensch entscheidet, ob Fahrzeug aus dem Umlauf genommen wird. Alle Schritte in Audit-Log.

Checkliste für den Start – ohne Bauchlandung