GRC Tool: Was sich durch KI ändert

Auf einen Blick

• Ein GRC Tool ist das eine Verzeichnis, in dem Richtlinien, Risiken, Kontrollen, Pflichten und die Nachweise zusammenlaufen, die sie miteinander verbinden. Sein Wert liegt im Datenmodell, nicht im Dashboard.
• Verändert hat sich durch KI der Umfang dieses Modells: Die KI-Systeme, die ein Unternehmen entwickelt oder einkauft, bilden inzwischen eine eigene Klasse regulierter Vermögenswerte.
• Artikel 17 der KI-Verordnung führt zwölf Bestandteile auf, die das Qualitätsmanagementsystem eines Anbieters dokumentieren muss. Als Beschaffungsliste gelesen beschreibt diese Aufzählung, was ein GRC Tool vorhalten muss.
• Der Digital Omnibus hat die Frist für Hochrisikosysteme nach Anhang III auf den 2. Dezember 2027 verschoben. Verschoben wurde die Frist, nicht die Zeit, die der Aufbau einer belastbaren Nachweiskette braucht.
• Entscheidend ist nicht die Zahl der Module, sondern ob die Ergebnisse der Prüfung durch eine benannte Stelle oder eine Marktüberwachungsbehörde standhalten.

Was ein GRC Tool tatsächlich leistet

Ein GRC Tool ist das zentrale Verzeichnis, in dem die Richtlinien einer Organisation stehen, die Risiken, die sie akzeptiert oder abgelehnt hat, die Kontrollen, die diese Risiken behandeln, die Pflichten, auf die diese Kontrollen antworten, und die Nachweise, dass jede Kontrolle tatsächlich gewirkt hat. Die drei Buchstaben bezeichnen drei Disziplinen, die in unterschiedlichen Abteilungen entstanden sind. Das Werkzeug ist genau das, was sie in eine gemeinsame Struktur zwingt. Diese Struktur ist das eigentliche Produkt. Governance ohne Risikodaten ergibt Dokumente, die niemand liest. Risiko ohne Verknüpfung zu Kontrollen ergibt ein Register, das nie etwas verändert. Compliance ohne Nachweis bleibt eine Behauptung. Solange die drei Bereiche in getrennten Tabellen liegen, wird jede Prüfung zu einer Abstimmungsübung und jede Frage der Aufsicht zu einem Projekt. Teilen sie sich dagegen ein Datenmodell, lässt sich eine Frage wie „welche Kontrollen behandeln dieses Risiko, wer verantwortet sie, wann wurden sie zuletzt getestet und wo liegt der Nachweis“ in Minuten statt in Wochen beantworten. Das erklärt auch, warum sich die Kategorie einer einfachen Definition entzieht. Zwei Produkte können beide als GRC-Plattform auftreten und dennoch kaum Funktionen teilen, weil das eine um Richtlinienverteilung und Kenntnisnahme herum gebaut ist, das andere um Kontrolltests und Prüfungsabläufe. Die brauchbare Frage lautet deshalb nie, ob es sich um ein GRC Tool handelt, sondern was sein Datenmodell billig macht und was teuer.

Warum das Datenmodell wichtiger ist als das Dashboard

In Produktvorführungen stehen Dashboards im Vordergrund, weil sie sich gut vorführen lassen. Sie liegen jedoch am Ende der Kette. Eine Risikomatrix entsteht mühelos, sobald Risiken, Kontrollen und Testergebnisse korrekt verknüpft sind, und lässt sich redlich gar nicht erzeugen, wenn sie es nicht sind. Die Fragen, die eine Bewertung wirklich tragen, betreffen die Struktur. Kann eine einzelne Kontrolle mehrere Rahmenwerke zugleich bedienen, oder erzwingt das Werkzeug je Rahmenwerk eine Dublette? Lässt sich eine Pflicht bis zu dem konkreten Nachweis verfolgen, der sie erfüllt? Lässt sich ein Risiko an einen Vermögenswert hängen und nicht nur an einen Geschäftsprozess? Diese Antworten entscheiden darüber, ob das Werkzeug Arbeit verringert oder sie lediglich verlagert. Unser Leitfaden zur KI-Governance beschreibt das Betriebsmodell, das diese Struktur tragen muss.

