AI-Act-Readiness-Check: KI-Inventar, Risikoklasse und Nachweise

Fachbeitrag von BlackMount

Fachredaktion BlackMountFachlich verantwortet von Jannik Christ · Geschäftsführer & Senior-Berater

Praxisorientierte Einordnung zu AI-Act-Readiness-Check: KI-Inventar, Risikoklasse und Nachweise: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für EU AI Act aufbauen.

AI-Act-Readiness-Check: KI-Inventar, Risikoklasse und Nachweise – Fachbeitrag von BlackMount

Ein AI-Act-Readiness-Check soll nicht vorschnell bestätigen, dass ein Unternehmen „compliant“ ist. Sein Wert liegt darin, unbekannte KI-Nutzung sichtbar zu machen, Rollen und Risikoklassen nachvollziehbar einzuordnen und fehlende Nachweise früh zu identifizieren. Das Ergebnis ist eine priorisierte Entscheidungsgrundlage: Welche Systeme dürfen unverändert weiterlaufen, wo sind zusätzliche Kontrollen nötig und welcher Einsatz muss eingeschränkt oder gestoppt werden?

Die Prüfung verbindet rechtliche Klassifizierung mit Informationssicherheit und betrieblicher Realität. Sie beginnt nicht bei einem abstrakten Fragenkatalog, sondern bei konkreten Anwendungen, Datenflüssen und Geschäftsentscheidungen. Gerade bei eingekauften Cloudfunktionen oder generativer KI liegt die Herausforderung häufig darin, dass Fachbereich, Einkauf und IT jeweils nur einen Teil des Systems kennen.

Was am Ende des Readiness-Checks vorliegen sollte

Der Check liefert ein belastbares KI-Inventar, eine dokumentierte Rollen- und Risikoklassifizierung, ein Sollprofil je Systemklasse, eine bewertete Nachweislage und eine priorisierte Roadmap. Für kritische Anwendungen kommen Systemsteckbrief, Datenfluss, verantwortliche Personen, offene Lieferantenfragen und Sofortmaßnahmen hinzu. Jede Bewertung verweist auf die zugrunde gelegten Tatsachen und bleibt dadurch überprüfbar.

Eine Ampel allein genügt nicht. „Gelb“ erklärt weder das Risiko noch die erforderliche Entscheidung. Jede Lücke wird deshalb mit betroffener Anforderung, möglichem Schadensszenario, vorhandenen Kontrollen, fehlendem Nachweis, Verantwortlichem und Zieltermin beschrieben. So kann das Management Ressourcen zuweisen und bewusst mit Restrisiken umgehen.

Den organisatorischen Geltungsbereich festlegen

Vor der Erhebung wird geklärt, welche Gesellschaften, Standorte, Produkte und internen Funktionen einbezogen sind. Ein zu enger Scope übersieht oft zentrale Plattformen oder konzernweit beschaffte Dienste; ein unbegrenzter Scope produziert dagegen eine lange Liste ohne ausreichende Tiefe. Zweckmäßig ist ein risikobasierter Start mit produktiven Systemen und Bereichen, die Personen, Sicherheit oder kritische Leistungen betreffen.

Der Scope muss auch Schattennutzung berücksichtigen. Beschäftigte verwenden öffentliche Chatbots, Browsererweiterungen, Übersetzungsdienste oder KI-Funktionen bestehender SaaS-Produkte, ohne dass ein separates Beschaffungsprojekt existiert. Deshalb werden technische Signale, Vertragsdaten, Befragungen und Prozessworkshops kombiniert. Eine reine Abfrage bei der IT-Abteilung bleibt systematisch unvollständig.

Ein gemeinsames Verständnis von „KI-System“ schaffen

