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.

Kontrollwirksamkeit klingt nach etwas, das man „einfach messen“ müsste: Kontrolle definiert, Kontrolle durchgeführt, fertig. Viele Dashboards funktionieren genau nach dieser Logik. Sie zeigen Quoten: wie viele Kontrollen wurden ausgeführt, wie viele waren „ok“, wie viele Maßnahmen sind offen. Und trotzdem bleibt bei Führung und Prüfern oft ein ungutes Gefühl: Das sieht nach Aktivität aus, aber es sagt nicht zuverlässig, ob das Unternehmen tatsächlich stabiler und sicherer geworden ist. Genau hier biegen viele GRC-Dashboards falsch ab. Sie messen vor allem, dass etwas passiert – nicht, dass es wirkt.

Das ist kein akademischer Einwand. Es ist ein praktisches Problem, weil falsche Messlogik zu falscher Steuerung führt. Wenn Sie „Erfüllung“ reporten, optimieren Teams auf Erfüllung. Wenn Sie „Wirksamkeit“ reporten, optimieren Teams auf Wirksamkeit. Das klingt trivial, ist aber einer der größten Hebel in GRC. Denn Kennzahlen verändern Verhalten. Und wenn Kennzahlen das falsche Verhalten fördern, wird GRC mit jeder Ausbaustufe schwerer – ohne dass die Risikolage spürbar sinkt.

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?

NIS2 und ISO 27001 begegnen sich in vielen Unternehmen gerade auf eine Weise, die erst einmal „logisch“ wirkt – und dann erstaunlich schnell anstrengend wird: Man hat ein etabliertes ISMS, dazu ein Set an Kontrollen, Richtlinien und Nachweisen. Dann kommt NIS2, und plötzlich entstehen neue Listen, neue Workstreams, neue Maßnahmenpläne, neue Reportings. Alles mit gutem Grund. Und trotzdem bleibt bei vielen Teams am Ende ein Gefühl: Wir machen vieles doppelt, und trotzdem sind wir nicht sicher, ob es wirklich besser geworden ist.

Genau hier lohnt sich ein Perspektivwechsel. Denn NIS2 ist kein Ersatz für ISO 27001, aber es zwingt dazu, den Blick zu erweitern: weg von „Sicherheitsmanagement als System“ hin zu „Sicherheits- und Resilienzfähigkeit als Betriebsrealität“. ISO 27001 liefert Ihnen die Struktur, um Informationssicherheit systematisch zu managen. NIS2 setzt stärker auf die Frage, ob diese Struktur in der Praxis spürbar wirkt – besonders dort, wo es unangenehm wird: bei Incidents, bei Lieferkettenabhängigkeiten, bei Managementverantwortung, bei operativer Steuerung. Das ist keine Kritik an ISO 27001. Es ist eine Erinnerung daran, dass ein Managementsystem erst dann seine Stärke zeigt, wenn es den Betrieb stabilisiert, nicht nur Dokumente erzeugt.

Der Moment, in dem DORA plötzlich „real“ wird, ist selten das Kick-off, selten das erste Requirements-Dokument und auch nicht die hundertste Folie. Real wird DORA meistens dann, wenn jemand fragt: „Zeigen Sie mir das bitte.“ Nicht: „Erklären Sie mir, wie Sie es machen.“ Nicht: „Schicken Sie mir Ihr Konzept.“ Sondern: „Zeigen Sie mir konkret den Nachweis, dass es im Betrieb funktioniert.“

Genau hier trennt sich in der Praxis die Spreu vom Weizen. Viele Organisationen haben nach ein paar Monaten DORA-Projektlaufzeit sehr ordentliche Unterlagen: Policy-Stacks, Prozessbeschreibungen, Rollenmodelle, Gremienstrukturen, Kontrolldatenbanken. Und trotzdem entsteht im Audit Stress. Warum? Weil Prüfer nicht auf der Suche nach „viel Material“ sind, sondern nach einer belastbaren Spur: Entscheidung → Umsetzung → überprüfbarer Nachweis. Wenn diese Spur nicht klar und schnell auffindbar ist, wirkt selbst gute Arbeit plötzlich unfertig.