Erst Befugnis, dann Autonomie bei KI im Unternehmen

KI im Unternehmen wird nicht durch eine einzige Autonomieeinstellung sicher oder nützlich. Befugnis muss für jede Aktion einzeln verdient werden: beobachten, empfehlen, simulieren, nach Freigabe schreiben und schließlich innerhalb messbarer Grenzen selbstständig handeln. Mit dieser Stufung verbinden wir technische Fähigkeit und einen Betrieb mit klarer Ergebnisverantwortung.

Die falsche Frage über Agenten

Führungsteams werden oft gefragt, ob ein KI-Agent autonom sein soll. Diese Frage ist zu grob für eine Entscheidung. Ein Agent kann Bestände gefahrlos lesen und dennoch ungeeignet sein, einen Meldebestand zu verändern. Er kann eine Kundenantwort gut formulieren, ohne zum Versand befugt zu sein, oder bekannte Zahlungsfälle zuverlässig abgleichen und eine unbekannte Gebühr eskalieren.

Autonomie ist keine Eigenschaft eines Modells oder einer Anwendung. Sie ist eine Berechtigung für eine definierte Aktion unter definierten Bedingungen. Dasselbe System kann unterschiedliche Befugnisstufen für Datenabruf, Analyse, Kommunikation und Zustandsänderungen haben. Ein globaler Schalter blockiert entweder sinnvolle Automatisierung oder vergibt mehr Macht, als die Nachweise rechtfertigen.

Diese Unterscheidung wird wichtig, wenn Unternehmen von Pilotprojekten zu einer breiten Einführung übergehen. Der im Juni 2026 veröffentlichte Bericht von BCG und Consumer Goods Forum beschreibt eine wachsende Lücke zwischen Experimenten und Wertschöpfung im großen Maßstab. Governance und Änderungen am Betriebsmodell stehen dabei im Zentrum. Für uns ist das eine Umsetzungsfrage: Unternehmen brauchen einen wiederholbaren Weg, Modellleistung in begrenzte operative Befugnis zu übersetzen.

Fähigkeit, Berechtigung und Ergebnisverantwortung

Drei Ebenen werden häufig vermischt.

Fähigkeit fragt, ob das System ein akzeptables Ergebnis erzeugen kann: Kann es einen Ausnahmefall klassifizieren, die richtige Richtlinie finden, einen Vorschlag berechnen oder eine gültige API-Anfrage erstellen?

Berechtigung fragt, ob es die Aktion in diesem Kontext ausführen darf: Erlauben die Vorgaben zum Speicher- und Verarbeitungsort dieses Modell? Gehört das Konto zum zulässigen Umfang? Liegt der Wert unter einem Schwellenwert? Ist eine menschliche Freigabe erforderlich?

Ergebnisverantwortung fragt, wer das Ergebnis trägt und wie es sich rekonstruieren lässt: Welches Team akzeptiert das Risiko? Welche Nachweise werden protokolliert? Wer reagiert auf eine falsche Schreibaktion? Wie wird der Zugriff entzogen?

Ein hoher Benchmarkwert beantwortet nur einen Teil der Fähigkeitsfrage. Er vergibt keine Berechtigung und schafft keine Ergebnisverantwortung. Unser Ansatz für Agent Harness und Modellrouting beginnt deshalb mit Prüfungen von Datenschutz sowie Speicher- und Verarbeitungsort: Erst muss der zulässige Ausführungspfad feststehen, bevor Qualität, Latenz oder Kosten verglichen werden können.

Befugnisstufen für jede Aktion

Wir verwenden fünf Befugnisstufen. Da jede Aktion unabhängig bewertet wird, kann ein Workflow gleichzeitig mehrere Stufen belegen.

1. Nur lesend

Das System darf freigegebene Daten abrufen und Ereignisse beobachten, aber keine operative Entscheidung über einen produktiven Kanal vorschlagen. Hier werden Identität, Umfang, Protokollierung und Datenbehandlung geklärt. Teams erkennen dabei, dass Lesen nicht automatisch risikoarm ist: Kundendatensätze, Personaldaten, Preisvereinbarungen und Sicherheitsprotokolle brauchen weiterhin feldgenaue Kontrollen.

Erfolg bedeutet, dass das System nur auf die vorgesehenen Quellen zugreift, deren Herkunft zitiert oder dokumentiert, Mandantengrenzen und Aufbewahrungsregeln einhält und bei unklarer Identität oder unklarem Umfang den Zugriff verweigert.

2. Empfehlungen geben