Teams erfassen entweder zu viel oder zu wenig, wenn sie keine einheitlichen Kriterien besitzen. Der AI Act definiert ein KI-System anhand maschinengestützter Arbeitsweise, unterschiedlicher Autonomie, möglicher Anpassungsfähigkeit und der Ableitung von Ausgaben aus Eingaben für explizite oder implizite Ziele. Nicht jede klassische Regelautomatisierung fällt darunter, während KI-Funktionen in scheinbar gewöhnlicher Software leicht übersehen werden.

Für den Readiness-Check erhalten Mitarbeitende verständliche Beispiele und einen Eskalationsweg für Grenzfälle. Die Inventarliste kann Kandidaten zunächst mit einem Prüfstatus aufnehmen. Erst eine fachlich-juristische Bewertung entscheidet, ob der Eintrag im regulatorischen KI-Inventar verbleibt. Dadurch wird Unsicherheit sichtbar, ohne jede kleine Automatisierung vorschnell als KI zu behandeln.

Vier Suchwege für ein vollständigeres KI-Inventar

Der erste Suchweg führt über Geschäftsprozesse: Wo werden Inhalte erzeugt, Prognosen erstellt, Personen bewertet oder Entscheidungen automatisiert? Der zweite nutzt Technikdaten wie Single-Sign-on-Katalog, Cloudzugriffe, API-Gateways, Softwareinventar und ausgehende Verbindungen. Der dritte betrachtet Verträge, Rechnungen und Datenschutzprüfungen. Der vierte besteht aus strukturierten Interviews mit Fachbereichen und Entwicklungsteams.

Die Quellen werden gegeneinander abgeglichen. Eine Rechnung kann einen KI-Dienst zeigen, der technisch nicht zentral integriert ist; ein API-Schlüssel kann auf einen Prototyp ohne Vertrag hinweisen; ein Fachbereich nennt möglicherweise eine Funktion, die vom Hersteller inzwischen automatisch aktiviert wurde. Widersprüche sind keine Störung, sondern ein Hinweis auf fehlende Governance.

Der Mindestdatensatz pro KI-Anwendung

Jeder Eintrag benötigt einen eindeutigen Namen, fachlichen Zweck, Prozess, Eigentümer, Nutzerkreis, Betriebsstatus und Anbieter. Hinzu kommen verwendetes Modell, Hosting, Ein- und Ausgabedaten, betroffene Personen, Schnittstellen, Grad der Automatisierung, menschliche Kontrolle, erlaubte und ausgeschlossene Nutzungen sowie bekannte Unterauftragnehmer. Eine separate Kennzeichnung zeigt, welche Angaben verifiziert und welche nur angenommen wurden.

Für Änderungen werden Modellversion, Konfiguration, Systemprompt, Datenquellen, Werkzeugzugriffe und Freigabestand erfasst. Das Inventar muss bei einer veröffentlichten Schwachstelle oder einem Lieferantenvorfall schnell beantworten können, welche Anwendungen betroffen sind. Deshalb sind Modell- und Dienstabhängigkeiten als strukturierte Felder wertvoller als lange Freitexte.

Geschäftswirkung ergänzend zur Rechtsklasse bewerten

Ein gesetzlich nicht als Hochrisiko eingestuftes System kann für ein Unternehmen dennoch kritisch sein. Der Check bewertet daher mögliche Folgen für Sicherheit, Vertraulichkeit, Lieferfähigkeit, Finanzen, Reputation und betroffene Personen. Auch die Umkehrbarkeit einer Entscheidung und die Möglichkeit menschlicher Korrektur beeinflussen die Priorität.

Ein Textassistent für Marketingentwürfe besitzt meist ein anderes Schadenspotenzial als ein Agent, der eigenständig Zahlungen auslöst. Ein internes Analysemodell kann regulatorisch unauffällig sein, aber Geschäftsgeheimnisse verarbeiten. Die getrennten Achsen „AI-Act-Klasse“ und „interne Kritikalität“ verhindern, dass Schutzmaßnahmen nur an der gesetzlichen Kategorie ausgerichtet werden.

Die Betreiber- oder Anbieterrolle begründen

