Die meisten Organisationen machen denselben Fehler, wenn mehrere Regelwerke gleichzeitig relevant werden: Sie bauen drei Programme. DORA bekommt ein Projekt, NIS2 bekommt ein Projekt, der EU AI Act bekommt ein Projekt. Jedes Projekt erstellt Anforderungen, Maßnahmenlisten, Richtlinien, Reportings. Und jedes Projekt hat gute Gründe, weil jede Anforderung „irgendwie“ stimmt. Das Ergebnis ist trotzdem oft enttäuschend: viel Arbeit, viel Dokumentation, aber die Betriebsfähigkeit wird nicht proportional besser. Noch schlimmer: Teams beginnen zu „optimieren“, indem sie das jeweils nächste Audit bedienen, statt das System als Ganzes stabiler zu machen.

Die Abkürzungen sind unterschiedlich, aber die Realität dahinter ist erstaunlich ähnlich. Alle drei Rahmenwerke wollen im Kern, dass Sie Entscheidungen nicht dem Zufall überlassen. Sie wollen Verantwortlichkeiten, die im Alltag funktionieren. Sie wollen, dass Störungen beherrscht werden können. Sie wollen, dass kritische Abhängigkeiten gesteuert werden. Und sie wollen, dass Sie das belegen können – nicht durch schöne Texte, sondern durch eine nachvollziehbare Spur.

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.

AI Governance ist gerade dabei, zwei typische Extreme zu produzieren. Das erste Extrem ist „wir machen erst mal gar nichts, bis alles klar ist“. Das zweite Extrem ist „wir bauen sofort ein großes Programm, das alles abdeckt“. Beides führt in der Praxis selten zu einem stabilen Ergebnis. Das erste Extrem endet meistens in Schattennutzung und hektischer Nacharbeit. Das zweite endet oft in Überkomplexität, Widerstand und Workarounds. Die brauchbare Mitte ist unspektakulärer: Sie definieren ein Minimum, das sofort handlungsfähig macht – und ein Maximum, das sinnvoll ist, wenn Volumen, Kritikalität und externe Anforderungen steigen.

Der Trick dabei ist, AI Governance nicht als neues „Thema“ zu behandeln, sondern als Erweiterung dessen, was gute Organisationen ohnehin tun: Entscheidungen vorbereiten, Risiken steuern, Änderungen kontrollieren, Nachweise so ablegen, dass sie im Ernstfall und im Audit funktionieren. KI bringt dabei nur eine neue Dynamik hinein: Systeme verändern sich schneller (Modelle, Daten, Features), ihre Wirkung ist oft schwerer intuitiv einzuschätzen, und viele Bausteine liegen außerhalb Ihres direkten Einflusses (Cloud-Services, Anbieter, Modelle von Dritten). Genau deshalb braucht es eine Governance, die nicht nur „schön“ aussieht, sondern im Alltag belastbar ist.

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.

Warum ist das so kritisch? Weil die Risikoklasse im EU AI Act nicht nur ein Label ist. Sie steuert, wie streng Sie Anforderungen erfüllen müssen, welche Nachweise Sie brauchen, wie viel Governance-Takt sinnvoll ist – und welche Risiken Sie eingehen, wenn Sie zu locker oder zu streng einsortieren. Eine Fehlklassifizierung ist daher selten nur ein „Formfehler“. Sie führt typischerweise zu einem von zwei Problemen: Entweder Sie unterschätzen Pflichten und stehen später mit Lücken da. Oder Sie überziehen unnötig und bauen eine Governance, die Projekte bremst und dann umgangen wird. Beides ist gefährlich – nur auf unterschiedliche Weise.