KI-Inventar & Risikoregister für den EU AI Act

Der schwierigste Teil der EU-AI-Act-Vorbereitung ist nicht die Konformitätsbewertung und nicht die technische Dokumentation. Es ist die Frage, die allem vorausgeht: Welche KI-Systeme haben wir eigentlich, und was tun sie? In jedem Readiness-Projekt, das wir bei CC Conceptualise begleiten, entscheidet sich am Inventar, ob das Programm Fahrt aufnimmt oder leise stehen bleibt.

Dieser Beitrag ist ein praxisorientierter Leitfaden für zwei verknüpfte Artefakte — ein KI-System-Inventar und ein KI-Risikoregister — die einer regulatorischen Prüfung standhalten, im Unternehmensmaßstab funktionieren und sich betreiben lassen, statt jedes Quartal von Hand neu erstellt zu werden.

TL;DR / Die Kernpunkte

• Ohne ein vollständiges, klassifiziertes KI-System-Inventar sind Konformitätsbewertung, Registrierung in der EU-Datenbank und Marktbeobachtung nicht durchführbar — es ist das tragende Artefakt für alles Weitere.
• Die Hochrisiko-Pflichten (Anhang III) gelten ab dem 2. August 2026; die GPAI-Pflichten gelten bereits seit dem 2. August 2025. Erfassung und Klassifizierung dauern länger als gedacht — fangen Sie jetzt an.
• Die richtige Inventareinheit ist meist der Anwendungsfall, nicht das Modell — ein Modell kann mehrere Systeme mit sehr unterschiedlichen Risikoprofilen antreiben.
• Ein KI-Risikoregister muss KI-spezifische Schäden erfassen (Bias, Drift, Halluzination, Datenvergiftung, schwache menschliche Aufsicht), jeweils verknüpft mit System, Artikel und konkreter Risikomanagementmaßnahme.
• In Azure lässt sich der Großteil des Inventars aus Signalen zusammenstellen, die Sie ohnehin erzeugen — Resource Graph, Azure OpenAI, Azure ML, AI Foundry, Purview, Defender for Cloud —, statt am ersten Tag ein Werkzeug zu kaufen. ISO/IEC 42001 liefert den Governance-Rahmen.

Warum das Inventar die Schlüsselpflicht ist

Wer den AI Act genau liest, erkennt eine Abhängigkeitskette. Die Konformitätsbewertung setzt voraus, dass Sie wissen, dass ein System hochriskant ist. Die Registrierung in der EU-Datenbank setzt voraus, dass Sie das System und seinen Anbieter identifiziert haben. Die Marktbeobachtung setzt voraus, dass Sie wissen, was produktiv läuft und wer es verantwortet. Die Pflicht zur menschlichen Aufsicht setzt voraus, dass Sie wissen, welche Systeme folgenreiche Entscheidungen treffen oder unterstützen.

Keine dieser Pflichten lässt sich sauber gegen einen Bestand erfüllen, den Sie nicht erfasst haben. Deshalb behandeln wir das Inventar als Schlussstein: Zieht man ihn heraus, fällt der gesamte Compliance-Bogen in sich zusammen. Für die übergeordnete Abfolge von Fristen und Aufgaben setzt unsere EU-AI-Act-Readiness-Checkliste für August 2026 den zeitlichen Rahmen; dieser Beitrag zoomt auf das Artefakt, an dem alles andere hängt.

Unbequem, aber wahr: Die meisten Unternehmen unterschätzen ihre KI-Angriffsfläche erheblich. KI gelangt heute durch drei Türen ins Haus: Systeme, die Sie selbst bauen, Modelle und Plattformen, die Sie nutzen (Azure OpenAI, Drittanbieter-APIs), und KI, die unbemerkt in bereits beschaffter SaaS steckt. Ein Inventar, das nur die erste Tür zählt, ist kein Inventar.

Schritt 1 — Den gesamten KI-Bestand erfassen

Die Erfassung ist der Teil, den Teams gern überspringen, und zugleich der Teil, der über die Glaubwürdigkeit des Programms entscheidet. Spannen Sie das Netz weit, mindestens über diese Quellen:

