Wie viel Befugnis sollte ein KI-System haben?

💡 Kurzfassung: Kernaussagen

• Die richtige Aktion zu empfehlen, gibt einem Modell nicht die Befugnis, sie auszuführen. Geschäftsregeln und Zugriffskontrollen müssen weiter gelten, wenn aus einem Vorschlag eine reale Transaktion wird.
• Ein Entwurf, eine Vorschau und eine verbindliche Aktion bergen unterschiedliche Risiken. Begrenzen Sie die Befugnis des Modells nach den Folgen für Geld, Kunden, Zugänge oder externe Kommunikation.
• Menschliche Freigabe ist nur sinnvoll, wenn sie die Entscheidung noch verändern kann. Wiederholungen dürfen keine Transaktionen verdoppeln; Erfolg ist im maßgeblichen System zu prüfen, nicht aus der Modellantwort abzuleiten.

Ein Kundensupportsystem erkennt, dass ein Kunde für eine doppelt belastete Bestellung eine Erstattung möchte. Es findet die Bestellung, berechnet die Erstattung und antwortet: „Ihre Erstattung wurde ausgeführt.“

Der Satz kann korrekt sein. Für sich allein beweist er jedoch nicht, dass etwas geschehen ist.

Das Modell kann die Anfrage richtig verstanden haben. Die Bestellung kann erstattungsfähig und der Betrag korrekt sein. Trotzdem muss das System prüfen, ob dieser Kunde die Anfrage stellen darf, ob die Erstattung der Unternehmensrichtlinie entspricht und ob der Zahlungsdienstleister sie tatsächlich verarbeitet hat.

Die richtige Aktion zu empfehlen und die Befugnis zu haben, sie auszuführen, sind zwei verschiedene Entscheidungen.

Eine Aktions-Empfehlung verleiht keine Befugnis

Sprachmodelle erzeugen nicht mehr nur Text. Sie können Bestelldaten lesen, E-Mails entwerfen, Termine in einen Kalender eintragen oder eine Anfrage an ein Zugriffsmanagementsystem senden. Die mit einem Modell verbundenen APIs und Softwarefunktionen werden üblicherweise Werkzeuge genannt.

Der Zugriff auf ein Werkzeug macht das Modell nicht zu einem autorisierten Entscheider.

Ein Vertriebsassistent kann eine E-Mail entwerfen und den passenden Kontakt im CRM finden. Doch in wessen Namen die Nachricht gesendet wird, ob der Empfänger korrekt ist und welche Kundeninformationen das Unternehmen verlassen dürfen, sind keine Entscheidungen, die das Modell frei treffen sollte.

Bei Mitarbeiterzugriffen ist die Grenze noch klarer. Ein Modell kann die Rolle eines neuen Mitarbeiters prüfen und die benötigten Systeme vorschlagen. Administratorzugriff auf das Finanzsystem zu vergeben, ist nicht der automatische nächste Schritt. Zugriffsrichtlinie, Freigabe durch die Führungskraft und bestehende Rollengrenzen des Unternehmens müssen weiter gelten.

Deshalb beschreibt OWASP das Risiko übermäßiger Handlungsautonomie nicht nur als Modellverhalten. OWASP empfiehlt, Werkzeugfunktionen, Berechtigungen und Autonomie getrennt zu begrenzen.

Entwurf, Vorschau und verbindliche Transaktion bergen unterschiedliche Risiken

Ein Beschaffungssystem kann Lieferantenangebote vergleichen und einen Entwurf für eine Bestellung vorbereiten. Der Entwurf kann Budgetcode, Menge und Lieferbedingungen enthalten. Zu diesem Zeitpunkt ist das Unternehmen gegenüber dem Lieferanten noch keine Verpflichtung eingegangen.

Der nächste Schritt kann eine Vorschau sein. Das System zeigt, welches Budget belastet und welcher Datensatz verändert wird, wenn die Transaktion fortgesetzt wird. Die berechtigte Person kann genau sehen, was sie freigeben will.

Sobald die Bestellung im ERP verbindlich angelegt und an den Lieferanten gesendet wird, hat die Aktion Folgen außerhalb des Systems. Dasselbe Modell kann in allen drei Stufen helfen. Es braucht nicht in jeder Stufe dieselbe Freiheit.

Das ist kein Argument dafür, jede Aktion hinter eine schwere Freigabekette zu stellen. Eine interne Notiz zu entwerfen ist nicht so riskant wie eine Erstattung auszuführen. Eine Kunden-E-Mail zu senden ist nicht dasselbe wie im Namen des Unternehmens einen offiziellen Antrag einzureichen. Mit wachsenden Folgen in der realen Welt sollte die Befugnis enger werden.

Autorisierung dort erzwingen, wo die Aktion stattfindet

Unternehmen brauchen nicht zwingend ein separates „KI-Autorisierungssystem“. Wenn die bestehende Anwendung bereits bestimmt, welche Kundendaten ein Nutzer sehen darf, wie hoch eine Erstattung sein darf oder aus welchem Budget er Ausgaben tätigen darf, können diese Kontrollen bestehen bleiben.

Entscheidend ist, dass die Kontrolle ausgeführt wird, wenn aus dem Vorschlag des Modells eine reale Transaktion wird. Die Anweisung „Führe nur autorisierte Aktionen aus“ in einen Prompt zu schreiben, ersetzt keine Durchsetzung.

Menschliche Freigabe funktioniert nur, wenn sie die Entscheidung verändern kann