Das OCEG-Fähigkeitsmodell und der tatsächliche Platz des Werkzeugs

Die meisten Darstellungen dieser Kategorie landen früher oder später beim GRC Capability Model der OCEG, veröffentlicht als Red Book. Es gliedert die Disziplin in vier Komponenten: Learn, Align, Perform und Review, zusammengefasst unter dem Begriff der Principled Performance. Learn bedeutet, Kontext, Kultur und Anspruchsgruppen zu verstehen. Align verbindet Ziele, Strategie und Risikobereitschaft. Perform umfasst die Ausführung der Kontrollen. Review misst, was tatsächlich gewirkt hat. Das Modell ist bei der OCEG erhältlich. Die ehrliche Lesart, die die meisten Darstellungen umgehen, lautet: Software instrumentiert Perform und Review gut und kann Align überhaupt nicht herstellen. Ein Werkzeug kann eine Erklärung zur Risikobereitschaft erfassen. Es kann nicht sagen, ob die Organisation diese Bereitschaft wirklich teilt oder ob die Geschäftsleitung sie unter kommerziellem Druck übergehen würde. Wer ein Werkzeug beschafft, bevor entschieden ist, was die Organisation tatsächlich zu akzeptieren bereit ist, erhält eine ausgesprochen gut dokumentierte Fassung eines ungelösten Streits. Bei KI wiegt diese Unterscheidung schwerer als früher bei Finanzkontrollen, weil Entscheidungen über KI sehr viel weiter unten in der Organisation fallen. Ein Produktverantwortlicher kann ein Modell an einem Nachmittag in einen kundennahen Ablauf einbauen. Hat Align nicht stattgefunden, protokolliert das Werkzeug die Folgen, statt die Entscheidungen zu prägen. Daraus erklärt sich auch die unscharfe Abgrenzung der Kategorie. Ein GRC Tool ist ein Baustein einer größeren Kontrollkette, zu der Identitätsverwaltung, Protokollierung, Modellregister und Sicherheitsüberwachung gehören, eine Aufteilung, die wir in unserer Analyse zur Compliance-Plattform gegenüber dem umgebenden Stack darlegen.

Was KI verändert: Das System wird zum regulierten Vermögenswert

Bis vor Kurzem umfasste ein GRC-Programm Prozesse, Lieferanten, Kontrollen und die Finanzberichterstattung. KI fügt etwas hinzu, wofür das Modell nicht gebaut war: einen Vermögenswert, der probabilistisch statt deterministisch arbeitet, der still an Güte verliert, sobald sich die Welt von seinen Trainingsdaten entfernt, und der je System statt je Prozess reguliert wird. Daraus folgen drei Dinge. Erstens wird das Inventar zur bindenden Beschränkung. Was man nicht kennt, lässt sich weder klassifizieren noch kontrollieren noch nachweisen, und die nicht angemeldete Nutzung ist der Normalfall und nicht die Ausnahme. Alles, was unsichtbar bleibt, liegt außerhalb sämtlicher geschriebener Kontrollen, was das praktische Problem hinter Shadow AI beschreibt. Zweitens wird die Klassifizierung zur Rechtshandlung und ist keine interne Bequemlichkeit mehr. Nach der KI-Verordnung entscheidet die Einordnung als verbotene Praktik, als Hochrisikosystem, als System mit bloßen Transparenzpflichten oder als praktisch unreguliertes System darüber, welche Pflichten greifen. Diese Einordnung muss festgehalten, begründet und bei jeder Änderung des Systems erneut geprüft werden. Drittens verliert das Risikoregister seinen periodischen Charakter. Eine jährlich getestete Kontrolle ist für einen Beschaffungsprozess eine vertretbare Antwort. Für ein Modell, dessen Verhalten sich nach einem unangekündigten Anbieter-Update verschieben kann, ist sie es nicht. Unser Leitfaden zum KI-Risikomanagement zeigt, was fortlaufend in der Praxis bedeutet.

