Human Approval für KI-Agenten: Freigaben ohne Prozessstillstand

Das Wichtigste in Kürze:

• Freigabe brauchen Aktionen, die schwer rückholbar sind oder nach außen wirken.
• Dazu zählen externe Kommunikation, Zahlungen, Löschungen und Schreibzugriffe auf Produktivsysteme.
• Ein Raster mit 4 Risikostufen von automatisch bis zwingend freizugeben hält den Prozess schlank.
• Jede Entscheidung wird protokolliert: Tool, Parameter, Person, Zeitpunkt, Ergebnis.

Ein KI-Agent, der jede E-Mail vor dem Versand von einem Menschen prüfen lässt, ist sicher, aber für die meisten Anwendungsfälle unbrauchbar langsam. Ein Agent, der alles autonom ausführt, ist schnell, aber ein Kontrollverlust, sobald er eine falsche Rechnung verschickt, eine Kundendatei löscht oder eine ungeprüfte Bestellung auslöst. Human Approval löst genau dieses Spannungsfeld. Nicht jede Aktion braucht eine Freigabe. Die kritischen brauchen eine, und zwar so, dass der Prozess dabei nicht steht.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in KMU, die einen KI-Agenten mit echten Tool-Zugriffen betreiben oder planen. Gemeint sind Systeme, die nicht nur Text ausgeben, sondern E-Mails verschicken, Datensätze ändern, Bestellungen auslösen oder mit anderen Systemen kommunizieren. Der Artikel ordnet ein, welche Aktionen Freigabe brauchen, wie man Risikostufen definiert, wie zeitversetzte Freigaben technisch funktionieren, was bei Ablehnung passiert und wie das Ganze auditierbar wird.

Begriffe kurz geklärt

Zuerst die Einordnung. Human Approval (auch Human-in-the-Loop für Tool-Aufrufe) bezeichnet einen Kontrollpunkt in einem KI-Agenten-Workflow. Bevor der Agent ein bestimmtes Tool ausführt, pausiert der Ablauf und wartet auf die Entscheidung einer berechtigten Person. Das ist etwas anderes als generelles Human-in-the-Loop-Design, bei dem Menschen KI-Ausgaben prüfen, bevor sie verwendet werden. Human Approval im engeren Sinn setzt am Tool-Aufruf an, nicht erst am Ergebnis.

In der Praxis sind 2 Varianten relevant:

• Synchrone Freigabe: Der Agent wartet in derselben Sitzung auf eine sofortige Ja/Nein-Entscheidung, meist über eine Chat-Oberfläche.
• Zeitversetzte (asynchrone) Freigabe: Die Anfrage geht über einen separaten Kanal an eine zuständige Person, etwa Slack, Microsoft Teams, E-Mail oder WhatsApp. Diese Person reagiert später, der Workflow bleibt bis dahin im Wartezustand.

Abzugrenzen ist Human Approval außerdem von Berechtigungen im technischen Sinn. Berechtigungen legen fest, worauf ein Agent überhaupt zugreifen darf, also Systeme, Daten und APIs. Human Approval legt fest, wann eine an sich mögliche Aktion zusätzlich eine menschliche Entscheidung braucht. Ein Agent kann also die Berechtigung haben, eine Zahlung auszulösen, und trotzdem bei jeder Zahlung über einem Schwellenwert eine Freigabe einholen müssen.

Welche Aktionen brauchen Freigabe?

Pauschal beantworten lässt sich das nicht, systematisch herleiten schon. 2 Kriterien reichen dafür aus: Rückholbarkeit (lässt sich die Aktion folgenlos rückgängig machen?) und Wirkungsradius (bleibt der Effekt intern oder wirkt er nach außen?).

Freigabe brauchen typischerweise Aktionen, bei denen beide Kriterien kritisch ausfallen.

