Wann sollte ein KI‑Agent die menschliche Genehmigung benötigen?

Nicht bei jedem Schritt. Wenn eine Person jede Lese‑ und jede Low‑Risk‑Tool‑Aufruf genehmigen muss, wird sie schnell mechanisch klicken. Genehmigungen sind dort sinnvoll, wo ein Agenten‑Fehler reale Konsequenzen auslösen kann: finanziell, extern, administrativ, rechtlich, sicherheitsrelevant oder schwer rückgängig zu machen.

Ein weiterer wichtiger Punkt: Das Maß an Kontrolle sollte nicht davon abhängen, wie zuversichtlich das Modell klingt. Ein zuversichtliches Modell kann trotzdem falsch liegen. Wir wählen die Kontrolle anhand der Konsequenz der Aktion.

Entscheidungsmodell: fünf Fragen, bevor Autonomie gewährt wird

Für jede Agenten‑Aktion prüfen wir fünf Merkmale.

1. Ändert die Operation den Zustand?

Ein Lesevorgang ist in der Regel weniger riskant als ein Schreibvorgang. Nicht immer – ein Lesevorgang kann sensible Daten preisgeben – aber die Trennung von Lesen und Schreiben ist ein nützlicher Ausgangspunkt.

2. Verläßt die Konsequenz das interne System?

Eine E‑Mail senden, einen Beitrag veröffentlichen, eine Anzeige aktivieren, ein Dokument ausstellen oder einem Kunden antworten ist extern sichtbar. Ein Fehler wird sofort zu einem Beziehungs‑, Kosten‑ oder Reputationsproblem.

3. Schafft die Operation Kosten oder Verpflichtungen?

Ein Agent kann einen API‑Aufruf korrekt ausführen und trotzdem die falsche geschäftliche Entscheidung treffen. Budget, Einkauf, Zahlung, Abonnements oder Ressourcen‑Reservierungen benötigen eine eigene Grenze.

4. Kann die Änderung leicht rückgängig gemacht werden?

Ein Label ändern und ein Konto löschen gehören nicht in dieselbe Klasse. Berücksichtigen Sie Wiederherstellungskosten, Wiederherstellungszeit, Datenverlust und die Auswirkungen auf andere Nutzer.

5. Ändert die Operation Sicherheit oder Berechtigungen?

Administrator‑Zugriff gewähren, ein Geheimnis rotieren, eine Ressource öffentlich machen oder die MFA‑Richtlinie ändern, verdient Kontrolle, selbst wenn die Aktion technisch reversibel ist.

Praktische Autonomie‑Matrix

Ebene	Merkmal der Aktion	Beispiele	Standard‑Entscheidung
A — autonom	Nur Lesezugriff, geringer Einfluss, eng begrenzt	Service‑Status, Kostenbericht, Aufgabenliste	Agent darf ausführen
B — autonom mit Audit	Reversibler Schreibvorgang in begrenztem Bereich	Tag hinzufügen, Entwurf speichern, Aufgabe erstellen	Agent darf ausführen mit expliziter Erlaubnis und Protokollierung
C — Genehmigung vor Wirkung	Externe Konsequenz, finanzielle Auswirkung oder materielle Änderung	Nachricht senden, veröffentlichen, Kampagne aktivieren	Mensch genehmigt die konkrete Operation
D — starke Kontrolle	Zerstörerisch, sicherheitsrelevant, schwer rückgängig zu machen	Daten löschen, Admin‑Zugriff ändern, Schlüssel widerrufen	Getrennte Scope + Genehmigung + Vorschau; oft zusätzliche Verifizierung

Dies ist ein operatives Modell, kein rechtlicher Standard. Ein konkretes System sollte die Ebenen an seine Daten, Regulierungen, Konsequenzen und Wiederherstellungsmechanismen anpassen.

Genehmigung muss an eine konkrete Konsequenz gebunden sein

Ein schlechtes Genehmigungs‑Dialog‑Design sieht so aus:

Der Agent möchte eine Aktion ausführen. Fortfahren? Ja / Nein.

Die Person weiß nicht, was sie autorisiert.