Von KI-gestütztem GRC zu GRC über KI

Nahezu jedes Produkt dieses Marktes wirbt inzwischen mit KI-Funktionen: Richtlinien zusammenfassen, Kontrollbeschreibungen entwerfen, Risikobewertungen vorschlagen, Fragebögen vorsortieren. Ein Teil davon nimmt tatsächlich Arbeit ab. Es ist allerdings ein vollkommen anderes Thema als das, wonach Aufsichtsbehörden fragen. KI-gestütztes GRC bedeutet, dass der Anbieter ein Modell einsetzt, um seine eigene Software zu beschleunigen. GRC über KI bedeutet, dass Ihre Organisation die Beherrschung der von ihr betriebenen KI-Systeme belegen kann. Ein Werkzeug kann im ersten Punkt hervorragend und im zweiten nutzlos sein. Die gesamte Unterscheidung steckt in der Präposition, und es lohnt sich, im Anbietergespräch deutlich nachzufragen, was gerade vorgeführt wird. Hinzu kommt ein Punkt zweiter Ordnung. Wirkt ein Modell an der Erzeugung Ihrer Kontrollnachweise mit, fällt dieses Modell selbst in den Anwendungsbereich. Ein Nachweis aus einem nicht validierten System ist nicht belastbarer als das System, das ihn erzeugt hat.

Die KI-Verordnung schreibt das Lastenheft

Das Nützlichste an der KI-Verordnung ist für alle, die Werkzeuge bewerten, ihre ungewöhnliche Genauigkeit darin, was schriftlich vorliegen muss. Die Artikel 8 bis 15 legen die Anforderungen an Hochrisikosysteme fest: Risikomanagementsystem (Artikel 9), Daten und Daten-Governance (Artikel 10), technische Dokumentation (Artikel 11), Aufzeichnungspflichten (Artikel 12), Transparenz und Bereitstellung von Informationen (Artikel 13), menschliche Aufsicht (Artikel 14) sowie Genauigkeit, Robustheit und Cybersicherheit (Artikel 15). Artikel 16 zählt anschließend die Anbieterpflichten auf: diese Anforderungen erfüllen, sich auf dem System kenntlich machen, ein Qualitätsmanagementsystem betreiben, die Dokumentation aufbewahren, die automatisch erzeugten Protokolle aufbewahren, das Konformitätsbewertungsverfahren durchlaufen, eine EU-Konformitätserklärung ausstellen, die CE-Kennzeichnung anbringen, das System registrieren, Korrekturmaßnahmen ergreifen, mit den zuständigen nationalen Behörden zusammenarbeiten und die Barrierefreiheitsanforderungen einhalten. In Artikel 17 erscheint eine Beschaffungsliste beinahe wörtlich. Das Qualitätsmanagementsystem des Anbieters muss dokumentiert sein und mindestens enthalten: eine Strategie zur Einhaltung der Regulierung einschließlich der Konformitätsbewertungsverfahren; Techniken für Entwurf, Entwicklung und Qualitätskontrolle; Prüf- und Testverfahren; technische Spezifikationen; Systeme für das Datenmanagement; ein Risikomanagementsystem; ein System zur Beobachtung nach dem Inverkehrbringen nach Artikel 72; Verfahren zur Meldung schwerwiegender Vorfälle nach Artikel 73; ein Verfahren für die Kommunikation mit Behörden; ein System zur Aufbewahrung von Aufzeichnungen; Ressourcenmanagement; und einen Rechenschaftsrahmen, der die Verantwortlichkeiten von Leitung und Personal festlegt. Zwölf Bestandteile, von denen jeder irgendwo liegen und auf Anforderung vorgelegt werden muss. Das ist ein Lastenheft für ein Verzeichnis, gleichgültig ob es jemand so nennt. Artikel 9 gibt der Risikoarbeit ihre Form. Risikomanagement ist ein fortlaufender iterativer Prozess über den gesamten Lebenszyklus: Risiken für Gesundheit, Sicherheit und Grundrechte ermitteln und analysieren, im Betrieb auftretende Risiken bewerten, Risiken bewerten, die sich aus den Daten der Beobachtung nach dem Inverkehrbringen ergeben, und daraufhin geeignete Maßnahmen ergreifen. Auch die Ziele sind festgelegt: Risiken so weit wie technisch möglich beseitigen oder verringern, das Verbleibende mindern, die Transparenzinformationen bereitstellen und Betreiber erforderlichenfalls schulen. Risiko selbst ist als Kombination aus der Wahrscheinlichkeit eines Schadens und seiner Schwere definiert. Ein Detail entkräftet den üblichen Einwand, all dies betreffe nur große Häuser. Artikel 17 Absatz 2 verlangt, dass die Umsetzung des Qualitätsmanagementsystems der Größe der Anbieterorganisation angemessen ist, und Erwägungsgrund 146 sieht ausdrücklich eine vereinfachte Fassung für Kleinstunternehmen vor. Die Verhältnismäßigkeit betrifft den Umfang der Verfahren, nicht das Bestehen der Pflichten. Unsere Materialien zur KI-Verordnung behandeln die Einordnungsfragen im Einzelnen.

