Menschliche Freigabe in der KI-Automatisierung - Die Pause vor der Nebenwirkung

Eine KI-Anwendung, die eine E-Mail entwirft, und eine Anwendung, die diese E-Mail versendet, können dasselbe Modell verwenden. Sie verfügen jedoch nicht über dieselbe Art von Befugnis. Die erste erzeugt einen Vorschlag. Die zweite verändert etwas außerhalb der Anwendung. An welcher Stelle sollte ein Mensch dieser Veränderung zustimmen müssen?

„Ein Mensch muss eingebunden bleiben“ klingt wie eine Antwort, lässt die schwierigen Punkte jedoch offen. Welche Aktionen werden angehalten? Was sieht die prüfende Person? Was geschieht, wenn sich Ziel oder Betrag nach der Freigabe ändern? Kann das Modell die Bestätigung über ein anderes Tool umgehen? Ein Bestätigungsdialog kann zur bloßen Formalität statt zu einer wirksamen Kontrolle werden, wenn die Anwendung diese Fragen nicht beantworten kann.

Dieser Artikel entwickelt ein praktisches Entwurfsmuster für kleine KI-Automatisierungen. Es ist eine Synthese aus Sicherheits- und Risikomanagement-Leitlinien, kein universeller Standard: Vorschlag und Ausführung werden getrennt, Aktionen nach ihren Folgen eingestuft, die Freigabe an genau einen Vorschlag gebunden und die Grenze durch gewöhnlichen Anwendungscode durchgesetzt.

Die Freigabe gehört außerhalb des Modells

Tools machen aus einer Modellausgabe eine Fähigkeit. Sie können Daten abrufen, aber auch Nachrichten versenden, Datensätze ändern, Seiten veröffentlichen, Käufe tätigen oder Dateien löschen. Das OWASP GenAI Security Project unterscheidet drei Ursachen übermäßiger Handlungsfähigkeit: zu viel Funktionalität, zu weitreichende Berechtigungen und zu viel Autonomie. Eine menschliche Freigabe behandelt einen Teil des Autonomieproblems. Die beiden anderen Ursachen beseitigt sie nicht.

Diese Unterscheidung ist wichtig, weil das Modell kein Autorisierungsdienst ist. Es kann send_message vorschlagen, erklären, weshalb der Aufruf angemessen erscheint, oder ihn sogar als risikoarm einstufen. Die Anwendung muss trotzdem entscheiden, ob der authentifizierte Benutzer an diesen Empfänger senden darf, ob die Operation eine Freigabe benötigt und ob tatsächlich die freigegebenen Parameter ausgeführt werden.

OWASP empfiehlt deshalb, Autorisierung in nachgelagerten Systemen durchzusetzen, anstatt ein LLM darüber entscheiden zu lassen, ob eine Aktion erlaubt ist. Der Leitfaden zum Aufbau von Agenten von OpenAI vertritt einen vergleichbaren Standpunkt: Guardrails sollten mit Authentifizierung, Autorisierung, strenger Zugriffskontrolle und üblichen Maßnahmen der Softwaresicherheit kombiniert werden. Die Freigabe ist eine Schicht in diesem Aufbau, kein Ersatz für den gesamten Aufbau.

Nach Folgen anhalten, nicht nur wegen eines vorhandenen Tools

Eine Bestätigung für jeden Aufruf ist nicht zwangsläufig sicherer. Muss eine prüfende Person Dutzende harmlose Lesezugriffe bestätigen, kann die folgenreiche Anfrage zu einer weiteren Schaltfläche in einer langen Warteschlange werden. Ein nützlicherer Ausgangspunkt ist die Einstufung einer Aktion anhand mehrerer Fragen:

• Liest sie nur oder erzeugt sie eine Nebenwirkung? Ein öffentliches Dokument abzurufen ist etwas anderes, als eines zu veröffentlichen.
• Ist die Wirkung umkehrbar? Einen privaten Entwurf zu speichern unterscheidet sich vom Versand an eine Mailingliste; eine Datei in einen wiederherstellbaren Papierkorb zu verschieben unterscheidet sich von ihrer endgültigen Löschung.
• Wie groß ist der Umfang? Einen Datensatz zu bearbeiten unterscheidet sich davon, alle passenden Datensätze zu verändern.
• Welche Befugnis wird verwendet? Ein auf die Entwürfe eines Benutzers beschränktes Tool unterscheidet sich von gemeinsam genutzten administrativen Zugangsdaten.
• Was könnte offengelegt oder übertragen werden? Ein Aufruf kann Daten preisgeben oder Geld binden, ohne offensichtlich destruktiv zu wirken.

