AI-Act-Gap-Analyse: Vom Inventar zum Maßnahmenplan

Die meisten Unternehmen, die sich ernsthaft mit der EU-KI-Verordnung (VO (EU) 2024/1689) befassen, kommen bis zum Inventar. Sie erfassen ihre KI-Systeme, tragen Verantwortliche ein, ordnen grob Risikoklassen zu — und bleiben dann stehen. Die Liste existiert, aber sie sagt niemandem, was zu tun ist. Der Schritt vom Inventar zur Gap-Analyse ist der Punkt, an dem KI-Governance von einer Dokumentationsübung zu einer Steuerungsaufgabe wird. Er ist auch der Punkt, an dem die meisten Programme unnötig viel Zeit verlieren.

Bis zum Enforcement-Datum 02.12.2027 bleibt Zeit — aber weniger, als die Kalenderrechnung suggeriert. Konformitätsbewertungen, Normenreife und Lieferantenverhandlungen laufen nicht parallelisierbar. Wer erst 2027 vom Inventar in die Analyse geht, hat die Puffer bereits verbraucht.

Was eine Gap-Analyse von einer Checkliste unterscheidet

Eine Checkliste fragt: Haben wir Dokument X? Eine Gap-Analyse fragt: Welche Pflicht trifft dieses konkrete System, welchen Nachweis verlangt sie, welchen Nachweis können wir heute erbringen — und wie groß ist die Lücke dazwischen?

Der Unterschied ist nicht semantisch. Die Verordnung knüpft Pflichten nicht an Unternehmen, sondern an die Kombination aus Rolle und Risikoklasse eines einzelnen Systems. Dasselbe Unternehmen kann für ein zugekauftes Bewerber-Screening Betreiber (Deployer) sein, für ein selbst entwickeltes Prognosemodell Anbieter (Provider) — und für ein drittes System, das es unter eigenem Namen weitervertreibt, nach Art. 25 vom Betreiber zum Anbieter werden. Eine Gap-Analyse, die auf Unternehmensebene ansetzt, produziert deshalb zwangsläufig falsche Ergebnisse.

Die belastbare Analyseeinheit ist das einzelne KI-System in seinem konkreten Verwendungszweck. Erst auf dieser Ebene lässt sich Art. 6 sinnvoll anwenden — die Klassifizierungsregel, die über Anhang I (Produktsicherheitsrecht) und Anhang III (die acht Hochrisiko-Bereiche) entscheidet, ob ein System überhaupt in den Hochrisiko-Pflichtenkreis fällt.

Die drei Spalten, die jede Zeile braucht

Eine Gap-Analyse, die im Audit standhält, hat pro System und Pflicht drei Spalten. Sie klingen banal, werden aber selten sauber getrennt.

Erstens: die Pflicht. Nicht als Schlagwort ("Risikomanagement"), sondern als konkrete Norm mit konkretem Adressaten. Art. 9 verlangt vom Anbieter ein über den gesamten Lebenszyklus fortlaufendes Risikomanagementsystem. Art. 10 verlangt Governance über Trainings-, Validierungs- und Testdaten. Art. 11 verlangt technische Dokumentation nach Anhang IV. Art. 12 verlangt automatische Protokollierung. Art. 26 verlangt vom Betreiber unter anderem den bestimmungsgemäßen Betrieb, geeignete menschliche Aufsicht und die Aufbewahrung der automatisch erzeugten Protokolle. Wer die Pflichtenspalte unpräzise füllt, kann die Lückenspalte nicht präzise füllen.

Zweitens: der vorhandene Nachweis. Hier gehört nicht hin, was theoretisch existiert, sondern was benannt, auffindbar und einem Zeitpunkt zuordenbar ist: welches Dokument, welche Version, wer hat es freigegeben, wann zuletzt geprüft. Ein Modell-Steckbrief ohne Freigabestand ist kein Nachweis. Eine Log-Datei ohne definierte Aufbewahrung ist kein Nachweis. Die Praxis zeigt: In diesem Feld schrumpfen die vermeintlich guten Reifegrade am schnellsten.