Die Frist verschob sich, die Aufbauzeit nicht

Der Zeitplan hat sich 2026 verschoben. Der Digital Omnibus zur KI verschob die Pflichten für eigenständige Hochrisikosysteme nach Anhang III auf den 2. Dezember 2027 und für KI, die in bereits vom EU-Produktsicherheitsrecht erfasste Produkte eingebettet ist, auf den 2. August 2028. Mehrere Daten blieben unverändert: Die Transparenz- und Kennzeichnungspflichten des Artikels 50 gelten seit dem 2. August 2026, die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck seit dem 2. August 2025 und die Verbote des Artikels 5 seit dem 2. Februar 2025. Die Analysen der Cloud Security Alliance und der Kanzlei Gibson Dunn stimmen in diesen Daten überein. Diese Verschiebung als Verschnaufpause zu lesen, ist aus einem sehr praktischen Grund ein Fehler. Beobachtung nach dem Inverkehrbringen und Aufzeichnungspflichten sind rückwärtsgerichtete Pflichten. Wenn eine Behörde 2028 fragt, wie sich ein System verhalten hat, entsteht die Antwort aus Protokollen, die erfasst werden mussten, während das System lief. Wer Ende 2027 mit der Erfassung beginnt, verfügt über ein konformes Managementsystem und über keine Historie, die sich hineinlegen ließe. Die Frist bezeichnet den Zeitpunkt, zu dem die Kette vorzeigbar sein muss, weshalb die Entscheidung zur Erfassung erheblich früher fällt.

ISO 42001 und NIST AI RMF: die Kontrollebene

Die Regulierung sagt, was gelten muss. Einen Kontrollsatz liefert sie nicht. Zwei Referenzen füllen diese Lücke, und jedes ernsthafte GRC Tool muss beide tragen, ohne die Arbeit zu verdoppeln. ISO/IEC 42001 spezifiziert ein KI-Managementsystem, aufgebaut wie andere Managementsystemnormen, und ist zertifizierbar. Das zählt kommerziell ebenso wie intern, denn ein Zertifikat ist ein übertragbarer Nachweis im Beschaffungsgespräch. Es deckt sich gut mit den Bestandteilen des Artikels 17, weshalb viele Anbieter es zum Rückgrat ihres Qualitätsmanagementsystems machen. Wir behandeln die Norm in ISO 42001 erklärt. Das NIST AI Risk Management Framework ist freiwillig und anders geschnitten: vier Funktionen, Govern, Map, Measure und Manage, die Teams ein gemeinsames Vokabular für KI-Risiken geben, ohne dass zuerst über Begriffe gestritten werden muss. Seine Stärke liegt in der analytischen Ordnung, seine Schwäche im Beweiswert bei einer Prüfung, also genau umgekehrt zu einer zertifizierbaren Norm. Unser Leitfaden zum NIST AI RMF geht die vier Funktionen durch. Die Folge für die Werkzeugwahl ist konkret. Die meisten Organisationen bedienen gleichzeitig eine Verordnung, eine zertifizierbare Norm und ein freiwilliges Rahmenwerk, häufig zusätzlich zu bestehenden Sicherheitszertifizierungen. Ein Werkzeug, das eine Kontrolle genau einem Rahmenwerk zuordnet, erzwingt die mehrfache Erhebung desselben Nachweises. Ein Werkzeug, das die Kontrolle einmal modelliert und auf mehrere Pflichten abbildet, macht aus einer Multiplikation eine Addition. Diese eine Frage trennt Werkzeuge, die mitwachsen, von solchen, die den Aufwand still verdreifachen.

