Wenn KI-Pilotprojekte in KMU scheitern, scheitern sie selten am Modell, selten am Tool — fast immer an der Übergabe. Entweder wird unbemerkt entschieden, weil niemand die Stelle definiert hat, an der ein Mensch übernehmen sollte. Oder ein Mensch nickt formal ab, ohne den Output ernsthaft zu prüfen.
Die wichtigste Designentscheidung agentischen Arbeitens ist deshalb nicht „welcher Agent", sondern „an welcher Stelle übernimmt ein Mensch". Wer die Übergabe-Punkte vor dem ersten Pilot festlegt, vermeidet die zwei häufigsten Fehler: stille Autonomie und Schein-Kontrolle.
Dieser Beitrag liefert die vier praktischen Übergabe-Modi, eine Risiko-Reversibilitäts-Matrix und die Mindestanforderungen an einen Audit-Trail: entlang Art. 14 EU AI Act, des NIST AI RMF und der etablierten Levels-of-Automation-Literatur.
Warum die meisten KI-Pilotprojekte an der Übergabe scheitern
Drei Muster wiederholen sich:
- Stille Autonomie. Der Agent handelt selbständig, aber die Lücke zwischen „Pilot" und „Produktion" wurde nie ausbuchstabiert. Folge: Output landet beim Kunden, ohne dass ein Mensch ihn vor der Auslieferung gesehen hätte. Wird ein Fehler entdeckt, ist die Verantwortungsfrage erst nach Schaden klärbar.
- Schein-Kontrolle (Rubberstamping). Der Übergabe-Punkt existiert formal: ein Mensch klickt „freigeben". In der Praxis liest niemand mehr, weil die Kadenz zu hoch oder die Toleranz für „sieht okay aus" zu groß ist. Die Freigabe wird zum Stempel.
- Eskalation ohne Owner. Bei kritischen Fällen soll eskaliert werden. Aber an wen? Wenn ein Eskalations-Ereignis eintritt, ist der Adressat unklar oder mehrere fühlen sich zuständig (oder niemand).
Hinter allen drei Mustern liegt eine einzelne Lücke: Die Übergabe ist nicht entworfen, sondern entstanden. Sie zu entwerfen heißt, vor dem Pilot vier Modi und eine Matrix anzulegen.
Vier Übergabe-Modi mit Beispielen
| Modus | Beschreibung | Wann sinnvoll | Typisches Risiko |
|---|---|---|---|
| Pre-Approval | Mensch entscheidet vor jeder Agent-Aktion | hoch riskant, irreversibel, externe Wirkung | Tempo-Verlust |
| Post-Review | Agent handelt, Mensch prüft Ergebnis vor Freigabe | mittleres Risiko, reversibel | Schein-Kontrolle (Rubberstamping) |
| Exception-Escalation | Agent handelt autonom; nur Ausnahmen eskalieren | wiederholbar, klares Regelwerk, niedriges Einzelrisiko | unentdeckte Drift |
| Continuous-Oversight | Agent handelt, Mensch beobachtet im Hintergrund mit Stichproben | hochfrequent, geringes Einzelrisiko, gut messbar | späte Fehlererkennung |
In der allgemeinen Diskussion ist daneben die kompaktere Stufung Human in the Loop / Human on the Loop / Human out of the Loop verbreitet: aktiver Entscheider, überwachender Beobachter, autonom handelnde Maschine. Diese drei Stufen ordnen das Spannungsfeld grob; die Quandes-Vier-Modi-Tabelle ergänzt sie um die Achse Reversibilität und macht aus der Stufung eine Entscheidungs-Heuristik für konkrete Aufgaben.
Beispiel Pre-Approval. Ein Agent erstellt Angebote über 50.000 EUR mit individuellen Konditionen. Die Geschäftsführung gibt jedes Angebot vor Versand frei. Tempo-Verlust ist akzeptabel, der externe Schaden bei Fehler wäre größer als der Tempo-Gewinn.
Beispiel Post-Review. Ein Agent erstellt Recherche-Berichte für interne Entscheidungen. Die Fachverantwortliche liest jeden Bericht und gibt zur Verwendung frei. Schein-Kontrolle ist hier das echte Risiko; gegen Rubberstamping helfen feste Mindest-Prüfschritte (z. B. Quellen-Stichprobe).
Beispiel Exception-Escalation. Ein Agent klassifiziert eingehende Support-Tickets nach Dringlichkeit. Standardfälle laufen automatisch ins Ticketsystem; nur Fälle mit niedriger Confidence oder besonderem Schlagwort werden an einen Menschen eskaliert. Drift-Gefahr: Wenn sich Eingaben verändern, ohne dass die Eskalations-Schwellen mit angepasst werden, übersieht der Agent zunehmend echte Eskalations-Fälle.
Beispiel Continuous-Oversight. Ein Agent formuliert Dokumentations-Bausteine für ein internes Wiki. Wöchentlich liest eine Person eine Stichprobe von zehn Bausteinen gegen Quelle und Faktentreue. Späte Fehlererkennung ist das Risiko, durch festen Review-Termin und dokumentierte Fehlerklassen begrenzt.
Risiko-Reversibilitäts-Matrix
Welcher Modus zu welcher Aufgabenklasse passt, lässt sich entlang zweier Dimensionen entscheiden: Risiko (Schadens-Höhe und Tragweite) und Reversibilität (lässt sich ein Fehler rückgängig machen?).
| Risikoebene | Reversibel | Irreversibel |
|---|---|---|
| Hohes Risiko | Post-Review | Pre-Approval |
| Niedriges Risiko | Continuous-Oversight | Exception-Escalation |
Zwei Orientierungspunkte machen die Matrix praktisch:
- Externe Wirkung erzwingt mindestens Post-Review. Wenn ein Fehler Kundenkommunikation, Rechnung oder Außenwirkung betrifft, ist Post-Review die Untergrenze, niemals Exception-Escalation.
- Korrektur-Dauer entscheidet zwischen Post-Review und Pre-Approval. Wenn ein Fehler in Stunden korrigierbar ist, reicht Post-Review. Wenn die Korrektur Stunden bis Tage kostet, gilt Pre-Approval.
Drei Anti-Muster und Korrekturen
Anti-Muster 1: Rubberstamping. Der Mensch ist im Loop, aber liest nicht mehr. Korrektur: Mindest-Prüfschritte schriftlich vorgeben (z. B. „pro Bericht zwei Quellen-Stichproben"); Kadenz prüfen, ob sie zu hoch ist; Audit-Trail einführen, damit Stichproben rückwirkend prüfbar werden.
Anti-Muster 2: Fehlender Audit-Trail. Es gibt Übergabe-Punkte, aber keine Dokumentation, wer wann was freigegeben hat. Korrektur: minimaler Audit-Trail pro Übergabe: Zeitstempel, Akteur, Entscheidung, ggf. Begründung bei Abweichung. Ohne Audit-Trail keine Lernschleife.
Anti-Muster 3: Eskalationskette ohne Owner. Eskalationen sollen an „das Team" gehen, aber niemand ist persönlich zuständig. Korrektur: pro Eskalations-Schwelle eine namentliche Verantwortliche plus Vertretung; Eskalations-Empfang wird in den regulären Workflow eingebunden, nicht in eine separate Inbox.
Audit-Trail: was muss dokumentiert werden?
Ein belastbarer Audit-Trail muss vier Felder pro Übergabe erfassen:
- Wann? Zeitstempel der Übergabe (Pre-Approval, Post-Review-Freigabe, Eskalations-Ereignis).
- Wer? Akteur (Mensch oder Agent) mit eindeutiger Identifikation.
- Was? Entscheidung (freigegeben, abgelehnt, eskaliert, Stichprobe gezogen) und betroffener Vorgang.
- Warum (bei Abweichung)? Wenn die Entscheidung vom Standard-Pfad abweicht, eine kurze Begründung.
Diese vier Felder sind kein Komfort, sondern Mindestanforderung. Sie bilden die Grundlage für drei Folge-Anwendungen: Lernschleife (welche Fehlerklassen wiederholen sich?), Compliance-Nachweis (wer hat wann freigegeben?) und Drift-Erkennung (verändert sich das Verhältnis von Standard zu Ausnahme?).
Was Quandes hier Audit-Trail nennt, geht inhaltlich zurück auf zwei Regelwerke:
- Art. 14 EU AI Act verlangt für Hochrisiko-KI-Systeme menschliche Aufsicht, deren konkrete Ausgestaltung dem Anbieter überlassen ist. Audit-Trail ist die praktische Form dieser Aufsicht.
- NIST AI Risk Management Framework 1.0 benennt menschliche Oversight nicht als Pflicht, sondern als Governance-Anforderung an die Organisation: Die GOVERN-Querschnittsfunktion verlangt, dass Verantwortlichkeit dokumentiert ist.
Für KMU außerhalb des Hochrisiko-Bereichs ist der Audit-Trail also keine gesetzliche Pflicht, aber bei jedem produktiven Agenteneinsatz die Voraussetzung für Lernschleife und Verantwortungsklarheit.
Praxisbild: drei KMU-Aufgaben mit unterschiedlichem Modus
Aufgabe A: Angebotsentwurf. Ein 40-MA-Engineering-KMU lässt einen Agenten Erstangebote mit Standardkonditionen entwerfen. Modus: Post-Review (Vertrieb liest jedes Angebot vor Versand). Audit-Trail: Zeitstempel, Vertriebsmitarbeiter, Freigabe/Anpassung.
Aufgabe B: Recherche-Berichte. Ein 70-MA-Beratungs-KMU lässt einen Agenten Markt-Recherchen für interne Mandats-Vorbereitung erstellen. Modus: Continuous-Oversight (wöchentliche Stichprobe von zwei Berichten mit Quellen-Check). Audit-Trail: Stichproben-Liste, Fehlerklassen pro Quartal.
Aufgabe C: Dokumentations-Bausteine. Ein 60-MA-Software-KMU lässt einen Agenten technische Wiki-Artikel auf Basis von Pull-Request-Beschreibungen formulieren. Modus: Exception-Escalation (Standard läuft automatisch; Artikel mit niedriger Confidence oder besonders sicherheitsrelevanten Schlagwörtern gehen an einen Senior-Entwickler). Audit-Trail: Eskalations-Statistik, Schwellen-Anpassungen.
Die drei Aufgaben unterscheiden sich nicht im Tool, sondern in der Übergabe. Wer das Tool wählt, ohne den Modus festgelegt zu haben, wählt ein Tool für ein Problem, das er noch gar nicht beschrieben hat.
Brücke zum agentischen Arbeiten
Die Übergabe steht nicht für sich, sondern setzt zwei vorgelagerte Bausteine voraus:
- Aufgabenbrief. Ohne schriftlichen Aufgabenbrief lässt sich kein Modus festlegen, weil unklar ist, was der Agent eigentlich tut.
- Readiness-Check. Vor dem ersten Pilot prüft ein 12-Fragen-Raster, ob das Unternehmen die Voraussetzungen für agentisches Arbeiten erfüllt: Aufgabenbrief, Verantwortungsgrenze, Eskalationskante, Review-Rhythmus.
Wer beide Bausteine hat, geht zur Übergabe. Wer einen oder beide nicht hat, beginnt nicht mit der Übergabe, sondern mit der Voraussetzung.
Häufige Fragen
Was ist eine Mensch-Agent-Übergabe?
Eine Mensch-Agent-Übergabe ist eine definierte Stelle in einem Arbeitsablauf, an der die Verantwortung zwischen einem KI-Agenten und einem Menschen wechselt: entweder vor einer Agent-Aktion (Pre-Approval), nach einer Agent-Aktion (Post-Review), als Ausnahme (Exception-Escalation) oder als laufende Beobachtung (Continuous-Oversight).
Was bedeutet Human-in-the-loop?
„Human in the loop" bedeutet, dass ein Mensch operativ in einen Entscheidungsprozess eines KI-Systems eingebunden ist. In der Quandes-Lesart umfasst der Begriff alle vier Übergabe-Modi; manche Quellen benutzen ihn enger nur für Pre-Approval oder Post-Review.
Wann ist ein KI-Agent zu autonom?
Ein Agent ist zu autonom, wenn sein Modus nicht zum Risiko-Reversibilitäts-Profil der Aufgabe passt, also wenn z. B. Exception-Escalation bei externer Wirkung gewählt wurde oder Continuous-Oversight bei hohem Einzelrisiko. Als Orientierung gilt: externe Wirkung erzwingt mindestens Post-Review.
Wie dokumentiert man Agent-Entscheidungen nachvollziehbar?
Mit einem Audit-Trail, der pro Übergabe vier Felder erfasst: Zeitstempel, Akteur, Entscheidung, Begründung bei Abweichung. Die Form ist nachrangig (Logfile, Datenbank, Spreadsheet): entscheidend ist die Vollständigkeit und die rückwirkende Prüfbarkeit.
Welche KMU-Aufgaben sollten nie vollautonom laufen?
Aufgaben mit hoher Schadensreichweite und geringer Reversibilität: rechtsverbindliche Außenkommunikation, finanzielle Zusagen, sicherheitsrelevante Entscheidungen, personenbezogene Bewertungen. Für diese Aufgaben gilt Pre-Approval; alles andere ist nach Risiko-Reversibilitäts-Matrix einzuordnen.
Wie verhindere ich Rubberstamping?
Drei Hebel: Mindest-Prüfschritte schriftlich vorgeben (z. B. Quellen-Stichprobe), Kadenz prüfen (wenn ein Mensch dutzende Freigaben pro Stunde leistet, ist Schein-Kontrolle wahrscheinlich), Audit-Trail einführen (rückwirkende Prüfbarkeit macht Schein-Kontrolle riskant für die freigebende Person).
Sind die vier Modi ein Standard?
Nein. Die vier Modi sind eine Quandes-Synthese aus der Levels-of-Automation-Literatur (Sheridan/Verplank 1978, Parasuraman/Sheridan/Wickens 2000), vereinfacht auf vier KMU-taugliche Klassen. In der Wissenschaft werden teils zehn oder mehr Stufen unterschieden.
Strategiegespräch
Wenn die Übergabe noch nicht entworfen ist
Wenn Sie einen KI-Agenten produktiv einsetzen wollen oder Ihr Pilot vor der Produktivsetzung steht, klärt Quandes mit Ihnen die Übergabe-Modi und den Audit-Trail vor der Tool-Auswahl. Das Erstgespräch beginnt nicht mit „welcher Agent", sondern mit „an welcher Stelle übernimmt ein Mensch".
Erstgespräch vereinbaren