Die Rollenprüfung fragt, wer das System entwickelt, unter welchem Namen es bereitgestellt wird, wer seinen vorgesehenen Zweck festlegt und ob eine wesentliche Änderung erfolgt. Ein Unternehmen ist nicht automatisch nur Betreiber, weil es ein Basismodell einkauft. Wird daraus eine eigene Kundenlösung mit eigenem Zweck, können Anbieterpflichten für das fertige KI-System entstehen.

Die Begründung sollte auf Vertrag, technische Ausgestaltung, Markenauftritt und tatsächliche Nutzung verweisen. Mehrere Rollen können in einer Lieferkette nebeneinander bestehen. Bei geplanten Änderungen definiert der Eintrag konkrete Trigger für eine Neubewertung, etwa neue Zielgruppe, neuer Zweck, zusätzliche autonome Aktionen oder Austausch des Modells.

Verbotene Praktiken als Gate prüfen

Die Ausschlussprüfung steht vor der detaillierten Priorisierung. Sie untersucht unter anderem manipulative oder täuschende Techniken, Ausnutzung bestimmter Schutzbedürftigkeiten, gesetzlich erfasste Formen sozialen Bewertens und einzelne biometrische Anwendungen. Weil die genaue Beurteilung stark vom Kontext abhängt, werden Beschreibung, Zielgruppe, beabsichtigte Wirkung und tatsächliche Funktionsweise dokumentiert.

Ein möglicher Treffer führt nicht zu einer improvisierten Fachbereichsentscheidung. Legal, Datenschutz und Governance bewerten ihn gemeinsam; bis zur Klärung wird die Einführung ausgesetzt oder der Funktionsumfang begrenzt. Das Protokoll hält auch negative Ergebnisse fest, damit später nachvollziehbar bleibt, warum eine Praxis nicht als verboten eingestuft wurde.

Hochrisiko nach Artikel 6 und den Anhängen prüfen

Die Prüfung folgt zwei Pfaden. Der erste betrifft KI als Sicherheitskomponente eines in Anhang I erfassten Produkts oder als entsprechendes Produkt, wenn eine Konformitätsbewertung durch Dritte erforderlich ist. Der zweite betrifft die in Anhang III beschriebenen sensiblen Einsatzbereiche, beispielsweise bestimmte Anwendungen in Beschäftigung, Bildung, kritischer Infrastruktur oder beim Zugang zu wesentlichen Diensten.

Begriffe werden nicht nur nach dem Projektnamen bewertet. Entscheidend sind vorgesehener Zweck, konkrete Funktion und Einfluss auf Entscheidungen. Für Anhang-III-Fälle wird außerdem eine mögliche Ausnahme nach Artikel 6 geprüft und begründet. Die im Jahr 2026 veröffentlichten Kommissionsleitlinien und Beispiele helfen bei der Auslegung, ersetzen aber keine Prüfung des konkreten Systems.

Transparenzpflichten gesondert erfassen

Bestimmte Systeme müssen Menschen darüber informieren, dass sie mit KI interagieren; synthetische oder manipulierte Inhalte können Kennzeichnungs- und Maschinenlesbarkeitsanforderungen auslösen. Diese Pflichten sind nicht identisch mit der Hochrisikoklassifizierung. Ein Chatbot kann daher Transparenzmaßnahmen benötigen, obwohl er kein Hochrisiko-System ist.

Der Check betrachtet Nutzeroberfläche, Ausgabekanal und nachgelagerte Weiterverwendung. Eine Kennzeichnung im Administrationshandbuch erreicht keine betroffene Person. Außerdem wird geprüft, ob technische Markierungen bei Export, Bearbeitung oder Veröffentlichung erhalten bleiben. Verantwortlichkeit und Testnachweis gehören in das Systemprofil.

General-Purpose-AI-Abhängigkeiten sichtbar machen