Eine Fähigkeitsprüfliste für Werkzeuge im KI-Zeitalter

Das Folgende gehört bei der Bewertung eines GRC Tools auf den Prüfstand, jeweils mit der Pflicht, auf die eine Fähigkeit antwortet. Die Liste denkt bewusst in Fähigkeiten statt in Modulen, weil Modulnamen sich zwischen Produkten unterscheiden, Pflichten dagegen nicht.

Zwei Zeilen tragen in der Praxis das meiste Gewicht. Die automatische Protokollierung ist der Bruchpunkt von Werkzeugen, die für Prozess-Compliance gebaut wurden, weil sie auf periodische menschliche Bestätigungen ausgelegt sind und nicht auf maschinelle Ereignisströme. Bei den Lieferkettennachweisen stellen die meisten Organisationen fest, dass sie elementare Fragen zu einem Modell nicht beantworten können, das sie nicht selbst trainiert haben, also genau jene Lücke, die unsere Arbeit zur Prüfbarkeit behandelt.

Nachweise, die einer Prüfung standhalten

Die meisten Nachweisprobleme sind keine Lücken. Es sind Artefakte, die vorhanden sind und der Prüfung dennoch nicht standhalten, nach vier wiederkehrenden Fehlermustern. Unser Leitfaden zur Prüfung von KI-Systemen beschreibt, worauf Prüfer tatsächlich achten. Die Zeitlichkeit steht am Anfang. Ein Bildschirmfoto belegt, dass ein Zustand in dem Moment bestand, in dem jemand es aufnahm, nicht dass eine Kontrolle über einen Zeitraum gewirkt hat. Die Zuordnung folgt: Ein Export ohne Urheber, ohne Systemversion und ohne Zeitstempel lässt sich an nichts binden. Die Veränderbarkeit ist das dritte Muster, denn eine im Nachhinein editierbare Tabelle belegt deutlich weniger, als ihr Inhalt nahelegt. Die Rückverfolgbarkeit bildet das vierte und häufigste: Ein Artefakt, das sich nicht mit der konkreten Pflicht verbinden lässt, die es erfüllt, überlässt dem Prüfer das Raten, und Prüfer raten nicht zu Ihren Gunsten. Die Arbeiten des COSO zur internen Kontrolle über generative KI liefern hier eine übernehmenswerte Unterscheidung. Stützt sich die Leitung auf eine Modellausgabe als Bestandteil des Nachweises für eine Kontrolle, steigt der Maßstab, der an diesen Nachweis anzulegen ist. Eine Prüfung selbst nachzuvollziehen ist etwas anderes, als die Schlussfolgerung eines Modells zu übernehmen, und die Dokumentationslast unterscheidet sich entsprechend: Eingabeaufforderung, Konfiguration und Modellversion gehören dann zur Akte. Dieselbe Veröffentlichung macht einen verwandten Punkt, der Teams häufig überrascht, nämlich dass Modelle, Konfigurationen, Feinabstimmungsartefakte, Einbettungen und Suchindizes als Konfigurationselemente unter Zugriffskontrolle und Änderungsmanagement zu behandeln sind und nicht als Inhalt. Der praktische Test für jedes Werkzeug ist schnell gemacht. Nehmen Sie eine Kontrolle, gehen Sie zu der Pflicht, auf die sie antwortet, und von dort zu dem Artefakt, das ihr Wirken im vergangenen Quartal belegt. Braucht dieser Weg mehr als zwei Klicks, oder hängt ein Schritt am Gedächtnis einer Person, handelt es sich um einen Aktenschrank und nicht um ein Verzeichnis.

