Mensch vor Maschine: Wie wir industrielle KI so bauen, dass Operatoren ihr wirklich vertrauen — und warum Observability die Voraussetzung ist

Ein Produktionsband steht in der Nachtschicht. Die KI empfiehlt: „Linie 3 neu kalibrieren, Haltepunkt +0,2 mm.“ Trifft das zu? Der Schichtleiter hat 90 Sekunden, sonst reißen die Taktzeiten. Er schaut auf den Bildschirm: Score 0,83. Keine Belege, kein Gegenbeispiel, nur ein Balken. Drückt er auf „Übernehmen“, trägt er Verantwortung für Ausschuss, Stillstand und Kosten. Drückt er auf „Ablehnen“, ignoriert er potenziell eine echte Abweichung. Das ist kein UX-Fehler, das ist ein Architekturfehler. Eine KI ohne Beweisführung, ohne nachvollziehbare Herkunft der Daten und ohne definierte Eskalationspfade zwingt Menschen in blinde Wetten.

Unser Standpunkt ist klar: Souveränität ermöglicht Intelligenz. Wer die Verantwortung trägt, braucht Kontrolle über Daten, Modelle, Entscheidungen und deren Begründungen. Diese Kontrolle entsteht nicht durch hübsche Dashboards, sondern durch technische Architektur, Observability, klare Governance und ein UI, das den Menschen an der richtigen Stelle entscheiden lässt.

Wann der Mensch entscheiden muss

Die häufigste Fehlannahme in KI-Projekten: „Mehr Automatisierung ist immer besser.“ In der Industrie gilt eine nüchternere Heuristik: Mensch entscheidet dort, wo die Kosten eines Fehlers und die Unsicherheit der KI sich so multiplizieren, dass ein automatischer Fehlpfad teurer wird als die menschliche Verifikation.

Pragmatische Entscheidungslogik:

  • Fehlerkosten hoch, Entdeckung im Nachgang schwer, Korrektur teuer: Mensch muss entscheiden. Beispiel: Freigabe einer sicherheitskritischen Wartungsmaßnahme.

  • Fehlerkosten mittel, Entdeckung im Nachgang möglich, Korrektur moderat: Mensch sollte stichprobenbasiert entscheiden. Beispiel: Anpassung einer Prozessgrenze.

  • Fehlerkosten niedrig, Entdeckung leicht, Korrektur günstig: Automatik mit nachgelagerter Audit-Fähigkeit. Beispiel: Sortierung in „manuelle Nachprüfung“.

Das bedeutet nicht, dass wir überall „Zweitschlüssel“ brauchen. Es bedeutet, dass die KI eine explizite Fähigkeit benötigt, Nein zu sagen (Abstain/Defer) — und dass diese Fähigkeit kalibriert sein muss. Ein System, das immer entscheidet, auch bei OOD (out-of-distribution) oder schlechter Evidenz, ist kein intelligentes System, sondern ein Zufallsgenerator mit gutem Marketing.

Muster für Human-in-the-Loop in der Praxis:

  • Abstain-first-Design: Standardverhalten ist „nicht sicher genug → eskalieren“. Das UI bietet dann drei Aktionen: Übernehmen mit Begründungspflicht, Ablehnen mit Grund, Zurück an KI mit Zusatzkontext.

  • Kalibrierte Unsicherheit: Wahrscheinlichkeiten sind wertlos, wenn sie nicht kalibriert sind. Zielgröße ist nicht „hoher Score“, sondern „Score als verlässlicher Prädiktor für Fehlerwahrscheinlichkeit“. Sonst berauben Sie den Menschen seiner Entscheidungsgrundlage.

  • Set-valued Predictions: Bei Klassifikation nicht einen Label-König küren, sondern eine kleine, wohldefinierte Menge mit garantierter Abdeckungswahrscheinlichkeit zurückgeben. Der Mensch prüft nur noch diese Menge.

  • OOD-Erkennung: Jede Pipeline braucht eine Wächterstufe, die erkennt „dieses Teil, diese Anweisung, dieser Text liegt außerhalb des Trainingsraums“ und die Entscheidung an den Menschen gibt. Technisch simpel: ein Distanzmaß im Einbettungsraum mit Betriebsgrenzen.

  • Entscheidungs-Gateways: Integrieren Sie menschliche Freigaben an System-Interfaces, nicht in PDFs oder E-Mails. Jede Freigabe ist maschinenlesbar, auditierbar und an einen konkreten Artefaktzustand (Model-Version, Prompt, Daten-Snapshot) gebunden.

