KI-Governance-Roadmap für den CISO

Problem in der Praxis

In den meisten Organisationen ist KI schneller im Einsatz als in der Governance angekommen. Fachbereiche nutzen generative Assistenten, in Produkte werden Modelle eingebettet, Dienstleister liefern KI-gestützte Funktionen mit. Niemand kann zuverlässig sagen, wie viele KI-Anwendungen es gibt, wer sie verantwortet, welche Daten sie verarbeiten und welche rechtliche Rolle die eigene Organisation jeweils einnimmt.

Ohne dieses Bild ist jede Risikoeinstufung Spekulation. Es lässt sich weder beurteilen, ob ein Anwendungsfall in eine regulierte Kategorie fällt, noch welche Nachweise später verlangt werden. Wenn dann ein Kunde, eine Aufsicht oder ein Auditor nach Belegen fragt, beginnt die hektische Suche. Ein zweiter Stolperstein ist die Fixierung auf Termine: Organisationen richten Programme an einzelnen Stichtagen aus, die sich verschieben können, und verpassen darüber den eigentlichen Aufbau der Steuerungsfähigkeit.

CISO-Einordnung

Eine tragfähige Roadmap beantwortet nicht die Frage "Welche Norm müssen wir erfüllen?", sondern eine Kette von Steuerungsfragen:

• Welche KI-Anwendungsfälle existieren tatsächlich, und wer ist je Fall verantwortlich?
• In welcher Rolle handelt die Organisation je Fall (etwa als Anbieter oder als Betreiber)?
• Welche Anwendungsfälle fallen voraussichtlich in eine regulierte Risikokategorie?
• Welche Pflichten und Nachweise ergeben sich daraus, und wer erbringt sie im Betrieb?
• Wie wird Wirksamkeit überprüft, und wann entscheidet das Management über Restrisiken?

Diese Fragen sind bewusst generisch. Sie ersetzen keine Rechtsprüfung und keine Normanforderung, sondern beschreiben die Managementlogik, die eine KI-Governance betreibbar macht. Der AI Act liefert das verbindliche "Was", ein AIMS nach ISO/IEC 42001 das organisatorische "Wie" der nachweisbaren Steuerung, und das NIST AI RMF mit den Funktionen Govern, Map, Measure und Manage eine frei nutzbare Methodik für Inventarisierung, Risikoarbeit und Wirksamkeitsmessung.

Umsetzungsperspektive

Die Roadmap lässt sich als vier aufeinander aufbauende Etappen denken, die alle in den ISMS-Regelkreis münden.

Etappe eins ist das KI-Inventar mit Use-Case-Register. Jeder Anwendungsfall wird mit Zweck, Verantwortlichem, Datenarten, eingesetzten Modellen oder Diensten, Lieferanten und vor allem der eigenen Rolle erfasst. Die Rollenfrage bestimmt die Pflichtenzuordnung, weil sich Anbieter- und Betreiberpflichten deutlich unterscheiden. Das Register sollte als lebende Liste betrieben werden, nicht als einmalige Erhebung. Methodisch entspricht dies der Map-Funktion des NIST AI RMF.

Etappe zwei ist die Risikoklassifizierung entlang des risikobasierten Ansatzes des AI Act. Dieser kennt vier Stufen: verbotene Praktiken mit unannehmbarem Risiko (Artikel 5), Hochrisiko-KI (Artikel 6 mit den Anhängen III und I), Universalmodelle (GPAI, Kapitel V, mit Sonderregime bei systemischem Risiko) sowie Anwendungen mit begrenztem Risiko und Transparenzpflichten (Artikel 50). Wegen des Marktortprinzips kann der AI Act auch greifen, wenn der KI-Output in der EU genutzt wird. Für eine verbindliche Einstufung sind die Originalanhänge heranzuziehen; die interne Einstufung dient der Priorisierung.

Etappe drei ist der Aufbau des AIMS in Struktur nach ISO/IEC 42001. Die Norm folgt der Harmonized Structure (Klauseln 4 bis 10, PDCA-Logik) wie ISO/IEC 27001 und ist damit in ein bestehendes ISMS integrierbar. Sie sieht eine risikobasierte Auswahl von Maßnahmen mit einer Anwendbarkeitserklärung sowie ein Impact Assessment für Auswirkungen auf Personen vor. Konkrete Maßnahmenkataloge werden hier bewusst nicht wiedergegeben, sie sind der Originalnorm zu entnehmen.