Bei Anwendungen auf Basis allgemeiner Modelle wird zwischen dem Modellanbieter und dem Anbieter beziehungsweise Betreiber des konkreten Systems unterschieden. Benötigte Informationen umfassen Modellbezeichnung, Version, Leistungsgrenzen, zulässige Nutzung, Trainings- und Urheberrechtsangaben, Sicherheitsinformationen und Änderungsmechanismen. Fehlen sie, kann die nachgelagerte Organisation ihre eigene Dokumentation nur eingeschränkt erstellen.

Das Inventar bildet daher nicht nur die direkte Software, sondern die Modellkette ab. Ein SaaS-Produkt kann ein Modell eines weiteren Unternehmens über eine Cloudplattform nutzen. Diese Abhängigkeit ist für Schwachstellen, Verfügbarkeit, Datenregion und Modellwechsel relevant. Einkauf und Systemverantwortliche erhalten offene Informationsanforderungen mit Frist und Eskalation.

Nachweise für Hochrisiko-Anbieter bewerten

Bei einer Anbieterrolle prüft der Readiness-Check insbesondere Qualitäts- und Risikomanagement, Daten-Governance, technische Dokumentation, Aufzeichnungsfunktionen, Gebrauchsanweisung, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersicherheit, Konformitätsbewertung, Registrierung und Beobachtung nach dem Inverkehrbringen. Nicht jedes Element muss ein separates Dokument sein.

Wichtig ist eine geschlossene Nachweiskette vom Risiko zur Kontrolle und vom Test zur Freigabe. Ein Bedrohungsmodell ohne umgesetzte Maßnahme genügt ebenso wenig wie ein Testergebnis ohne definierte Akzeptanzschwelle. Stichproben verfolgen ausgewählte Anforderungen bis zu Code, Konfiguration, Protokoll oder Entscheidung und zeigen dadurch, ob das Managementsystem tatsächlich wirkt.

Nachweise für Hochrisiko-Betreiber bewerten

Bei Betreibern stehen ordnungsgemäße Nutzung, technische und organisatorische Maßnahmen, menschliche Aufsicht, Qualität kontrollierter Eingabedaten, Monitoring und Aufbewahrung relevanter Protokolle im Mittelpunkt. Je nach Organisation und Einsatz kommen Information von Beschäftigten oder Betroffenen, Registrierung und eine Grundrechte-Folgenabschätzung hinzu.

Der Prüfer beobachtet den realen Fachprozess. Kann die aufsichtführende Person eine Ausgabe verwerfen? Erkennt sie typische Grenzen? Wird bei einem auffälligen Ergebnis tatsächlich eskaliert? Sind Vertretung und Ersatzverfahren vorhanden? Interviews, Systemdemonstration und Fallstichprobe sind aussagekräftiger als eine unterschriebene Rollenbeschreibung.

Informationssicherheit entlang des Lebenszyklus prüfen

Die Sicherheitsanalyse deckt Planung, Datenbeschaffung, Entwicklung, Test, Bereitstellung, Betrieb, Änderung und Außerbetriebnahme ab. Sie untersucht Identitäten, Berechtigungen, Geheimnisse, Mandantentrennung, Datenflüsse, Protokollierung, Schwachstellenmanagement, sichere Schnittstellen und Wiederherstellung. Hinzu kommen KI-spezifische Angriffe auf Daten, Modelle, Prompts und angebundene Werkzeuge.

Kontrollen werden anhand realistischer Szenarien getestet. Ein generativer Assistent muss beispielsweise mit indirekter Prompt Injection in hochgeladenen Dokumenten umgehen; ein Prognosemodell benötigt Schutz vor unbemerkter Datenvergiftung; ein Agent darf keine privilegierte Aktion nur aufgrund einer Modellausgabe ausführen. Die erwartete sichere Reaktion wird vorab festgelegt.

Daten- und Modellherkunft nachvollziehen

Die Bewertung fragt, aus welchen Quellen Trainings-, Validierungs-, Test- und Retrieval-Daten stammen, welche Rechte bestehen und wie Qualität sowie Integrität geschützt werden. Versionen müssen reproduzierbar sein. Bei externen Modellen wird dokumentiert, welche Herkunftsinformationen der Anbieter liefert und wo bewusste Unsicherheit verbleibt.