Dies ist eine praktische Einteilung, keine vorgeschriebene Liste. Das Generative AI Profile des NIST weist darauf hin, dass Aufsichtsformen je nach Kontext und Risiko unterschiedlich ausfallen können. Der OpenAI-Leitfaden empfiehlt ebenfalls, Tools anhand von Faktoren wie Lese- oder Schreibzugriff, Umkehrbarkeit, Kontoberechtigungen und finanziellen Auswirkungen einzustufen. Für eine kleine Anwendung kann daraus eine einfache Richtlinie entstehen: eng begrenzte Lesezugriffe zulassen, risikoarme und umkehrbare Schreibvorgänge automatisch ausführen und vor externen, sensiblen, weitreichenden, teuren, privilegierten oder unumkehrbaren Wirkungen anhalten.

Einige Aktionen sollten gar nicht verfügbar sein, statt lediglich hinter einer Abfrage zu liegen. Muss eine Automatisierung E-Mails nur zusammenfassen, sollte ihr Tool keine Nachrichten versenden oder löschen können. Muss sie nur einen bestimmten Datensatztyp aktualisieren, bietet ein uneingeschränktes SQL- oder Shell-Tool wesentlich mehr Macht als die Aufgabe erfordert. Unnötige Befugnisse zu entfernen ist stärker, als Menschen wiederholt um Zustimmung zu deren Nutzung zu bitten.

Den Vorschlag prüfbar machen

Eine prüfende Person kann „Fortfahren“ nicht sinnvoll genehmigen. Die Oberfläche muss die vorgeschlagene Nebenwirkung so beschreiben, dass ein Mensch sie prüfen kann. Je nach Operation gehören dazu:

• die Aktion sowie das Konto oder die Identität, die sie ausführt;
• das Ziel, etwa Empfänger, Repository, Dateipfad, Datensatz oder Veröffentlichungskanal;
• wesentliche Parameter wie Nachrichtentext, Patch, Betrag, Berechtigung oder Löschmodus;
• der erwartete Umfang und die Frage, ob das Ergebnis umkehrbar ist;
• der relevante Quellkontext und nicht vertrauenswürdige Inhalte, die den Vorschlag beeinflusst haben;
• die Grenzen, also was diese Freigabe nicht erlaubt.

Die Tool-Spezifikation des Model Context Protocol liefert ein konkretes Beispiel in diese Richtung. Sie empfiehlt deutliche Anzeigen bei Tool-Aufrufen, Bestätigungen für Operationen und die Anzeige von Tool-Eingaben vor sensiblen Aufrufen. Zugleich schreibt das Protokoll kein bestimmtes Interaktionsmodell vor. Ein Mechanismus für Tool Calls gestaltet also nicht automatisch einen vertrauenswürdigen Prüfprozess.

Eine Vorschau sollte die Wirkung und nicht die Begründung des Modells in den Mittelpunkt stellen. Bei einer E-Mail zeigt sie die tatsächlichen Empfänger, Betreff, Text und Anhänge. Bei einer Codeänderung zeigt sie Repository, Branch und Diff. Bei einer Veröffentlichung zeigt sie endgültigen Titel, Ziel, Sichtbarkeit und Inhalt. Ein selbstsicher formulierter Absatz darüber, warum die Aktion sinnvoll sei, ersetzt nicht die Bytes und Ziele, die verändert werden.

„Freigeben“ an genau eine Aktion binden

Die zentrale technische Schlussfolgerung lautet: Eine Freigabe sollte sich auf einen unveränderlichen oder zumindest gegen unbemerkte Änderungen geschützten Vorschlag beziehen. Der Vorschlag erhält eine Kennung und speichert die wesentlichen Aktionsdaten. Die prüfende Person genehmigt diese Kennung. Der Executor verwendet anschließend genau diesen Vorschlag, statt einen neuen Satz modellgenerierter Argumente anzunehmen.