Drittens: die Lücke mit Aufwandsschätzung. Eine Lücke ist entweder inhaltlich (die Anforderung wird nicht erfüllt), formal (sie wird erfüllt, ist aber nicht nachweisbar dokumentiert) oder organisatorisch (niemand ist zuständig). Diese drei Lückentypen haben völlig unterschiedliche Behebungskosten — formale Lücken sind meist in Wochen zu schließen, organisatorische brauchen Entscheidungen, inhaltliche brauchen Entwicklungskapazität.

Priorisierung: nicht alphabetisch, sondern nach Exposure

Aus der Gap-Liste wird ein Maßnahmenplan, indem drei Faktoren übereinandergelegt werden: die Schwere der Rechtsfolge, die Nähe zur Marktbereitstellung und die Behebungsdauer.

Verbotene Praktiken nach Art. 5 stehen immer oben — hier ist die Rechtsfolge kein Nachbesserungsauftrag, sondern die Unzulässigkeit des Einsatzes, sanktionsseitig in Art. 99 mit dem höchsten Bußgeldrahmen hinterlegt. Danach folgen Hochrisiko-Systeme, die vor dem Stichtag neu in Betrieb oder auf den Markt gehen sollen: Sie brauchen die vollständige Kette aus technischer Dokumentation, Konformitätsbewertung, Konformitätserklärung und Registrierung, und diese Kette hat externe Abhängigkeiten, die nicht beschleunigbar sind.

Erst danach kommen Bestandssysteme und die Transparenzpflichten nach Art. 50. Und quer über alles liegt Art. 4 — die KI-Kompetenz der eigenen Belegschaft, die keine Konformitätsbewertung braucht, aber Vorlaufzeit.

Ein häufiger Fehler: Programme priorisieren nach Sichtbarkeit statt nach Exposure. Das prominente Kundenchat-Projekt bekommt Ressourcen, während ein unauffälliges Scoring-Modell im Personalbereich unbearbeitet bleibt — obwohl es nach Anhang III Nr. 4 klar im Hochrisikobereich liegt.

Der Übergang in einen dauerhaften Zustand

Eine Gap-Analyse ist eine Momentaufnahme, und Momentaufnahmen veralten. Modelle werden nachtrainiert, Verwendungszwecke verschieben sich, Anbieter ändern ihre Systeme. Genau deshalb ist die Gap-Analyse kein Projektartefakt, sondern der erste Messpunkt eines Managementsystems.

Hier setzt ISO/IEC 42001 an: Das AI Management System (AIMS) beschreibt genau den Regelkreis, den eine einmalige Analyse nicht leisten kann — Kontext, Ziele, Maßnahmen, Wirksamkeitsprüfung, Verbesserung. Kombiniert mit einem Reifegradmodell nach CMMI v3 wird aus der Frage "haben wir die Lücke geschlossen?" die belastbarere Frage: "Ist der Prozess, der diese Lücke schließt, wiederholbar, gesteuert und gemessen?" Diese AIMS-Reifegradsicht ist der Unterschied zwischen einem Ordner voller Dokumente und einer Organisation, die ihren eigenen Zustand kennt.

Für Teams, die die Analyse nicht auf leerem Blatt beginnen wollen, sind strukturierte Vorlagen und Prüfraster ein sinnvoller Startpunkt — eine Sammlung dazu findet sich unter ki-hochrisiko.de.

Was am Ende zählt

Der Wert einer Gap-Analyse bemisst sich nicht an ihrer Länge, sondern daran, ob sie eine Frage beantwortbar macht: Können wir für jedes KI-System zu jedem Zeitpunkt zeigen, welche Pflicht gilt, wer sie trägt und welcher Nachweis sie belegt? Wer diese Frage mit Verweis auf konkrete, versionierte, zuordenbare Artefakte beantworten kann, ist vorbereitet. Wer sie mit Verweis auf Absichten beantwortet, hat eine Liste, keine Nachweisfähigkeit.

Der Unterschied wird nicht am 02.12.2027 sichtbar, sondern beim ersten Auskunftsersuchen einer Marktüberwachungsbehörde — und das kann früher kommen.

Mehr dazu, wie Nachweisführung entlang des KI-Lebenszyklus als belastbare Evidenzbasis statt als Dokumentensammlung aufgebaut wird: aegira.ai.