• Externe Kommunikation im Namen des Unternehmens: E-Mails an Kund:innen, Nachrichten in sozialen Netzwerken oder Support-Antworten mit rechtlicher oder finanzieller Aussage.
• Zahlungen und Bestellungen: Überweisungen auslösen, Rechnungen freigeben, Bestellungen bei Lieferanten aufgeben.
• Löschungen und irreversible Datenänderungen: Datensätze löschen, Zugriffsrechte entziehen oder vergeben, Konfigurationen in Produktivsystemen ändern.
• Schreibzugriffe auf Produktivsysteme, die nachgelagerte Prozesse auslösen, etwa ein CRM-Update, das automatisch eine Marketingkampagne anstößt.

Keine Freigabe brauchen üblicherweise Aktionen, die leicht korrigierbar sind und intern bleiben.

• Lesezugriffe: Daten abfragen, Dokumente durchsuchen, Status prüfen.
• Textentwürfe, die ohnehin ein Mensch liest, bevor sie irgendwohin gehen.
• Zusammenfassungen, Kategorisierungen und interne Vorsortierungen ohne unmittelbare Außenwirkung.

Dazwischen liegt eine Grauzone, etwa eine interne Slack-Nachricht an ein ganzes Team oder eine automatische Kalenderbuchung, und solche Fälle lohnen eine bewusste Entscheidung statt einer Bauchgefühl-Regel. Genau dafür dient die Risikomatrix im nächsten Abschnitt.

Eine praktische Faustregel aus Projekten: Stell dir vor, die Aktion läuft mit falschen Parametern. Erfordert die Korrektur mehr als eine E-Mail oder einen kurzen internen Hinweis, gehört die Aktion mindestens auf die zeitversetzte Freigabestufe. Diese Frage lässt sich für jedes Tool in wenigen Minuten beantworten und ist oft aussagekräftiger als eine abstrakte Kategorisierung nach Tool-Typ.

Wie definiert man Risikostufen?

Statt jede Aktion einzeln zu diskutieren, hilft ein wiederverwendbares Raster. Die folgende Matrix ist ein eigenes, vereinfachtes Modell aus der Beratungspraxis. Sie ist kein branchenweiter Standard, sondern ein Ausgangspunkt, den du an dein Unternehmen anpassen solltest. 4 Stufen reichen.

• Stufe 0, automatisch: vollständig rückholbar, rein intern. Keine Freigabe nötig. Beispiele: suchen, lesen, zusammenfassen, Entwurf erstellen.

• Stufe 1, protokolliert: vollständig rückholbar, extern sichtbar mit niedriger Tragweite. Keine Vorab-Freigabe, aber Nachprotokollierung und Stichproben. Beispiele: interne Statusmeldung an ein Team, automatische Terminbestätigung.

• Stufe 2, zeitversetzt freizugeben: teilweise oder nur aufwändig rückholbar, mittlerer bis hoher Wirkungsradius. Asynchrone Freigabe vor der Ausführung. Beispiele: Kundenmail mit individuellem Inhalt, Bestellung unterhalb eines Schwellenwerts.

• Stufe 3, zwingend synchron freizugeben: nicht oder nur mit Schaden rückholbar, hohe finanzielle oder rechtliche Tragweite. Sofortige Freigabe, kein automatischer Fallback. Beispiele: Zahlung auslösen, Datensatz löschen, Vertrag versenden.

Eigenes Stufenmodell Philogic Labs, abgeleitet aus Umsetzungsprojekten. Die Zuordnung einzelner Aktionen zu einer Stufe ist unternehmensspezifisch. Sie gehört mit den Fachbereichen abgestimmt, nicht allein von der IT festgelegt.

In der Praxis reicht meist eine Excel- oder Notion-Tabelle mit den Tool-Aufrufen des Agenten in einer Spalte und der zugeordneten Stufe in der nächsten. Wichtig ist weniger die Feinheit des Modells als die Disziplin, jeden Tool-Aufruf tatsächlich einmal durchzugehen. Die meisten Vorfälle, die ich in Projekten sehe, entstehen nicht durch ein falsch eingestuftes Risiko. Sie entstehen durch ein Tool, das schlicht vergessen wurde einzustufen.

Wie funktionieren zeitversetzte Freigaben?