Das System erstellt einen Aktionsvorschlag für eine autorisierte Person. Die Empfehlung muss genügend Kontext für eine Beurteilung enthalten: Eingaben, Richtliniengrundlage, Konfidenz oder Unsicherheit, wesentliche Alternativen und erwartete Wirkung. Eine bloße Empfehlung „freigeben“ oder „ablehnen“ verlagert Denkarbeit, ohne Verständnis zu schaffen.

Hier messen wir Empfehlungsqualität und Prüfverhalten. Die Annahmequote allein ist irreführend: Eine erschöpfte Person kann schlechte Vorschläge annehmen, eine sorgfältige Person ein nützliches System korrigieren. Unabhängige Stichprobenprüfungen und die Nachverfolgung der Ergebnisse sind wichtig.

3. Probelauf ohne Änderungen

Das System erstellt die exakt vorgeschlagene Schreibaktion und validiert sie, ohne den Zustand im Produktivsystem zu verändern. Bei einer API kann das ein Validierungsendpunkt sein, bei einer Datenpipeline eine Schattentabelle mit deterministischem Diff und bei Kundenkommunikation die Darstellung der endgültigen Nachricht mit aufgelösten Empfängern und deaktiviertem Versand.

Probeläufe decken Integrationsfehler auf, die eine Offline-Evaluation übersieht: ungültige Kennungen, veralteten Zustand, nicht passende Berechtigungen, Aufruflimits und unbeabsichtigte Folgeaktionen. Das validate_only-Muster in unserem Google-Ads-API-Betriebsleitfaden ist ein konkretes Beispiel. Eine Simulation ist nur nützlich, wenn sie dem tatsächlichen Schreibpfad nahe genug kommt, um dieselben Einschränkungen sichtbar zu machen.

4. Freigegebene Schreibaktion

Nach Freigabe durch eine ergebnisverantwortliche Person oder einen Richtliniendienst darf das System eine konkrete Änderung ausführen. Die Freigabe muss an die geprüften Nutzdaten gebunden sein, nicht nur an ein Gespräch. Ändern sich Preis, Empfänger, Menge oder zugrunde liegender Zustand nach der Prüfung, sollte sie verfallen.

Der Schreibpfad benötigt Idempotenz, Vorbedingungen, Zugangsdaten mit minimalen Berechtigungen, ein Audit-Protokoll und ein definiertes Wiederherstellungsverfahren. Menschliche Prüfung im Ablauf ist nur dann eine Kontrolle, wenn die Person die entscheidenden Felder sieht, Zeit und Kompetenz zur Beurteilung hat und die Ausführung stoppen kann.

5. Begrenzte Autonomie

Innerhalb ausdrücklich definierter Grenzen darf das System ohne Einzelfreigabe handeln. Diese Grenzen können Aktionstyp, Konten, Zeitfenster, Wert, Volumen, Konfidenz, Datenaktualität und Ausnahmeklasse umfassen. Alles außerhalb wird abgelehnt oder eskaliert.

Begrenzte Autonomie wird durch Nachweise aus dem Produktivbetrieb auf früheren Stufen verdient und ist nicht dauerhaft. Je nach gemessener Leistung und Veränderungen der Umgebung können Befugnisse erweitert, eingeschränkt oder auf reine Empfehlungen zurückgeführt werden.

Die Aktionsvereinbarung definieren

Vor der Evaluation schreiben wir eine Aktionsvereinbarung: eine kompakte Spezifikation, die fachlich Verantwortliche, Risikoverantwortliche und Entwickler gemeinsam nutzen.

Feld der Vereinbarung	Leitfrage
Zweck	Welches Geschäftsergebnis soll die Aktion fördern?
Ziel	Welches System, Objekt und welche Felder dürfen sich ändern?
Zulässigkeit	Welche Konten, Fälle und Datenklassen sind zulässig?
Voraussetzungen	Was muss zum Ausführungszeitpunkt wahr und aktuell sein?
Grenzen	Welche Grenzen für Wert, Volumen, Zeit und Konfidenz gelten?
Nachweise	Welche Eingaben, Regeln, Modelle und Freigaben werden gespeichert?
Wiederherstellung	Ist die Aktion reversibel, kompensierbar oder begrenzbar?
Verantwortliche Person	Wer trägt das Ergebnis und reagiert bei Fehlern?