Kaufen, erweitern oder beides

Für die Beschaffung eines GRC Tools, das KI abdeckt, gibt es drei ehrliche Wege, und der richtige hängt vom Bestand ab. Eine vorhandene Plattform zu erweitern lohnt sich, wenn ein ausgereiftes Programm läuft, der Anbieter ein belastbares KI-Modul statt eines umbenannten Risikoregisters anbietet und die bestehende Kontrollbibliothek wirklich wiederverwendbar ist. Der Vorteil liegt in einem System und einem eingeübten Vorgehen. Das Risiko liegt in einem Modul, das KI-Systeme als gewöhnliche Vermögenswerte modelliert und damit an Klassifizierung, Protokollierung und Modellherkunft scheitert. Ein eigenes System für KI-Governance lohnt sich, wenn KI im Produkt zentral ist, wenn die Pflichten so spezifisch sind, dass generische Kontrollstrukturen nicht passen, oder wenn nichts Ausgereiftes zum Erweitern vorhanden ist. Der Vorteil liegt in einem Datenmodell, das für das Problem gebaut wurde. Der Preis ist ein zweites System samt Integrationsarbeit, die niemand gern übernimmt. Der Mischweg ist das häufigste und am wenigsten besprochene Ergebnis. Die bestehende Plattform bleibt das Unternehmensverzeichnis, während ein spezialisiertes System die KI-spezifischen Pflichten führt und einen verdichteten Stand nach oben meldet. Das funktioniert, wenn die Grenze bewusst gezogen wird, und erzeugt zwei konkurrierende Register, wenn sie es nicht wird. Welchen Weg Sie auch wählen, ziehen Sie diese Grenze vor dem Anbietergespräch und nicht währenddessen. Unsere Seite zur KI-Compliance-Software beschreibt unseren Zugang zum spezialisierten Teil.

Häufige Fragen