Ohne diese Bindung könnte die Oberfläche einen Empfänger anzeigen, während die Ausführungsanfrage einen anderen enthält. Das Modell könnte einen Entwurf nach der Prüfung ändern, ein Hintergrundprozess könnte einen Datensatz verändern oder eine gewöhnliche Race Condition könnte die Vorschau veralten lassen. Das Problem ist nicht ausschließlich „KI-spezifisch“; es ist die bekannte Lücke zwischen Prüfung und Verwendung.

Eine kleine State Machine macht die Grenze sichtbar:

proposed -> pending_review -> approved -> executing -> completed
                           \-> rejected
                           \-> expired
                                          \-> failed

Wesentliche Änderungen erzeugen einen neuen Vorschlag und erfordern eine neue Freigabe. Ausstehende Freigaben laufen ab. Ein genehmigter Vorschlag wird einmal verbraucht, oder die Ausführung wird idempotent gestaltet, wenn Wiederholungen erforderlich sind. Der konkrete Mechanismus kann eine kanonische Serialisierung mit kryptografischem Digest, eine versionierte und nach der Prüfung nicht mehr editierbare Datenbankzeile oder eine andere zum Bedrohungsmodell passende Lösung sein. Die Quellen schreiben kein bestimmtes Speicherformat vor; entscheidend ist die Invariante: Die geprüfte und die ausgeführte Aktion dürfen nicht unbemerkt auseinanderfallen.

Befugnisse zum Ausführungszeitpunkt erneut prüfen

Eine Freigabe besagt, dass eine bestimmte Person einen bestimmten Vorschlag zu einem bestimmten Zeitpunkt akzeptiert hat. Sie beweist nicht, dass die Aktion weiterhin zulässig ist. Rollen können sich ändern, ein Datensatz kann bereits geschlossen sein, ein Ausgabenlimit kann erreicht oder das Ziel nicht mehr vorhanden sein.

Der Executor sollte deshalb den Akteur authentifizieren, die aktuelle Autorisierung neu bewerten, sämtliche Eingaben validieren und Geschäftsregeln unmittelbar vor der Nebenwirkung prüfen. Er sollte möglichst eng begrenzte Zugangsdaten des nachgelagerten Systems verwenden und, soweit möglich, im Kontext des Benutzers handeln. Diese Kontrollen folgen den OWASP-Empfehlungen zu minimalen Berechtigungen und vollständiger Vermittlung im Kapitel über excessive agency. Auch die MCP-Spezifikation verlangt von Servern, Tool-Eingaben zu validieren und Zugriffskontrollen einzusetzen.

Diese Trennung verhindert außerdem eine verlockende, aber unsichere Abkürzung: Das Modell darf nicht allein deshalb ein weitreichendes Tool aufrufen, weil in seinem Kontext ein boolesches approved=true erscheint. Freigabedienst und Executor, nicht die Unterhaltung, müssen den Übergang kontrollieren. Eine neue Prompt Injection, Modellantwort oder Tool-Ausgabe kann sich nicht selbst eine Berechtigung erteilen.

Belege aufbewahren, ohne Logs zum nächsten Datenleck zu machen

Der Lebenszyklus sollte genügend Belege hinterlassen, um das Geschehen zu rekonstruieren: Wer hat die Operation angefordert, welcher Vorschlag wurde angezeigt, wer hat ihn genehmigt oder abgelehnt, wann ist er abgelaufen oder ausgeführt worden, welche Richtlinienversion galt und welches Ergebnis oder welcher Fehler folgte? NIST empfiehlt klar definierte Aufsichtsrollen, die Überwachung und Dokumentation von Overrides sowie Prozesse nach der Bereitstellung für Einsprüche, Incident Response, Wiederherstellung und Änderungsmanagement. MCP empfiehlt ebenfalls, Tool-Nutzung für Audits zu protokollieren.