Diese Vereinbarung verhindert einen häufigen Fehler: Eine breite Gesprächsaufgabe wird evaluiert, während ein technisch eng gefasster Zugang vergeben wird, der viel mehr erlaubt. Die Zugangsberechtigungen sollten die Vereinbarung abbilden. Ein Preisworkflow, der nur ein freigegebenes Feld ändern darf, sollte keinen allgemeinen Zugriff auf die Katalogverwaltung erhalten.

Aktionsvereinbarungen machen auch Portfolios vergleichbar: Die Unternehmensleitung erkennt, weshalb eine Aktion auf der Empfehlungsstufe bleibt und eine andere zur begrenzten Autonomie aufsteigt. Entwickler können Richtlinien in Zusicherungen, Schemas und Tests übersetzen.

Nachweise für die verdiente Befugnis

Aufgabenerfolg in der Offline-Evaluation ist notwendig, reicht aber nicht aus. Wir kombinieren vier Gruppen von Nachweisen:

Entscheidungsqualität: Genauigkeit bei geprüften Fällen, nach Schweregrad gewichtete Fehler, Kalibrierung, Richtlinientreue und Leistung in wichtigen Teilgruppen.

Ausführungsqualität: Quote gültiger Nutzdaten, Fehler bei Vorbedingungen, Duplikatvermeidung, Integrationslatenz und erfolgreiche Wiederherstellung.

Betriebsqualität: Eskalationsquote, Korrekturen durch Prüfende, Alter offener Ausnahmen, nachgelagerte Ergebnisse und Reaktion auf Vorfälle.

Kontrollqualität: Zugriffsverstöße, fehlende Datenherkunft, veraltete Eingaben, nicht freigegebene Umfangsänderungen und Vollständigkeit der Audit-Dokumentation.

Kennzahlen brauchen Bezugsgrößen und Kohorten. Zehn Fehler sind ohne Aktionsvolumen und Schweregrad nicht interpretierbar; gute Gesamtgenauigkeit kann eine gefährliche Minderheitsklasse verdecken. Ein Workflow kann bei normalen Fällen korrekt sein und jedes Mal scheitern, wenn Daten verspätet eintreffen.

Bei vertraulichen internen Größenordnungen berichten wir normalisierte Indizes. Ist das nach Schweregrad gewichtete Interventionsvolumen zu Beginn eines kontrollierten Versuchs Baseline = 100, lassen sich Folgeperioden damit vergleichen. Die Veränderung ist ein Anlass zur Prüfung, kein automatischer Beweis für eine Modellwirkung. Prozessänderungen, Fallzusammensetzung und Lerneffekte der Prüfenden können ebenfalls beitragen.

Auf- und Rückstufung müssen symmetrisch sein

Teams definieren häufig, wie Automatisierung mehr Befugnis erhält, aber nicht, wie sie diese verliert. Das schafft ein einseitig wachsendes Risiko. Für jede Stufe müssen vor dem Start Kriterien für Auf- und Rückstufung vereinbart werden.

Eine Aufstufung kann eine Mindeststichprobe über repräsentative Kohorten, keine ungelösten kritischen Fehler, eine akzeptable nach Schweregrad gewichtete Fehlerrate, ein getestetes Rücksetzverfahren und die Freigabe durch die aktionsverantwortliche Person verlangen. Zeit allein ist kein Nachweis; eine hohe Annahmequote ohne Ergebnisprüfung ebenso wenig.

Eine Rückstufung sollte bei klaren Kontrollfehlern automatisch greifen: fehlenden oder veralteten Quelldaten, nicht passender Richtlinienversion, ungewöhnlichem Aktionsvolumen, gescheitertem Datenabgleich, nicht verfügbarem Rücksetzverfahren, einer wesentlichen Verschiebung der Datenverteilung oder abgelaufenen Zugangsdaten. Die sichere Reaktion kann von autonomen Schreibaktionen auf freigegebene Schreibaktionen, reine Empfehlungen oder nur lesenden Zugriff zurückführen, statt das gesamte System abzuschalten.

Dieser geordnete Abbau von Funktionen ist leichter, wenn die Stufen von Anfang an vorgesehen sind. Ein Workflow, der nur vollständig an oder aus sein kann, hat keine betrieblich nützliche Ausweichlösung.

Modelle von deterministischen Kontrollen trennen

Befugnis gehört an die Schnittstelle zur Aktionsausführung, nicht an das Modell. Modelle können unstrukturierte Eingaben interpretieren, mögliche Nachweise abrufen, Fälle klassifizieren und Vorschläge formulieren. Deterministische Dienste sollten Identitäten, Schemas, Schwellenwerte, erlaubte Felder, Zustandsvorbedingungen und Idempotenz durchsetzen.

