KI-Governance: Verantwortung, Kontrollen und Nachweise
KI-Governance für agentische Prozesse: Verantwortlichkeiten festlegen, Freigaben begrenzen und Kontrollen mit einer herunterladbaren Checkliste prüfen.
KI-Governance legt fest, wer einen KI-Einsatz verantwortet, welche Aufgaben und Daten zulässig sind, wie Entscheidungen freigegeben werden und welche Nachweise den Betrieb überprüfbar machen. Bei KI-Agenten muss sie auch Werkzeugzugriffe und externe Aktionen begrenzen. Eine Richtlinie wird erst wirksam, wenn sie einen Verantwortlichen, einen technischen Kontrollpunkt, ein Abnahmekriterium und ein Verfahren für Ausnahmen hat.
Dieser Leitfaden hilft Prozess-, Plattform- und Sicherheitsverantwortlichen, diese Zuordnung für einen konkreten Prozess aufzubauen. Er behandelt organisatorische und technische Gestaltung. Er ist keine Feststellung rechtlicher Konformität. Welche rechtlichen Anforderungen im Einzelfall gelten, muss die zuständige Fachfunktion anhand des tatsächlichen Einsatzes beurteilen.
KI-Governance beginnt mit einem abgegrenzten Einsatz
Erfassen Sie nicht nur Modellnamen und Anbieter. Ein sinnvoller Registereintrag beschreibt Zweck, Prozessverantwortung, betroffene Personen, Datenquellen, erlaubte Werkzeuge, Ausgabeempfänger und mögliche externe Wirkungen. Derselbe Modellanbieter kann in zwei Prozessen unterschiedliche Kontrollen erfordern. Entscheidend ist die Aufgabe mit ihren Folgen.
Als Referenz dient ein Agent, der ein internes Nachweispaket vorbereitet. Sein Ergebnis ist ein Entwurf mit Quellenverweisen und offenen Fragen. Er darf keine Quelldokumente ändern, keine Konformität bescheinigen und keine Prüfung abschließen. Diese Grenzen lassen sich als konkrete Werkzeuge, Rollen und Freigabeschritte abbilden. Der Leitfaden für KI-Agenten im Unternehmen beschreibt die zugehörige Architektur.
Das freiwillige NIST AI Risk Management Framework bietet mit Govern, Map, Measure und Manage eine Struktur für Risikomanagement. Es ist keine Zertifizierung. Die folgende Zuordnung ist eine praktische Arbeitsvorlage, keine von NIST vorgeschriebene Organisationsstruktur.
Verantwortungsmatrix für einen agentischen Prozess
| Entscheidung | Verantwortliche Rolle | Benötigter Nachweis | Wann erneut prüfen? |
|---|---|---|---|
| Zweck und zulässiges Ergebnis | Prozessverantwortung | Versionierter Auftrag mit Ausschlüssen | Bei verändertem Prozess oder Empfängerkreis |
| Datenquellen und Felder | Dateneigentümer | Quellenregister und Zugriffsentscheidung | Bei neuer Quelle oder Datenklasse |
| Identität und delegierte Rechte | Identity- und Security-Team | Agentenregister, Mandat und Ablauf | Bei Eigentümerwechsel oder Sperre |
| Fachliche Freigabe | Benannte Fachperson | Inhalt, Ziel, Zweck und Versionsbezug | Bei jeder materiellen Änderung |
| Technische Ausführung | Plattform-Team | Durchsetzungspunkt und Fehlertests | Bei Werkzeug- oder Policy-Änderung |
| Aufbewahrung und Einsicht | Datenverantwortung und zuständige Fachfunktionen | Aufbewahrungs- und Zugriffskonzept | Bei neuem Zweck oder neuer Verpflichtung |
| Stopp und Wiederanlauf | Betrieb mit Prozessverantwortung | Vorfall, Sperrwirkung und Wiederfreigabe | Nach Störung oder Sicherheitsereignis |
Benennen Sie für jede Zeile eine konkrete Person oder verantwortliche Einheit sowie eine Vertretung. „Das KI-Team“ ist zu ungenau, wenn bei einem Vorfall niemand die Entscheidung übernehmen kann. Mehrere beteiligte Rollen sind sinnvoll; die letztverantwortliche Entscheidung sollte dennoch eindeutig sein.
Trennen Sie Freigabe und Ausführung bei folgenreichen Aktionen. Ein Agent sollte sich keine eigenen Rechte ausstellen können. Eine Fachperson muss erkennen können, welchen Inhalt sie für welches Ziel freigibt. Eine erneute Freigabe ist notwendig, wenn geschützte Parameter nach der Prüfung verändert werden.
Von der Richtlinie zum technischen Kontrollpunkt
Eine Anweisung im Systemprompt kann gewünschtes Verhalten beschreiben. Sie ist kein Ersatz für eine Zugriffskontrolle außerhalb des Modells. Prüfen Sie Identität, Zweck, erlaubte Aktion, Ziel und aktuelle Zustandsdaten an der Stelle, an der die Aktion tatsächlich ausgeführt wird. Entfernen Sie Umgehungswege mit direkten Zugangsdaten.
| Governance-Regel | Technische Umsetzung | Beobachtbares Abnahmekriterium |
|---|---|---|
| Nur freigegebene Quellen | Quellen- und Feldberechtigungen vor Abruf | Fremder Datensatz wird nicht an das Modell geliefert |
| Keine ungeprüfte Veröffentlichung | Freigabe bindet genaue Anfrage | Veränderte Nutzlast wird abgelehnt |
| Rechte gelten nur befristet | Ablauf und Sperrstatus prüfen | Abgelaufene Berechtigung verursacht keinen Versand |
| Ein Auftrag wird nicht versehentlich doppelt ausgeführt | Operationskennung und dauerhafte Zustandsverwaltung | Wiederholung wird erkannt und abgeglichen |
| Jeder Vorfall hat einen Eigentümer | Alarmierung und Bereitschaftsverfahren | Testvorfall erreicht eine benannte Rolle |
Für MCP-Anbindungen erläutert der MCP-Gateway-Leitfaden die Grenze zwischen Protokollzugang und Berechtigung für eine konkrete Geschäftshandlung. Die offizielle MCP-Sicherheitsdokumentation beschreibt unter anderem Risiken durch falsch verwendete Tokens und Sitzungen. Ihre unternehmensspezifischen Freigaberegeln müssen darüber hinaus separat umgesetzt werden.
Checkliste für Kontrollen und Nachweise herunterladen
Die KI-Governance-Checkliste 1.0.0 als CSV enthält zwölf Kontrollen mit Rolle, Nachweis und Freigabekriterium. Die Spalten für Status, Nachweislink, Prüfer und Prüfdatum sind bewusst nicht ausgefüllt. Eine leere Vorlage ist keine bestandene Prüfung. Ergänzen Sie konkrete Zuständigkeiten und verlinken Sie die Ergebnisse aus Ihrer eigenen Testumgebung.
Öffnen Sie die UTF-8-Datei in einem Tabellenprogramm mit Komma als Trennzeichen. Technische Spaltennamen verwenden einfache Zeichen für den Import. Speichern Sie eine datierte Kopie im eigenen Dokumentationssystem. Tragen Sie keine Zugangsdaten oder vollständigen personenbezogenen Quelldaten in die Tabelle ein; verwenden Sie kontrollierte Referenzen mit passenden Zugriffsrechten.
Kontrolle: G04 – Anfragebindung
Verantwortung: benannte Security-Rolle
Nachweis: Testlauf mit geänderter Nutzlast nach Freigabe
Erwartung: Ablehnung vor Versand; kein Aufruf im Zielsystem
Status: offen, bis Ergebnis und Prüfung dokumentiert sind
Ein guter Nachweis nennt Testversion, Zeitpunkt, Umgebung, Eingaben, erwartetes Ergebnis und tatsächliche Beobachtung. Ein Screenshot eines grünen Dashboards belegt nicht automatisch, dass die relevante Umgehung geprüft wurde. Für jeden blockierten Fall sollte auch die Zielseite beobachtet werden: Hat trotz einer Fehlermeldung ein Aufruf stattgefunden?
KI-Agenten-Sicherheit im laufenden Betrieb
Kontrollen müssen nach Modell-, Werkzeug-, Policy- und Organisationsänderungen weiterhin funktionieren. Halten Sie die Versionen getrennt fest. Wenn ein Werkzeug zusätzliche Parameter erhält oder ein Dienst neue Daten zurückliefert, kann sich die Risikogrenze verändern, obwohl der Prompt unverändert bleibt.
Testen Sie mindestens den Zugriff auf fremde Daten, eine manipulierte Quellenanweisung, eine veränderte Freigabe, einen gesperrten Agenten und eine Zeitüberschreitung nach Versand. Nicht jeder Test ist durch einen allgemeinen Prompt-Injection-Filter abgedeckt. Eine zuverlässige Begrenzung entsteht durch mehrere Kontrollen, darunter Datenberechtigungen, Werkzeugauswahl, Parameterprüfung und Freigabe am Ausführungspunkt.
Im Kontrolllabor können Sie Ablehnungen und Wiederholungen lokal nachvollziehen. Das Labor authentifiziert keine realen Identitäten und prüft keine verteilte Betriebsumgebung. Verwenden Sie seine Fälle als Ausgangspunkt für eigene Integrationstests. Dokumentieren Sie ausdrücklich, welche Prüfungen nur simuliert und welche gegen das tatsächliche System ausgeführt wurden.
Vorfallübung und kontrollierter Wiederanlauf
Führen Sie vor der Freigabe eine kleine Übung durch: Der Agent versendet einen genehmigten Entwurf, die Antwort des Zielsystems geht verloren, anschließend versucht der Agent denselben Auftrag erneut. Der Betrieb muss den Zustand als unklar erkennen, neue unkontrollierte Versuche verhindern und die Operationskennung im Zielsystem abgleichen können.
Die Übung ist erst abgeschlossen, wenn die Zuständigkeit für den Abgleich, das beobachtete Ergebnis und die Entscheidung zum Wiederanlauf dokumentiert sind. Fehlt der Nachweis, bleibt der Vorgang offen. Ein neues Modellurteil darf die Unklarheit nicht in einen vermeintlichen Erfolg umwandeln. Ebenso darf eine gültige Signatur nicht als Beweis für eine tatsächlich durchgeführte Aktion missverstanden werden.
Prüfen Sie außerdem den Notstopp. Sperren Sie den Testagenten und beobachten Sie jeden Ausführungspunkt. Laufende Vorgänge benötigen eine definierte Behandlung: stoppen, kontrolliert abschließen oder in eine menschliche Klärung überführen. Die passende Entscheidung hängt von der Aktion ab und muss vor dem Vorfall festgelegt sein.
Freigabe und aktueller Intelliger-Stand
Eine Freigabe sollte den zugelassenen Umfang, den Teststand, offene Abweichungen, befristete Ausnahmen und die nächste Prüfung nennen. Jede Ausnahme benötigt eine verantwortliche Person und ein Enddatum. Lassen Sie den Betrieb erst beginnen, wenn die zuständigen Prozess-, Sicherheits- und Fachverantwortlichen ihre jeweiligen Entscheidungen getroffen haben.
Intelliger beschreibt Agent Trust als Kontrollschicht für folgenreiche Agentenaktionen. OATI ist ein Developer Preview; lokale Implementierungen und synthetische Nachweise ersetzen weder unabhängige Sicherheitsprüfung noch Freigabe für Ihren Prozess. Dieser Leitfaden ist eine eigenständige deutschsprachige Wissensseite und keine Übersetzung der kommerziellen Agent-Trust-Seite.
Beginnen Sie mit der herunterladbaren Checkliste und einem einzigen Prozess. Weitere technische Grundlagen finden Sie in der Leitfadenübersicht. Benennen Sie zuerst Auftrag, Eigentümer und Abnahmekriterien; wählen Sie anschließend die dafür erforderlichen technischen Komponenten.