Warum Agent Governance zählt

Der Unterschied lässt sich in einem Satz fassen: Ein Assistent entwirft eine E-Mail, ein Agent versendet sie. Der erste erzeugt einen Vorschlag, den ein Mensch prüft. Der zweite handelt — im Namen der Organisation, mit ihren Berechtigungen, in ihren Systemen. Wer für beide dieselben Regeln anwendet, übersieht die wichtigste Verschiebung, die Enterprise AI seit ihrer Einführung durchgemacht hat.

Ich formuliere es bewusst zugespitzt: Die meisten Organisationen haben in den letzten Jahren gelernt, generative AI zu governen — also die Qualität und Zulässigkeit von Inhalten zu beurteilen. Agents stellen eine andere Frage. Nicht mehr „Ist der Output gut?", sondern „War diese Handlung autorisiert, angemessen und umkehrbar?" Das ist keine Variante desselben Problems. Es ist ein neues.

Digitale Mitarbeiter, die niemand eingestellt hat

Es hilft, Agents nicht als Software zu denken, sondern als etwas, das der Organisation viel vertrauter ist: als Mitarbeiter. Ein Agent bekommt Aufgaben, Zugriffe und Handlungsspielraum. Er bearbeitet Vorgänge, löst Prozesse aus, bewegt Daten, trifft im Kleinen laufend Entscheidungen. Er betreibt — nüchtern betrachtet — ein kleines Stück des Geschäfts.

Nur: Für Mitarbeiter hat jede Organisation ein über Jahrzehnte gereiftes Regelwerk. Es gibt eine Einstellung mit Prüfung, eine Führungskraft, eine Rollenbeschreibung, Berechtigungen nach Funktion, Beurteilungen, und irgendwann ein geordnetes Ausscheiden. Niemand käme auf die Idee, jemanden unbefristet und unbeaufsichtigt arbeiten zu lassen, nur weil das Bewerbungsgespräch gut lief.

Für Agents existiert dieses Regelwerk in den meisten Organisationen nicht. Sie werden erstellt — zunehmend von Fachbereichen selbst, in Minuten statt in Monaten — und laufen dann. Kein definierter Owner, keine explizite Grenze, kein Prüfrhythmus, kein Ende. Jeder einzelne davon mag harmlos sein. In Summe entsteht etwas, das ich stilles Risiko nenne: eine wachsende Belegschaft digitaler Mitarbeiter, von der niemand eine Personalliste hat.

Warum die bestehende IT-Governance das nicht auffängt

Der naheliegende Einwand: Dafür gibt es doch IT-Governance, Berechtigungskonzepte, Change-Prozesse. Der Einwand unterschätzt zwei Dinge.

Erstens die Menge und Geschwindigkeit. Klassische Governance-Prozesse sind für eine überschaubare Zahl von Systemen gebaut, die von Profis in geordneten Zyklen verändert werden. Agents entstehen dezentral, in hoher Zahl, von Menschen ohne IT-Hintergrund. Ein Freigabeprozess, der pro Fall Wochen braucht, wird bei dieser Taktung nicht etwa durchlaufen — er wird umgangen.

Zweitens die Natur des Risikos. Berechtigungskonzepte regeln, worauf jemand zugreifen darf. Sie regeln nicht, was eine autonom handelnde Instanz mit legitimen Zugriffen in unvorhergesehenen Situationen tut. Ein Agent, der formal alles darf, was er tut, kann trotzdem etwas tun, das niemand gewollt hat. Dieses Risiko steht in keinem Berechtigungskonzept — es steht in der Frage, wer den Agent verantwortet und wie er geführt wird.

Die sechs Fragen, die jeder Agent beantworten muss

In der Praxis lässt sich Agent Governance auf einen erstaunlich kompakten Kern reduzieren. Bevor ein Agent produktiv arbeitet, muss jemand sechs Fragen beantworten können:

• Wem gehört er? Eine verantwortliche Person — nicht ein Team, das sich auflöst, nicht ein Funktionspostfach.
• Was darf er tun? Explizite Grenzen bei Werkzeugen, Daten und Handlungen.
• Was darf er ausdrücklich nicht? Die Verbote sind so wichtig wie die Erlaubnisse, weil sie die Fälle regeln, an die beim Bau niemand dachte.
• Wie wird er geprüft? Ein Rhythmus und ein Auslöser für die Neubewertung — denn ein Agent, der heute angemessen ist, muss es nächstes Quartal nicht sein.
• Wie wird er beobachtet? Sichtbarkeit darüber, was er tatsächlich getan hat, nicht nur darüber, was er tun sollte.
• Wann endet er? Jeder Agent braucht ein definiertes Ende oder einen Anlass für die Außerbetriebnahme. Was kein Ende hat, wird zu Altlast.

Bleibt eine dieser Fragen offen, ist der Agent nicht governt. Er läuft bloß.

Die Führungsperspektive: das Ja skalierbar machen

Man kann diese sechs Fragen als Kontrollinstrument lesen. Interessanter ist die umgekehrte Lesart: Sie sind das, was es einer Organisation erlaubt, zu vielen Agents Ja zu sagen.

Denn die Alternative ist nicht „weniger Regeln, mehr Geschwindigkeit". Die Alternative ist, dass jeder einzelne Agent zur maßgeschneiderten Einzelfallentscheidung wird — mit allen Folgen, die ich im Beitrag über das AI Operating Model beschrieben habe: Entscheidungen, die niemand zu treffen wagt, Vorhaben, die im Ungefähren versanden, und Risiken, die dort wachsen, wo der offizielle Weg zu mühsam ist. Wenn dagegen Ownership, Grenzen und Prüfung Standard sind, wird aus der Einzelfallprüfung ein Pfad. Die zwanzigste Freigabe kostet dann so wenig wie die zweite — und genau das ist die Bedingung, unter der aus fünf Agents fünfzig werden können, ohne dass das Risiko mitwächst.

Deshalb gehört Agent Governance nicht in die Kategorie „technische Detailfrage, klärt die IT". Sie ist die Personalpolitik für eine neue Art von Belegschaft, und sie verdient dieselbe Führungsaufmerksamkeit. Organisationen, die das früh verstehen, verschaffen sich einen unspektakulären, aber nachhaltigen Vorteil: Sie können Handlungsfähigkeit delegieren, ohne Verantwortung zu verlieren.

Agents sind die bislang folgenreichste Form von Enterprise AI — gerade weil sie nicht nur antworten, sondern handeln. Ihre Governance als eigenständige Disziplin zu behandeln macht ihr Wachstum zu einer Entscheidung, die man treffen, begründen und verteidigen kann. Die Alternative ist, dass dieses Wachstum einfach passiert. Es ist dieselbe Wahl wie beim Operating Model insgesamt: Steuerung ist nicht das Gegenteil von Geschwindigkeit. Sie ist der Grund, warum man sich Geschwindigkeit leisten kann.