Ein Freigabeknopf vor einer riskanten Transaktion kann beruhigend wirken. Er ist keine starke Kontrolle, wenn die prüfende Person nur die kurze Zusammenfassung des Modells sieht, Hunderte Anfragen rasch abarbeiten muss oder die Aktion gar nicht stoppen darf.

Im Erstattungsbeispiel sollte der Supportmitarbeiter zumindest Kunde, Bestellung, Betrag, Erstattungsgrund und die erfüllte Richtlinienbedingung sehen. Er sollte den Betrag ändern, die Transaktion ablehnen oder eskalieren können. Das muss geschehen, bevor sich das Geld bewegt, nicht danach.

Die Sicherheitsleitlinien von OpenAI für computernutzende Modelle empfehlen ähnlich, an dem Punkt um Bestätigung zu bitten, an dem eine folgenreiche Aktion klar wird. Wer ein grobes Ziel nennt, hat nicht zwangsläufig jeden später angetroffenen Empfänger, jede Datei oder Transaktion freigegeben.

Auch der Ansatz für minimale tragfähige Governance von MIT CISR unterscheidet: Vorab genehmigte Kategorien und delegierte Befugnisse für risikoarme Arbeit; tiefere Prüfung und fortlaufendes Monitoring für Arbeit mit hohem Risiko. Das Ziel ist nicht, jede Aktion an ein Gremium zu senden, sondern die Intensität der Aufsicht an die realen Folgen anzupassen.

Eine Freigabe für jede Aktion ist ebenfalls kein guter Standard. Beobachtbare Arbeiten mit geringen Auswirkungen können unter expliziten Regeln automatisch erfolgen. Wird menschliche Aufmerksamkeit über jeden kleinen Schritt verteilt, werden gerade die wichtigen Freigaben zu Routineklicks.

Dieselbe Anfrage darf die Aktion nicht zweimal erzeugen

Die Verbindung kann abbrechen, unmittelbar nachdem eine Erstattungsanfrage den Zahlungsdienstleister erreicht hat. Nimmt das Supportsystem dann an, der Versuch sei gescheitert, und sendet dieselbe Anfrage erneut, könnte der Kunde zwei Erstattungen erhalten.

KI hat dieses Problem nicht geschaffen. Zahlungs-, Bestell- und Reservierungssysteme kennen diese Unsicherheit seit Jahren. Die Antwort besteht nicht darin, dem Modell Sorgfalt zu befehlen. Das System sollte der Geschäftsabsicht eine Transaktionskennung geben, eine wiederholte Anfrage als dieselbe Operation erkennen und das Ergebnis gegen den Zahlungsdatensatz prüfen.

Der AWS-Leitfaden zu sicheren Wiederholungen mit idempotenten APIs empfiehlt, diese Absicht durch eine explizite Kennung weiterzutragen, damit ein Wiederholungsversuch kein zusätzliches Ergebnis erzeugt. Dass ein Modell die Erstattungsanfrage vorbereitet, ändert an dieser Transaktionsregel nichts.

Nicht jede Aktion lässt sich rückgängig machen. Falscher Zugriff kann widerrufen werden. Eine irrtümliche Reservierung lässt sich manchmal stornieren. Eine bereits an einen Kunden versandte E-Mail oder ein bereits eingereichter offizieller Antrag kann später korrigiert werden, aber nicht ungesendet gemacht werden. Wenn ein System behauptet, eine Aktion lasse sich zurückrollen, sollte klar sein, was tatsächlich rückgängig gemacht werden kann.

Ein erfolgreicher Werkzeugaufruf ist kein abgeschlossenes Ergebnis

Das Modell kann das richtige Werkzeug wählen, jedes Feld korrekt ausfüllen und eine Erfolgsmeldung erhalten. Das System sollte das Ergebnis dennoch an seiner maßgeblichen Quelle überprüfen.

Bei einer Erstattung kann dies die Transaktions-ID des Zahlungsdienstleisters und der aktuelle Bestelldatensatz sein. Bei einer E-Mail das Zustellprotokoll, bei Zugriffsrechten die im Identitätssystem verzeichnete Rolle und bei einer Bestellung ihr verbindlicher Status im ERP.

Im Artikel darüber, wann Unternehmens-KI RAG benötigt, trenne ich die Frage, woher verlässliche Informationen kommen sollen. Dasselbe Prinzip gilt für Aktionen: Prüfen Sie die Änderung dort, wo der maßgebliche Datensatz liegt, nicht in der Beschreibung des Systems über seine eigene Tätigkeit.

Die zentrale Frage lautet nicht, ob Sie dem Modell vertrauen. Sie lautet, wo das Modell eine Aktion vorschlagen darf, wo Unternehmensrichtlinien eingreifen müssen, wessen Befugnis die Transaktion ermöglicht und wo das Ergebnis überprüft wird.

Ein Modell kann viel Raum zum Schlussfolgern haben und zugleich nur enge transaktionale Befugnisse besitzen. Das ist kein Widerspruch. So kann ein System in einem Unternehmen zuverlässig handeln.

Der vorherige Artikel untersucht den Unterschied zwischen Arbeitsabläufen und Agenten, wenn ein System den nächsten Schritt wählen muss, statt nur eine Antwort zu erzeugen.

Die weiteren Entscheidungen zu Modellen, Informationen, Befugnis und Bewertung finden Sie im Leitfaden zum Entwurf eines KI-Systems für Ihr Unternehmen.