• Selbst gebaute Systeme — Anwendungs-Repositories, in Azure ML registrierte Modelle, AI-Foundry-Projekte, Databricks-Modellregister.
• Genutzte Modelle — Azure-OpenAI-Deployments, LLM-API-Schlüssel von Drittanbietern, eingebettete Anbietermodelle.
• Bezogene KI — SaaS-Werkzeuge mit KI-Funktionen (Bewerber-Screening, CRM-Scoring, Support-Copilots). Werten Sie Beschaffungs- und SSO-Protokolle aus.
• Schatten-KI — Browser-Erweiterungen, private API-Nutzung, Abteilungsskripte. Netzwerk- und CASB-Signale helfen hier.

In Azure fördern Resource-Graph-Abfragen plus Tag-Konventionen Cognitive-Services- und ML-Ressourcen schnell zutage, und Microsoft Purview verankert die Datenherkunft. Ziel dieser Phase ist eine Kandidatenliste — Breite vor Präzision. Klassifiziert und bereinigt wird danach.

Schritt 2 — Die Inventareinheit definieren

Bevor Sie irgendetwas ausfüllen, klären Sie eine trügerisch wichtige Frage: Was ist ein KI-System?

Inventareinheit	Bedeutung	Wann sinnvoll	Abwägung
Modell	Ein einzelnes trainiertes oder gehostetes Modell	Selten als primäre Einheit	Ein Modell bedient viele Anwendungsfälle mit unterschiedlichem Risiko; verfehlt den regulatorischen Rahmen
Anwendungsfall	Eine zweckgebundene KI-Nutzung im Geschäftskontext	Standardwahl für den AI Act	Bildet Anhang III, Anbieter-/Betreiberrolle und Risikoklasse sauber ab
Deployment	Eine konkrete Umgebungsinstanz	Für Betriebs-/Monitoring-Details	Zu kleinteilig für Governance; bläht das Register auf

Der AI Act argumentiert über Zweckbestimmung und Nutzung, daher ist der Anwendungsfall fast immer die richtige primäre Einheit. Ein Modell der GPT-4-Klasse, das sowohl einen internen Wissensassistenten (minimales Risiko) als auch ein Werkzeug zum Ranking von Lebensläufen (hochriskant, Anhang III) antreibt, sind zwei Einträge, nicht einer. Dies falsch zu machen ist der häufigste Grund, warum Inventare ein irreführendes Risikobild liefern.

Schritt 3 — Die Klassifizierungs-Metadaten erfassen

Jeder Inventareintrag sollte genug Metadaten tragen, um Klassifizierung und Folgepflichten zu steuern. Ein praktikables Mindestschema:

1. Identität — Name, Verantwortliche, Geschäftsbereich, System-ID.
2. Zweck — Zweckbestimmung, getroffene oder unterstützte Entscheidung, betroffene Personen.
3. Rolle — Sind Sie Anbieter (Sie bringen es in Verkehr / entwickeln es) oder Betreiber (Sie nutzen es unter Ihrer Verantwortung)? Die Pflichten unterscheiden sich deutlich.
4. Technik — verwendete Modelle, GPAI-Beteiligung, Datenquellen, Hosting (z. B. Azure OpenAI, On-Premises), Integrationspunkte.
5. Regulatorik — etwaige Anhang-III-Kategorie, Risikoklasse, Konformitätspfad, Status der EU-Datenbank-Registrierung.
6. Lebenszyklus — Status (vorgeschlagen, in Entwicklung, produktiv, stillgelegt), letztes und nächstes Prüfdatum.

Um die Anhang-III-Anknüpfungen präzise zu bestimmen, kombinieren Sie diesen Schritt mit unserer Vertiefung zur Anhang-III-Hochrisiko-Klassifizierung. Die frühe Erfassung der Rolle Anbieter vs. Betreiber ist enorm wichtig: Eine Bank, die das Kreditscoring-Modell eines Anbieters betreibt, hat Pflichten zur Überwachung und menschlichen Aufsicht, während der Anbieter die schwerere Last aus Konformitätsbewertung und Nachweispflichten trägt.

Schritt 4 — Jedes System klassifizieren

Mit vorliegenden Metadaten weisen Sie jedem Eintrag eine Risikoklasse zu. Halten Sie die Entscheidung samt Begründung fest — Aufsichtsbehörden und Prüfer interessiert das Wie der Entscheidung ebenso wie das Was.