Was ist ein Beispiel für ein GRC Tool? Die Kategorie umfasst mehrere Produktzuschnitte. Unternehmensweite GRC-Plattformen bündeln Risikoregister, Kontrolltests und Prüfungsabläufe für große regulierte Häuser. Werkzeuge zur Compliance-Automatisierung konzentrieren sich auf die fortlaufende Nachweiserhebung entlang von Sicherheitszertifizierungen. Systeme für das Richtlinienmanagement decken Erstellung, Verteilung und Kenntnisnahme ab. Eigenständige Systeme für KI-Governance modellieren KI-Systeme, ihre Einordnung und ihre Pflichten. Die meisten Organisationen betreiben mehrere davon, weshalb der sinnvolle Vergleich lautet, welches System das Verzeichnis führt und welche es speisen. Ist GRC dasselbe wie IT-Revision? Nein, auch wenn beides oft verwechselt wird, weil es dieselben Kontrollen betrachtet. GRC ist die fortlaufende Betriebsdisziplin: Richtlinien setzen, das Risikoregister pflegen, Kontrollen ausführen und laufend Nachweise sammeln. Die IT-Revision ist eine periodische unabhängige Beurteilung, ob diese Disziplin funktioniert. Ein gut geführtes GRC-Programm verbilligt Prüfungen, weil die Nachweise bereits strukturiert vorliegen. Prüfungsfeststellungen fließen anschließend in das Risikoregister zurück. Das Verhältnis ist zyklisch, die Rollen bleiben jedoch bewusst getrennt, und der Grund dafür ist die Unabhängigkeit. Ist Jira ein GRC Tool? Für sich genommen nicht. Jira verfolgt Aufgaben, und ein großer Teil der GRC-Arbeit besteht aus Aufgaben: Maßnahmen zur Behebung, Kontrolltests, Nachweisanforderungen. Viele Teams wickeln ihre Compliance-Tätigkeit zunächst darüber ab. Was fehlt, ist das darunterliegende Datenmodell, also eigenständige Objekte für Risiken, Kontrollen, Pflichten und Nachweise samt ihren Beziehungen. Vorgänge mit Etiketten nähern das an, bis ein Prüfer fragt, welche Kontrollen ein bestimmtes Risiko behandeln und wo der Nachweis liegt. Jira funktioniert gut neben einem Verzeichnis und schlecht als eines. Setzt GRC Programmierkenntnisse voraus? Für die tägliche Arbeit in der Regel nicht. Heutige Werkzeuge werden über Oberflächen konfiguriert, und die anspruchsvollen Teile der Aufgabe sind analytisch statt technisch: Systeme richtig einordnen, wirklich prüfbare Kontrollen formulieren, entscheiden, was als ausreichender Nachweis gilt. Programmierung wird an den Rändern relevant, vor allem bei Integrationen, die Nachweise automatisch aus Cloud-Plattformen, Modellregistern oder Protokollsystemen ziehen. Diese Automatisierung macht fortlaufende Überwachung überhaupt erst skalierbar, weshalb technische Kompetenz im Team auch dort ein praktischer Vorteil ist, wo sie nicht verlangt wird. Was ist besser, SOC oder GRC? Beide beantworten verschiedene Fragen und sind keine Alternativen. Ein Security Operations Center erkennt Bedrohungen nahezu in Echtzeit und reagiert darauf. GRC legt fest, was beherrscht werden soll, warum, und ob die Kontrollen über einen Zeitraum gewirkt haben. Ein SOC erzeugt Nachweise und Vorfälle, die ein GRC-Programm verarbeitet, und ein GRC-Programm setzt die Richtlinien und die Risikobereitschaft, innerhalb derer ein SOC arbeitet. Wer beides als konkurrierende Budgetposten behandelt, endet mit einer Erkennung, die niemand einer Pflicht zugeordnet hat, oder mit Pflichten, die nichts überwacht. Decken GRC-Werkzeuge die KI-Verordnung ab? Zunehmend behaupten sie es, und diese Behauptungen gehören geprüft. Lassen Sie sich ein Inventar der KI-Systeme mit systembezogener Einordnung und festgehaltener Begründung zeigen, Nachweise, die an konkrete Artikel geknüpft sind statt an eine allgemeine Kontrollfamilie, aufbewahrte Maschinenprotokolle statt menschlicher Bestätigungen und eine Vorfallbearbeitung, die an der regulatorischen Frist ausgerichtet ist. Viele Produkte erfüllen den ersten Punkt und straucheln beim Rest. Ein Anbieter, der diese Abdeckung behauptet, sollte ein System von der Registrierung bis zu einer für einen Prüfer lesbaren Aktenmappe durchspielen können.

Fazit

Die Kategorie hat ihren Namen nicht geändert. Geändert hat sich ihr Umfang. Ein GRC Tool wurde daran gemessen, wie gut es Prozesse, Lieferanten und Finanzkontrollen führt; gemessen wird es nun daran, ob es zusätzlich ein KI-System als eigenständiges Governance-Objekt behandeln kann, mit Einordnung, Kontrollsatz, Protokollkette und Verantwortlichem. Die Regulierung hat die Anforderungen ungewöhnlich gut lesbar gemacht. Artikel 17 listet auf, was dokumentiert sein muss, Artikel 12 verlangt die Protokolle, Artikel 72 setzt die Beobachtung nach dem Einsatz fort, und die verschobenen Fristen bedeuten, dass die Nachweiskette lange vor dem Datum beginnen muss, an dem gemessen wird. Bewerten Sie entsprechend: nicht nach der Zahl der Module, sondern danach, ob der Weg von der Pflicht über die Kontrolle zum datierten Artefakt trägt, wenn jemand mit Befugnis ihn abschreitet. Wenn Sie diese Bewertung gezielt für KI-Systeme führen, ist unsere KI-Compliance-Plattform genau um die oben beschriebenen artikelbezogenen Pflichten herum gebaut.