Eine bessere Vorschau sieht eher so aus:

Operation: KAMPAGNE AKTIVIEREN
Konto: Brillnet Ads / [menschlich lesbarer Bezeichner]
Kampagne: Search — Pulsar GRC
Durchschnittliches Tagesbudget: PLN 80
Ziel: Polen
Änderung: PAUSED → ENABLED
Reversibler Zustand: Kampagne kann wieder pausiert werden; bereits angefallene Ausgaben werden nicht zurückgebucht
Konsequenz: Nach Genehmigung kann die Kampagne Ausgaben generieren
Entscheidungsquelle: Task #…

Erst dann hat ein „Genehmigen“-Button eine sinnvolle Bedeutung. In Google Ads ist ein durchschnittliches Tagesbudget kein striktes Tageslimit: Für die meisten Kampagnen beträgt das tägliche Abrechnungs‑Limit das Doppelte dieses Betrags. Die Vorschau sollte diese Konsequenz erklären, anstatt ein PLN 80‑Deckelchen zu versprechen.

Genehmigung darf nicht zu einer Pauschal‑Freigabe für zukünftige Änderungen werden

Angenommen, eine Person genehmigt:

Diese Nachricht an 12 Empfänger senden

Wenn der Agent nach der Genehmigung den Inhalt oder die Empfängerliste auf 1 200 Personen ändert, sollte die ursprüngliche Genehmigung nicht mehr gelten.

Eine praktische Regel lautet:

Genehmigung ist an eine spezifische, normalisierte Operation gebunden. Eine wesentliche Änderung ihrer Parameter macht die Genehmigung ungültig und erfordert eine neue.

Eine Implementierung kann die Genehmigungs‑ID an einen Hash der Operations‑Parameter, eine Ressourcen‑Version oder eine andere stabile Repräsentation dessen binden, was tatsächlich genehmigt wurde.

Das Modell sollte nicht selbst entscheiden, ob Genehmigung übersprungen werden kann

Ein Modell kann nach Risiko geschätzt werden. Das kann als ein Signal nützlich sein, aber es sollte nicht die einzige Kontrolle sein.

Wenn die Richtlinie lautet:

Wenn das Modell die Operation als riskant einstuft, fragt es einen Menschen

dann kontrolliert das Modell zugleich den Mechanismus, der dazu gedacht ist, die Auswirkungen seiner eigenen Fehler zu begrenzen.

Ein stärkeres Design ist:

1. Das Modell wählt das Tool und die Parameter.
2. Das Gate‑Klasse klassifiziert die Operation anhand expliziter Richtlinien.
3. Die Richtlinien‑Engine bestimmt, ob eine Genehmigung erforderlich ist.
4. Eine Person genehmigt, wenn nötig.
5. Erst danach wird die Ausführung durchgeführt.

Das Modell kann die Erklärung liefern. Die endgültige Klassifizierung kommt aus der System‑Richtlinie.

Beispiel aus unserer eigenen Automatisierung: Kampagnenvorbereitung ≠ Ausgaben starten

In unserem internen Brillnet Ads MCP trennen wir die Möglichkeit, eine Kampagne vorzubereiten oder zu ändern, von der Möglichkeit, Ausgaben zu aktivieren.

Eine neu erstellte Kampagne hat standardmäßig den Status PAUSED, wenn kein anderer Status explizit angegeben wird. Das Speichern der Konfiguration ist keine Zustimmung zum Ausgabenstart. Das Aktivieren der operativen Wirkung erfordert eine explizite Operate‑Berechtigung und Bestätigung im Request. Ein reines Bestätigungsfeld beweist nicht, dass eine Person die Aktion geprüft hat. Dieser Nachweis erfordert den unabhängigen Genehmigungsmechanismus, der oben beschrieben wurde.

Diese kleine Trennung hat ein nützliches Ergebnis:

• Der Agent kann den Großteil der Vorbereitungsarbeit erledigen;
• Eine Person muss nicht jedes Feld manuell eingeben;
• Das Budget startet nicht nur, weil das Modell die Konfiguration für fertig hielt.

