Governance-Framework für KI-Agenten

1. Mit Governance-Prinzipien beginnen

Ein Governance-Modell sollte mit wenigen, konsistenten Prinzipien starten, die für das gesamte Agentenportfolio gelten. Diese Prinzipien müssen für Product Owner, Entwickler, Risk, Compliance und Fachbereiche verständlich sein.

Zu den wichtigsten Prinzipien gehören nachvollziehbare Ownership, Least Privilege, verhältnismäßige Kontrollen, menschliche Rechenschaftspflicht, Evidence by Design und kontrollierte Änderungen. Höheres Risiko sollte stärkere Kontrollen auslösen, statt jeden Use Case mit demselben Prozess zu behandeln.

• Jeder Agent hat einen benannten Business Owner und einen technischen Owner.
• Jeder Agent arbeitet innerhalb eines klar definierten Zwecks und einer Befugnisgrenze.
• Zugriff auf Systeme, Daten und Aktionen folgt dem Least-Privilege-Prinzip.
• Menschliche Aufsicht richtet sich nach den möglichen Folgen eines Fehlers.
• Test- und Freigabenachweise werden aufbewahrt und sind reproduzierbar.
• Wesentliche Änderungen lösen eine erneute Bewertung aus.

2. Ein verbindliches Agenten-Inventar führen

Organisationen können Agenten nicht steuern, wenn sie diese nicht identifizieren können. Ein unternehmensweites Inventar ist daher eine grundlegende Governance-Kontrolle.

Das Inventar sollte mehr als eine Namensliste enthalten. Es muss ausreichend Informationen liefern, um Zweck, Betriebsort, Systemzugriffe und Verantwortlichkeiten zu verstehen.

• Agentenname, Version und Lifecycle-Status.
• Business-Zweck und vorgesehene Nutzer.
• Business Owner, technischer Owner und Support Owner.
• Microsoft-Umgebung, Solution und Deployment-Ort.
• Verbundene Systeme, Konnektoren, Tools und Datenkategorien.
• Aktionsberechtigungen und Transaktionsbefugnisse.
• Risikoklassifizierung und erforderliche Freigabestufe.
• Modell der menschlichen Aufsicht.
• Testnachweise, Zertifizierungsstatus und letztes Review-Datum.

3. Risiko vor dem Deployment klassifizieren

Die Risikoklassifizierung bestimmt, wie viel Governance ein Agent benötigt. Entscheidend ist nicht nur das verwendete Modell, sondern was der vollständige Agent sehen, entscheiden und ausführen kann.

Ein rein lesender Informationsagent unterscheidet sich grundlegend von einem Agenten, der Transaktionen genehmigen, extern kommunizieren, Datensätze verändern oder Folgeprozesse auslösen kann.

Der CAI Score ist der strukturierte Ansatz von ColleagueAI zur Klassifizierung von Enterprise-Agentenrisiken. Er berücksichtigt Autonomie, Auswirkung, Datensensitivität, Tool-Zugriff, Reversibilität, Aufsicht und Governance-Anforderungen. Die Klassifizierung sollte vor Deployment und bei wesentlichen Capability-Änderungen erneut erfolgen.

4. Business-Verantwortung und technische Ownership trennen

Technische Teams können einen Agenten entwickeln und betreuen, sollten aber nicht allein für das Business-Ergebnis verantwortlich sein. Der Fachbereich, der den Agenten einsetzt, muss für Prozess und Folgen verantwortlich bleiben.

Ein reifes Modell trennt deshalb Business Ownership, technische Ownership und Governance Assurance. Dadurch verschwindet Verantwortung nicht zwischen Technologie und Betrieb.

Das Ownership-Modell sollte auch die Entscheidungsrechte eindeutig festlegen. Der Business Owner genehmigt den vorgesehenen Zweck, akzeptable Ergebnisse und wesentliche Prozessänderungen, während der Technical Owner für die Integrität der Lösungskomponenten, der Konfiguration und der technischen Kontrollen verantwortlich bleibt. Governance-, Risiko-, Sicherheits- oder Compliance-Funktionen können unabhängige Prüfung und Challenge leisten, ohne die klare Verantwortung des Business Owners zu ersetzen.

5. Identität, Zugriff und Tool-Berechtigungen steuern

Die Fähigkeiten eines Agenten werden wesentlich durch die Systeme und Aktionen bestimmt, auf die er zugreifen darf. Governance muss deshalb Konnektoren, Credentials, Service-Identitäten und Aktionsberechtigungen als zentrale Kontrollen behandeln.

Berechtigungen sollten sich auf das Minimum beschränken, das für den genehmigten Use Case notwendig ist. Wenn möglich, sollten hochwirksame Aktionen von risikoarmen Retrieval- und Analysefunktionen getrennt werden.

• Dedizierte Identitäten verwenden, wenn Plattform und Architektur dies unterstützen.
• Konnektoren und Aktionen auf genehmigte Use Cases begrenzen.
• Keine breiten Berechtigungen nur aus Entwicklungsbequemlichkeit vergeben.
• Privilegierte Aktionen in auditierbaren Logs festhalten.
• Für irreversible oder hochwirksame Aktionen Freigabegates nutzen.
• Berechtigungen bei Workflow- oder Integrationsänderungen erneut validieren.

6. Menschliche Aufsicht in den Workflow integrieren

