GRC wird in vielen Organisationen immer noch wie ein Sammelbegriff behandelt: ein bisschen Risiko hier, ein paar Kontrollen dort, dazu Richtlinien, Audits und eine Handvoll Reports. Und dann – ganz am Ende – eine Excel, die alles „zusammenführt“. Das Problem daran ist nicht Excel. Das Problem ist die Erwartung, dass man Führung, Steuerung und Nachweisführung über Listen „nachrüsten“ kann, während der Betrieb längst mit eigener Logik läuft.

Wenn Sie GRC wirklich wirksam machen wollen, hilft ein anderes Bild: GRC als Betriebssystem. Nicht als Tool, nicht als Abteilung und nicht als Papierlage – sondern als die Logik, nach der Entscheidungen vorbereitet, umgesetzt und überprüfbar gemacht werden. Ein Betriebssystem ist unsichtbar, solange es funktioniert. Es macht Abläufe zuverlässig, reduziert Reibung und sorgt dafür, dass ein System unter Last stabil bleibt. Genau das ist auch die Aufgabe eines guten GRC-Ansatzes: Er muss das Unternehmen im Alltag stabiler machen – und nebenbei auditfest.

Ein KI-Register klingt zunächst wie ein Verwaltungsartefakt: eine Liste, ein Tool, ein paar Felder, fertig. Genau so werden viele Register auch gebaut – und genau deshalb funktionieren sie später weder im Audit noch im Betrieb. Denn ein Register, das nur „Daten sammelt“, wird schnell veraltet, erzeugt Diskussionen und wird umgangen. Ein Register, das dagegen Audit und Betrieb bedient, ist etwas anderes: Es ist die zentrale Steuerungsspur für Verantwortlichkeiten, Klassifizierung, Änderungen und Nachweise. Und es ist vor allem so gestaltet, dass es im Alltag genutzt wird, nicht nur im Prüfungsfall.

Der EU AI Act macht diese Doppelrolle wichtig, weil sich die Nachweiserwartung nicht auf „wir haben uns Gedanken gemacht“ beschränkt. Es geht um nachvollziehbare Entscheidungen: warum eine Anwendung so eingestuft wurde, welche Anforderungen daraus folgen, wie sie umgesetzt werden, wie Änderungen erkannt werden und wie man im Ereignisfall reagieren kann. Wenn Ihr Register diese Kette nicht abbildet, müssen Sie sie in PowerPoints, E-Mails und Einzeldokumenten nachbauen – und genau das ist der Moment, in dem das Thema kippt: zu viel Aufwand, zu wenig Klarheit.

Als über den EU AI Act gesprochen wird, landen die Gespräche oft sehr schnell bei Governance-Strukturen, Risikoklassen, Registern und internen Prüfprozessen. Das ist wichtig – aber es blendet eine Realität aus, die in vielen Unternehmen darüber entscheidet, ob AI-Compliance überhaupt kontrollierbar wird: Der größte Teil der KI, die heute genutzt wird, wird nicht „gebaut“, sondern eingekauft. Und genau deshalb ist Einkauf und Vendor Management die unterschätzte Frontlinie.

Das klingt zunächst nach Zuständigkeitsdebatte, ist aber in Wahrheit eine Steuerungsfrage. Denn wenn KI-Funktionen in Standardsoftware, Cloud-Services, Plattformen oder Dienstleisterleistungen stecken, dann entstehen Pflichten und Risiken dort, wo Sie als Kunde Einfluss nehmen können: in Beschaffung, Vertragsgestaltung, laufender Steuerung und Exit-/Fallback-Logik. Wenn diese Hebel nicht sauber gesetzt sind, kann die beste interne Governance im Alltag kaum greifen. Dann haben Sie vielleicht ein KI-Register – aber die wesentlichen Informationen fehlen. Oder Sie haben eine Klassifizierung – aber kein vertragliches Fundament, um Nachweise einzufordern. Oder Sie haben Regeln – aber keine Routine, um Änderungen des Anbieters rechtzeitig zu erkennen.

NIS2 wird in vielen Unternehmen zunächst als „Security-Thema“ einsortiert: IT und Informationssicherheit klären Maßnahmen, Compliance koordiniert, und irgendwann bekommt die Geschäftsleitung ein Update mit Ampeln. Das wirkt vertraut, weil viele Regulierungs- und Auditwellen so gelaufen sind. Der Unterschied bei NIS2 ist jedoch, dass sich die Erwartung an die Geschäftsleitung deutlich verändert – nicht nur als Empfänger von Berichten, sondern als sichtbarer Teil der Verantwortungskette. In der Praxis ist das weniger dramatisch, als es manchmal klingt, aber es ist konkreter: Es geht um Organisationsentscheidungen, um Priorisierung, um nachvollziehbare Steuerung – und darum, dass diese Steuerung im Ernstfall und in der Prüfung belegbar ist.

Genau hier entstehen typische Reibungen. Auf der einen Seite will die Geschäftsleitung keine zusätzlichen „Programme“, die den Betrieb lähmen. Auf der anderen Seite will sie nicht in einer Situation stehen, in der ein Vorfall eskaliert, die Aufsicht Fragen stellt oder ein Kunde Nachweise fordert – und man dann feststellt, dass vieles zwar „gemacht“ wurde, aber nicht sauber als Verantwortung, Entscheidung und Evidenz zusammenläuft. Das ist der eigentliche Kern: NIS2 verlangt nicht, dass Vorstände plötzlich technische Spezialisten werden. NIS2 verlangt, dass Verantwortung so organisiert ist, dass sie im Betrieb funktioniert und im Zweifel auch nachweisbar ist.

Policy-Sprawl ist eines dieser Probleme, die selten als „Problem“ gestartet sind. Es entsteht fast immer aus guten Gründen. Ein Audit bringt neue Anforderungen, ein Incident erzeugt Druck, ein neuer Dienstleister will klare Regeln, eine Revision fordert Nachweise, eine Aufsicht setzt Schwerpunkte, oder ein interner Standard soll harmonisiert werden. Also schreibt man eine Richtlinie. Und noch eine. Und irgendwann sind es nicht zehn, sondern vierzig, sechzig, achtzig. Das Ergebnis wirkt zunächst professionell – bis der Alltag zeigt, was sich heimlich aufgebaut hat: Niemand weiß mehr sicher, welche Regel in welchem Fall gilt, welche Version verbindlich ist, wo Ausnahmen stehen, welche Vorgaben sich widersprechen und welche davon wirklich gelebt werden. Im schlimmsten Fall entsteht eine Parallelrealität: Auf dem Papier ist alles geregelt, im Betrieb entscheidet Erfahrung, Gewohnheit und der schnellste Weg.

Das Gefährliche an Policy-Sprawl ist nicht die Anzahl der Dokumente. Das Gefährliche ist die verlorene Steuerbarkeit. Je mehr Richtlinien existieren, desto stärker steigt die Wahrscheinlichkeit, dass sie sich gegenseitig überlagern, dass Zuständigkeiten unklar werden und dass Teams anfangen, Richtlinien zu umgehen, weil sie zu schwer, zu unübersichtlich oder zu weit weg vom Betrieb sind. Dann kippt das Ganze in ein Muster, das man im Audit häufig sofort erkennt: Es gibt viele Dokumente, aber wenig belastbare Evidenz dafür, dass die Regeln im Alltag wirklich wirken. Und genau das ist der Punkt, an dem aus „guter Governance“ plötzlich „Dokumentationslast“ wird – ohne dass das Risiko sinkt.