Das gleiche Muster lässt sich auf andere Workflows übertragen:

Vorbereitung	Wirkung, die eine separate Entscheidung erfordert
Entwurf einer E‑Mail	Versand
Vorschlag einer Nutzerrolle	Zugriff gewähren
Migrationsplan	Migration ausführen
Liste zu löschender Dateien	Löschen
Vorgeschlagene Preisänderung	Neuen Preis veröffentlichen
Vorbereitete Zahlung	Zahlung autorisieren

Wann Genehmigung möglicherweise unnötig ist

Nicht jede Automatisierung muss halb‑automatisch sein.

Menschliche Genehmigung bringt oft wenig Mehrwert, wenn alle folgenden Bedingungen zutreffen:

• Die Operation ist nur Lese‑ oder von geringem Einfluss;
• Der Agent arbeitet innerhalb eines engen, vorab genehmigten Umfangs;
• Das Ergebnis wird nicht automatisch veröffentlicht;
• Ein Fehler ist leicht zu erkennen und zu beheben;
• Es entstehen keine Kosten oder externen Verpflichtungen;
• Berechtigungen und Sicherheitseinstellungen bleiben unverändert;
• Die Aktion hinterlässt genügend Audit‑Beweise, um das Ergebnis zu rekonstruieren.

Beispiel: Ein Agent ruft täglich den Kampagnen‑Status ab und erstellt einen internen Bericht. Die Genehmigung jedes Lesevorgangs erhöht die Sicherheit nicht im Verhältnis zu den Betriebskosten.

Wann wir Genehmigung als Minimum empfehlen

In unseren Projekten würde ich keine autonome Ausführung ohne separate Analyse für Operationen gewähren, die:

• Kunden‑ oder öffentliche Kommunikation senden;
• Ausgaben starten oder erhöhen;
• Daten löschen oder überschreiben, ohne einfachen Wiederherstellungsweg;
• Berechtigungen gewähren, erweitern oder widerrufen;
• Geheimnisse, Sicherheitskonfigurationen oder MFA ändern;
• Rechtsverbindliche Bedingungen im Namen einer Organisation akzeptieren;
• Auf eine mehrdeutig identifizierte Ressource zugreifen;
• Ein anderes System auslösen, das selbst hoch‑impact‑Aktionen ausführen kann.

Das bedeutet nicht, dass menschliche Genehmigung immer die einzige Kontrolle ist. Für kritische Aktionen sollte sie eine von mehreren Schichten sein.

Auf Genehmigungs‑Müdigkeit achten

Wenn ein System 80 Mal am Tag um Genehmigung bittet, hören die Nutzer auf, die Hinweise zu lesen. Genehmigung wird zu einem „Employee CAPTCHA“.

Das weist meist auf eines von drei Design‑Problemen hin:

1. Die Risikoklassifizierung ist zu breit;
2. Der Workflow gruppiert logisch zusammengehörige Änderungen nicht;
3. Der Agent hat zu wenig sichere Autonomie bei geringem Risiko, sodass alles eskaliert.

Die Antwort ist nicht, Warnungen zu verstecken. Es ist, bessere Grenzen zu entwerfen.

Was ein nützliches Genehmigungs‑Mechanismus leisten sollte

Unterschied (Diff) zeigen, nicht das ganze Objekt

Bei Konfigurationen zeigen Sie vorher → nachher und nur die geänderten Felder. Der Prüfer muss nicht manuell zwei Bildschirme vergleichen.

Konsequenz benennen

„Änderung speichern“ ist schwächer als „Kampagne aktivieren — sie kann beginnen, Ausgaben mit einem durchschnittlichen Tagesbudget von PLN 80 zu generieren“.

Einen Scope und eine Lebensdauer haben

Eine alte Genehmigung sollte nicht mehr autorisieren, wenn sich der Kontext ändert.

Material geänderte Operation ablehnen

Wenn Parameter nach Genehmigung geändert werden, muss die Genehmigung verfallen.

Unabhängiger Datensatz

Der Audit‑Eintrag sollte enthalten, wer was wann und unter welcher Operations‑ID genehmigt hat. Er darf nicht nur auf eine Modell‑Nachricht „der Nutzer hat zugestimmt“ vertrauen.