Klasse	Auslöser	Wesentliche Pflichten	Inventar-Maßnahme
Verboten	Praktiken nach Artikel 5	Einstellen	Markieren und sofort an die Geschäftsleitung eskalieren
Hochriskant	Anhang III oder Sicherheitskomponente	Konformitätsbewertung, EU-Datenbank-Registrierung, technische Dokumentation, Marktbeobachtung, menschliche Aufsicht	Vollständiger Risikoregister-Eintrag; verantwortliche Person benennen
Begrenzt	Interaktion mit Personen, Inhaltserzeugung	Transparenz / Offenlegung	Schlanker Registereintrag
Minimal	Alles Übrige	Freiwillige gute Praxis	Nur Inventar

Behandeln Sie die Klassifizierung als dokumentierte Entscheidung mit benannter Entscheidungsträgerin, nicht als Tabellen-Schätzung. Ist ein System hochriskant, führt der weitere Weg über unseren Leitfaden zur Konformitätsbewertung.

Schritt 5 — Das KI-Risikoregister aufbauen

Das Inventar sagt Ihnen, was existiert; das Risikoregister sagt Ihnen, was schiefgehen kann und was Sie dagegen tun. Legen Sie für jedes Hochrisiko- und sonstige wesentliche System Einträge an, die über generisches Unternehmensrisiko hinausgehen und KI-spezifische Fehlerbilder erfassen:

• Verzerrung und Diskriminierung in Ausgaben, die Einzelpersonen betreffen.
• Leistungsdrift, wenn sich Datenverteilungen nach dem Deployment verschieben.
• Halluzination / Faktenfehler in generativen Systemen.
• Datenvergiftung und Prompt Injection gegen die Pipeline.
• Unzureichende menschliche Aufsicht — Automatisierungsverzerrung, bloßes Abnicken.
• Robustheits- und Sicherheitsmängel, einschließlich Risiken aus der Modell-Lieferkette.

Jeder Eintrag sollte verweisen auf (a) das System im Inventar, (b) den einschlägigen Artikel oder die Anhang-III-Kategorie und (c) eine oder mehrere konkrete Risikomanagementmaßnahmen mit Verantwortlichen und Prüfrhythmus. Genau hier weicht ein AI-Act-Risikoregister von einem finanziellen ab: Die Einheit der Minderung ist ein technisches oder organisatorisches Control, keine Rückstellung.

Das Inventar in Azure betreiben

Ein Register, das einmal gebaut und nie angefasst wird, ist schlimmer als keines — es erzeugt falsche Sicherheit. Das Muster, das wir ausrollen, macht das Inventar selbstpflegend:

• Tagging-Standard — erzwingen Sie die Tags ai-system-id, risk-tier und owner per Azure Policy auf Cognitive-Services- und ML-Ressourcen.
• Resource-Graph-Abfragen — geplante Abfragen erkennen neue KI-Ressourcen und markieren jedes ungetaggte oder nicht registrierte Deployment als Drift.
• Purview-Katalog — verankert die Datenherkunft, sodass Sie im Audit beantworten können, womit ein Modell trainiert wurde.
• CI/CD- und Beschaffungs-Gates — eine Pipeline-Prüfung und ein Einkaufs-Checkpoint verlangen einen Inventareintrag, bevor ein KI-System ausgeliefert oder beschafft wird, und schließen die Schatten-KI-Lücke an der Quelle.
• Defender for Cloud — speist Sicherheitslage und Befunde zu KI-Workloads zurück ins Register.

Legen Sie ISO/IEC 42001 darüber, erhalten Sie ein auditfähiges KI-Managementsystem: Seine Controls erwarten genau diese dokumentierte Menge an Systemen, Folgenabschätzungen und Lebenszyklus-Governance, sodass dieselben Artefakte sowohl die Norm als auch Ihre AI-Act-Sorgfalt belegen. In unserer Projektpraxis sind es die Teams, die Governance in Pipelines und Beschaffung verdrahten — statt eine jährliche Handzählung zu betreiben —, die zwölf Monate später noch ein korrektes Inventar haben.

Eine pragmatische Abfolge

Loading diagram...

1. Erfassung über selbst gebaute, genutzte und bezogene KI durchführen; Kandidatenliste erstellen.
2. Inventareinheit (Anwendungsfall) und Metadatenschema festlegen.
3. Einträge füllen und verantwortliche Personen benennen.
4. Jedes System klassifizieren und die Begründung dokumentieren.
5. Risikoregister-Einträge für Hochrisiko- und wesentliche Systeme anlegen.
6. Erkennung, Tagging und Gates automatisieren, damit das Register lebendig bleibt.