Für operative Systeme gehören Aktualisierungsfrequenz, Verantwortlicher, Löschregeln und Freigabeverfahren hinzu. Eine Datenquelle kann rechtmäßig und qualitativ geeignet sein, aber durch zu weit gefasste Berechtigungen vertrauliche Informationen offenlegen. Datenschutz, Fachqualität und Informationssicherheit werden deshalb in einem gemeinsamen Datenblatt betrachtet.

Menschliche Aufsicht praktisch erproben

Die bloße Anwesenheit eines Menschen macht einen Prozess nicht kontrolliert. Die Person benötigt Kompetenz, verständliche Informationen, ausreichende Zeit, Autorität und eine echte Möglichkeit zum Eingreifen. Automation Bias ist besonders wahrscheinlich, wenn das System zuverlässig wirkt, Entscheidungen in hoher Zahl produziert oder Widerspruch zusätzlichen Aufwand verursacht.

Der Readiness-Check nutzt konkrete Testfälle mit plausiblen, aber falschen Ausgaben. Beobachtet wird, ob die Person Zweifel erkennt, Zusatzinformationen anfordert, die Entscheidung stoppt und den Fall meldet. Erkenntnisse fließen in Oberflächengestaltung, Arbeitslast, Schulung und Eskalationsregeln ein. So wird Aufsicht messbar statt symbolisch.

Änderungsmanagement als häufigste Nachweislücke

Cloudmodelle, Datenbestände und Systemprompts ändern sich schneller als klassische Unternehmenssoftware. Der Check untersucht, welche Änderungen der Anbieter ankündigt, wer sie bewertet und wann Regressionstests erforderlich sind. Ohne Baseline lässt sich später nicht erklären, warum sich Verhalten oder Risikoprofil verändert hat.

Wesentliche Änderungen können Rolle oder Konformitätsbewertung beeinflussen. Deshalb enthält das Verfahren fachliche und technische Trigger: neuer Zweck, andere betroffene Personengruppe, zusätzliche Datenklasse, neues Modell, autonome Werkzeugnutzung oder erhebliche Leistungsänderung. Notfalländerungen werden nachträglich kontrolliert und dürfen nicht dauerhaft außerhalb der Governance bleiben.

Findings nach Entscheidung statt Formalie priorisieren

Eine Lücke erhält Priorität anhand gesetzlicher Dringlichkeit, möglichem Schaden, Exposition, Kontrollschwäche und Abhängigkeiten. Ein verbotenes oder unkontrolliert entscheidendes System verlangt sofortige Behandlung. Eine unvollständige Formatierung in einer vorhandenen Systemakte kann trotz formaler Relevanz später folgen.

Jedes Finding beschreibt eine konkrete Zielwirkung. „Richtlinie erstellen“ ist kein ausreichendes Ergebnis; besser lautet es: Öffentliche KI-Dienste verarbeiten keine vertraulichen Daten, weil zentrale Zugänge, technische Sperren, genehmigte Alternativen und Stichproben wirksam sind. Diese Formulierung ermöglicht Abnahme und spätere Wirksamkeitsprüfung.

Sofortmaßnahmen für die ersten dreißig Tage

Typische Sofortmaßnahmen sind Benennung einer verantwortlichen Stelle, zentraler Meldekanal für KI-Anwendungen, klare Nutzungsregeln, Sperrung unzulässiger öffentlicher Konten, Aktivierung zentraler Identitäten und Sicherung kritischer Protokolle. Laufende sensible Einsätze erhalten eine vorläufige Risikoprüfung und gegebenenfalls Funktionsbegrenzung.

Parallel werden offene Lieferanteninformationen angefordert und die wichtigsten Schattenanwendungen verifiziert. Der Zweck ist nicht, Innovation pauschal zu stoppen. Stattdessen schafft das Unternehmen sichere, genehmigte Alternativen und einen schnellen Intake. Verbote ohne praktikablen Ersatz treiben Nutzung häufig weiter in unsichtbare Kanäle.

