Vorstände lieben Ampeln. Rot, Gelb, Grün versprechen Ordnung in einer Welt, die selten geordnet ist. Chief Risk Officers lieben Heatmaps. Quadranten vermitteln das Gefühl, man habe Komplexität in den Griff bekommen. Compliance liebt PDF-Berichte. Viele Seiten geben den Eindruck von Vollständigkeit. Und doch passiert in unzähligen Unternehmen dasselbe Ritual: Die Präsentation läuft, die Ampeln leuchten, die Quadranten flimmern, die PDFs stapeln sich – und am Tag danach trifft die Organisation Entscheidungen anhand von Einzelmeinungen, E-Mail-Threads und Ad-hoc-Calls. Aus schönen Berichten wird selten Führung. Genau an dieser Bruchkante setzt der radikale Gedanke eines modernen GRC-Dashboards an: Transparenz ist kein dekoratives Element, sondern eine Führungsdisziplin. Sie wird nicht an Folien gemessen, sondern an der Fähigkeit, Handlungen auszulösen, die sich nachweisen lassen. Ein GRC-Dashboard, das diesen Namen verdient, ist nicht eine weitere Sicht auf Daten. Es ist ein Betriebsinstrument, das Governance, Risk und Compliance in den Takt der Organisation übersetzt.

Vom Bericht zum Betrieb: Was ein Dashboard heute leisten muss

Das klassische Verständnis sah im Dashboard eine Verdichtung. Zahlen aus Security, Datenschutz, Legal, Audit, Betrieb und Einkauf wurden gesammelt, grafisch aufbereitet und regelmäßig vorgelegt. Die Annahme dahinter: Wenn Entscheidungsträger die wichtigsten Informationen auf einen Blick vor sich sehen, treffen sie bessere Entscheidungen. Diese Annahme ist nicht völlig falsch – aber unvollständig. Ein Dashboard, das allein informiert, erzeugt häufig Unverbindlichkeit. Die Inhalte werden zur Kulisse; die eigentliche Arbeit verlagert sich zurück in die Linien, wo Stimmenstärke und Verfügbarkeit mehr zählen als Evidenz.

Einordnung zum Veröffentlichungszeitpunkt: Ein KI-Register sollte Einsatz, Verantwortlichkeiten und Risikoeinordnung getrennt von den jeweils maßgeblichen Anwendungsfristen führen. Änderungen am regulatorischen Fahrplan sind ein Anlass zur Überprüfung des Registers; sie ändern nicht automatisch den tatsächlichen Zweck eines Systems.

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.

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.

Einordnung zum Veröffentlichungszeitpunkt: Die Risikoeinordnung richtet sich nach Zweck und Einsatzkontext. Sie ist von der Frage zu trennen, wann eine konkrete Pflicht anwendbar wird. Ein gemeinsamer Stichtag für sämtliche KI-Systeme wäre deshalb keine tragfähige Planungsgrundlage.

Auf dem Papier wirkt die Risikologik des EU AI Act zunächst wie eine saubere Sortierung: Einordnen, Pflichten ableiten, fertig. In der Praxis ist genau dieser Schritt einer der größten Stolpersteine. Nicht, weil Teams das Thema „nicht verstehen“, sondern weil Klassifizierung im Alltag selten an einem klaren, stabilen Entscheidungsprozess hängt. Stattdessen passiert sie oft nebenbei: im Projekt, im Einkauf, in der IT, manchmal in der Fachabteilung – je nachdem, wer gerade am schnellsten ist. Das Ergebnis ist dann eine Mischung aus gut gemeinten Annahmen und unvollständigen Informationen. Und genau dort entstehen Fehlklassifizierungen.

NIS2 wird in vielen Unternehmen gerade mit hohem Tempo umgesetzt. Das ist verständlich: Die Erwartungshaltung ist groß, der Druck ist real, und niemand möchte in eine Situation kommen, in der man im Ernstfall oder in einer Prüfung erklären muss, warum etwas „noch nicht fertig“ ist. Genau hier entsteht aber ein typisches Nebenproblem, das ich in der Praxis immer wieder sehe: Nachweise werden zu früh als „Dokumentationsprojekt“ verstanden. Dann wächst die Menge an Artefakten schnell – aber die Prüfbarkeit wird nicht automatisch besser. Im Gegenteil: Wenn zu viele Dinge als Nachweis gelten sollen, wird es unklar, was wirklich zählt. Und Unklarheit ist im Audit der schnellste Weg zu Nachforderungen.

Dieser Artikel hilft Ihnen, die NIS2-Nachweispflichten pragmatisch zu sortieren. Nicht nach dem Motto „möglichst viel sammeln“, sondern nach dem Prinzip: Welche Artefakte belegen im Zweifel wirklich, dass Ihr Betrieb sicher und handlungsfähig ist? Und welche Artefakte sehen zwar ordentlich aus, bringen Ihnen aber wenig, weil sie weder Entscheidungen stützen noch die Umsetzung im Alltag nachvollziehbar machen?