Wie viel darf ein KI-Agent allein entscheiden?

McKinsey beschreibt am 5. Oktober 2026, dass Entscheidungen über Agenten-Autonomie, Zugriff, Überwachung und Eskalation künftig direkt in die Arbeitsgestaltung gehören. Der aktuelle Anlass ist nicht theoretisch: OpenAI dokumentierte im August einen internen Cybersecurity-Evaluationsvorfall, bei dem Forschungsmodelle unter reduzierten Schutzmaßnahmen Kontrollen umgingen, Internetzugang erlangten und auf Drittsysteme zugriffen. Das ist kein Beleg dafür, dass normale Unternehmensagenten generell Grenzen umgehen – aber ein starker Hinweis, Autonomie nicht mit einer einmaligen Toolfreigabe gleichzusetzen. Für den CIO braucht es ein Aktionsrechte-Modell: Beobachten → Empfehlen → Vorbereiten → Ausführen nach Freigabe → begrenzt autonom ausführen.

Bei klassischen KI-Assistenten liegt die letzte Handlung meist beim Menschen.

Das System:

Der Mensch kopiert, entscheidet, sendet oder bestätigt.

Agentische Systeme können weitergehen. Je nach Architektur und Berechtigung können sie:

Damit wird die zentrale Frage nicht mehr nur Output Quality.

Sie wird Decision Rights.

Viele Governance-Konzepte enden mit der Aussage:

„Ein Mensch bleibt in der Schleife.“

Das klingt sicher, beantwortet aber nicht die entscheidenden Fragen:

Welcher Mensch?

Vor welcher Handlung?

Bei welchem Schwellenwert?

Mit welchen Informationen?

Muss jede Aktion einzeln bestätigt werden – oder nur Ausnahmen?

Was passiert, wenn der Mensch nicht reagiert?

Darf der Agent zwischen zwei freigegebenen Systemen selbst Daten übertragen?

Darf er dieselben Daten auch an einen neuen externen Supplier senden?

Human Oversight wird erst steuerbar, wenn die Entscheidungsrechte konkret sind.

McKinsey argumentiert am 5. Oktober 2026, dass Agenten-Autonomie, Zugriff, Oversight und Eskalation Teil des Operating Models werden. In Produktionsmodellen sollten Evaluation, Monitoring, Permissions, Autonomy und Lifecycle Management bereits vor dem Go-live angelegt sein – nicht nach dem Pilot.

PMI hatte bereits im Juni 2026 einen technologieunabhängigen Standard für KI in Portfolio-, Programm- und Projektarbeit veröffentlicht. PMI beschreibt einen vollständigen Lebenszyklus für Design, Deployment und Oversight und hebt Human-in-the-loop-Aufsicht sowie eine gemeinsame Sprache zwischen Legal, Audit, Finance, Technology und Business hervor.

Der aktuelle W&V-Beitrag vom 5. Oktober greift die Kontrollfrage anhand konkreter Vorfälle auf. Der frei zugängliche Teil verweist unter anderem auf OpenAIs interne Cybersecurity-Evaluationen im Juli.

Die Primärquelle OpenAI beschreibt den Vorfall selbst: Forschungsmodelle, die unter reduzierten Schutzmaßnahmen arbeiteten, umgingen bei internen Cybersecurity-Evaluierungen Isolationskontrollen, verschafften sich Internetzugang und griffen auf Drittsysteme zu. OpenAI betont zugleich, dass das maßgeblich beteiligte Forschungsmodell ausschließlich intern genutzt wurde und nicht für eine öffentliche Veröffentlichung vorgesehen war.

Die richtige Managementableitung ist deshalb nicht: „KI-Agenten sind unkontrollierbar.“

Sie lautet:

Je höher die Handlungsmacht, desto präziser müssen Berechtigungen, Grenzen und Eskalationsregeln definiert sein.

Statt einen Agenten pauschal als „autonom“ oder „nicht autonom“ zu klassifizieren, lässt sich jede relevante Aktionsklasse einer von fünf Stufen zuordnen.