Menschliche Aufsicht sollte nicht nur als allgemeiner Hinweis formuliert werden, dass ein Mensch verantwortlich bleibt. Es muss klar sein, wo Menschen prüfen, genehmigen, eingreifen oder den Agenten stoppen.

Das passende Modell hängt vom Risiko ab. Manche Agenten können innerhalb eng begrenzter, risikoarmer Aufgaben autonom arbeiten. Andere benötigen eine menschliche Freigabe vor einer folgenreichen Aktion. Hochrisiko-Use-Cases können kontinuierliche Aufsicht erfordern oder für autonome Ausführung ungeeignet sein.

Die Kontrolle sollte festlegen, wann ein Eingriff erfolgt, wer die Prüfung durchführt, welche Informationen dieser Person zur Verfügung stehen und welche Maßnahmen sie ergreifen darf. Ein formaler Genehmigungsschritt reicht nicht aus, wenn der Prüfer das vorgeschlagene Ergebnis nicht verstehen oder stoppen kann. Menschliche Aufsicht sollte deshalb als operative Kontrolle getestet und nicht lediglich als Richtlinienanforderung dokumentiert werden.

7. Den Agenten als Gesamtsystem testen

Agent Assurance erfordert Tests des vollständigen Workflows. Prompt-Qualität ist wichtig, aber ebenso Berechtigungen, Tool-Aufrufe, Fehlerverhalten, Datenverarbeitung, Eskalationslogik, Output-Qualität und Verhalten bei unerwarteten Eingaben.

Ein Produktionspaket sollte dokumentieren, was getestet wurde, welches Verhalten erwartet wird, welche bekannten Einschränkungen bestehen und welche Version den Test bestanden hat.

• Funktionale und szenariobasierte Tests.
• Tests von Berechtigungen und Konnektoren.
• Fehler- und Ausnahmewege.
• Freigabe- und Eskalationspfade.
• Umgang mit sensiblen Daten.
• Kriterien für Output-Qualität.
• Logging und Evidence-Erzeugung.
• Regressionstests nach wesentlichen Änderungen.

8. Deployment als kontrollierte Übergabe gestalten

Ein paketierter Agent braucht eine klare Deployment-Grenze. Der Anbieter kann ein getestetes Solution Package, Dokumentation, Konfigurationshinweise, Governance-Nachweise und Deployment-Anleitungen bereitstellen, während der Kunde seinen eigenen Tenant und die Betriebsumgebung kontrolliert.

Bei ColleagueAI-Produkten bleiben Deployment und Runtime in der Microsoft-Umgebung des Kunden. Tenant-spezifische Konfiguration, Integrationen, Deployment und Betrieb erfolgen durch den Kunden oder dessen freigegebenen Implementierungspartner.

Eine kontrollierte Übergabe sollte außerdem Voraussetzungen, Umgebungsvariablen, Connection References, erforderliche Rollen, bekannte Einschränkungen und Validierungsschritte nach dem Import dokumentieren. Dadurch kann der Kunde oder Implementierungspartner die getestete Konfiguration reproduzieren, ohne auf nicht dokumentiertes Wissen des ursprünglichen Entwicklers angewiesen zu sein. Die bereitgestellte Version sollte jederzeit auf das genehmigte Paket und die zugehörigen Nachweise zurückgeführt werden können.

9. Betriebsrisiko und wesentliche Änderungen überwachen

Die Freigabe zum Go-live beendet Governance nicht. Agentenverhalten kann sich ändern, wenn Prompts, Modelle, Tools, Berechtigungen, Wissensquellen oder verbundene Systeme geändert werden.

Kontinuierliche Governance sollte sich daher auf wesentliche Änderungen, Ausnahmen, Incidents, Nutzungsmuster, Freigabe-Overrides und Nachweise konzentrieren, dass die deployte Konfiguration weiterhin dem genehmigten Design entspricht.

Monitoring sollte mit klar definierten Auslösern für eine erneute Prüfung verbunden sein. Dazu können ein neuer Connector, erweiterte Berechtigungen, ein anderes Modell, eine neue Wissensquelle, zunehmende Overrides, wiederkehrende Ausnahmen oder Änderungen am Geschäftsprozess gehören. Solche Signale sollten bestimmen, wann Untersuchung, Korrekturmaßnahmen, Rezertifizierung oder eine neue Governance-Entscheidung erforderlich werden.

10. Stilllegung genauso kontrollieren wie den Start

Nicht mehr genutzte oder ersetzte Agenten sollten keine inaktiven Zugriffe unbegrenzt behalten. Bei der Stilllegung sollten Berechtigungen entfernt, Integrationen deaktiviert, Nachweise archiviert und das Inventar aktualisiert werden.

Ein sauberer Stilllegungsprozess reduziert die Angriffsfläche und verhindert unklare oder verwaiste KI-Fähigkeiten.

Auch beim Retirement müssen operative und Governance-Abhängigkeiten sauber geschlossen werden. Verantwortliche sollten bestätigen, dass geplante Flows deaktiviert, Service-Zugangsdaten soweit erforderlich widerrufen, nachgelagerte Integrationen angepasst und Nachweise gemäß Richtlinie archiviert wurden. Nutzer sollten gegebenenfalls auf einen Ersatzprozess verwiesen werden, und das Inventar sollte sowohl das Retirement-Datum als auch den endgültigen Status des Agenten dokumentieren.

Häufig gestellte Fragen