Etappe vier sind Kontrollen und Nachweise. Aus den AI-Act-Anbieterpflichten für Hochrisiko-KI lassen sich wiederkehrende Nachweisarten ableiten: Risikomanagement über den Lebenszyklus, Daten-Governance, technische Dokumentation, automatische Protokollierung, menschliche Aufsicht sowie Genauigkeit, Robustheit und Cybersicherheit (Artikel 15). Gerade Artikel 15 ist der Anknüpfungspunkt zur klassischen Informationssicherheit und damit zu vorhandenen ISMS-Controls. Hinzu kommen Betreiberpflichten (Artikel 26), gegebenenfalls eine Grundrechte-Folgenabschätzung (Artikel 27) und die KI-Kompetenz des Personals (AI Literacy, Artikel 4).

Typische Fehler

1. Die Roadmap startet mit Dokumenten und Tools, bevor überhaupt ein Inventar existiert.
2. Die rechtliche Rolle je Anwendungsfall (Anbieter oder Betreiber) wird nicht geklärt, wodurch Pflichten falsch zugeordnet werden.
3. Das Programm wird an einzelnen Stichtagen ausgerichtet, die sich verschieben können, statt an der Steuerungsfähigkeit.
4. KI-Governance wird parallel zum ISMS aufgebaut, mit doppelten Registern und Prozessen.
5. Eine ISO/IEC-42001-Zertifizierung wird fälschlich als automatische AI-Act-Konformität verstanden.

Risiken und Trade-offs

Ein zu schlankes Vorgehen übersieht regulierte Anwendungsfälle oder unterschätzt deren Nachweistiefe. Ein zu schweres Vorgehen überfordert die Organisation und verliert Akzeptanz, bevor Wirksamkeit entsteht. Gefragt ist eine angemessene, risikobasierte Steuerung.

Ein zweiter Trade-off betrifft die Geschwindigkeit. Bindet man jede KI-Nutzung sofort an strenge Kontrollen, bremst das Innovation und treibt Schatten-KI. Verzichtet man auf Steuerung, wächst das Haftungs- und Sanktionsrisiko. Der AI Act sieht abgestufte Bußgelder vor, bei verbotenen Praktiken bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes, bei sonstigen Verstößen geringere Rahmen.

Ein dritter Punkt ist die Planungsunsicherheit bei Fristen. Wer Investitionen ausschließlich auf ein vermutetes Verschiebungsdatum stützt, geht ein Risiko ein, solange der finale Rechtstext nicht veröffentlicht ist.

Entscheidungspunkte

• Welcher Scope der KI-Governance ist fachlich sinnvoll und organisatorisch betreibbar?
• Wird das AIMS in das bestehende ISMS integriert oder separat geführt?
• Welche Risikoschwelle löst welche Tiefe an Kontrollen und Nachweisen aus?
• Welche Anwendungsfälle werden vorrangig behandelt, weil sie potenziell hochrisikobehaftet sind?
• Wird eine ISO/IEC-42001-Zertifizierung angestrebt, und welchen Zweck soll sie erfüllen?
• Wie wird mit unsicheren AI-Act-Fristen geplant, ohne sich auf ein einzelnes Datum zu verlassen?

Praktische Empfehlungen

1. Beginnen Sie mit dem KI-Inventar und Use-Case-Register, bevor Sie Maßnahmen definieren.
2. Klären Sie je Anwendungsfall die rechtliche Rolle, da sie die Pflichten bestimmt.
3. Nutzen Sie eine gemeinsame Risikoeinstufung statt getrennter Register für Recht, Managementsystem und Methodik.
4. Setzen Sie das AIMS auf der vorhandenen ISMS-Infrastruktur auf und verbinden Sie Artikel 15 mit Ihren Informationssicherheits-Controls.
5. Machen Sie Nachweise zum Nebenprodukt laufender Prozesse und legen Sie eine feste Review-Taktung fest.
6. Führen Sie einen Fristenkalender mit Quellenvorbehalt und prüfen Sie volatile Termine regelmäßig gegen den finalen Rechtstext.

Relevante Normreferenzen

• EU AI Act (Verordnung (EU) 2024/1689): Referenz für den risikobasierten Ansatz, Anbieter- und Betreiberpflichten, Transparenz und Sanktionen. Frei zugänglich und zitierbar (EUR-Lex).
• NIST AI RMF (AI 100-1, AI 600-1): Referenz für eine freiwillige Methodik (Govern, Map, Measure, Manage). Public Domain.
• ISO/IEC 42001:2023: Referenz für die Struktur eines KI-Managementsystems (AIMS). Lizenziert, nur als Strukturbezug.
• ISO/IEC 27001:2022: Referenz für das ISMS-Fundament, in das ein AIMS integriert werden kann. Lizenziert, nur als Strukturbezug.