Warum die Freigabe eines KI-Tools noch keine Freigabe seiner Handlungen ist – und welche Entscheidungen Geschäftsführung, IT und Informationssicherheit treffen sollten.
Ein KI-Assistent fasst Kundenanfragen zusammen. Im nächsten Ausbauschritt legt er Tickets an, ändert Stammdaten oder verschickt Antworten. Die Oberfläche kann dabei nahezu gleich aussehen. Die Verantwortung verändert sich erheblich.
Solange ein System lediglich einen Text vorschlägt, steht zunächst die Qualität dieses Vorschlags im Mittelpunkt. Sobald es auf andere Systeme zugreift und dort handelt, kommen weitere Fragen hinzu: Welche Befugnisse wurden übertragen? Wer hat sie freigegeben? Wo endet der Auftrag? Und wer kann eingreifen, wenn etwas schiefläuft?
Für Geschäftsführung, IT-Leitung und CISO liegt hier eine konkrete Sicherheitsaufgabe: Die Freigabe eines Werkzeugs muss von der Freigabe seiner Handlungsmöglichkeiten getrennt werden.
Das Thema reicht über die Qualität des Modells hinaus
Das US-amerikanische NIST hat die Identität und Autorisierung von Software- und KI-Agenten 2026 ausdrücklich aufgegriffen. In seiner Veröffentlichung vom 5. Februar beschreibt das National Cybersecurity Center of Excellence ein Konzeptpapier zu diesem Themenfeld. Genannt werden unter anderem Identifizierung, Autorisierung, Auditierbarkeit und Schutz vor Prompt Injection.[1] Das ist eine fachliche Initiative, keine neue gesetzliche Pflicht für deutsche Unternehmen.
Eine passende Risikobeschreibung liefert OWASP mit „Excessive Agency“: Schädliche Handlungen können entstehen, wenn ein sprachmodellbasiertes System zu viele Funktionen, zu weitreichende Berechtigungen oder zu viel Autonomie erhält. Auslöser können manipulierte Eingaben sein, aber auch missverständliche Anweisungen oder fehlerhafte Modellausgaben.[2]
Daraus folgt eine wichtige Unterscheidung: Ein besseres Modell kann die Qualität seiner Entscheidungen verbessern. Es ersetzt nicht die Entscheidung des Unternehmens darüber, welche Handlungen überhaupt zulässig sind.
Ein freigegebenes Tool ist noch kein freigegebener Geschäftsprozess
Ein hypothetisches Beispiel: Ein Agent soll eingehende Serviceanfragen zusammenfassen und Antwortentwürfe vorbereiten. Dafür benötigt er Zugriff auf ausgewählte Nachrichten und passende Wissensbestände.
Kann dieselbe Anbindung auch Nachrichten versenden, Dokumente löschen oder Kundendaten verändern, besitzt das System mehr Handlungsmöglichkeiten, als der Auftrag erfordert. Eine Anweisung wie „Versende nichts ohne Rückfrage“ beschreibt zwar eine Grenze. Sie belegt noch nicht, dass diese Grenze bei der Ausführung durchgesetzt wird.
OWASP empfiehlt deshalb ausdrücklich, Berechtigungen in den nachgelagerten Systemen durchzusetzen, statt die Zulässigkeit einer Aktion allein vom Sprachmodell beurteilen zu lassen.[2]
Für die Governance bedeutet das: Die fachliche Aufgabenbeschreibung, die erteilten Zugriffsrechte und die erlaubte Autonomie müssen zusammenpassen. Ein Einkaufsvorgang für eine KI-Lizenz kann diese Abstimmung nicht ersetzen.
Vier Entscheidungen gehören vor den produktiven Einsatz
1. Auftrag und Verantwortung festlegen
Welcher Geschäftsprozess soll unterstützt werden? Was darf der Agent vorbereiten, was selbst ausführen und was ausdrücklich nicht?
Ein verantwortlicher Prozesseigner sollte den fachlichen Auftrag bestätigen. Die IT verantwortet die technische Umsetzung in ihrem Zuständigkeitsbereich; Informationssicherheit unterstützt die Risikobewertung und die Auswahl geeigneter Kontrollen. Für verbleibende Risiken braucht es eine entscheidungsbefugte Stelle.
„Der Fachbereich wollte das“ ist ebenso wenig eine ausreichende Verantwortungsregel wie „Die IT hat das Tool freigegeben“.
2. Zugriff und Autonomie getrennt begrenzen
Lesen, Entwürfe erzeugen, interne Datensätze ändern und nach außen kommunizieren sind unterschiedliche Befugnisse. Sie sollten nicht als ein einziges Berechtigungspaket behandelt werden.
Auch innerhalb einer freigegebenen Handlung ist der Umfang entscheidend: Für welche Datenbestände, Empfänger und Geschäftsvorgänge gilt die Erlaubnis? Welche Auswirkungen darf eine einzelne Aktion haben? Wann ist eine menschliche Entscheidung erforderlich?
Nicht jeder Arbeitsschritt braucht einen Bestätigungsdialog. Sinnvoll sind Kontrollen dort, wo die Folgen eines Fehlers wesentlich sind: etwa bei vertraulichen Daten, verbindlicher Außenkommunikation oder schwer rückgängig zu machenden Änderungen. Das entspricht OWASPs Empfehlung, menschliche Freigaben für Handlungen mit hohen Auswirkungen vorzusehen.[2]
3. Freigaben entscheidbar machen
Ein Freigabeknopf allein ist noch keine wirksame Kontrolle. Wer zustimmen soll, muss erkennen können, welche konkrete Handlung bevorsteht, welche Daten betroffen sind und welche Folgen zu erwarten sind.
Ein pauschales „Fortfahren?“ hilft wenig, wenn unklar bleibt, ob lediglich ein Entwurf gespeichert oder bereits eine Nachricht an einen Kunden versendet wird.
Ebenso wichtig ist die organisatorische Seite: Wer darf freigeben? Wer vertritt diese Person? Was geschieht bei ausbleibender Zustimmung? Eine zeitkritische Tätigkeit sollte nicht unbemerkt stehen bleiben, nur weil der einzige Freigabeberechtigte nicht erreichbar ist. Sie braucht einen definierten Eskalations- oder Ersatzprozess – keine stillschweigende Erweiterung der Agentenrechte.
4. Eingriff und Wiederanlauf vorbereiten
Ein Unternehmen sollte einen Agenten stoppen und seine Zugriffe entziehen können. Danach beginnt jedoch eine zweite Aufgabe: feststellen, welche Handlungen bereits ausgeführt wurden und wie der Geschäftsprozess weiterläuft.
Welche Änderungen lassen sich zurücknehmen? Welche Nachrichten wurden bereits versendet? Wer prüft betroffene Datensätze? Wie wird während einer Abschaltung gearbeitet?
Diese Fragen gehören zur Betriebsfähigkeit. Ein abgeschalteter Agent verhindert möglicherweise weitere Aktionen, stellt aber weder veränderte Daten noch einen unterbrochenen Prozess automatisch wieder her. Deshalb sollten Stilllegung, Ersatzverfahren und Wiederanlauf gemeinsam vorbereitet und erprobt werden.
Was als Nachweis wirklich weiterhilft
Für eine belastbare Freigabe würde ich nicht mit einer weiteren allgemeinen KI-Richtlinie beginnen, sondern mit einem konkreten Anwendungsfall und wenigen überprüfbaren Nachweisen:
- einem bestätigten Auftrag mit benanntem Prozesseigner;
- einer Übersicht der tatsächlich eingeräumten Zugriffe und Handlungsbefugnisse;
- klaren Freigabe- und Eskalationsregeln;
- einem Test, der auch unerlaubte Handlungen und den Entzug von Zugriffsrechten umfasst;
- einer nachvollziehbaren Aufzeichnung relevanter Aktionen sowie einem erprobten Ersatz- und Wiederanlaufverfahren.
Dabei sollten Protokolle nur die für Kontrolle und Aufklärung erforderlichen Informationen enthalten. Eine vollständige Sammlung sensibler Eingaben auf Vorrat ist kein Selbstzweck.
Diese Nachweise sind eine praktische Empfehlung, kein universeller Zertifizierungskatalog. Ihr Umfang muss zum konkreten Prozess, zur Datenkritikalität und zum möglichen Schaden passen. Ein rein lesender Rechercheassistent braucht andere Kontrollen als ein Agent, der Geschäftsdaten verändert oder extern kommuniziert.
Die entscheidende Managementfrage
KI-Agenten pauschal zu blockieren wäre ebenso wenig überzeugend wie ihre Handlungsmöglichkeiten allein nach dem technisch Machbaren zu erweitern. Der sinnvolle Weg ist ein abgegrenzter Auftrag mit angemessenen Befugnissen und überprüfbaren Kontrollen.
Für das Management lautet die entscheidende Frage deshalb nicht nur: „Welche KI setzen wir ein?“
Sondern: „Welche Handlungen erlauben wir ihr – und können wir diese Verantwortung im Betrieb tatsächlich wahrnehmen?“
Wer diese Frage beantwortet, verbindet KI-Nutzung mit Informationssicherheit, statt beides nebeneinander zu organisieren.
Quellen
[1] NIST/NCCoE: New Concept Paper on Identity and Authority of Software Agents, 5. Februar 2026. Die Quelle beschreibt ein Konzeptpapier und einen möglichen Projektansatz, keinen verbindlichen Unternehmensstandard. Abgerufen am 24. September 2026. https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents
[2] OWASP GenAI Security Project: LLM06:2025 – Excessive Agency. Risikobeschreibung und Empfehlungen insbesondere unter „Prevention and Mitigation Strategies“. Abgerufen am 24. September 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
Zum Autor
Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt ist, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.
Mehr zur Security-Governance-Beratung: https://www.a-r-c.me/security-governance.html