In vielen Organisationen existieren inzwischen zwei Listen derselben KI-Systeme. Die eine steht im Projektportfolio, gepflegt von denen, die die Vorhaben priorisieren und finanzieren. Die andere entsteht im Governance-Bereich, gepflegt von denen, die sie nachweisen müssen. Beide beschreiben dasselbe – und nach einem Quartal stimmen sie nicht mehr überein.
Niemand hat entschieden, zwei Listen zu führen. Sie entstehen, weil zwei Bereiche verschiedene Fragen beantworten müssen.
Das PMO fragt: Was machen wir, warum, mit welchen Mitteln, in welcher Reihenfolge? Daraus wird ein Portfolio mit Initiativen, Verantwortlichen, Budgets, Stage Gates und Berichtsterminen. Compliance und Risiko fragen: Welche Systeme betreiben wir, in welcher Risikoklasse, mit welchen Nachweisen? Daraus wird ein Register – meist in einem GRC-Werkzeug, oft in einer Tabelle.
Der EU AI Act verlangt kein organisationsweites KI-Inventar in der Form, wie es viele Unternehmen heute aufbauen. Er verlangt je nach System und Rolle Klassifizierung, Risikomanagement, Dokumentation, menschliche Aufsicht, Transparenz und weitere Nachweise. Praktisch lassen sich diese Pflichten kaum zuverlässig erfüllen, ohne zu wissen, welche KI-Systeme eine Organisation überhaupt einsetzt.
Also führt fast jede Organisation ein Inventar – auch die, die es nicht so nennt. Und weil die Pflichten dort ankommen, wo Compliance sitzt, entsteht es dort. Nicht dort, wo dieselben Systeme längst stehen.
Seit dem 27. Juli 2026 ist die Digital-Omnibus-Verordnung zur Künstlichen Intelligenz in Kraft (Verordnung (EU) 2026/1744). Sie verschiebt die Anwendung der einschlägigen Vorschriften für Hochrisiko-Systeme nach Anhang III um 16 Monate auf den 2. Dezember 2027 und für Hochrisiko-Systeme nach Anhang I auf den 2. August 2028.
In vielen Portfolios ist das Thema damit nach hinten gerutscht – nachvollziehbar. Nur verschiebt die Verordnung die Frist, nicht die Systeme. Die KI-Vorhaben, die in diesen 16 Monaten entstehen, entstehen trotzdem – und sie entstehen nun in einem Zeitraum, in dem niemand einen äußeren Anlass hat, ihre Einstufung festzuhalten.
Wer Ende 2027 Nachweise braucht, muss deshalb nicht weniger rekonstruieren, sondern mehr. Die Verschiebung ist die Gelegenheit, ein Inventar aufzubauen, solange es klein ist. Verstanden wird sie meist als Gelegenheit, es später zu tun.
Der Schaden zeigt sich selten sofort, sondern erst, wenn jemand eine Frage stellt, die beide Listen betrifft.
Der Zweck driftet. Ein System, das als Assistenzfunktion startete, entscheidet ein Jahr später mit. Im Portfolio steht das im Statusbericht, im Register die ursprüngliche Einstufung.
Die Begründung fehlt. Warum ein System als geringes Risiko eingestuft wurde, wussten drei Leute im Projekt. Zwei davon sind inzwischen woanders.
Die Nachweise werden rekonstruiert – nicht aus Dokumenten, sondern aus Erinnerungen von Menschen, die nicht dabei waren.
Die Geschäftsleitung bekommt zwei Antworten. Eine aus dem Portfoliobericht, eine aus dem Compliance-Bericht. Beide plausibel, beide unterschiedlich.
Das ist kein Compliance-Problem. Es ist ein Steuerungsproblem, das sich als Compliance-Problem bemerkbar macht.
Die Informationen, die für eine regulatorische Einordnung und Risikoklassifizierung benötigt werden, sind großenteils Informationen, die ein Portfolio ohnehin führt: Was tut das System? Wer ist betroffen? Welche Entscheidung wird beeinflusst? Wie viel menschliche Kontrolle liegt dazwischen? Wer verantwortet es? In welchem Land wird es eingesetzt?
Wer diese Fragen für die Priorisierung ohnehin beantwortet, hat den größeren Teil der Einstufung bereits geleistet. Führt man beides in einem Objekt, altert sie nicht separat – sie bewegt sich mit, wenn sich das Vorhaben ändert.
Gegen diese Zusammenführung spricht mehr, als ihre Befürworter zugeben.
Ein Portfoliomodell, das zusätzlich regulatorische Zustände pro System tragen muss, wird schwerer. Portfolios leiden selten an zu wenigen Attributen. Jedes Feld, das jemand pflegen muss, ist ein Feld, das jemand vergisst – und ein halb gepflegtes Inventar ist gefährlicher als gar keines, weil es Sicherheit vortäuscht.
Dazu kommen unterschiedliche Takte. Ein Portfolio atmet im Quartal, Governance im Ereignis: Ein Modell wird ausgetauscht, ein Anbieter ändert die Nutzungsbedingungen. Auch die Adressaten sind verschieden – ein Steuerungsgremium will Entscheidungen, eine Prüfung will Belege. Wer beides in dieselbe Ansicht presst, bedient am Ende keinen von beiden.
Der stärkste Einwand ist der grundsätzliche: Ein Portfolio ist kein Compliance-System und sollte keines werden. Wo Nachweispflicht das Steuerungsinstrument dominiert, wird aus einem Werkzeug für Entscheidungen eines für Absicherung.
Ob am Ende ein System oder zwei stehen, ist zweitrangig. Vorher ist etwas anderes zu klären: Wer verantwortet die Einstufung eines KI-Vorhabens – und zu welchem Zeitpunkt?
Drei Fragen bringen das in einer Sitzung an die Oberfläche:
Wenn heute ein neues KI-Vorhaben startet: An welcher Stelle im Prozess wird es klassifiziert, und wer tut es?
Wenn sich der Zweck eines laufenden Systems ändert: Wer erfährt davon, und über welchen Weg?
Wenn eine Prüfung morgen nach der Begründung einer Einstufung fragt: Wo liegt sie, und ist sie älter als das System?
Wo diese Fragen keine Antwort haben, ist die Werkzeugdiskussion verfrüht.
Die Klassifizierung an ein Gate hängen, nicht an einen Stichtag. Ein Vorhaben, das ein Gate passiert, wird eingestuft – und die Einstufung bei jedem weiteren Gate überprüft.
Die Begründung mit der Einstufung speichern, nicht nur das Ergebnis. Eine Risikoklasse ohne Herleitung ist bei der ersten Rückfrage wertlos.
Eine Person je System benennen, die den Zweck verantwortet. Nicht die Technik – den Zweck. Er ist es, der driftet.
Änderungen des Zwecks wie Änderungen des Umfangs behandeln. Sie gehen durch dieselbe Instanz und lösen dieselbe Prüfung aus.
Keiner dieser Punkte setzt eine bestimmte Software voraus. Sie funktionieren mit zwei Listen genauso – nur muss dann jemand dafür sorgen, dass die zweite von der ersten erfährt.
Die Frage ist nicht, welches Werkzeug das KI-Inventar hält. Die Frage ist, ob die Einstufung eines Systems dort entsteht, wo über das System entschieden wird – oder erst danach, an anderer Stelle, aus zweiter Hand.
Für PMOs ist das eine unbequeme Gelegenheit. Sie führen bereits den Prozess, in dem KI-Vorhaben entstehen, bewertet und freigegeben werden – und sind damit die naheliegende Instanz für eine Aufgabe, die ihnen bisher niemand gegeben hat. Ob sie sie annehmen, ist eine Entscheidung – keine Konsequenz aus der Regulierung.
Keine Kommentare
Volkmar Ritter ist Inhaber von BICon | Business & IT Consulting in Vaduz, Liechtenstein. Nach drei Jahrzehnten in der Business- und IT-Beratung entwickelt er heute Software für die Steuerung von KI-, Digital- und Transformationsportfolios. Er ist damit in diesem Feld Anbieter – die hier vertretene Position ist entsprechend nicht neutral.
volkmar.ritter@bicon.digital
Kommentare