Beginnen Sie jetzt, nicht erst im Juli. Mit Anhang-III-Pflichten ab dem 2. August 2026 und Bußgeldern von bis zu 15 Mio. EUR oder 3 % des weltweiten Umsatzes bei Hochrisiko-Verstößen (und 35 Mio. EUR oder 7 % bei verbotenen Praktiken) ist das Inventar die günstigste Versicherung, die Sie aufbauen können.

FAQ

Was ist ein KI-System-Inventar im Sinne des EU AI Act? Ein KI-System-Inventar ist das verbindliche Verzeichnis aller KI-Systeme, die Ihr Unternehmen entwickelt, betreibt oder bezieht, samt der Metadaten, die zur Klassifizierung und Steuerung nötig sind. Es erfasst Zweck, Rolle (Anbieter oder Betreiber), Risikoklasse, Datenquellen, Modelle, Verantwortliche und Lebenszyklusstatus. Konformitätsbewertung, Registrierung und Marktbeobachtung bauen darauf auf.

Ist ein KI-Inventar nach dem EU AI Act gesetzlich vorgeschrieben? Der AI Act nennt das Inventar nicht als eigenständiges Artefakt, aber ohne ein solches lassen sich die Pflichten nicht erfüllen. Anbieter von Hochrisiko-Systemen müssen technische Dokumentation führen, Systeme in der EU-Datenbank registrieren und eine Beobachtung nach dem Inverkehrbringen betreiben; Betreiber müssen menschliche Aufsicht sicherstellen. All das setzt voraus, dass Sie wissen, welche Systeme existieren und wie sie eingestuft sind.

Worin unterscheidet sich ein KI-Risikoregister von einem üblichen Risikoregister? Ein KI-Risikoregister erfasst KI-spezifische Schäden wie Verzerrung (Bias), Leistungsdrift, Halluzination, Datenvergiftung und unzureichende menschliche Aufsicht, zusätzlich zu den Konformitäts- und Grundrechtsrisiken, die der AI Act betont. Es verknüpft jedes Risiko mit einem konkreten System im Inventar, mit dem einschlägigen Artikel oder der Anhang-III-Kategorie und mit konkreten Risikomanagementmaßnahmen statt nur mit finanziellen Auswirkungen.

Ab wann gelten die Hochrisiko-Pflichten des EU AI Act? Die Pflichten für die in Anhang III gelisteten Hochrisiko-Systeme gelten ab dem 2. August 2026. Die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck (GPAI) gelten seit dem 2. August 2025; GPAI-Modelle, die vor diesem Datum bereits auf dem Markt waren, müssen bis zum 2. August 2027 konform sein. Inventar und Register jetzt aufzubauen macht diese Fristen erst erreichbar.

Lässt sich ein KI-Inventar in Azure aufbauen? Ja. Die meisten Unternehmen erzeugen die Signale bereits in Azure: Azure-OpenAI-Deployments, in Azure ML registrierte Modelle, AI-Foundry-Projekte, Azure Resource Graph, Microsoft Purview und Defender for Cloud. Wir aggregieren diese typischerweise in ein einziges gesteuertes Register mit Azure-Tags, einem Purview-Katalog und Resource-Graph-Abfragen, statt am ersten Tag ein separates Werkzeug zu kaufen.

Wie hängt ISO/IEC 42001 mit Inventar und Risikoregister zusammen? ISO/IEC 42001 ist die Norm für KI-Managementsysteme. Ihre Controls erwarten eine dokumentierte Menge von KI-Systemen, einen Folgen- und Risikobewertungsprozess sowie eine Lebenszyklus-Governance, die fast eins zu eins auf Inventar und Risikoregister abbilden. Eine Ausrichtung an 42001 schafft einen auditfähigen Governance-Rahmen, der zugleich die Sorgfalt im Sinne des EU AI Act nachweist.

---

Bauen Sie Ihr KI-Inventar und Risikoregister vor August 2026 auf oder stellen es auf den Prüfstand? Unsere Praxis für KI-Governance und -Engineering hilft europäischen Unternehmen, ein belastbares, Azure-natives KI-Register samt der dahinterliegenden Controls aufzubauen. Wir sind Praktiker, keine Foliengeber — gern tauschen wir uns aus.