Human-in-the-Loop, wann Du nicht alles automatisieren sollst

Die Frage hinter der Frage

Du hast einen Agent gebaut der Aufgaben löst. Irgendwann kommt die Frage: lässt Du ihn einfach laufen, oder muss er bei bestimmten Schritten nachfragen? Antwort: es kommt drauf an. Aber auf was genau kommt es an. Das ist diese Lektion.

Die drei Modi

Es gibt drei Betriebsarten für jeden Agent:

1. Volle Autonomie. Agent entscheidet, führt aus, berichtet im Nachhinein. Kein Freigabe-Schritt.
2. Draft-First. Agent erstellt einen Entwurf, legt ihn Dir zur Freigabe vor, führt erst nach "Ja" aus.
3. Halt bei Unsicherheit. Agent läuft grundsätzlich autonom, stoppt aber selbst wenn er merkt er ist unsicher oder die Entscheidung ist zu groß.

Der Fehler der Einsteiger ist, alles in Modus 1 zu bauen weil es schneller aussieht. Der Fehler der Paranoiker ist, alles in Modus 2 zu bauen weil es sicher aussieht. Richtig ist: pro Aktion entscheiden. Nicht pro Agent.

Das Umkehrbarkeits-Kriterium

Die einzige Regel die funktioniert: Je schwerer eine Aktion rückgängig zu machen ist, desto eher muss ein Mensch drauf schauen.

• Leicht rückgängig: Entwurf einer E-Mail. Notiz-Eintrag. Rohrecherche. Datei-Umbenennung im Arbeitsordner. → Volle Autonomie ok.

• Mittel rückgängig: Kalendereintrag. Ein Post-Draft in der Warteschlange. Eine Datenbank-Zeile in Deinem eigenen System mit Undo-Knopf. → Volle Autonomie ok, aber Undo-Knopf bauen oder Ereignisse loggen.

• Schwer rückgängig: E-Mail an Kunden senden. Zahlung auslösen. Datei an öffentliche Domain hochladen. Datenbank-Einträge löschen ohne Backup. Externen API-Call der Geld kostet. → Immer Draft-First. Immer Freigabe-Schritt.

• Gar nicht rückgängig: Öffentlichen Post auf LinkedIn. Überweisung ausführen. Kunden-Vertrag gegenzeichnen. Datenbank-Schema migrieren. → Zwei-Augen-Prinzip. Idealerweise Agent erstellt, Mensch reviewt, zweiter Mensch bestätigt. Wenn Du solo arbeitest: Draft-First mit Zeitpuffer ("morgen nochmal lesen").

Wie der Freigabe-Schritt in der Praxis aussieht

Der Agent schreibt seinen Entwurf nicht direkt raus, sondern in eine Warteschlange. Die Warteschlange siehst Du an einem Ort den Du regelmässig aufsuchst (Mail-Inbox, Notion-Seite, dedizierte Web-Oberfläche). Du klickst "Senden" oder "Verwerfen". Erst nach Deinem Klick wird ausgeführt.

Das klingt aufwendig, ist es aber nicht. Der Zeitverlust ist klein. Der Vertrauens-Gewinn ist groß. Und Du trainierst damit nebenbei Deinen Agent, weil Du bei jeder Ablehnung sagen kannst warum, und das im nächsten Lauf besser wird.

Wo der Agent selbst pausieren muss

Selbst bei Aktionen die in Kategorie "leicht rückgängig" fallen, sollte der Agent selbst stoppen wenn:

• Er eine Entscheidung sieht die nicht klar durch seine Anweisungen abgedeckt ist.
• Er merkt dass er mit Daten arbeitet die er nicht eindeutig identifizieren kann (zum Beispiel "welcher Kunde ist gemeint, es gibt drei Müllers").
• Ein vorher funktionierender Schritt plötzlich einen unerwarteten Fehler wirft.
• Er eine externe Änderung macht die er nicht selbst rückgängig machen kann.

Das ist kein Defizit. Das ist der Indikator für einen reifen Agent.

Das anti-muster das Du vermeiden musst

Nichts schlimmer als ein Agent der mit jeder Kleinigkeit nachfragt. "Soll ich die E-Mail als Betreff 'Update' oder 'Wochenbericht' setzen?" Das ist nicht Human-in-the-Loop, das ist einfach unterspezifizierte Anweisung. Der Agent soll das selbst entscheiden können, Du hast ihm eine Rolle gegeben, er füllt sie aus.

Nachfrage ist legitim bei: Risiko, Mehrdeutigkeit echt (nicht gekünstelt), externer Einfluss (Zeitfenster abgelaufen, Quelle nicht erreichbar). Nachfrage ist schlecht bei: Details die der Agent selbst ableiten kann.

Regel: Wenn Du jede Nachfrage einzeln genervt abnickst, ist Dein Agent kalibrierungs-bedürftig. Schraub die Autonomie hoch. Wenn Du dagegen froh bist dass Du gefragt wurdest und die Entscheidung wichtig war, genau richtig.

Zwei Beispiele aus der Praxis

E-Mail-Agent für Kundenanfragen. Liest eingehende Mails, kategorisiert, schreibt Antwort-Entwurf. Modus: Draft-First. Der Agent antwortet nicht selbst, er legt die Antwort in den "Entwürfe"-Ordner. Du liest morgens durch, klickst was rausgehen soll. Der Agent sendet nie selbst, weil Du nie eine peinliche AI-Mail an einen Kunden schicken willst ohne gegengelesen zu haben.

Such-Agent für Recherche. Dir Unterlagen zu einem Thema zusammenstellen. Modus: volle Autonomie. Er darf beliebig Websites öffnen, PDFs lesen, Zitate sammeln und Dir einen Bericht zurückgeben. Der Schaden wenn er was Falsches liest ist null, der Gewinn an Zeit ist groß. Du reviewst im Output, nicht im Prozess.

Gleiche Architektur, völlig unterschiedliche Einstellung. Weil die Aktionen unterschiedlich kritisch sind.

Warum Legal das auch so will

EU AI Act, Artikel 14, verlangt Human Oversight für "high-risk" Systeme. Was als "high-risk" gilt ist ein eigenes Kapitel. Aber die Logik hinter dem Paragraphen ist genau das hier: bei weitreichenden Entscheidungen muss ein Mensch drüber schauen können. Nicht als Technik-Frage, als rechtliche Anforderung.

Das heisst: wenn Du einen Agent baust der im KMU-Bereich Entscheidungen über Menschen trifft (Bewerbungen, Kündigungen, Kreditscoring), ist Human-in-the-Loop nicht optional. Es ist Pflicht. Und muss dokumentiert sein.

Wie Du das heute startest

Geh durch Deine bestehenden Agents, oder die Prozesse bei denen Du einen bauen willst. Pro Prozess:

• Liste die einzelnen Aktionen auf die der Agent machen wird.
• Bewerte jede Aktion auf der Umkehrbarkeits-Skala (leicht / mittel / schwer / gar nicht).
• Für alles mit "schwer" oder "gar nicht": Draft-First bauen.
• Für "leicht": volle Autonomie ok.
• Für "mittel": Undo-Mechanismus oder Event-Log.

Das ist zehn Minuten Arbeit pro Agent und erspart Dir drei Monate später eine peinliche Situation.

Weiter

Level 6 Lesson 4 geht tiefer in Deployment von Agents und Server inklusive der technischen Mechanik hinter Freigabe-Schleifen. Und in der Academy Blog gibts (wenn Du diesen Text liest) auch einen Artikel dazu wie wir bei StudioMeyer selbst Human-in-the-Loop in unserem Agent-Fleet gebaut haben.