KI Inventar nach dem AI Act: Alle Systeme, Rollen und Risiken im Blick

Den Erfassungskreis nach Nutzung statt Produktnamen bestimmen

Ein Inventar darf nicht bei ausdrücklich als KI beschafften Produkten enden. Zu erfassen sind auch KI Funktionen in Standardsoftware, SaaS-Diensten, Such- und Übersetzungswerkzeugen, Plugins, Analyseplattformen, Maschinen, Kundenportalen und Eigenentwicklungen. Pilotprojekte, kostenlose Konten und private Accounts mit beruflicher Nutzung gehören in den Suchraum. Entscheidend ist der konkrete Anwendungsfall, weil dasselbe Produkt in verschiedenen Prozessen andere Personen, Daten und Risiken betrifft.

Die Bestandsaufnahme sollte mehrere Datenquellen kombinieren: Einkauf und Vertragsregister, Identitäts- und Zugriffsverwaltung, technische Scans, Spesen, Cloud-Nutzung, Datenschutzverzeichnis, Projektportfolios und strukturierte Befragungen der Fachbereiche. Keine Quelle ist allein vollständig. Ein risikofreier Meldeweg für bisher ungenehmigte Nutzung verbessert die Sicht auf Schatten-KI; eine reine Sanktionskampagne verlagert sie oft nur weiter aus dem Blickfeld.

• Anwendungsfälle statt bloßer Hersteller- oder Produktlisten erfassen
• Zentrale Datenquellen mit Fachbereichserhebung und Stichproben verbinden
• Piloten, kostenlose Tools, Plugins und eingebettete Funktionen einschließen

Quellen: [1]

Mindestfelder für eine belastbare Steuerung

Jeder Eintrag braucht eine eindeutige Kennung, Geschäftszweck, Prozess, fachlichen und technischen Owner, Nutzergruppen, betroffene Personen, Datenkategorien, Lieferant, Produkt, Modell oder Version, Schnittstellen und Einsatzländer. Zusätzlich sind Entwicklungs-, Pilot-, Produktiv-, eingeschränkter und stillgelegter Status zu unterscheiden. Der Eintrag sollte auf Vertrag, Datenschutzprüfung, Sicherheitsbewertung, Freigabebeschluss, Bedienungsanweisung und vorhandene Testnachweise verweisen, ohne alle Dokumente im Register zu duplizieren.

Für die Leitung sind Entscheidungsfelder erforderlich: vorläufige Rolle nach dem AI Act, mögliche Rechtskategorie, Verbotsprüfung, Transparenzpflichten, Relevanz von Artikel 4, verantwortliche Risikoeigner, Freigabestufe, offene Maßnahmen und nächste Überprüfung. Unsichere Angaben erhalten einen Status und eine Klärungsfrist statt einer erfundenen Genauigkeit. Freitext allein erschwert Auswertung; kontrollierte Wertelisten sollten mit einem Begründungsfeld kombiniert werden.

• Stammdaten, Rechtsprüfung, Freigabe und Nachweise logisch trennen
• Ungeklärte Angaben mit Owner und Fälligkeit kennzeichnen
• Kontrollierte Auswahlfelder mit nachvollziehbarer Begründung kombinieren

Quellen: [1] [3]

Die Unternehmensrolle je Anwendungsfall klären

Rollen dürfen nicht pauschal dem Lieferanten zugewiesen werden. Ein Unternehmen kann Betreiber eines eingekauften Systems sein, bei einer Eigenentwicklung selbst Anbieter werden oder durch Vermarktung unter eigenem Namen, wesentliche Änderung oder geänderte Zweckbestimmung zusätzliche Anbieterpflichten übernehmen. Einführer, Händler und Produkthersteller sind gesondert zu prüfen. Die Rolle ist je Rechtsträger und Marktaktivität zu dokumentieren, nicht nur auf Konzernebene.

Artikel 25 regelt Konstellationen, in denen bestimmte Akteure als Anbieter eines Hochrisiko-KI-Systems gelten können. Diese Beurteilung verlangt belastbare Informationen über Branding, Änderungen, Zweckbestimmung und vertragliche Aufgaben. Das Inventar sollte deshalb nicht nur ein Ergebnisfeld enthalten, sondern die zugrunde liegenden Tatsachen und den Prüfer nennen. Bei einer neuen Version, einer anderen Vermarktung oder einer Zweckänderung wird die Rollenprüfung erneut geöffnet.

• Rolle je Rechtsträger, Anwendung und Marktaktivität festhalten
• Rebranding, wesentliche Änderung und Zweckänderung als Auslöser markieren
• Tatsachengrundlage und Prüfer neben dem Rollenergebnis dokumentieren

Quellen: [1] [4]

Verbote, Transparenz und Hochrisiko systematisch prüfen

