Blog
•
11 Min. Lesezeit
Nicht immer. Eine GRC-Suite für Unternehmen deckt bereits Richtlinienbestätigungen, Kontrolltests, das Management von Feststellungen und Audit-Workflows ab, und diese Funktionen lassen sich unverändert auf KI-Systeme anwenden. Was sie nicht von Haus aus abbildet, ist der KI-spezifische Datenbestand: Erkennung, Metadaten zu Modellen und Agenten, versionierte Nachweise und das Mapping über sich überschneidende KI-Regelwerke hinweg. Die Antwort hängt davon ab, wie viel davon Sie vorlegen müssen.
Was deckt eine bestehende GRC-Suite für KI bereits gut ab?
Die zentralen GRC-Disziplinen und -Prinzipien lassen sich ohne Anpassung auf KI anwenden. ServiceNow beschreibt die Compliance-Workflows in Integrated Risk Management mit den Worten „Richtlinien verwalten, Kontrolltests automatisieren und Probleme untersuchen“ und verspricht, „Audit-Nachweise zu zentralisieren“. Archer vereint Produkte für Richtlinien-Governance, Audit-Management, Einhaltung gesetzlicher Vorschriften und Unternehmensrisiken in einem führenden System. Ein KI-Governance-Programm braucht all das vom ersten Tag an und sollte nichts davon neu aufbauen. Sechs dieser Funktionen lassen sich direkt auf die KI-Governance übertragen:
Richtlinienbestätigung. Eine Nutzungsrichtlinie für generative KI ist eine Richtlinie wie jede andere: veröffentlichen, Bestätigungen einholen, Ausnahmen nachverfolgen.
Management von Feststellungen und Befunden. Ein Befund zu Verzerrungen aus einer Modellprüfung ist eine Feststellung mit Verantwortlichem, Fälligkeitsdatum und Maßnahmenplan.
Audit-Workflow. Die Interne Revision steuert Prüfungsplanung, Prüfungsdurchführung und Berichterstattung bereits über die Suite.
Kontrollbibliotheken. Eine Kontrolle, die den Zugriff auf Produktivsysteme beschränkt, gilt für einen Inferenz-Endpunkt ebenso wie für eine Datenbank.
Unternehmensweite Risikotaxonomie. KI-Risiken sollten in die Taxonomie operationeller Risiken einfließen, die dem Vorstand bereits vorliegt, nicht in eine parallele.
Bestehende Freigaben. Beschaffung, Sicherheitsprüfung, Datenschutzprüfung und Änderungsmanagement sind etablierte Wege, und eine KI-Anfrage sollte sie durchlaufen, nicht umgehen.
Auch die etablierten Anbieter haben nachgezogen. ServiceNow AI Control Tower verspricht, „jeden KI-Agenten, jedes Modell und jeden MCP-Server, ob selbst entwickelt oder von Drittanbietern, automatisch zu inventarisieren“, und liefert Inhalte für den EU AI Act, das NIST AI RMF und den California AI Transparency Act. Collibra AI Governance bietet „ein einheitliches Verzeichnis für jedes KI-Asset“, Vorlagen für EU AI Act und NIST AI RMF sowie die Nachverfolgung der Datenherkunft „von den Quelldatensätzen über Modelltraining, Inferenz und Bereitstellung bis zur Nutzung“. OneTrust AI Governance soll „KI-Systeme, Modelle, Agenten, Datensätze, Anbieter, Projekte und Anwendungsfälle erkennen und inventarisieren“ und bringt Vorlagen für EU AI Act, NIST AI RMF und ISO 42001 mit. Auch Archer führt ein Angebot für AI Governance. Für Käufer lautet die Frage also nicht mehr, ob die Suite ein KI-Modul hat, sondern ob dieses Modul für die eigene KI-Landschaft tief genug reicht und wo der KI-spezifische Datenbestand liegen sollte.
Was kann ein GRC-Modul für KI-Systeme strukturell nicht leisten?
Ein GRC-Datenmodell ist um Richtlinien, Kontrollen, Risiken, Feststellungen und, im Fall von ServiceNow, Konfigurationselemente in der CMDB herum aufgebaut. Ein gutes KI-Governance-Programm braucht jedoch Objekte, für die diese Modelle nicht ausgelegt sind. In Unternehmen, die ihre KI-Governance über diese Tools abwickeln wollen, sehen wir sechs Lücken, die im Folgenden einzeln erläutert werden.
Die erste Lücke ist die Erkennung. Ein GRC-Datensatz existiert, weil jemand ihn angelegt hat. KI gelangt jedoch über Funktionen ins Unternehmen, die ein SaaS-Anbieter freigeschaltet hat, über Abonnements, die über Spesen abgerechnet werden, über Modelle in Anbieterprodukten und über Agenten, die auf internen Plattformen entstehen. Nichts davon erzeugt eine Registrierung. Das KI-Inventar von Enzai kombiniert KI-Erkennung, Plattformimporte und Anwendungsfallanfragen. Der Leitfaden zum Aufbau eines KI-Inventars zeigt, was jede Methode übersieht.
Die zweite sind Metadaten zu Modellen und Agenten. Basismodell und Version, Anbieter, Prompt-Konfiguration, Daten für die Feinabstimmung, Autonomiegrad und Tool-Berechtigungen sind Attribute eines KI-Systems, und ein Kontrolldatensatz hat für keines davon ein Feld.
Die dritte ist das Framework-Mapping über sich überschneidende KI-Regelwerke hinweg. Ein einzelnes System für Kreditentscheidungen kann unter Anhang III des EU AI Act fallen, im Geltungsbereich von ISO 42001 liegen und zugleich dem NIST AI RMF sowie dem Recht des Bundesstaats unterliegen, in dem der Kunde lebt. Und diese Regelwerke ändern sich. Colorado hat sein KI-Gesetz aufgehoben und als SB 26-189 neu erlassen, unterzeichnet am 14. Mai 2026; die Verbraucherrechte gelten ab dem 1. Januar 2027. Der Digital Omnibus zur KI ist am 27. Juli 2026 in Kraft getreten und hat die Pflichten nach Anhang III auf den 2. Dezember 2027 verschoben. Eine von Hand gepflegte Kontrollbibliothek hinkt jeder Änderung hinterher, und Nachweise für ein Framework werden selten für das nächste wiederverwendet.
Die vierte ist die kontinuierliche Überwachung des Modellverhaltens. Kontrolltests finden periodisch statt. Artikel 9 Absatz 2 des EU AI Act beschreibt das Risikomanagementsystem für Hochrisiko-KI-Systeme als „einen kontinuierlichen iterativen Prozess, der während des gesamten Lebenszyklus geplant und durchgeführt wird“. Drift, Ausgabequalität und Signale der Leitplanken sind Telemetriedaten, keine quartalsweisen Testergebnisse.
Die fünfte sind Nachweise, die an eine bestimmte Modellversion gebunden sind. Wenn ein Prüfer fragt, wogegen ein System validiert wurde, von wem und in welcher Version, muss die Antwort die Version in Produktion benennen, und die Nachweise müssen neu angestoßen werden, sobald der Anbieter das Basismodell wechselt. Ein Kontrolltest beantwortet das nicht.
Die sechste sind Autonomie und Berechtigungsverwaltung auf Agentenebene. Welche Tools ein Agent aufrufen darf, was er ohne Bestätigung tun darf und wo Rekursion begrenzt wird, sind Entscheidungen, die sich ändern, wenn der Aufgabenbereich des Agenten wächst. Das Enzai-Modul für die Governance agentischer KI stuft jeden Agenten ein, „je nachdem, was er ohne Aufsicht tun kann: nur lesen, nur vorschlagen oder handeln“, und blockiert nicht genehmigte Tool-Aufrufe direkt an der Grenze.
Wie unterscheiden sich ein GRC-Modul und eine spezialisierte KI-Governance?
Kriterium | GRC-Suite mit KI-Modul | Spezialisierte KI-Governance-Ebene |
|---|---|---|
Führendes System für Richtlinien, Risiken, Feststellungen und Audit | Nativ, ausgereift, vorstandstauglich | Speist es mit Daten. Sollte es nicht ersetzen |
KI-Erkennung | Registrierungsbasiert; neuere Module ergänzen eine automatisierte Inventarisierung | Mehrere Erkennungsmethoden für genehmigte KI und Schatten-KI |
Objektmodell | Richtlinie, Kontrolle, Risiko, Feststellung, Konfigurationselement | KI-System, Modell, Agent, Anwendungsfall, Anbieter, Version |
Abdeckung von KI-Frameworks | Vom Anbieter gelieferte Inhalte; die drei für diesen Artikel geprüften Module führen jeweils zwei oder drei KI-spezifische Frameworks | Bibliothek für EU AI Act, ISO 42001, NIST AI RMF, DSGVO, Regelwerke der US-Bundesstaaten, FS AI RMF und OWASP Agentic Top 10, mit Wiederverwendung von Nachweisen über Frameworks hinweg |
Granularität der Nachweise | Pro Kontrolle, pro Testzyklus | Pro System, pro Framework, mit Live-Compliance-Status in Echtzeit |
Überwachung | Periodische Kontrolltests und wichtige Risikoindikatoren | Handlungsspielraum von Agenten, Abweichungen von erlaubten Aktionen |
Agenten-Governance | Im Entstehen; Umfang und Tiefe variieren je nach Anbieter | Autonomiestufen, erlaubte Aktionen, Multi-Agenten-Topologie |
Aufnahme und Freigabe | Bestehende Freigabe-Workflows im Unternehmen | Risikobasierte Einstufung bei der KI-Erfassung, mit Übergaben an Jira, ServiceNow und Slack |
Typische Verantwortung | GRC oder Risikomanagement der zweiten Verteidigungslinie | KI-Leitung oder Verantwortliche für verantwortungsvolle KI, gemeinsam mit GRC |
Am besten geeignet für | Kleine KI-Landschaft, geringe regulatorische Exposition, klare bestehende Verantwortlichkeiten | Agenten in Produktion, in Anbieterprodukte integrierte KI, Geltungsbereich von Anhang III oder ISO 42001, mehrere Rechtsräume |
Die Tiefe variiert je nach Anbieter und Release. Verstehen Sie jede Zeile daher als Frage für Ihre Evaluierung, nicht als Urteil.
Wann ist der Ausbau der GRC-Suite die richtige Wahl?
Wenn in Ihrem Unternehmen die folgenden drei Bedingungen erfüllt sind, kann Ihr bestehendes GRC-Tool die richtige Wahl sein.
Die KI-Landschaft ist klein und statisch: einige Dutzend Systeme, keines davon ein Agent mit Schreibzugriff, keines in einer Kategorie nach Anhang III oder unter einem sektoralen Hochrisiko-Regime, und kein Plan, daran innerhalb eines Jahres etwas zu ändern.
Die regulatorische Exposition ist gering: keine Hochrisiko-Präsenz in der EU, keine ISO-42001-Zertifizierung geplant, keine aufsichtsrechtliche Erwartung, die KI ausdrücklich nennt.
Die Verantwortlichkeiten sind bereits klar geregelt: eine benannte verantwortliche Stelle für KI-Risiken in der zweiten Verteidigungslinie, ein funktionierender Antragsprozess und Fachbereiche, die registrieren, was sie einkaufen.
Treffen alle drei zu, ergänzen Sie das bestehende Risikoregister um KI-Attribute, aktivieren Sie das KI-Modul des Anbieters und legen Sie einen Termin für die Überprüfung fest. Die Kosten einer zweiten Plattform sind real: eine weitere Integration, eine weitere Risikoprüfung eines Anbieters, eine weitere Anmeldung. Ein Programm, das sich im Governance-Reifegradmodell noch in der Ad-hoc- oder Wiederholbarkeitsstufe befindet, gewinnt mehr dadurch, die Richtlinie zu schreiben und die Systeme zu finden, als durch neue Tools.
Ein Beispiel zur Veranschaulichung: ein regionaler Versicherer mit acht in Anbieterprodukte integrierten KI-Funktionen, einem Betrugserkennungsmodell, das bereits im Modellrisikomanagement erfasst ist, und keinen Agenten. Hier ist der Ausbau der Suite vorerst die richtige Entscheidung.
Wann wird eine spezialisierte KI-Governance-Ebene notwendig?
Schon eines dieser Signale reicht in der Regel aus.
Agenten sind in Produktion und dürfen handeln. Ein Feststellungsdatensatz im GRC-System kann eine Regel wie „Dieser Agent darf das CRM lesen und eine Erstattung vorschlagen, aber keine ausführen“ nicht abbilden, und eine solche Liste ändert sich häufiger als jede Richtlinie.
Für dasselbe System gilt mehr als ein KI-Regelwerk, und die Regelwerke ändern sich laufend. Nur Nachweise pro System und pro Framework mit framework-übergreifender Wiederverwendbarkeit beenden das ständige erneute Einsammeln.
Die Organisation ist eine Bank. SR 26-2, veröffentlicht am 17. April 2026 als Nachfolger von SR 11-7, stellt fest, dass generative und agentische KI-Modelle „nicht in den Anwendungsbereich dieser Leitlinie fallen“ (Federal Reserve). Das Rahmenwerk für das Modellrisikomanagement einer Bank deckt also genau die Systeme formal nicht ab, die sie am schnellsten einführt, und ein paralleles Rahmenwerk, das später abgeglichen werden soll, braucht einen Platz außerhalb des MRM-Tools und des GRC-Feststellungsprotokolls.
Der Rückstau an Anpassungen ist das deutlichste Indiz. Wenn das GRC-Team eigene Tabellen für Modelle, Agenten und Versionen anlegt, wird die Suite Änderungsantrag für Änderungsantrag zur KI-Governance-Plattform.
Eine Zertifizierung nach ISO/IEC 42001 steht an. ISO/IEC 42001:2023, veröffentlicht im Dezember 2023, „legt die Anforderungen für die Einrichtung, Umsetzung, Aufrechterhaltung und fortlaufende Verbesserung eines Managementsystems für Künstliche Intelligenz fest“. Prüfer erwarten Nachweise, dass es über einen längeren Zeitraum hinweg wirksam war, und zwar für jedes KI-System im Geltungsbereich.
Ist es ein Entweder-oder, oder speist die KI-Governance-Ebene das führende GRC-System?
Es ist kein Entweder-oder, und wer davon ausgeht, verliert auf beiden Seiten Abschlüsse. Das bewährte Muster ist ein geteilter Datenbestand. Die KI-Governance-Ebene enthält die Objekte, für die GRC nicht ausgelegt ist: Inventar, Metadaten zu Modellen und Agenten, Framework-Mapping, Nachweise pro System und die risikobasierte Einstufung bei der Erfassung. Die GRC-Suite bleibt das führende System für Unternehmensrisiken, Richtlinien, Feststellungen und Audit.
Datensatz | Gespeichert in | Wird an GRC übergeben als |
|---|---|---|
KI-System, Modell, Agent, Version | KI-Governance-Ebene | Referenz-ID am zugehörigen Risiko oder an der zugehörigen Feststellung |
Aufnahmeentscheidung und Freigabe | KI-Governance-Ebene | Aufgabe oder Freigabedatensatz im ITSM- oder GRC-Workflow |
Befund aus der Modellprüfung | KI-Governance-Ebene, an die Version gebunden | Feststellung mit Verantwortlichem und Fälligkeitsdatum |
KI-Restrisiko | KI-Governance-Ebene, pro System | Eintrag in der unternehmensweiten Risikotaxonomie |
Richtlinie und Bestätigung | GRC-Suite | Bleibt in GRC; die KI-Ebene verweist darauf |
Auditplan und Prüfungsdurchführung | GRC-Suite | Bleibt in GRC; ruft Nachweise pro System bei Bedarf ab |
Die Plattform von Enzai bietet Workflow-Übergaben an Jira und ServiceNow und überträgt Aufgaben und Freigaben aus dem Antragsprozess in die Systeme, die Ihre Teams bereits nutzen. Der Leitfaden zur gestuften Aufnahme beschreibt den Antrag als zentralen Eingang für Lieferantenrisiko, Beschaffung, Sicherheit und Datenschutz, sodass jede Funktion auf einen einzigen Datensatz zugreift, statt erneut nachzufragen.
Der EU AI Act zieht dieselbe Linie. Nach Artikel 17 Absatz 4 gilt für einen Anbieter, der ein Finanzinstitut ist und nach dem Finanzdienstleistungsrecht der Union Anforderungen an seine interne Governance unterliegt, die Pflicht zum Qualitätsmanagementsystem durch diese bestehende Governance als erfüllt, mit Ausnahme von drei Elementen: dem Risikomanagementsystem nach Artikel 9, der Beobachtung nach dem Inverkehrbringen nach Artikel 72 und der Meldung schwerwiegender Vorfälle nach Artikel 73. Die Verordnung geht also davon aus, dass das Governance-Rahmenwerk des Unternehmens bestehen bleibt und um die KI-spezifischen Bestandteile ergänzt wird.
Was, wenn statt einer Suite bisher Tabellenkalkulationen im Einsatz sind?
Bei Tabellenkalkulationen, wie sie bei Teams auf dem Weg zu ISO 42001 häufig vorkommen, liegt der Fall anders. Für die ersten zwanzig Systeme ist eine Tabelle ein brauchbares Inventar. Sie stößt an ihre Grenzen, wenn mehrere Personen sie bearbeiten, wenn Nachweise an eine Version gebunden werden müssen und wenn ein Prüfer fragt, wer eine Risikoeinstufung wann geändert hat. Ein Unternehmen ohne GRC-Suite sollte keine anschaffen, nur um KI-Governance umzusetzen: Die KI-Governance-Ebene ist die kleinere Investition, sie enthält die Dokumentation, die der Prüfer anfordern wird, und sie lässt sich an das bereits genutzte Ticketing-Tool anbinden. Ein Unternehmen mit Suite, das KI dennoch in Tabellen steuert, hat den geteilten Datenbestand ohne die Verbindung, und genau diese Verbindung herzustellen, ist das eigentliche Projekt.
Was das in der Praxis bedeutet
Die Abfolge ist dieselbe, egal wie die Entscheidung ausfällt.
Erfassen Sie die KI-Landschaft, bevor Sie entscheiden. Führen Sie eine Erkennung durch und halten Sie für jedes System Autonomiegrad, regulatorischen Geltungsbereich und Verantwortliche in einem Inventar fest. Anzahl und Zusammensetzung entscheiden die Frage.
Legen Sie die Aufteilung schriftlich fest. Entscheiden Sie, welche Objekte in der GRC-Suite liegen (Richtlinien, Unternehmensrisiken, Feststellungen, Audit) und welche in der KI-Ebene (Systeme, Modelle, Agenten, Versionen, Nachweise pro System), und veröffentlichen Sie diese Aufteilung, damit kein Team zwei Kopien pflegt.
Ordnen Sie jedes System jedem anwendbaren Regelwerk zu und halten Sie die sich verschiebenden Termine fest: 2. Dezember 2027 für Anhang III, 1. Januar 2027 für die Verbraucherrechte in Colorado, SR 26-2 für generative und agentische Systeme bei Banken. Ab einer Framework-Bibliothek mit framework-übergreifender Wiederverwendung von Nachweisen ist das keine Tabellenarbeit mehr.
Definieren Sie die Übergaben. Eine Freigabe wird zur Aufgabe im bestehenden Workflow, ein Befund zur Feststellung, ein Restrisiko fließt in die Taxonomie ein. Testen Sie die Übergabe an einem System, bevor Sie sie ausweiten; die Vergleiche mit ServiceNow und Collibra zeigen, was wo verbleibt.
Legen Sie Auslöser fest, bei denen die Entscheidung erneut geprüft wird: der erste Agent mit Schreibzugriff, das erste System nach Anhang III, die erste Abstimmung zum Geltungsbereich einer ISO-42001-Zertifizierung.
Enzai ist für die KI-spezifische Hälfte des geteilten Datenbestands entwickelt, einschließlich der Übergaben an die GRC- und ITSM-Tools, die Sie bereits einsetzen. Wenn Sie sehen möchten, wie automatisierte KI-Governance an eine bestehende Suite angebunden wird, sprechen Sie mit dem Enzai-Team.
Seit 2023 nach ISO 27001 zertifiziert, jährlich von NQA auditiert
An der DSGVO ausgerichtete Datenverarbeitung
Kundendaten auf AWS in mehreren Regionen gehostet
Eigenes KI-Modell über eine private Verbindung nutzen
Finden Sie die KI, die Ihre Teams nutzen, prüfen Sie sie vor der Einführung, bewerten Sie sie anhand der geltenden Vorschriften und kontrollieren Sie, was Agenten tun dürfen. Entwickelt für regulierte Organisationen.