Diese Trennung begrenzt die Auswirkungen von Fehlern und erleichtert den Modellwechsel. Ein stärkeres Modell umgeht die Aktionsvereinbarung nicht. Ein günstigeres oder lokales Modell kann für eine zulässige Aufgabe eingesetzt werden, ohne Berechtigungen neu zu entwerfen. Unser Leitfaden zu domänenspezifischen Agent Skills beschreibt den Nutzen gebündelter Anweisungen und Werkzeuge für begrenzte Workflows; die Befugnisschicht ergänzt die Kontrollen für den Produktivbetrieb.

Entwickler sollten Modellausgaben als nicht vertrauenswürdige Eingaben behandeln: in typisierte Vorschläge parsen, Referenzen gegen aktuelle Systeme auflösen, wesentliche Werte nach Möglichkeit nachrechnen, unbekannte Felder ablehnen und Richtlinien zum Ausführungszeitpunkt erneut prüfen. Vorschlag und endgültige Aktion werden beide gespeichert, damit die Umwandlung sichtbar bleibt.

Die menschliche Rolle verändert sich

Auf der Empfehlungsstufe beurteilt der Mensch einzelne Entscheidungen. Bei freigegebenen Schreibaktionen prüft er zusätzlich die genaue Folge und autorisiert die Ausführung. Bei begrenzter Autonomie verlagert sich seine Aufmerksamkeit auf die Gestaltung der Grenzen, Stichprobenprüfungen, Ausnahmen und den Systemzustand.

Die Ergebnisverantwortung entfällt nicht; sie verschiebt sich von wiederholter Fallbearbeitung zur Verantwortung für die Kontrollen. Prüfende brauchen Schulung, Arbeitslastgrenzen und einen klaren Eskalationsweg. Verantwortliche benötigen Dashboards mit Kohorten und Schweregraden statt eines beruhigenden Durchschnitts. Risiko- und Compliance-Teams brauchen prüfbare Nachweise, ohne dafür ein Agentengespräch rekonstruieren zu müssen.

Das Unternehmen sollte auch abweichende Einschätzungen schützen. Wenn Bediener Empfehlungen wiederholt übersteuern, sollte das eine Untersuchung auslösen statt Druck, die Annahmequote zu erhöhen. Korrekturen aus der Praxis zeigen fehlenden Kontext oft früher als Gesamtkennzahlen.

Ein praktischer Rollout

Für eine neue Aktion verwenden wir die folgende Einführungsreihenfolge:

Aktionsvereinbarung und ergebnisverantwortliche Person definieren.
Datenschutz, Speicher- und Verarbeitungsort, Identität und Dateneignung prüfen.
Geprüftes Evaluationsset mit seltenen und ungünstigen Fällen aufbauen.
Nur lesenden Zugriff und Empfehlungen mit vollständiger Datenherkunft betreiben.
Reale Integration durch Probeläufe ohne Änderungen und deterministische Diffs testen.
An Nutzdaten gebundene Freigaben mit Rücksetzverfahren und Abläufen für Vorfälle aktivieren.
Einer repräsentativen Kohorte einen engen autonomen Korridor geben.
Ergebnisse, Ausnahmen und Funktionsfähigkeit der Kontrollen prüfen und regelbasiert auf- oder rückstufen.

Nicht jede Aktion muss autonom werden. Manche Schreibaktionen sind selten, irreversibel oder so kontextabhängig, dass auf Einzelfreigaben dauerhaft nicht verzichtet werden kann. Die Stufen schaffen trotzdem Nutzen: Sie verbessern Empfehlungen und machen freigegebene Ausführungen schneller und zuverlässiger.

Die Entscheidung der Unternehmensleitung

Die Governance von KI im Unternehmen wird konkret, wenn Führungskräfte Aktionsvereinbarungen statt „Agenten“ freigeben. Budgets können dann messbaren betrieblichen Ergebnissen folgen. Risikodiskussionen konzentrieren sich auf Umfang, Reversibilität und Nachweise. Technologieteams können Modelle innerhalb eines zulässigen Pools vergleichen und zugleich die Befugnisse stabil halten.

Das zentrale Prinzip ist klar: Fähigkeit rechtfertigt eine Prüfung, Nachweise rechtfertigen Berechtigungen, und klare Zuständigkeit erhält die Befugnis. Unternehmen, die diese Reihenfolge wahren, können sinnvolle Automatisierung ausbauen, ohne Geschwindigkeit mit Kontrolle zu verwechseln.