Explainability, die in der Industrie wirklich hilft

„Heatmaps“ und „Erklärungen“ sind oft hübsch, aber operativ nutzlos. In der Linie zählt: Welche Evidenz hat die KI, wie belastbar ist sie, und welche Alternative gibt es?

Was Operatoren brauchen:

  • Evidenz, nicht nur Attribution: Bei visueller Inspektion sind Referenzbeispiele aus der eigenen Linie wertvoller als bunte Überlagerungen. Zeigen Sie die drei ähnlichsten historischen Fälle mit ihrem Ergebnis und Prüfbericht.

  • Gegenfaktische Vorschläge: „Würde die Empfehlung kippen, wenn…?“ Beispiel: „Wenn die Temperaturmessung T2 um +0,5°C steigt, fällt der Befund weg.“ Das macht Handlungsspielräume transparent.

  • Zeitliche Einordnung: Wie neu ist das zugrunde liegende Wissen? Besonders bei LLM-Agenten ist „Cutoff“ nicht nur ein Trainingsdatum, sondern auch die Aktualität der Datenquellen im Retrieval.

  • Datenherkunft (Provenance): Aus welcher Datenbank, welchem Sensorlauf, welchem Kamera-Frame kommt die Evidenz? Verlinken, nicht paraphrasieren.

  • Absichtserklärung des Systems: Bei Agenten: Welche Ziele und Constraints wurden dem Agenten vorgegeben? Welche Tools darf er verwenden, welche nicht? Welche Nebenbedingungen (z. B. Kostenlimit, maximale Durchlaufzeit) sind aktiv?

Domänenspezifische Erklärungsbausteine:

  • Visuelle Qualitätsprüfung: Neben Overlay: Konturlinien des Defekts, metrische Messwerte, Vergleichsgeometrie, und drei Next-best-Actions (z. B. „Aufnahme wiederholen“, „Kalibrierung prüfen“, „an QS eskalieren“).

  • Prädiktive Instandhaltung: Restlebensdauer als Konfidenzintervall, Residuenverlauf zum physikalischen Modell, Schwellenhistorie. Kein „RUL=32 Tage“ ohne Bandbreite und Messfehler.

  • LLM-gestützte Assistenz: Für jede Antwort: Zitationsliste mit anklickbaren Originalstellen, Tool-Call-Protokoll (welches Tool, welche Parameter, welche Antwort), und ein Abschnitt „Antwort basiert auf X, nicht abgedeckt: Y“. Ein „weiß ich nicht“ ist hier ein Qualitätsmerkmal, kein Makel.

LLM-Agenten in Produktion: Observability und Kontrolle sind Sicherheitsfunktionen

LLM-Agenten sind nicht nur Textgeneratoren; sie sind Laufzeitumgebungen, die Tools ansteuern, Entscheidungen treffen, Zustände verändern. Das verlangt dieselbe Strenge, die wir für jedes andere verteilte System anwenden.

Was wir systematisch erfassen (Telemetry):

  • Eingaben: Prompt-Template-Version, Parameter (Temperatur, Top-p, Max-Tokens), Kontext-Hashes, Retrieval-Ergebnisse mit Quellen.

  • Ausgaben: Vollständige Token-Streams, Finalentscheidungen, Selbstbewertungen (falls aktiviert), abgeleitete Strukturergebnisse.

  • Tool-Graph: Liste aller Funktionsaufrufe mit Zeit, Argumenten (PII-sicher), Rückgaben, Fehlerpfaden, Retries.

  • Ressourcen: Latenzen, Tokens, GPU-Auslastung, Kostenmetriken (auch on-prem intern bewertet).

  • Risiken: Heuristiken zu Halluzinationsverdacht (Antwort ohne Stütze), PII-Treffer, Policy-Verstöße, OOD-Signale.