Technisch läuft eine zeitversetzte Freigabe in einer festen Abfolge ab. Als Beispiel dient ein Workflow-Tool wie n8n, das diese Funktion für KI-Agenten-Tool-Aufrufe direkt eingebaut hat. Der Ablauf hat 6 Schritte.

1. Der Agent entscheidet sich für einen Tool-Aufruf, zum Beispiel „Bestellung auslösen“ mit bestimmten Parametern wie Artikel, Menge und Lieferant.

2. Das System erkennt die Freigabepflicht dieses Tools und pausiert die Ausführung an dieser Stelle, statt sie durchzureichen.

3. Eine Genehmigungsanfrage geht über den konfigurierten Kanal raus. Laut n8n-Dokumentation sind das unter anderem Chat, Slack, Discord, Telegram, Microsoft Teams, Gmail, WhatsApp, Google Chat oder Microsoft Outlook. Die Anfrage zeigt, welches Tool mit welchen Parametern ausgeführt werden soll.

4. Eine berechtigte Person prüft und entscheidet: zustimmen oder ablehnen. Das kann Minuten oder Stunden dauern. Der Workflow bleibt in diesem Zustand, ohne dass der Agent weiterarbeitet oder Ressourcen blockiert.

5. Bei Zustimmung führt das System den Tool-Aufruf mit den ursprünglich vorgeschlagenen Parametern aus.

6. Bei Ablehnung wird der Aufruf nicht ausgeführt. Der Agent erhält die Ablehnung als Information für den weiteren Ablauf, mehr dazu im nächsten Abschnitt.

Wichtig ist die Granularität. Freigabepflicht lässt sich pro Tool einzeln setzen, nicht nur pauschal für den ganzen Agenten. Ein Agent kann also frei suchen und zusammenfassen, aber bei „E-Mail senden“ und „Zahlung auslösen“ jeweils separat pausieren.

Eine ehrliche Lücke gehört hier dazu. Die n8n-Dokumentation macht zum Zeitpunkt dieses Artikels keine pauschale Aussage zum Timeout-Verhalten, also zu dem Fall, dass niemand innerhalb einer Frist reagiert.

Wer zeitversetzte Freigaben produktiv einsetzt, sollte diesen Fall explizit im eigenen Workflow regeln. Sinnvoll sind eine Eskalation an eine zweite Person, eine Erinnerung nach einer festgelegten Frist oder ein automatischer Abbruch mit Benachrichtigung. Eine Anfrage unbegrenzt offen zu lassen, ist keine Option. Das ist kein Nachteil des Werkzeugs, sondern ein Punkt, den jedes Unternehmen für seinen Kontext festlegen muss.

Was passiert bei Ablehnung?

Eine abgelehnte Freigabe ist kein Fehlerzustand, das System funktioniert wie vorgesehen. Trotzdem wird sie in der Praxis oft schlecht behandelt. 2 Muster sind zu vermeiden.

• Der stille Abbruch. Der Agent bricht die Aufgabe ab, ohne die anfragende Person oder den ursprünglichen Auslöser zu informieren. Ergebnis: Ein Kunde wartet auf eine Antwort, die nie kommt, weil intern jemand eine E-Mail abgelehnt hat, aber niemand den Vorgang weiterverfolgt.

• Die blinde Wiederholung. Der Agent versucht denselben Tool-Aufruf erneut, ohne dass sich an den Parametern etwas geändert hat. Meist fehlt schlicht ein alternativer Pfad.

Ein durchdachter Ablehnungspfad legt vorher fest: Wer wird bei Ablehnung informiert, die ursprünglich anfragende Person oder ein Team-Kanal? Gibt es eine Alternative, zum Beispiel die E-Mail nicht versenden, sondern als Entwurf ablegen? Und wird die Ablehnung inklusive Begründung dokumentiert, damit sich Muster erkennen lassen? Wird ein bestimmter Tool-Aufruf auffällig oft abgelehnt, deutet das meist auf ein Konfigurationsproblem hin, nicht auf einen Einzelfall.