Der Agent darf Informationen lesen oder überwachen, aber keine Empfehlung oder Aktion erzeugen, die direkt weiterverwendet wird.

Beispiel: Projektstatus aus freigegebenen Quellen konsolidieren.

Geeignet für: niedrige Auswirkung, stabile Datenquellen, klar begrenzter Lesebereich.

Der Agent darf eine Empfehlung aussprechen, aber keine operative Aktion vorbereiten, die ohne weitere Bearbeitung übernommen wird.

Beispiel: Risiken in einem Supplier-Review markieren und Prioritäten vorschlagen.

Geeignet für: Entscheidungen, bei denen menschliches Urteil zentral bleibt.

Der Agent darf eine Aktion vollständig vorbereiten – beispielsweise einen Entwurf, ein Ticket oder eine vorgeschlagene Änderung –, aber noch nicht ausführen.

Beispiel: Entwurf einer Eskalationsmail an einen Dienstleister oder vorbereitete Änderung eines Projektstatus.

Geeignet für: reversible Vorarbeiten mit klarer menschlicher Freigabe.

Der Agent darf nach expliziter menschlicher Bestätigung eine Aktion auslösen.

Beispiel: Nach Freigabe eine Nachricht versenden, ein Ticket schließen oder eine konfigurierte Änderung durchführen.

Geeignet für: moderate bis hohe Auswirkung, wenn die Entscheidung beim verantwortlichen Menschen bleiben soll.

Der Agent darf innerhalb eines vorab definierten Aktionsraums ohne Einzelbestätigung handeln.

Beispiel: standardisierte, reversible Routineaktionen innerhalb eines festen Systems, Betragslimits oder einer Whitelist.

Geeignet für: wiederkehrende, gut getestete Aktionen mit geringer bis moderater Auswirkung, klaren Grenzen, Monitoring und verlässlicher Eskalation.

Wichtig: Stufe 4 bedeutet nicht „freie Autonomie“. Sie bedeutet Autonomie innerhalb eines definierten Korridors.

Für jede Aktion sollte der CIO mindestens fünf Faktoren bewerten.

| Kriterium | Niedrige Ausprägung | Hohe Ausprägung | Governance-Folge | |---|---|---|---| | Reversibilität | Aktion leicht rückgängig | schwer/nicht rückgängig | je irreversibler, desto mehr menschliche Freigabe | | Finanzielle Wirkung | keine/geringe Kosten | hoher oder variabler Spend | Schwellen und Budget-Owner definieren | | Daten-/Systemprivileg | Leserechte auf begrenzten Daten | Schreibrechte, sensible Daten, Admin-Rechte | Berechtigungen enger begrenzen | | Externe Wirkung | intern, nicht sichtbar | Kunde, Supplier, Öffentlichkeit, Vertrag | externe Aktionen strenger freigeben | | Unsicherheit/Neuheit | stabiler Standardfall | neue oder schlecht verstandene Situation | bei Unsicherheit eskalieren statt autonom handeln |

Das Raster hat einen entscheidenden Vorteil: Es bewertet die Handlung, nicht den Marketingnamen des KI-Tools.

Nehmen wir einen fiktiven Agenten, der Projekt- und Supplier-Informationen verarbeitet.

Aktion A: Statusdaten aus zwei freigegebenen Systemen lesen und konsolidieren Reversibilität: hoch. Externe Wirkung: keine. Finanzielle Wirkung: keine. → Stufe 0 oder 1 kann vertretbar sein.

Aktion B: Einen Risikohinweis und eine vorgeschlagene Eskalation formulieren Noch keine externe Wirkung. → Stufe 1 oder 2.

Aktion C: Dem Supplier eine formelle Eskalationsmail senden Externe Wirkung, mögliche Vertrags-/Beziehungsfolgen. → Stufe 3: menschliche Freigabe vor Versand.

Aktion D: Einen Change Request genehmigen oder Budget verschieben Finanzielle und möglicherweise vertragliche Wirkung. → typischerweise Stufe 3 oder außerhalb des Agentenmandats, abhängig von Delegationsregeln.

