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.

NIS2 bringt viele Organisationen dazu, Sicherheitsmaßnahmen zu „listen“: man schaut auf Kataloge, orientiert sich an Standards, erstellt Maßnahmenpläne. Das ist grundsätzlich sinnvoll. Die unangenehme Wahrheit ist aber: Nicht jede Maßnahme, die auf dem Papier gut aussieht, trägt im Ernstfall wirklich. Und umgekehrt sind es oft ein paar Basics, die darüber entscheiden, ob ein Vorfall kontrollierbar bleibt – oder ob er sich in Chaos, Stillstand und Nacharbeit übersetzt.

Wenn man über „Basics“ spricht, klingt das schnell nach Allgemeinplätzen. In der Praxis ist es deutlich konkreter. „Basics, die tragen“ sind Maßnahmen, die in kritischen Momenten zwei Dinge gleichzeitig ermöglichen: schnelle Entscheidungen und stabile Abläufe. Genau das erwartet NIS2 im Kern: nicht Perfektion, sondern Betriebsfähigkeit.

DORA-Gap-Analysen haben einen schlechten Ruf, und das nicht ganz zu Unrecht. Viele Organisationen starten mit guter Absicht und landen trotzdem in einem Zustand, der sich anfühlt wie „Workshop-Dauerbetrieb“: Anforderungen werden diskutiert, Interpretationen werden verglichen, Listen wachsen, offene Punkte werden in Maßnahmenpläne geschrieben – und nach einigen Wochen fragt jemand zu Recht: „Was haben wir jetzt eigentlich konkret gewonnen? Können wir irgendetwas belastbar zeigen, oder sind wir nur klüger geworden?“

Das Problem ist selten Fachwissen. Das Problem ist die Form. Eine Gap-Analyse, die nur auf Papier existiert, produziert zwar Erkenntnisse, aber keine Betriebsfähigkeit. DORA bewertet jedoch am Ende nicht Ihre Fähigkeit, Anforderungen zu erklären, sondern Ihre Fähigkeit, sie im Betrieb wiederholbar zu erfüllen – inklusive Nachweisen. Genau deshalb bleibt eine Gap-Analyse oft stecken, wenn sie als „Interpretationsprojekt“ geführt wird. Sie wird erst wirksam, wenn sie als Aufbau von prüfbaren Pfaden gestaltet wird: kritische Services, Entscheidungen, Prozesse, Evidenz. Das ist weniger diskutieren, mehr bauen.

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.

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.