Wie wird es auditierbar?

Auditierbarkeit ist kein Nice-to-have, sondern in zwei Richtungen relevant: operativ und regulatorisch. Operativ heißt: Was ist passiert, wenn etwas schiefgeht? Regulatorisch verlangt der EU AI Act für Hochrisiko-Systeme ausdrücklich eine Aktivitätsprotokollierung als eine der „strikten Verpflichtungen“. Dazu kommen Risikobewertung, qualitativ hochwertige Datensätze und Dokumentationspflichten gegenüber Behörden.

Ob ein konkreter Agenten-Einsatz als Hochrisiko-System im Sinne der Verordnung gilt, hängt vom Einsatzbereich ab (Stand Juli 2026, keine Rechtsberatung). Details dazu bei der Europäischen Kommission. Unabhängig von der rechtlichen Einordnung gilt: Ohne Protokoll lässt sich im Nachhinein weder klären, warum eine Aktion ausgeführt wurde, noch, ob der Freigabeprozess überhaupt funktioniert hat.

Praktisch gehört für jede freigabepflichtige Aktion mindestens Folgendes ins Protokoll.

• Welches Tool mit welchen Parametern angefragt wurde.
• Wer die Anfrage gestellt hat, also der Agent im Auftrag welches ursprünglichen Vorgangs.
• Wer entschieden hat und wann.
• Das Ergebnis (freigegeben, abgelehnt, Timeout) und, falls vorhanden, eine Begründung.

Das BSI empfiehlt in seinem Leitfaden zu sicherer generativer KI drei Dinge. KI-Ausgaben nie ungeprüft für kritische Geschäftsprozesse übernehmen. Ein Berechtigungskonzept für KI-Systeme erstellen. Rollen und Verantwortlichkeiten für KI-Anwendungen eindeutig zuweisen.

Ein Freigabeprotokoll ist die praktische Umsetzung genau dieser Empfehlungen für Agenten mit Tool-Zugriff. Es macht sichtbar, wer wann worüber entschieden hat.

Umsetzung: In sechs Schritten zum Freigabeprozess

So gehst du vor.

1. Tool-Inventar erstellen. Liste alle Tools und Aktionen auf, auf die der Agent Zugriff hat oder haben soll. Auch die technisch möglichen zählen, nicht nur die geplanten.

2. Jedes Tool einer Risikostufe zuordnen, mit der Matrix aus dem Abschnitt oben. Diesen Schritt macht ihr gemeinsam mit dem Fachbereich, nicht allein aus der IT heraus. Der Fachbereich kennt die tatsächliche Tragweite einer Aktion besser.

3. Freigabekanal und Zuständigkeit festlegen. Wer erhält Anfragen für welche Risikostufe? Eine einzelne Person als Single Point of Failure ist bequem, aber riskant. Plant mindestens eine Vertretung ein.

4. Ablehnungs- und Timeout-Pfad definieren, bevor der Agent produktiv geht. Was passiert, wenn niemand reagiert? Wer wird bei Ablehnung informiert?

5. Protokollierung einrichten, bevor der erste freigabepflichtige Aufruf passiert, nicht nachträglich.

6. Mit echten Randfällen testen, nicht nur mit dem Idealpfad: eine Anfrage, die niemand beantwortet, eine Ablehnung, ein Tool-Aufruf mit ungewöhnlichen Parametern. Erst wenn diese Fälle sauber laufen, ist der Prozess bereit für den Produktivbetrieb.

Ob dahinter ein klassischer Workflow oder ein autonomerer Agent steckt, ändert am Grundmuster wenig, denn Freigaben lassen sich in beiden Fällen einbauen, nur die konkrete Umsetzung unterscheidet sich.

Zum Aufwand gibt es seriös nur eine grobe Einordnung, keine feste Zahl. Für einen einzelnen Agenten mit wenigen Tools ist die Grundkonfiguration meist eine Sache von Tagen, nicht Wochen. Dazu zählen Kanal anbinden, zwei bis drei Tools als freigabepflichtig markieren und die Protokollierung einrichten. Voraussetzung ist, dass die Workflow-Plattform die Funktion bereits mitbringt.