Mehr Protokollierung ist nicht automatisch besser. Tokens, Passwörter, private Nachrichtentexte und unnötige personenbezogene Daten gehören nicht allein deshalb in einen Audit-Datensatz, weil das System sie speichern kann. Ein nützliches Log kann Kennungen, Digests, Klassifizierungen, Zeitstempel und redigierte Zusammenfassungen enthalten, während sensible Nutzdaten eigenen Zugriffs- und Aufbewahrungsregeln unterliegen.

Fehlerpfade verdienen dieselbe Aufmerksamkeit wie die Freigabe. Was geschieht nach einem Timeout? Kann der Benutzer „nicht gesendet“ von „Antwort nach dem Senden verloren“ unterscheiden? Können zwei prüfende Personen denselben Vorschlag doppelt ausführen? Lässt sich eine teilweise abgeschlossene mehrstufige Aktion wiederherstellen? Eine menschliche Prüfung beantwortet diese Transaktionsfragen nicht.

Auch ein menschlicher Klick ist eine fehlbare Kontrolle

Ein Mensch kann die falsche Aktion freigeben, eine unklare Vorschau nur überfliegen oder sich an das Bestätigen von Abfragen gewöhnen. Für die in seinen Geltungsbereich fallenden Hochrisikosysteme zeigt Artikel 14 des EU AI Act, was „menschliche Aufsicht“ zusätzlich bedeuten kann: Aufsichtspersonen sollen Fähigkeiten und Grenzen verstehen, unerwartetes Verhalten erkennen, sich der Automatisierungsverzerrung bewusst bleiben, Ausgaben interpretieren, ignorieren oder umkehren und das System stoppen können. Diese rechtlichen Anforderungen gelten nicht für jede kleine KI-Anwendung. Auch die eng umrissene Zwei-Personen-Prüfung des Gesetzes ist keine allgemeine Regel für gewöhnliche Tool Calls. Die bescheidenere Lehre lautet: Eine Freigabe ist nur dann sinnvoll, wenn die prüfende Person über ausreichenden Kontext, Kompetenz und Befugnis sowie eine echte Möglichkeit zur Ablehnung verfügt.

Eine menschliche Freigabe neutralisiert auch keine bösartigen Inhalte. Ein manipuliertes Dokument kann weiterhin einen Vorschlag beeinflussen, ein kompromittiertes Prüferkonto kann ihn weiterhin genehmigen und ein übermächtiger Executor kann weiterhin übermäßigen Schaden verursachen. Sandboxing, Behandlung von Ein- und Ausgaben, Rate Limits, Monitoring, eng begrenzte Tools und Wiederherstellungspläne bleiben relevant. Die britischen Leitlinien zur sicheren Entwicklung von KI-Systemen des NCSC ordnen KI-spezifische Risiken in einen vollständigen Lebenszyklus aus sicherem Design, Entwicklung, Bereitstellung, Betrieb und Wartung ein, statt Modellverhalten als das gesamte Sicherheitsproblem zu betrachten.

Drei Beispiele für eine echte Grenze

E-Mail

Das Modell darf Nachrichten durchsuchen und mit reinen Lese- und Entwurfsrechten einen privaten Entwurf erstellen. Vor dem Versand hält der Ablauf an. Die Prüfung zeigt alle Empfänger, den genauen Betreff und Text, Anhänge sowie das Absenderkonto. Die Freigabe bezieht sich auf diesen eingefrorenen Entwurf; eine Änderung des Empfängers macht sie ungültig. Der E-Mail-Dienst prüft weiterhin, ob der Benutzer von diesem Konto senden darf.

Veröffentlichung

Recherche, Gliederung und das Speichern einer unveröffentlichten Überarbeitung können in einem eingeschränkten Arbeitsbereich erfolgen. Beim Übergang zu einer öffentlichen URL hält der Ablauf an. Der Vorschlag enthält die endgültige Inhaltsversion, Titel, Ziel, Sichtbarkeit und geplante Zeit. Die Freigabe eines Content-Digests kann keine spätere Neufassung veröffentlichen. Eine separate Deployment-Richtlinie kann die Veröffentlichung weiterhin wegen fehlender Übersetzung, fehlendem Thumbnail oder nicht bestandenem Quality Gate ablehnen.

Dateien

