Das Governance-Objekt, das Ihnen fehlt
Jedes mittelständische Unternehmen im DACH-Raum, das eine KI-Agenten-Fähigkeit aufbaut, stößt früher oder später auf dieselbe Mauer: nicht technisches Versagen, nicht Datenqualität, sondern einen Moment, in dem ein Agent etwas Folgenreiches tut und niemand sicher ist, wer es hätte stoppen, prüfen oder die Rückfallebene besitzen sollen. Der Agent hat eine Rückerstattung versendet. Er hat eine Gruppenmitgliedschaft geändert. Er hat eine Antwort an eine Aufsichtsbehörde entworfen, auf die jemand im Vertrieb „Senden" geklickt hat, ohne sie zu lesen. Die technischen Leitplanken haben funktioniert – der Agent ist innerhalb seiner Handlungsschwelle geblieben –, aber die organisatorischen Leitplanken existierten nicht.
Das Problem ist nicht, dass Ihnen eine KI-Richtlinie fehlt. Das Problem ist, dass die Richtlinie keine Entscheidungsrechte spezifiziert. Wer genehmigt den Use Case? Wer kann das Deployment blockieren? Wer besitzt das Monitoring nach dem Launch? Wer kann ein Rollback auslösen? Wer überstimmt den Agenten, wenn ein Kunde eskaliert? Das sind keine Fragen, die ein Lenkungsausschuss grundsätzlich klären sollte; das sind Fragen, die Antworten brauchen, die an Namen, Rollen und Systeme gebunden sind, bevor der Agent live geht. KI-Governance-Literatur diskutiert Verantwortlichkeit über Ebenen hinweg – von Team- über Organisations- bis hin zu externer Governance – und verstärkt die Notwendigkeit expliziter Entscheidungsrechte, nicht Annahmen. Das fehlende Governance-Objekt ist nicht das Policy-Dokument; es ist die Entscheidungsrechte-Matrix.
Warum Agenten traditionelle Genehmigungsabläufe brechen
Traditionelle IT-Genehmigungsabläufe setzen voraus, dass ein Mensch die Handlung initiiert und ein anderer Mensch sie prüft. Agenten kehren diese Reihenfolge um. Der Agent initiiert. Der Mensch, wenn er überhaupt in der Schleife ist, prüft nachträglich – oder nur, wenn der Agent eskaliert. Das funktioniert, wenn der Agent Empfehlungen mit geringem Risiko macht: Informationen zusammenfassen, eine Antwort entwerfen, Dokumente organisieren. Es bricht, wenn der Agent operative Entscheidungen trifft: Rückerstattungen verarbeiten, Vereinbarungen eingehen, Genehmigungen erteilen, Mitarbeiterdaten ändern oder Handlungen auslösen, die Kunden oder Aufsichtsbehörden betreffen.
Action Thresholds definieren eine klare Grenze für das, was ein Agent ohne menschliche Genehmigung tun kann. Ein Agent darf vielleicht Rückerstattungen unterhalb eines bestimmten Werts verarbeiten, aber alles darüber hinaus erfordert die Freigabe eines Managers. Die Schwelle ist eine technische Kontrolle, aber sie beantwortet nicht die Governance-Frage: Wer hat diese Schwelle gesetzt, wer kann sie ändern und wer prüft, ob die Schwelle drei Monate nach dem Deployment noch angemessen ist? Der Agent führt innerhalb seiner erlaubten Grenze aus, aber die Grenze selbst ist eine Entscheidung, die jemand besitzen muss.
Hier entdecken die meisten mittelständischen DACH-Unternehmen, dass ihre bestehenden RACI-Matrizen – Responsible, Accountable, Consulted, Informed – nicht sauber auf KI-Agenten abbilden. Der Agent ist keine Person. Er sitzt nicht in einer Abteilung. Er hat keinen Manager. Er hat einen technischen Owner (normalerweise IT oder Data), einen Business Owner (die Funktion, die von der Automatisierung profitiert), einen Risk Owner (Compliance oder Legal) und eine Reihe menschlicher Prüfer, die je nach Action Threshold im Workflow sein können oder nicht. Die traditionelle RACI-Matrix geht von einer einzigen Accountable-Partei aus. KI-Agenten erfordern oft eine Aufteilung: eine Partei verantwortlich für das technische Verhalten des Agenten, eine andere verantwortlich für das Geschäftsergebnis und eine dritte verantwortlich für die Risikohaltung. Wenn sich diese drei Parteien nicht vor dem Deployment auf Entscheidungsrechte einigen, werden sie nach dem ersten Vorfall lautstark nicht einig sein.
Die Entscheidungsrechte-Matrix: fünf Befugnisebenen
Eine funktionsfähige Entscheidungsrechte-Matrix für KI-Agenten weist Befugnisse über fünf Ebenen zu: Use-Case-Genehmigung, Deployment-Kontrolle, Handlungsgenehmigung, Monitoring und Eskalation sowie Rollback oder Override. Jede Ebene beantwortet eine andere Frage, und jede erfordert eine benannte Rolle – nicht ein Komitee, nicht ein Prinzip, sondern eine Person oder ein System mit der Befugnis zu handeln.
Use-Case-Genehmigung beantwortet: Wer entscheidet, dass dieser Agent existieren soll? In den meisten mittelständischen DACH-Unternehmen ist dies eine gemeinsame Befugnis. Der Business Owner schlägt den Use Case vor und besitzt den ROI-Case. IT oder Data bewertet technische Machbarkeit und Integrationsrisiko. Legal oder Compliance bewertet regulatorisches Risiko und Haftungsrisiko. Die Entscheidung fortzufahren erfordert die Freigabe von allen dreien, aber eine Partei – normalerweise der Business Owner – ist accountable für die endgültige Entscheidung. Der Fehler ist, dies als einmaliges Gate zu behandeln. Die Use-Case-Genehmigung sollte einen Review-Trigger enthalten: Wenn sich der Scope des Agenten ändert, wenn sich die Datenquellen ändern, wenn sich das regulatorische Umfeld ändert, muss die Genehmigung erneut geprüft werden. Das Entscheidungsrecht umfasst die Befugnis, die Genehmigung wieder zu öffnen, nicht nur sie einmal zu erteilen.
Deployment-Kontrolle beantwortet: Wer kann diesen Agenten in die Produktion bringen und wer kann es blockieren? Dies ist typischerweise IT oder Platform Engineering, aber die Blockierbefugnis liegt oft bei Risk oder Compliance. Ein gängiges Muster in mittelständischen DACH-Unternehmen ist, dass IT die Deployment-Pipeline besitzt, aber Compliance ein Vetorecht bis zum Moment des Deployments hält. Das Veto ist keine Prüfung; es ist ein binärer Block. Wenn Compliance beim finalen Pre-Production-Testing etwas sieht, das während der Use-Case-Genehmigung nicht aufgetaucht ist – eine unerwartete Datenquelle, eine Änderung im Handlungsscope des Agenten –, können sie das Deployment stoppen, ohne ein Meeting einberufen zu müssen. Das Entscheidungsrecht ist die Befugnis, Nein zu sagen, auch wenn alle anderen Ja gesagt haben.
Handlungsgenehmigung beantwortet: Welche Handlungen kann der Agent autonom ausführen und welche erfordern menschliche Freigabe? Hier werden Action Thresholds zu Governance, nicht nur zu Konfiguration. Der Business Owner setzt typischerweise die Schwelle, aber IT implementiert sie als technische Kontrolle, und Compliance prüft sie als Risikokontrolle. Das Entscheidungsrecht hier ist nicht nur das Setzen der Schwelle; es ist sie zu ändern. Wenn der Business Owner die Rückerstattungsschwelle von fünfhundert auf zweitausend Euro erhöhen möchte, wer genehmigt diese Änderung? Wenn der Agent HR-Anfragen verarbeitet, wer entscheidet, welche Anfragen automatisch genehmigt werden können und welche an einen Manager geroutet werden müssen? Die Matrix sollte nicht nur die aktuelle Schwelle spezifizieren, sondern die Befugnis, sie anzupassen – und den Trigger für eine obligatorische Prüfung (zum Beispiel nach den ersten hundert Handlungen oder nach der ersten Eskalation).
Monitoring und Eskalation beantwortet: Wer beobachtet diesen Agenten und wer erhält die Warnung, wenn etwas schiefgeht? In den meisten mittelständischen DACH-Unternehmen überwacht IT die technische Gesundheit (Uptime, Latenz, Fehlerraten), aber der Business Owner überwacht die Ergebnisqualität (hat der Agent das Richtige getan?), und Compliance überwacht Risikoindikatoren (ist der Agent innerhalb der Richtlinie geblieben?). Das Entscheidungsrecht hier ist Eskalationsbefugnis: Wer kann den Agenten pausieren, wenn das Monitoring ein Fehlermuster zeigt, und wer entscheidet, wann wieder aufgenommen wird? Ein häufiger Fehlermodus ist, dass IT Fehler sieht, aber nicht die Befugnis hat zu pausieren, weil der Business Owner darauf besteht, dass der Agent „größtenteils funktioniert". Die Matrix sollte spezifizieren, dass jede Partei mit einer Monitoring-Rolle auch Pause-Befugnis hat – vorbehaltlich einer obligatorischen Prüfung innerhalb von vierundzwanzig Stunden.
Rollback oder Override beantwortet: Wer kann rückgängig machen, was der Agent getan hat, und wer entscheidet, dass der Agent falsch lag? Rollback ist oft eine technische Handlung (IT macht eine Änderung rückgängig, storniert eine Transaktion, stellt einen vorherigen Zustand wieder her), aber die Entscheidung zum Rollback ist ein geschäftliches oder Risiko-Urteil. Wenn ein Agent eine Rückerstattung genehmigt hat, die ein Manager für betrügerisch hält, hat der Manager Override-Befugnis – er kann die Entscheidung umkehren. Aber wenn ein Agent eine Rückerstattung abgelehnt hat, die ein Kunde eskaliert, wer hat die Befugnis, die Ablehnung zu überstimmen? In den meisten mittelständischen DACH-Unternehmen ist dies der Business Owner, aber der Override muss protokolliert und von Compliance geprüft werden, weil ein Muster von Overrides darauf hindeutet, dass die Entscheidungslogik des Agenten fehlkalibriert ist. Das Entscheidungsrecht umfasst nicht nur die Befugnis zu überstimmen, sondern die Verpflichtung zu dokumentieren warum, damit der Override zum Input für die nächste Modellprüfung wird.
Human-in-the-Loop als Entscheidungsrechte-Muster
Human-in-the-Loop-Governance wird oft als Sicherheitskontrolle beschrieben: Der Agent schlägt vor, der Mensch genehmigt. In der Praxis ist es ein Entscheidungsrechte-Muster. Der Agent hat die Befugnis zu empfehlen. Der Mensch hat die Befugnis zu genehmigen, abzulehnen oder zu eskalieren. Das Muster funktioniert, wenn die Entscheidungsrechte explizit sind: Der Mensch weiß, dass er accountable für die Entscheidung ist, nicht nur fürs Klicken eines Buttons. Das Muster bricht, wenn der Mensch glaubt, er stempelt nur ab, oder wenn die Empfehlung des Agenten so undurchsichtig ist, dass der Mensch kein Urteil bilden kann.
Ein risikobasiertes Genehmigungsmodell weist unterschiedliche Ebenen menschlicher Aufsicht zu, abhängig von der Auswirkung der Handlung. Handlungen mit geringem Risiko (ein Dokument zusammenfassen, ein Meeting planen) erfordern keine menschliche Genehmigung. Handlungen mit mittlerem Risiko (eine Rückerstattung unterhalb einer Schwelle verarbeiten, eine Standardanfrage genehmigen) erfordern die Genehmigung eines designierten Prüfers, aber der Prüfer kann im Batch genehmigen. Handlungen mit hohem Risiko (Vertragsbedingungen eines Kunden ändern, einen Compliance-Bericht ausstellen, eine Einstellungsentscheidung treffen) erfordern die Genehmigung einer Senior-Rolle, mit einer obligatorischen Prüfung der Argumentation des Agenten. Die Entscheidungsrechte-Matrix spezifiziert, wer der designierte Prüfer für Handlungen mit mittlerem Risiko ist, wer der Senior-Genehmiger für Handlungen mit hohem Risiko ist und wer die Befugnis hat, eine Handlung von mittlerem auf hohes Risiko umzuklassifizieren, wenn sich der Kontext ändert.
Die Matrix sollte auch spezifizieren, was passiert, wenn der Mensch nicht antwortet. Wenn ein Agent eine Entscheidung an einen Manager eskaliert und der Manager innerhalb eines definierten Zeitfensters weder genehmigt noch ablehnt, wird die Handlung fortgesetzt oder verfällt sie? In den meisten mittelständischen DACH-Unternehmen ist der sichere Standard Verfall: Wenn der Mensch nicht handelt, handelt der Agent nicht. Aber das schafft ein neues Risiko: Der Agent wird zum Flaschenhals, und das Geschäft setzt IT unter Druck, Schwellen zu erhöhen oder menschliche Genehmigungen zu entfernen, um den Workflow zu „entblocken". Die Entscheidungsrechte-Matrix sollte diesen Trade-off explizit machen: Der Business Owner kann eine Schwellenänderung beantragen, aber der Antrag muss von Risk oder Compliance genehmigt werden, und die Änderung muss als Governance-Ereignis protokolliert werden.
Audit Trails als Entscheidungsrechte-Artefakt
Jurisdiktionen wie Colorado verlangen durch den Colorado AI Act (SB 24-205) dokumentierte Governance über KI-Systeme, die in Versicherungsentscheidungen verwendet werden, einschließlich expliziter Bias-Tests und einer nachvollziehbaren Aufzeichnung darüber, welche Daten verwendet wurden, welcher Agent die Empfehlung gemacht hat, auf welcher Basis, und wer sie geprüft und genehmigt hat. Der Audit Trail ist keine Compliance-Nettigkeit; er ist das Artefakt, das beweist, dass Entscheidungsrechte ausgeübt wurden. Wenn ein Agent einen Anspruch verarbeitet und eine Aufsichtsbehörde fragt, wer ihn genehmigt hat, muss die Antwort im Trail sein: Der Agent hat empfohlen, der Prüfer hat genehmigt, die Entscheidung wurde protokolliert und der Eskalationspfad war klar.
Für mittelständische DACH-Unternehmen muss der Audit Trail nicht nur erfassen, was der Agent getan hat, sondern wer die Befugnis hatte, ihn es tun zu lassen. Jede Handlung, die der Agent ausführt, sollte das Entscheidungsrecht protokollieren, das sie erlaubt hat: die Use-Case-Genehmigung, die Action Threshold, den menschlichen Prüfer (falls vorhanden) und die Monitoring-Warnung (falls vorhanden). Wenn später festgestellt wird, dass der Agent eine falsche Entscheidung getroffen hat, sollte der Audit Trail zeigen, ob der Fehler ein technisches Versagen war (der Agent hat Daten falsch interpretiert), ein Governance-Versagen (der Agent hat außerhalb seines genehmigten Scope gehandelt) oder ein menschliches Versagen (der Prüfer hat etwas genehmigt, das er hätte ablehnen sollen). Die Entscheidungsrechte-Matrix ist das Schema für diesen Audit Trail.
Entscheidungsrechte schnell machen, nicht bürokratisch
Der Einwand gegen Entscheidungsrechte-Matrizen ist, dass sie alles verlangsamen. Wenn jede Agenten-Handlung einen benannten Genehmiger, eine dokumentierte Schwelle und einen protokollierten Eskalationspfad erfordert, wie bewegt man sich mit der Geschwindigkeit, die das Geschäft verlangt? Die Antwort ist, dass Entscheidungsrechte keine Genehmigungen sind; sie sind Vor-Autorisierungen. Man entscheidet einmal, zur Design-Zeit, wer Befugnis für jede Ebene hat. Man kodiert diese Befugnisse ins System. Man überwacht, ob die Befugnisse korrekt ausgeübt werden. Man beruft nicht jedes Mal ein Meeting ein, wenn der Agent handelt.
Ein schnelles Entscheidungsrechte-Modell weist breite Befugnis Rollen zu, nicht Individuen. Der Business Owner hat Befugnis, Action Thresholds innerhalb eines definierten Bereichs zu setzen. IT hat Befugnis, Agenten zu deployen, die technische und Sicherheitsstandards erfüllen. Compliance hat Veto-Befugnis über jeden Agenten, der regulierte Daten berührt. Der menschliche Prüfer hat Befugnis, Handlungen mit mittlerem Risiko ohne Eskalation zu genehmigen. Der Senior-Genehmiger hat Befugnis, den Agenten bei Handlungen mit hohem Risiko zu überstimmen. Jede Rolle kennt ihren Scope. Jede Rolle weiß, wann zu eskalieren ist. Das System erzwingt die Grenzen.
Der Governance-Flywheel – Entscheidungsrechte zuweisen, dokumentieren was zählt, Ergebnisse überwachen, das Modell verfeinern – funktioniert, weil Entscheidungsrechte Verantwortlichkeit schnell machen. Man braucht keinen Lenkungsausschuss, um zu entscheiden, ob ein Agent eine Rückerstattung verarbeiten soll. Man braucht eine Schwelle, einen Prüfer und einen Rollback-Pfad. Man braucht keine Rechtsauskunft jedes Mal, wenn ein Agent eine Antwort entwirft. Man braucht ein vorab genehmigtes Template, einen Review-Trigger für Ausnahmen und einen Audit Trail. Die Entscheidungsrechte-Matrix ist das Betriebsmodell, das es einem erlaubt, sich schnell zu bewegen, ohne die Kontrolle zu verlieren.
Mit einem Agenten beginnen, auf viele skalieren
Die meisten mittelständischen DACH-Unternehmen werden nicht auf einmal eine Entscheidungsrechte-Matrix für alle möglichen Agenten bauen. Sie werden mit einem Agenten beginnen, in einer Funktion, mit einem Satz von Entscheidungsrechten. Die Matrix für diesen ersten Agenten wird zum Template. Wenn man Agenten hinzufügt, verfeinert man das Template: Neue Handlungstypen erfordern neue Schwellen, neue Datenquellen erfordern neue Genehmigungen, neue regulatorische Anforderungen erfordern neue Veto-Rechte. Die Matrix skaliert, weil sie modular ist. Jeder Agent erbt die Basis-Entscheidungsrechte für seine Risikokategorie, plus alle funktionsspezifischen Befugnisse.
Der Fehler ist, Entscheidungsrechte als Projekt-Deliverable zu behandeln – etwas, das man einmal dokumentiert und ablegt. Entscheidungsrechte sind ein operatives Artefakt. Sie ändern sich, wenn sich der Scope des Agenten ändert, wenn sich der Geschäftskontext ändert, wenn sich das regulatorische Umfeld ändert. Die Matrix sollte versioniert, vierteljährlich geprüft und aktualisiert werden, wann immer ein Agent modifiziert oder ein neuer Agent deployed wird. Das Entscheidungsrecht, Entscheidungsrechte zu ändern – wer kann eine neue Genehmigungsebene hinzufügen, wer kann eine Schwelle entfernen, wer kann ein Veto neu zuweisen – sollte selbst explizit in der Matrix sein.
Ein Fit Call geht die Entscheidungsrechte-Matrix Ihres ersten Agenten durch – wer genehmigt, wer blockiert, wer überwacht, wer überstimmt –, bevor Sie deployen und die Lücken unter Druck entdecken.
*References: Forbes, „From AI Chaos To Confidence: The Governance Flywheel Executives Need," 2026, https://www.forbes.com/sites/geraldleonard/2026/06/08/from-ai-chaos-to-confidence-the-governance-flywheel-executives-need/; Forbes, „The 7 AI Agent Guardrails Every Business Needs Before Things Go Wrong," 2026, https://www.forbes.com/sites/bernardmarr/2026/06/03/the-7-ai-agent-guardrails-every-business-needs-before-things-go-wrong/; Dark Reading, „Human-in-the-Loop (HITL): Balancing AI Speed with Human," 2026, https://www.darkreading.com/identity-access-management-security/human-in-the-loop-hitl-balancing-