Aufwändiger wird es mit eigener Eskalations- und Timeout-Logik oder mehreren Systemen mit unterschiedlichen Freigabemechanismen. Dann hängt der Aufwand stark von der bestehenden Systemlandschaft ab. Seriös schätzen lässt er sich erst nach einer kurzen technischen Bestandsaufnahme.

Risiken & Grenzen

Ein Freigabeprozess ist kein Selbstläufer. Diese 5 Punkte gehören auf den Radar.

• Freigabe-Müdigkeit. Werden zu viele unkritische Anfragen zur Freigabe geschickt, sinkt die Sorgfalt der Prüfung. Menschen klicken irgendwann reflexhaft „Ja“. Eine gut kalibrierte Risikomatrix verlangt deshalb so wenige Freigaben wie nötig, nicht so viele wie möglich.

• Prozessstillstand bei falscher Kalibrierung. Wird zu viel als Stufe 2 oder 3 eingestuft, entsteht genau der Effekt, den man vermeiden wollte. Der Agent wartet ständig auf Menschen, und der Geschwindigkeitsvorteil der Automatisierung geht verloren.

• Freigabe ist keine Rechtsprüfung. Wer schnell auf „Zustimmen“ klickt, prüft in der Regel Plausibilität, nicht rechtliche oder fachliche Korrektheit im Detail. Aktionen mit echter rechtlicher Tragweite, etwa Verträge oder personenbezogene Entscheidungen, brauchen fachliche Prüfkompetenz bei der freigebenden Person. Eine Freigabe-Schaltfläche allein reicht nicht.

• Kein Ersatz für ein Berechtigungskonzept. Human Approval regelt einzelne Aktionen. Hat ein Agent grundsätzlich zu weitreichenden Systemzugriff, hilft die beste Freigabe-Logik nur bedingt. Berechtigungen und Freigaben gehören zusammen gedacht, nicht als Ersatz füreinander.

• Kein garantierter Schutz. Ein Freigabeprozess senkt das Risiko fehlerhafter oder schädlicher Aktionen, ersetzt aber keine vollständige Kontrolle. Er ist auch kein Nachweis rechtlicher Konformität. Dafür bleibt eine Einzelfallprüfung nötig, insbesondere bei AI-Act-relevanten Einsatzszenarien.

Checkliste: Human Approval für KI-Agenten einführen

1. Alle Tools und Aktionen des Agenten sind inventarisiert, auch die technisch möglichen.

2. Jedes Tool ist einer Risikostufe zugeordnet, gemeinsam mit dem Fachbereich, nicht allein von der IT.

3. Kritische Aktionen, also extern wirkend oder schwer rückholbar, sind als freigabepflichtig markiert.

4. Ein Freigabekanal und mindestens eine Vertretung sind benannt.

5. Der Ablehnungspfad ist definiert: Wer wird informiert, gibt es eine Alternative?

6. Der Timeout-Fall ist geregelt: Eskalation, Erinnerung oder definierter Abbruch statt unbegrenztem Warten.

7. Jede Entscheidung wird protokolliert: Tool, Parameter, Entscheider, Zeitpunkt, Ergebnis.

8. Der Prozess wurde mit echten Randfällen getestet, nicht nur mit dem Idealpfad.

9. Die Risikoeinstufung wird regelmäßig überprüft, denn neue Tools oder geänderte Prozesse verändern sie.

10. Bei AI-Act-relevanten oder rechtlich sensiblen Szenarien ist zusätzlich fachliche oder rechtliche Prüfung eingeplant.

Du bist unsicher, wo dein Agenten-Vorhaben auf dieser Skala steht? Wir schauen uns gemeinsam an, welche Aktionen bei euch wirklich Kontrolle brauchen und wie sich das umsetzen lässt, ohne den Nutzen der Automatisierung zu verlieren. Der Weg dahin: Erstgespräch anfragen oder direkt unser Beratungsangebot.