Lesen: KI‑Agent‑Audit‑Trails

Checkliste für eine einzelne Agenten‑Aktion

Bevor Autonomie gewährt wird, beantworten Sie:

• Ist die Aktion nur Lese‑Zugriff?
• Ändert sie den geschäftlichen Zustand?
• Schafft sie Kosten oder eine Verpflichtung?
• Ist das Ergebnis extern sichtbar?
• Bezieht sie persönliche oder vertrauliche Daten ein?
• Ändert sie Rollen, Berechtigungen oder Sicherheitskonfigurationen?
• Ist sie leicht reversibel?
• Ist die Ziel‑Ressource eindeutig?
• Kann ein Retry die Aktion zweimal ausführen?
• Kann das System vor Ausführung eine konkrete Vorschau zeigen?
• Wird die Genehmigung an die exakten Parameter gebunden?
• Kann der resultierende Zustand nach Ausführung verifiziert werden?

Wenn eine Aktion mehrere hoch‑riskante Merkmale kombiniert, kann ein einzelnes „OK“ selbst zu schwach sein.

Durchgerechnetes Beispiel: Ein Dienstleistungsunternehmen sendet einen Kundenbericht

Betrachten wir einen vorgeschlagenen Workflow statt einer gemeldeten Implementierung. Ein Agent ruft genehmigte Datensätze ab, vergleicht Fristen und erstellt einen Bericht. Der Kontoinhaber bleibt für den Inhalt verantwortlich. Der Prozess‑Owner definiert zulässige Daten und wer die Lieferung autorisieren darf.

Die Entwurfs‑Vorbereitung kann innerhalb des vorab genehmigten Rahmens laufen. Vor dem Versand werden Kunde, exakte Empfängeradresse, Betreff, Nachricht und Anhänge zusammen mit der Version der Quelldaten angezeigt. Der Prüfer sollte das Dokument direkt inspizieren können. Nur das Vertrauen auf die Zusammenfassung des Modells schwächt die Prüfung.

Die Genehmigung deckt genau dieses Paket ab. Das Hinzufügen eines Empfängers, das Ersetzen eines Anhangs oder das Ändern einer wesentlichen Empfehlung macht die Genehmigung ungültig. Eine zuvor definierte Regel kann eine Rechtschreibkorrektur zulassen, aber das darf nicht zur Erlaubnis werden, die Bedeutung zu ändern. Der Prozess‑Owner definiert, was als wesentliche Änderung gilt; die Ausführungs‑Komponente erzwingt die Grenze.

Was der Genehmigungs‑Datensatz enthalten sollte

Verknüpfen Sie die Genehmigung mit Person, Rolle, Mandant, Tool, Ziel‑Ressource, Daten‑Version, Parametern, Ablaufzeit und Task‑ID. Unterscheiden Sie zwischen vorgeschlagen, ausstehend, genehmigt, ausführend und unsicheren Ergebnissen. Der Bediener muss wissen, ob ein Klick eine Vorbereitung oder die eigentliche Ausführung auslöst.

Ein Parameter‑Hash hilft, Substitution zu erkennen. Er beweist nicht, dass die Person die Vorschau gelesen hat. Eine klare Oberfläche und ein autorisierter Prüfer bleiben wichtig. Eine Person ohne Berechtigung, Administrator‑Zugriff zu gewähren, darf diese Berechtigung nicht über ein Agenten‑Genehmigungs‑Dialog erhalten.

Für Batches zeigen Sie die Objekt‑Anzahl, wesentliche Ausnahmen und die Gesamtauswirkung. Eine Genehmigung kann ein präzise definiertes Batch abdecken, nicht jedoch beliebig weitere Objekte, die nach der Genehmigung ausgewählt werden. Das reduziert wiederholte Dialoge, ohne den Scope zu verlieren.

Unsichere Ausführung vor Wiederholung behandeln

