• Verteidigung/Behördenkritisch: Dokumentenauswertung
  • Problem: LLM-Zusammenfassungen ohne belegte Quellen sind inakzeptabel.
  • Architektur:
  • Striktes RAG mit verpflichtender Zitation; No-Source = No-Ship.
  • Air-gapped Serving; Prompt-Registry signiert; Tools mit hartem Schema.
  • UI zwingt zur Sichtung der Top-Quellenpassagen; Eskalation bei Widersprüchen.
  • Telemetrie: Knowledge-Citation Coverage nahe 100% für alle freigegebenen Outputs.
  • Ergebnis: Bediener akzeptieren Vorschläge, weil Quelle und Gültigkeit immer prüfbar sind.

9) Metriken, die Verhalten steuern

Wenn Teams nur Genauigkeit messen, verfehlen sie Interaktion. Ergänzende Metriken:

  • Assist Rate: Anteil Entscheidungen, die durch KI-Unterstützung schneller/robuster wurden.
  • Override Rate: Anteil abgelehnter KI-Empfehlungen; Gründe kategorisiert (Quelle, Kontext, Risiko).
  • Hold-to-Approve Ratio: Wie oft hat Policy korrekterweise eine menschliche Freigabe verlangt?
  • False Auto-Exec Rate: Wie oft wurden automatisch ausgeführte Aktionen vom Incident-Postmortem als falsch eingestuft?
  • Explanation Utility Score: Bedienerbewertung (1–5), ob die angezeigte Erklärung zur Entscheidung half.
  • Drift/Degradation KPIs: Veränderung in Inputverteilung, Saliency-Verschiebung, Retrieval-Qualität.

Diese Metriken werden pro Risiko-Klasse getrennt betrachtet. Ein Gesamt-„Accuracy“-Wert sagt über Sicherheit und Vertrauen zu wenig aus.

10) Build vs. Buy: Was selbst bauen, was zukaufen?

  • Eigenbau sinnvoll für:
  • Domänenspezifische Tools und Policies (z. B. Umlaufregeln, Fertigungsspezifika).
  • Edge-Inferenz und Daten-Pipelines nahe an OT/ERP.
  • Zukauf sinnvoll für:
  • Agenten-Observability-Backbone (Event-Schema, Replay, Telemetrie).
  • Approval-Workflows und Policy Engine, sofern on-prem und auditfest.
  • Prompt-/Index-Registry mit Signatur/Versionierung.

Nicht verhandelbar: On-prem-Option, DSGVO-Sicherheit, keine Abhängigkeit von US-Cloud-Diensten, reproduzierbare Audits, semantische Diffs für Aktionen, klare HITL-Integration. Unser eigener Stack (Alpi-M) adressiert genau diese nicht-funktionalen Anforderungen; das Gleiche können Sie mit Hausmitteln bauen — aber rechnen Sie mit signifikantem Aufwand für Schema, Replay und sichere Policies.

Fazit

Vertrauen in KI entsteht nicht durch Marketing oder bunte UIs, sondern durch technische Gestaltung der Mensch-KI-Interaktion: risikobasierte Gates, handlungsleitende Erklärungen, Observability auf Schritt-Ebene, robuste QA und Governance mit klaren Verantwortungen. Wer Souveränität ernst meint, baut diese Prinzipien on-premise, DSGVO-konform und ohne Cloud-Abhängigkeiten. Dann wird KI nicht nur akkurat, sondern betriebsfähig — und die Bediener drücken den Freigabeknopf mit gutem Grund.

FAQ

1) Brauchen wir wirklich LLM-Agenten, wenn wir nur strukturierte Prozesse haben?

  • Wenn Ihre Prozesse deterministisch und gut formalisiert sind, reichen regelbasierte Systeme oder klassische Services. LLM-Agenten sind dann sinnvoll, wenn unstrukturierte Informationen (Dokumente, Freitext, Mails) und variable Kontextsuche dominieren. Wichtig ist die Trennung: Tool-Execution bleibt deterministisch und policy-gebunden, der LLM-Anteil orchestriert und begründet.

2) Wie verhindern wir Halluzinationen bei RAG?

  • Strikte Zitationspflicht: Antworten werden nur freigegeben, wenn belegte Quellenpassagen mitgeliefert werden. Retrieval-Qualität überwachen (Recall@K, MRR). Bei niedrigem Retrieval-Score: Auto-Abbruch mit „I don’t know“. Index-Pflege als eigener Prozess mit Versionierung, PII-Redaktion und Qualitätsmetriken.

3) Wie viel On-premise ist realistisch ohne riesiges MLOps-Team?

  • Starten Sie hybrid: On-prem Data/Control Plane (Policy, Audit, Indexe, Prompt-Registry), Modell-Serving je nach Bedarf on-prem oder in einer souveränen EU-Cloud. Nutzen Sie fertige Observability- und Governance-Komponenten, um nicht bei Null anzufangen. Kritisch ist die Fähigkeit zum Replay und zur Policy-Durchsetzung — diese sollte lokal liegen.

4) Wie messen wir, ob Bediener der KI vertrauen?

  • Indikatoren: Sinken der Override Rate bei gleichzeitiger Senkung der False Auto-Exec Rate; steigender Explanation Utility Score; reduzierte Entscheidungszeit ohne Eskalationen; stabile Assist Rate in High-Impact-Fällen. Führen Sie regelmäßig Reviews mit echten Ablehnungsgründen durch und schließen Sie die Feedback-Schleife in Prompt-/Policy-Änderungen.

5) Wer trägt Verantwortung, wenn eine KI-gestützte Aktion Schaden verursacht?

  • Formal die Rolle, die per RACI als „Accountable“ definiert wurde. Technisch muss das System lückenlos belegen können, welche Daten/Quellen, welches Modell, welche Policies und welcher Mensch (bei HITL) beteiligt waren. Deshalb sind WORM-Audits, signierte Prompt-/Policy-Versionen und Replay-Fähigkeit keine „Nice-to-haves“, sondern Haftungsgrundlagen.