Roadmap für drei bis zwölf Monate

Mittelfristig werden Inventar und Beschaffung verbunden, Rollen- und Klassifizierungsentscheidungen standardisiert, Kontrollprofile aufgebaut und kritische Systeme technisch getestet. Anbieter eigener Lösungen integrieren Nachweise in ihren Entwicklungslebenszyklus. Betreiber verankern Aufsicht, Monitoring und Incident-Abläufe in den jeweiligen Fachprozessen.

Die Roadmap berücksichtigt die gestaffelten Anwendungstermine des AI Act, priorisiert aber auch bereits geltendes Datenschutz-, Sicherheits- und Arbeitsrecht. Abhängigkeiten zu ISO 27001, Datenschutzfolgenabschätzung oder Lieferantenmanagement werden bewusst genutzt. Eine zentrale Steuerung verhindert, dass dieselbe Anwendung in mehreren Programmen widersprüchlich bewertet wird.

Beispiel für eine belastbare Inventarzeile

Ein Kundenservice-Assistent beantwortet Fragen auf Basis interner Produktunterlagen. Er nutzt ein externes Sprachmodell, wird von Beschäftigten bedient und sendet keine Antwort automatisch. Der Systemsteckbrief nennt Zweck, erlaubte Daten, Modellversion, Wissensquellen, Besitzer, Aufsicht, Schnittstellen, Protokolle und verbotene Aktionen. Die AI-Act-Prüfung ergibt keine Hochrisiko-Einstufung, aber eine Transparenz- und Datenschutzprüfung bleibt erforderlich.

Intern wird das System wegen möglicher Offenlegung vertraulicher Produktdaten als erhöht kritisch eingestuft. Vor Freigabe sind Berechtigungsprüfung, Prompt-Injection-Test, Quellenanzeige und ein Verfahren für fehlerhafte Antworten nachzuweisen. Ein Modellwechsel löst Regressionstests aus. Die Zeile verbindet damit regulatorische Einordnung, technische Realität und konkrete Entscheidung.

Qualitätskriterien für den Readiness-Bericht

Ein guter Bericht trennt bestätigte Tatsachen, Annahmen und offene Punkte. Er nennt die verwendete Fassung von Gesetz und Leitlinien, weil sich Auslegung und Zeitplan entwickeln können. Stichproben und Interviews sind dokumentiert; Bewertung und Empfehlung lassen sich vom Einzelsystem bis zur Quelle zurückverfolgen.

Außerdem zeigt der Bericht Grenzen der Prüfung. Ein kurzer Readiness-Check ist keine Konformitätsbewertung und keine Rechtsgarantie. Er kann jedoch früh sichtbar machen, ob Grundlagen fehlen und welche vertiefte Prüfung erforderlich ist. Diese Ehrlichkeit verhindert falsche Sicherheit und ermöglicht einen realistischen Ressourcenplan.

Fazit: Erst Transparenz, dann belastbare Priorität

AI-Act-Readiness entsteht nicht durch einen universellen Fragebogen. Sie entsteht, wenn tatsächliche Anwendungen gefunden, Zwecke und Rollen begründet, gesetzliche Klasse sowie Geschäftskritikalität getrennt bewertet und Nachweise stichprobenartig geprüft werden. Der Check muss Entscheidungen ermöglichen und direkt in Beschaffung, Entwicklung und Betrieb münden.

BlackMount unterstützt bei AI-Act-Readiness-Checks und sicherer KI-Governance. Der Ansatz verbindet KI-Inventar, regulatorische Einordnung, Informationssicherheit und umsetzbare Roadmap. Unternehmen erhalten damit keine pauschale Ampel, sondern eine nachvollziehbare Sicht auf kritische Systeme, konkrete Lücken und die nächsten wirksamen Schritte.