Das Lesen aus einem erlaubten Projektverzeichnis kann automatisch erfolgen. Vor dem Löschen werden kanonische Pfade, Anzahl, Gesamtumfang und Wiederherstellbarkeit angezeigt. Der Executor lehnt Pfade außerhalb des erlaubten Stammverzeichnisses ab und prüft sie nach dem Auflösen von Links erneut. Bei besonders wertvollen Daten kann der bessere Entwurf ganz auf ein Tool zum endgültigen Löschen verzichten: Die Daten werden in Quarantäne verschoben und später durch einen getrennten Aufbewahrungsprozess entfernt.

Diese Beispiele teilen ein Muster, keine universelle Schwelle. Die nützliche Pause liegt unmittelbar vor der folgenreichen Grenze, und der Mensch prüft die Wirkung, die diese Grenze überschreiten soll.

Wann kein Agent um die Aufgabe gebaut werden sollte

Eine Freigabearchitektur kann eine Automatisierung kontrollierbarer machen. Sie kann aber auch darauf hinweisen, dass die Automatisierung unnötig kompliziert ist. Anthropic empfiehlt in seinem Engineering-Artikel über Agenten, mit der einfachsten Lösung zu beginnen, und unterscheidet vordefinierte Workflows von Systemen, in denen ein Modell die Tool-Nutzung dynamisch steuert. OpenAI weist ebenfalls darauf hin, dass eine deterministische Lösung ausreichen kann, wenn eine Aufgabe keine modellgesteuerte Behandlung von Mehrdeutigkeit erfordert.

Wenn Schritte und Richtlinien bereits feststehen, kann gewöhnlicher Anwendungscode Eingaben erfassen, validieren, eine Vorschau anzeigen und nach Bestätigung ausführen. Das Modell kann beim Formulieren von Inhalten helfen, ohne die Transaktion zu kontrollieren. Ist eine Folge nicht hinnehmbar, schwer zu prüfen oder nicht wiederherstellbar, kann die richtige Antwort darin bestehen, diese Fähigkeit vollständig aus der Automatisierung herauszuhalten.

Fazit

Ein nützlicher Freigabeschritt ist keine dekorative Frage des Modells. Er ist eine von der Anwendung durchgesetzte Grenze, die vier Punkte klar beantwortet: Wer darf freigeben, welche genaue Aktion wurde geprüft, wie lange gilt die Freigabe und welcher Code darf anschließend ausgeführt werden?

Diese Grenze funktioniert am besten zusammen mit enger begrenzten Tools, Zugangsdaten nach dem Least-Privilege-Prinzip, aktuellen Autorisierungsprüfungen, sorgfältigen Vorschauen, Audit-Datensätzen und Wiederherstellungspfaden. Sie bleibt von fehlbaren Menschen abhängig und kann eine unvertretbare Operation nicht in eine sichere verwandeln. Die ehrliche Entwurfsfrage lautet daher nicht nur: „Ist ein Mensch eingebunden?“ Sie lautet: „Was kann dieser Mensch tatsächlich sehen, ablehnen, stoppen und verbindlich mit der nachfolgenden Aktion verknüpfen?“

References

1. National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, Juli 2024. Abgerufen am 26. Oktober 2026.
2. OWASP GenAI Security Project, LLM06:2025 Excessive Agency, Ausgabe 2025. Abgerufen am 26. Oktober 2026.
3. Model Context Protocol, Tools - Specification 2025-06-18, 18. Juni 2025. Abgerufen am 26. Oktober 2026.
4. UK National Cyber Security Centre, Guidelines for Secure AI System Development, Version 1.0, 27. November 2023. Abgerufen am 26. Oktober 2026.
5. OpenAI, A Practical Guide to Building AI Agents, 15. Januar 2026. Abgerufen am 26. Oktober 2026.
6. Erik S. und Barry Zhang, Anthropic, Building Effective Agents, 19. Dezember 2024. Abgerufen am 26. Oktober 2026.
7. Europäisches Parlament und Rat der Europäischen Union, Regulation (EU) 2024/1689, Article 14: Human Oversight, Amtsblatt, 12. Juli 2024. Abgerufen am 26. Oktober 2026.