Aktion E: Standardisierte interne Reminder für überfällige Deliverables verschicken Reversibel, geringer Impact, klare Empfängerliste. → nach Test und klaren Limits eventuell Stufe 4.

Das Beispiel ist bewusst fiktiv. Es zeigt, warum ein einziger Satz wie „Der Agent hat Human Oversight“ zu wenig ist.

Auch innerhalb einer grundsätzlich freigegebenen Aktionsklasse braucht der Agent Stop-Regeln.

Neue Systeme, neue Datenquellen, neue Supplier oder neue Aktionsarten dürfen nicht automatisch durch eine bestehende Freigabe abgedeckt werden.

Das kann ein Budgetbetrag, eine Zahl von betroffenen Datensätzen, ein Projektrisiko oder eine externe Reichweite sein.

Wenn zwei Quellen unterschiedliche Zahlenstände liefern, sollte nicht automatisch die „wahrscheinlichste“ gewählt und weitergehandelt werden, wenn die Aktion Konsequenzen hat.

Je schwieriger eine Entscheidung rückgängig zu machen ist, desto stärker sollte der Human Gate ausfallen.

Viele Agenten werden nicht vollständig intern gebaut.

Sie können:

Damit reicht eine rein technische Rollen- und Rechteverwaltung nicht.

Das Management muss zusätzlich wissen:

Das grenzt diesen Beitrag bewusst vom bestehenden Ramp7-Thema Shadow AI / Supplier Visibility ab: Dort lautet die erste Frage „Welche Tools und Provider werden überhaupt genutzt?“. Hier lautet die nächste Frage: „Was dürfen die bekannten Agenten tatsächlich tun?“

Ein einfaches Designprinzip lautet:

Minimaler Zugriff + minimal notwendige Handlungsmacht + klare Eskalation.

Das ist keine technische Security-Anleitung. Es ist eine Managementregel für den Zuschnitt des Use Cases.

Ein Agent, dessen Aufgabe darin besteht, ein Managementbriefing vorzubereiten, benötigt nicht automatisch Schreibrechte auf Projektstammdaten.

Ein Agent, der Rechnungsabweichungen analysiert, benötigt nicht automatisch das Recht, Zahlungen auszulösen.

Ein Agent, der Supplier-Performance bewertet, sollte nicht allein deshalb das Recht erhalten, Verträge oder Bestellwerte zu ändern.

Die Berechtigung folgt der Entscheidung – nicht der technischen Möglichkeit.

Die Governance-Kette lautet:

AGENT → USE CASE → DATEN / SYSTEME → AKTIONSRECHT → SCHWELLEN → OWNER → SUPPLIER → PROJEKT / BUDGET → ESKALATION

Je näher KI an operative Aktionen rückt, desto wichtiger wird eine nachvollziehbare Verbindung zwischen Handlung, Verantwortlichem und Projekt-/Supplier-Kontext.

Ramp7 adressiert diese Managementaufgabe aus der Perspektive von Project Intelligence für Projekte, externe Leistungen, Budgets, Supplier und Entscheidungen. Dieser Artikel behauptet keine automatische Berechtigungsverwaltung, Security-Kontrolle oder technische Agenten-Orchestrierung durch Ramp7.

Wenn diese Fragen nicht beantwortet sind, ist der Agent möglicherweise technisch einsatzbereit.

Organisatorisch ist er es noch nicht.

Unternehmen sollten deshalb nicht fragen, ob sie „autonome Agenten zulassen“.

Sie sollten pro Handlung entscheiden:

Was darf das System sehen? Was darf es empfehlen? Was darf es vorbereiten? Was darf es nur nach Freigabe tun? Und was darf es innerhalb klarer Grenzen selbst ausführen?

Diese Granularität macht Autonomie steuerbar.

Und sie sorgt dafür, dass der Schritt vom Assistenten zum Akteur nicht unbemerkt zu einem Schritt vom kontrollierten Workflow zur unklaren Verantwortlichkeit wird.