Ein Provider kann eine Anfrage ausführen, obwohl die Antwort nie den Agenten erreicht. Fehlende Bestätigung ist kein Beweis für einen Fehlschlag. Ein erneuter Versuch kann eine zweite E‑Mail, ein doppeltes Dokument oder zusätzliche Kosten erzeugen. Prüfen Sie zuerst die Anfragen‑ID und den Provider‑Zustand.

Wo Idempotenz‑Schlüssel unterstützt werden, binden Sie einen an die Operation und verwenden ihn für dieselbe Anfrage erneut. Andernfalls implementieren Sie Duplikaterkennung oder lassen den Bediener nach Prüfung des Zustands entscheiden. Dokumentieren Sie ein unsicheres Ergebnis ehrlich. Mehrfaches Klicken löst kein unbekanntes Ergebnis auf.

Schweigen ist keine Genehmigung

Weisen Sie jedem Prozess einen Stellvertreter und einen Benachrichtigungskanal zu. Ablauf ohne Antwort blockiert die geschützte Operation. Der Agent kann weiter andere autorisierte, risikoarme Arbeiten erledigen; er darf nicht aus Stille oder einer geschäftlichen Frist Zustimmung ableiten.

Definieren Sie ein Not‑Stop‑Verfahren separat. Die Berechtigung, einen falschen Workflow zu stoppen, kann enger sein als die, ihn zu starten. Bewahren Sie den Ausführungs‑Zustand und die Liste erledigter Aktionen. Das Wiederherstellen einer Konfiguration kann eine bereits gelesene Kunden‑Nachricht nicht zurückrufen.

Prüfen, ob die Überprüfung Entscheidungen ändert

Verfolgen Sie Korrekturen, Ablehnungen, Wartezeiten und Versuche, materiell geänderte Parameter auszuführen. Vergleichen Sie Operationstypen separat. Langsame Genehmigungen von Kunden‑Kommunikationen sollten nicht die autonome interne Aufgaben‑Vorbereitung verhindern.

Wenn jede Vorschlag wochenlang sofort genehmigt wird, prüfen Sie eine Stichprobe mit dem Prozess‑Owner. Die Richtlinie ist möglicherweise zu breit, oder die Vorschau lässt wichtige Informationen weg. Eine hohe Genehmigungs‑Zahl beweist keine Sicherheit.

Morgen wählen Sie eine externe Aktion. Erstellen Sie deren Vorschau, bestimmen Sie einen autorisierten Prüfer, definieren Sie ein Ablaufdatum und verifizieren Sie, dass das Ändern des Empfängers die Genehmigung ungültig macht. Bestätigen Sie, dass eine Ablehnung keinerlei externe Wirkung hat.

Empfehlungen und Quellen‑Grenzen

OWASP behandelt Kontrollen für hoch‑impact‑Aktionen und Genehmigungs‑Integrität. Richtlinien zur Transaktions‑Autorisation befassen sich mit serverseitiger Verifizierung signifikanter Transaktionsdaten. Das NIST AI RMF ist freiwillige Risiko‑Management‑Leitlinie. Unsere A‑D‑Matrix ist eine ingenieurtechnische Empfehlung, keine gesetzliche Verpflichtung, jede KI‑Aktion zu genehmigen. Die interne Ads‑MCP‑Dokumentation vom 28. Juli 2026 beschreibt das zitierte Kontroll‑Design; sie beweist nicht eigenständig den Produktionseinsatz für einen Kunden.

Grenze

Dieses Klassifizierungs‑Modell ist unsere ingenieurtechnische Praxis, kein Rechtsrat oder formaler Risikobewertungs‑Standard. Regulierte, medizinische, finanzielle oder sicherheitskritische Prozesse können strengere Kontrollen erfordern.

Siehe auch MCP und KI‑Agenten: sicherere Werkzeuge entwerfen und Least privilege for AI agents.

Quellen

• OWASP AI Agent Security Cheat Sheet. Aufgerufen: 2026‑10‑02.
• OWASP Transaction Authorization Cheat Sheet. Aufgerufen: 2026‑10‑02.
• NIST AI Risk Management Framework. Aufgerufen: 2026‑10‑02.
• Google Ads Help — About spending limits. Aufgerufen: 2026‑10‑02.