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

Ein KI-Agent, der jede E-Mail vor dem Versand von einem Menschen prüfen lässt, ist sicher – und für die meisten Anwendungsfälle unbrauchbar langsam. Ein Agent, der alles autonom ausführt, ist schnell – und ein Kontrollverlust, sobald er eine falsche Rechnung verschickt, eine Kundendatei löscht oder eine Bestellung auslöst, die niemand geprüft hat. Human Approval für KI-Agenten löst genau dieses Spannungsfeld: Nicht jede Aktion braucht eine Freigabe, aber 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 – also Systeme, die nicht nur Text ausgeben, sondern E-Mails verschicken, Datensätze ändern, Bestellungen auslösen oder mit anderen Systemen kommunizieren können. Er 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

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 irgendwo verwendet werden – Human Approval im engeren Sinn setzt am Tool-Aufruf an, nicht erst am Ergebnis.

Zwei Varianten sind in der Praxis 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 – Slack, Microsoft Teams, E-Mail, WhatsApp – an eine zuständige Person, die zu einem späteren Zeitpunkt reagiert. 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 (Systeme, Daten, APIs); Human Approval legt fest, wann eine an sich mögliche Aktion zusätzlich eine menschliche Entscheidung braucht. Ein Agent kann also technisch die Berechtigung haben, eine Zahlung auszulösen, und trotzdem bei jeder Zahlung über einem Schwellenwert eine Freigabe einholen müssen.

Welche Aktionen brauchen Freigabe?

Die Kernfrage lässt sich nicht pauschal mit einer Liste beantworten, aber mit zwei Kriterien systematisch herleiten: Rückholbarkeit (lässt sich die Aktion folgenlos rückgängig machen?) und Wirkungsradius (bleibt der Effekt intern, oder wirkt er nach außen – auf Kund:innen, Lieferant:innen, Öffentlichkeit, Finanzen?).

Aktionen, die typischerweise Freigabe brauchen, weil beide Kriterien kritisch ausfallen:

• Externe Kommunikation, die im Namen des Unternehmens verschickt wird: E-Mails an Kund:innen, Nachrichten in sozialen Netzwerken, automatisierte Antworten auf Support-Anfragen 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.

Aktionen, die üblicherweise keine Freigabe brauchen, weil sie leicht korrigierbar und intern bleiben:

• Lesezugriffe: Daten abfragen, Dokumente durchsuchen, Status prüfen.
• Textentwürfe erstellen, die anschließend ohnehin von einem Menschen gelesen werden, bevor sie irgendwohin gehen.
• Zusammenfassungen, Kategorisierungen und interne Vorsortierungen ohne unmittelbare Außenwirkung.

Die Grauzone dazwischen – etwa eine interne Slack-Nachricht an ein ganzes Team oder eine automatische Kalenderbuchung – lohnt eine bewusste Einzelfallentscheidung statt einer Bauchgefühl-Regel. Genau dafür dient die Risikomatrix im nächsten Abschnitt.

Eine praktische Faustregel aus Projekten: Wenn die Antwort auf die Frage „Was passiert im schlimmsten Fall, wenn diese Aktion mit falschen Parametern ausgeführt wird?” mehr als eine Korrektur-E-Mail oder einen kurzen internen Hinweis erfordert, 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 – kein branchenweiter Standard, sondern ein Ausgangspunkt, den du an dein Unternehmen anpassen solltest:

Stufe	Rückholbarkeit	Wirkungsradius	Freigabe-Modus	Beispiele
0 – Automatisch	vollständig	intern	keine Freigabe	Suchen, lesen, zusammenfassen, Entwurf erstellen
1 – Protokolliert	vollständig	extern sichtbar, aber niedrige Tragweite	keine Vorab-Freigabe, aber Nachprotokollierung und Stichproben	Interne Statusmeldung an ein Team, automatische Terminbestätigung
2 – Zeitversetzt freizugeben	teilweise oder aufwändig	mittel bis hoch	asynchrone Freigabe vor Ausführung	Kundenmail mit individuellem Inhalt, Bestellung unterhalb eines Schwellenwerts
3 – Zwingend synchron freizugeben	nicht oder nur mit Schaden	hoch, finanziell oder rechtlich relevant	sofortige Freigabe, kein automatischer Fallback	Zahlung auslösen, Datensatz löschen, Vertrag versenden