Die Prüfreihenfolge beginnt mit bereits anwendbaren Regeln. Für jeden Use Case sind die tatbestandsgebundenen Verbote des Artikels 5 und seit 2. August 2026 die einschlägigen Transparenzpflichten des Artikels 50 zu untersuchen. Maßnahmen zur Unterstützung der KI Kompetenz nach Artikel 4 sind anhand von Personal, Vorwissen, Einsatzkontext und betroffenen Gruppen zu planen. Diese Schichten dürfen nicht auf die späteren Hochrisikofristen verschoben werden.

Danach folgt die Hochrisikoprüfung nach Artikel 6 sowie Anhang I oder III. Ein Branchenetikett reicht nicht; Zweckbestimmung und konkrete Verwendung sind entscheidend, mögliche Ausnahmen müssen geprüft werden. Nach der Verordnung (EU) 2026/1744 gelten die Abschnitte 1 bis 3 des Kapitels III für Anhang-III-Systeme grundsätzlich ab 2. Dezember 2027 und für Systeme nach Artikel 6 Absatz 1 grundsätzlich ab 2. August 2028. Bei Produkten nach Anhang I Abschnitt B, darunter Maschinen, begrenzt Artikel 2 Absatz 2 die unmittelbare Geltung; zusätzlich ist das jeweilige sektorale Produktrecht zu prüfen. Der maßgebliche Termin wird im Inventar sichtbar hinterlegt.

• Verbote und bereits anwendbare Transparenzpflichten zuerst behandeln
• Hochrisikoeinstufung anhand von Zweck und Tatbestandsmerkmalen begründen
• Anwendungsdatum der konkreten Pflicht statt eines pauschalen Datums speichern

Quellen: [1] [2] [3]

Änderungen und Nachweise über den Lebenszyklus führen

Ein statischer Tabellenstand veraltet schnell. Anbieter wechseln Modelle, Fachbereiche erweitern Zwecke, neue Schnittstellen entstehen und Systeme werden stillgelegt, während Daten oder Konten weiterbestehen. Änderungsereignisse brauchen Datum, Beschreibung, Freigabestatus und verantwortliche Person. Wesentliche Änderungen lösen eine erneute Rollen-, Risiko-, Datenschutz- und Sicherheitsprüfung aus. Die Historie muss erkennen lassen, welche Konfiguration und Unterlagen zu einem bestimmten Entscheidungszeitpunkt galten.

Verträge sollten Anbieter zur Mitteilung relevanter Änderungen verpflichten und ausreichende Informationen für Aktualisierungen sichern. Technische Verantwortliche gleichen Versions- und Zugriffsstände periodisch mit dem Inventar ab. Bei Stilllegung sind offene Schnittstellen, Konten, gespeicherte Daten, Aufbewahrungspflichten und Ersatzprozesse zu bearbeiten. Ein Eintrag wird nicht gelöscht, sondern mit Abschlussnachweisen und Aufbewahrungsregel in einen nachvollziehbaren Archivstatus überführt.

• Änderungshistorie mit Entscheidung und Prüfauslöser führen
• Anbietermeldungen und technische Versionskontrollen vertraglich absichern
• Stilllegung einschließlich Daten, Konten und Schnittstellen dokumentieren

Quellen: [1] [2]

Governance, Qualität und Managementauswertung verankern

Die Leitung sollte einen Inventarverantwortlichen bestimmen, während Fachbereiche für Vollständigkeit und Richtigkeit ihrer Anwendungen verantwortlich bleiben. Ein verbindlicher Prozess verknüpft Beschaffung, Projektstart, technische Bereitstellung und Zugriffsfreigabe mit der Registrierung. Ausnahmen erhalten Frist und Genehmiger. Regelmäßige Abgleiche mit Verträgen, Konten und Datenschutzunterlagen sowie risikobasierte Stichproben testen, ob das Register die tatsächliche Nutzung abbildet.

Managementberichte verdichten offene Verbotsprüfungen, ungeklärte Rollen, bevorstehende Fristen, überfällige Kontrollen, nicht genehmigte Nutzung und kritische Anbieterabhängigkeiten. Das Inventar ist kein Selbstzweck und keine ausdrücklich benannte allgemeine Universalpflicht. Es unterstützt die Erfüllung konkreter Anforderungen, beweist diese aber nicht allein. Qualität entsteht durch klare Zuständigkeiten, überprüfbare Nachweise und die Verbindung mit Freigabe, Schulung, Vorfallmanagement und laufender Aufsicht.

• Registrierung an Beschaffung, Bereitstellung und Zugriffsvergabe koppeln
• Vollständigkeit durch unabhängige Datenabgleiche messen
• Leitungsberichte auf Lücken, Fristen und Entscheidungen ausrichten

Quellen: [1] [4]

Häufige Fragen