Eigenes Stufenmodell Philogic Labs, abgeleitet aus Umsetzungsprojekten. Die konkrete Zuordnung einzelner Aktionen zu einer Stufe ist unternehmensspezifisch und sollte mit den Fachbereichen abgestimmt werden, 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, es tatsächlich einmal für jeden Tool-Aufruf durchzugehen – die meisten Vorfälle, die ich in Projekten sehe, entstehen nicht durch ein falsch eingestuftes Risiko, sondern durch ein Tool, das schlicht vergessen wurde einzustufen.

Wie funktionieren zeitversetzte Freigaben?

Technisch läuft eine zeitversetzte Freigabe in einer festen Abfolge ab. Am Beispiel eines Workflow-Tools wie n8n, das eine solche Funktion für KI-Agenten-Tool-Aufrufe direkt eingebaut hat:

1. Der Agent entscheidet sich für einen Tool-Aufruf, zum Beispiel „Bestellung auslösen” mit bestimmten Parametern (Artikel, Menge, Lieferant).
2. Das System erkennt, dass dieses Tool als freigabepflichtig markiert ist, und pausiert die Ausführung an dieser Stelle, statt sie durchzureichen.
3. Eine Genehmigungsanfrage wird über den konfigurierten Kanal verschickt – laut n8n-Dokumentation 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, und der Agent erhält die Ablehnung als Information für den weiteren Ablauf (mehr dazu im nächsten Abschnitt).

Die Granularität ist dabei wichtig für die Praxistauglichkeit: 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 zu Timeout-Verhalten – also was passiert, wenn niemand innerhalb einer bestimmten Frist reagiert. Wer zeitversetzte Freigaben produktiv einsetzt, sollte diesen Fall explizit im eigenen Workflow regeln: eine Eskalation an eine zweite Person, eine Erinnerung nach einer festgelegten Frist, oder ein automatischer Abbruch mit Benachrichtigung, statt eine Anfrage unbegrenzt offen zu lassen. Das ist kein Nachteil des Werkzeugs, sondern ein Punkt, den jedes Unternehmen für seinen eigenen Kontext festlegen muss.

Was passiert bei Ablehnung?

Eine abgelehnte Freigabe ist kein Fehlerzustand, sondern das System funktioniert wie vorgesehen – trotzdem wird sie in der Praxis oft schlecht behandelt. Zwei 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, weil kein alternativer Pfad definiert wurde.

Ein durchdachter Ablehnungspfad legt vorher fest: Wer wird bei Ablehnung informiert (die ursprünglich anfragende Person, ein Team-Kanal)? Gibt es eine Alternative (zum Beispiel: „E-Mail nicht automatisch versenden, sondern als Entwurf ablegen”)? Und wird die Ablehnung inklusive Begründung dokumentiert, damit sich Muster erkennen lassen – etwa wenn ein bestimmter Tool-Aufruf auffällig oft abgelehnt wird, was meist auf ein grundsätzliches Konfigurationsproblem hindeutet, nicht auf einen Einzelfall.

Wie wird es auditierbar?

Auditierbarkeit ist kein Nice-to-have, sondern in zwei Richtungen relevant: operativ (was ist passiert, wenn etwas schiefgeht?) und regulatorisch. Der EU AI Act verlangt 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 sollte für jede freigabepflichtige Aktion mindestens Folgendes protokolliert werden:

• welches Tool mit welchen Parametern angefragt wurde,
• wer die Anfrage gestellt hat (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 in Unternehmen unter anderem, KI-Ausgaben nie ungeprüft oder für kritische Geschäftsprozesse zu übernehmen, ein Berechtigungskonzept für KI-Systeme zu erstellen und Rollen sowie Verantwortlichkeiten für KI-Anwendungen eindeutig zuzuweisen. Ein Freigabeprotokoll ist im Grunde die praktische Umsetzung genau dieser Empfehlung für Agenten mit Tool-Zugriff: Es macht sichtbar, wer wann worüber entschieden hat.

Umsetzung: In sechs Schritten zum Freigabeprozess

1. Tool-Inventar erstellen. Liste alle Tools/Aktionen, auf die der Agent Zugriff hat oder haben soll – nicht nur die geplanten, auch die technisch möglichen.
2. Jedes Tool einer Risikostufe zuordnen, mit der Matrix aus dem Abschnitt oben. Diesen Schritt gemeinsam mit dem Fachbereich machen, 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 Person als Single Point of Failure zu benennen, ist bequem, aber riskant – mindestens eine Vertretung einplanen.
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 technisch ein klassischer Workflow oder ein autonomerer Agent steckt, ändert am Grundmuster wenig – Freigabeprozesse lassen sich in beiden Fällen einbauen, nur die konkrete technische Umsetzung unterscheidet sich.

Zum Aufwand lässt sich seriös nur eine grobe Einordnung geben, keine feste Zahl: Für einen einzelnen Agenten mit wenigen Tools ist die Grundkonfiguration – Kanal anbinden, zwei bis drei Tools als freigabepflichtig markieren, Protokollierung einrichten – meist eine Sache von Tagen, nicht Wochen, sofern die zugrunde liegende Workflow-Plattform die Funktion bereits mitbringt. Aufwändiger wird es, wenn eigene Eskalations- und Timeout-Logik gebaut werden muss oder mehrere Systeme mit unterschiedlichen Freigabemechanismen zusammenspielen sollen – dann hängt der Aufwand stark von der bestehenden Systemlandschaft ab und lässt sich erst nach einer kurzen technischen Bestandsaufnahme seriös schätzen.

Risiken & Grenzen

Ein Freigabeprozess ist kein Selbstläufer und löst nicht automatisch alle Probleme:

• Freigabe-Müdigkeit. Werden zu viele unkritische Anfragen zur Freigabe geschickt, sinkt die Sorgfalt der Prüfung – Menschen klicken irgendwann reflexhaft „Ja”. Das eigentliche Ziel einer gut kalibrierten Risikomatrix ist deshalb, so wenige Freigaben wie nötig zu verlangen, 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. Eine Person, die schnell auf „Zustimmen” klickt, prüft in der Regel Plausibilität, nicht rechtliche oder fachliche Korrektheit im Detail. Für Aktionen mit echter rechtlicher Tragweite (Verträge, personenbezogene Entscheidungen) braucht es zusätzlich fachliche Prüfkompetenz bei der freigebenden Person, nicht nur eine Freigabe-Schaltfläche.
• Kein Ersatz für ein grundsätzliches Berechtigungskonzept. Human Approval regelt einzelne Aktionen, aber wenn ein Agent grundsätzlich zu weitreichenden Systemzugriff hat, 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 und ist 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/Aktionen des Agenten sind inventarisiert – auch die technisch möglichen, nicht nur die aktiv genutzten.
2. Jedes Tool ist einer Risikostufe zugeordnet, gemeinsam mit dem Fachbereich, nicht allein von der IT.
3. Kritische Aktionen (extern wirkend, schwer rückholbar) sind als freigabepflichtig markiert.
4. Ein Freigabekanal und mindestens eine vertretungsberechtigte Person 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 Freigabeentscheidung wird protokolliert: Tool, Parameter, Entscheider, Zeitpunkt, Ergebnis.
8. Der Prozess wurde mit echten Randfällen getestet, nicht nur mit dem Idealpfad.
9. Es gibt eine regelmäßige Überprüfung der Risikoeinstufung – neue Tools oder geänderte Prozesse verändern die Einstufung.
10. Bei AI-Act-relevanten oder rechtlich sensiblen Einsatzszenarien ist zusätzlich fachliche oder rechtliche Prüfung eingeplant, nicht nur eine technische Freigabe.

Wenn du unsicher bist, wo dein Agenten-Vorhaben auf dieser Skala steht oder wie ein Freigabeprozess konkret für eure Tool-Landschaft aussehen sollte: 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 – Kontaktaufnahme für ein Erstgespräch oder direkt zu unserem Beratungsangebot.