Ein praxisnaher Leitfaden zum Aufbau eines KI-Systeminventars für die Governance – Ermittlungsmethoden, welche Informationen erfasst werden sollten, der Kontext zum EU AI Act 2026, die Anforderung des Treasury FS AI RMF an ein Inventar sowie Hinweise, wie es korrekt und aktuell gehalten wird.
•
•
21 Minuten Lesezeit
Themen
Ein Inventar von KI-Systemen (auch als KI-Systemregister bezeichnet) ist ein umfassender, zentraler Katalog aller im Unternehmen eingesetzten KI-Systeme, Modelle und Agenten. Es erfasst ihren geschäftlichen Zweck, ihre Zuständigkeit und ihr Risikoniveau - die Grundlage jedes unternehmensweiten Governance-Programms. Der Aufbau eines vollständigen KI-Inventars ist heute eine zwingende Voraussetzung für die Einhaltung des EU AI Act, der ISO 42001, des NIST AI RMF und des neuen Financial Services AI Risk Management Framework des Treasury Department.
Die meisten Organisationen können eine scheinbar einfache Frage nicht beantworten: Wie viele KI-Systeme sind derzeit im gesamten Unternehmen im Einsatz? Die Unfähigkeit, eine verlässliche Antwort zu liefern - und das Fehlen eines umfassenden KI-Inventars - ist nicht bloß eine administrative Lücke. Sie stellt ein Compliance-Risiko, einen blinden Fleck im Risikomanagement und eine zunehmend unhaltbare Position dar, da regulatorische Rahmenwerke weltweit von freiwilligen Leitlinien zu verbindlichen Pflichten übergehen.
Der EU AI Act, der im August 2024 in Kraft getreten ist und dessen Pflichten bis 2027 schrittweise eingeführt werden, verpflichtet Betreiber von Hochrisiko-KI-Systemen, diese Systeme in der EU-Datenbank zu registrieren (Artikel 71) und eine Dokumentation vorzuhalten, die eine vollständige Erfassung jedes in den Anwendungsbereich fallenden Systems voraussetzt.[1] ISO/IEC 42001, der internationale Standard für KI-Managementsysteme, verlangt von Organisationen, den Umfang und Kontext ihrer KI-Systeme als Voraussetzung für die Zertifizierung zu dokumentieren, wodurch systematisches Katalogisieren zu einer praktischen Notwendigkeit wird.[2] Das NIST AI Risk Management Framework betrachtet die Identifizierung und Klassifizierung von KI-Systemen als grundlegende Aktivität innerhalb seiner „Map“-Funktion, die alle nachgelagerten Aktivitäten zur Risikomessung und zum Risikomanagement speist.[3] Das Treasury Department's Financial Services AI Risk Management Framework, veröffentlicht im Februar 2026, macht das KI-Inventar zu einem eigenen Kontrollziel (GV-1.6) mit sechs Unterzielen, die von der Aufdeckung von Shadow IT bis zur Risikoanalyse auf Portfolio-Ebene reichen.[4] Ohne ein umfassendes KI-Inventar ist die Einhaltung dieser Rahmenwerke strukturell unmöglich.
Doch die Aufgabe, jedes KI-System innerhalb eines Unternehmens zu katalogisieren, ist weitaus komplexer, als es zunächst erscheint. Dieser Leitfaden bietet einen systematischen Ansatz für den Aufbau eines KI-Inventars von Grund auf, einschließlich der zu erfassenden Informationen, der Entdeckung von Systemen, die für die zentrale Governance unsichtbar sein können, und der Aufrechterhaltung der Genauigkeit des Inventars über die Zeit.
Warum ein KI-Inventar die Grundlage der Governance ist
Abgesehen von regulatorischen Vorgaben dient ein vollständiges Inventar von KI-Systemen als Voraussetzung für nahezu jede nachgelagerte Governance-Aktivität. Risikobewertungen können nicht auf unbekannte Systeme angewendet werden. Bias-Audits können KI-Tools nicht erfassen, die im Einkauf nie erfasst wurden. Incident-Response-Pläne können KI-gestützte Prozesse nicht berücksichtigen, in die die IT keinen Einblick hat.
Die praktischen Folgen des Betriebs ohne Inventar sind bereits sichtbar. Organisationen, die dem EU AI Act unterliegen, sehen sich für Hochrisiko-Systeme mit einer Registrierungspflicht in der europäischen Datenbank konfrontiert.[1] Wer eine ISO 42001-Zertifizierung anstrebt, muss einen systematischen Prozess zur Identifizierung und Verwaltung von KI-Systemen im gesamten Unternehmen nachweisen.[2] Finanzaufsichtsbehörden, darunter die Bank of England, die FCA und die Europäische Zentralbank, haben begonnen, Aufsichtsanforderungen zu formulieren, die voraussetzen, dass Unternehmen genau wissen, welche Entscheidungen durch algorithmische oder KI-basierte Tools beeinflusst werden.[5] Und seit Februar 2026 müssen US-Finanzinstitute in der Lage sein, den Fragebogen des Treasury FS AI RMF zu unterstützen, der ohne ein grundlegendes KI-Inventar nicht ausgefüllt werden kann.[4]
Die Herausforderung wird durch das Tempo der KI-Adoption noch verstärkt. Die McKinsey Global Survey on AI 2024 ergab, dass 72 % der Organisationen KI in mindestens einer Geschäftsfunktion eingeführt hatten, wobei sich die Einführung nahezu von Jahr zu Jahr verdoppelte und vieles davon auf Abteilungsebene ohne zentrale Aufsicht geschah.[6] Plattformen wie Enzai wurden speziell entwickelt, um die Komplexität der Pflege eines lebenden KI-Inventars im Unternehmensmaßstab zu adressieren, indem sie Erkennung, Risikoklassifizierung und fortlaufendes Monitoring in einer einzigen Governance-Schicht verbinden.
Ein KI-Inventar ist keine Compliance-Checkliste. Es ist das eine Artefakt, von dem jede andere Governance-Aktivität abhängt.
Was in Ihrem KI-Inventar 2026 zu erfassen ist: Aktualisierte Anforderungen
Seit die meisten Organisationen ihre Inventarspezifikation zuletzt überprüft haben, hat sich zweierlei verändert. Die regulatorische Messlatte ist höher geworden, und die zu inventarisierenden Systeme haben sich weiterentwickelt. Ein 2024 zur Unterstützung der EU AI Act-Vorbereitung konzipiertes Inventar ist für 2026 materiell unzureichend.
Der regulatorische Kontext 2026
EU AI Act - Hochrisiko-Pflichten ab 2. August 2026 wirksam. Das vollständige Paket der Anforderungen an Hochrisiko-Systeme gemäß den Artikeln 9-15, die Konformitätsbewertung nach Artikel 43, die Transparenzpflichten nach Artikel 50 sowie die Registrierung in der EU-Datenbank nach Artikel 71 tritt am 2. August 2026 in Kraft.[7] Der im November 2025 vorgeschlagene Digital Omnibus würde die Frist für Anhang III bis Dezember 2027 verlängern, doch dieser Vorschlag befindet sich weiterhin in den Trilog-Verhandlungen und das Ergebnis ist ungewiss. Planen Sie mit August; betrachten Sie jede Verlängerung als Ausnahmeszenario, nicht als Ausgangsbasis. Die Inventarwirkung ist konkret: Jedes System, das in die Kategorien des Anhangs III fallen kann, muss identifizierbar, klassifiziert und für die Registrierung vorbereitet sein.
Treasury Financial Services AI Risk Management Framework - veröffentlicht am 19. Februar 2026. Das US-Finanzministerium veröffentlichte am 19. Februar 2026 gemeinsam mit einem AI Lexicon das Financial Services AI Risk Management Framework (FS AI RMF) und passte damit das NIST AI RMF für Finanzinstitute über 230 Kontrollziele hinweg an.[4] Der Aufbau des KI-Inventars ist ein eigenes Kontrollziel - GV-1.6 - mit sechs Unterzielen, die von der Aufdeckung von Shadow IT bis zur Risikoanalyse auf Portfolio-Ebene reichen. Das Rahmenwerk ist derzeit freiwillig, dürfte jedoch die Erwartungen von Prüfern rasch prägen. Für Organisationen im Finanzdienstleistungssektor muss das Inventar nun als Baseline die Beantwortung des FS AI RMF-Fragebogens unterstützen.
Colorado AI Act und parallele Landesgesetze. Der Colorado AI Act, ursprünglich ab 1. Februar 2026 wirksam und Gegenstand anhängiger Änderungen, verpflichtet Entwickler und Betreiber von Hochrisiko-KI-Systemen zu angemessener Sorgfalt, um algorithmische Diskriminierung bei folgenreichen Entscheidungen zu vermeiden.[8] Inventare zur Unterstützung der Colorado-Compliance müssen Entscheidungswirkung, betroffene Populationen und Kennzeichnungen für folgenschwere Entscheidungen erfassen - Felder, die in älteren KI-Inventaren nicht immer enthalten sind.
ISO/IEC 42001 und NIST AI RMF. Fortbestehende freiwillige Rahmenwerke. Die ISO 42001-Zertifizierung erfordert den Nachweis eines systematischen Prozesses zur Identifizierung und Verwaltung von KI-Systemen. Das NIST AI RMF behandelt Identifizierung und Klassifizierung als grundlegende Aktivität innerhalb seiner Map-Funktion.[2][3]
Was 2026 zusätzlich zu erfassen ist
Die Felder und Aspekte, die 2026 speziell hinzukommen:
Kennzeichnungen für agentische Systeme. Ob es sich bei dem System um einen autonomen Agenten handelt, seine Autonomiestufe (siehe Enzais Leitfaden zur Governance agentischer KI) und der begrenzte Aktionsraum, in dem es operiert.
Abhängigkeit von Foundation Models. Für Systeme, die auf Foundation Models von Drittanbietern aufbauen, der Modellanbieter, die Modellversion, die Richtlinie zur Versionsbindung sowie Revalidierungsauslöser, wenn der Anbieter Aktualisierungen bereitstellt.
Felder zur Risikoklassifizierung nach EU AI Act. Kategorie des Anhangs III (falls zutreffend), Begründung der Hochrisiko-Klassifizierung, Pfad der Konformitätsbewertung, Status der Registrierung in der EU-Datenbank, Verweis auf den Plan zum Post-Market-Monitoring. Siehe Enzais Leitfaden zur Compliance mit dem EU AI Act für die vollständige Aufschlüsselung der Pflichten.
FS AI RMF-Mapping (Finanzdienstleistungen). Zuordnung zu den relevanten Kontrollzielen, insbesondere den Unterzielen von GV-1.6, einschließlich externer Exponierung, Nutzung sensibler oder regulierter Daten, Auswirkungen auf Kunden oder den Markt sowie Kritikalität.
Kennzeichnungen zur Entdeckung von Shadow Agents. Spezifisches Tracking für autonome Agenten, die außerhalb formeller Beschaffung eingeführt wurden - häufig in SaaS-Plattformen eingebettet oder informell von Data-Science-Teams entwickelt.
Auslöser für wesentliche Änderungen. Definierte Kriterien dafür, wann eine Änderung an einem bestehenden System eine „wesentliche Änderung“ gemäß Artikel 3 Absatz 23 des EU AI Act darstellt und eine erneute Bewertung auslöst.
Dies sind Ergänzungen zu dem im Folgenden beschriebenen Feldrahmen. Organisationen, deren Inventare bereits die unten aufgeführten Kernfelder abdecken, sollten einen gezielten Anreicherungslauf einplanen, um die spezifischen Daten von 2026 zu ergänzen, anstatt alles von Grund auf neu aufzubauen.
Die Discovery-Herausforderung
Zu verstehen, warum KI-Systeme schwer zu katalogisieren sind, ist entscheidend, bevor der Aufbau des Inventars selbst begonnen wird. KI verhält sich in puncto Sichtbarkeit nicht wie herkömmliche Software. Sie bettet sich in bestehende Tools ein, arbeitet über Drittanbieter-APIs und verbreitet sich über individuelle Entscheidungen von Mitarbeitenden, die nie einen Einkaufsvorgang durchlaufen.
Shadow AI - Die bedeutendste Discovery-Herausforderung ist Shadow AI: Systeme, die von Mitarbeitenden oder Teams ohne formelle Freigabe eingeführt wurden. Eine Marketing-Analystin, die auf einer privaten Kreditkarte ein KI-gestütztes Copywriting-Tool abonniert, ein Vertriebsteam, das einen KI-Dienst zur Transkriptions von Meetings nutzt, ein Finanzteam, das über eine Browser-Erweiterung mit einem Large Language Model experimentiert. Jedes dieser Beispiele stellt ein KI-System dar, das Organisationsdaten außerhalb eines Governance-Rahmens verarbeitet.
Eingebettete KI in SaaS-Plattformen - Große Anbieter von Unternehmenssoftware haben KI-Funktionen in bestehende Produkte mit außergewöhnlicher Geschwindigkeit integriert. Eine CRM-Plattform, die Predictive Lead Scoring eingeführt hat, ein HR-System, das eine Lebenslauf-Sichtung ergänzt hat, ein Customer-Support-Tool, das eine automatisierte Antwortgenerierung bereitgestellt hat. Das sind KI-Systeme, sie erscheinen jedoch häufig als Feature-Updates statt als neue Beschaffungen und bleiben damit für traditionelle Software-Audits unsichtbar.
Vendor- und Drittanbieter-KI - Wenn eine Organisation einen Anbieter beauftragt, der bei der Leistungserbringung KI einsetzt, kann die Organisation im Rahmen von Regulierungsrahmen wie dem EU AI Act selbst zum Betreiber dieses KI-Systems werden. Ein Anbieter von Background Checks, der KI zur Vorauswahl von Kandidaten nutzt, ein Outsourcing-Dienstleister für Schadensbearbeitung, der KI zur Triage von Vorgängen einsetzt, ein Logistikpartner, der KI für die Routenoptimierung verwendet. Jedes dieser Beispiele schafft eine Governance-Verpflichtung, die damit beginnt, die Existenz des Systems zu kennen.
Intern entwickelte KI - Data-Science-Teams, Innovationslabore und Software-Engineering-Abteilungen können KI-Modelle entwickeln und bereitstellen, die nie einen formellen Release-Management-Prozess durchlaufen. Jupyter-Notebooks, die in die Produktion überführt werden, Machine-Learning-Modelle, die auf Abteilungsservern laufen, automatisierte Entscheidungsskripte, die sich vom Proof of Concept zu geschäftskritischen Anwendungen entwickelt haben, ohne dass sie jemals formell beauftragt wurden.
Die Discovery-Herausforderung ist im Kern eine Frage der Sichtbarkeit. Klassisches IT-Asset-Management wurde nicht für KI konzipiert, und die meisten Tools und Prozesse, auf die Organisationen setzen, werden den Großteil ihres KI-Footprints übersehen.
Was in Ihrem KI-Inventar zu erfassen ist
Ein nützliches KI-Inventar muss Vollständigkeit und Praktikabilität in Einklang bringen. Zu wenig zu erfassen macht das Inventar für Risikobewertung und Compliance unzureichend. Zu viel zu erfassen erzeugt einen Pflegeaufwand, der das Inventar veralten lässt. Das folgende Vorlagenrahmenwerk deckt die Felder ab, die regulatorische Anforderungen, Branchenstandards und praktische Governance-Bedürfnisse verlangen.
Kernidentifikationsfelder
Feld | Beschreibung | Beispiel |
|---|---|---|
System-ID | Eindeutige Kennung für das KI-System | AI-2026-0042 |
Systemname | Beschreibender Name | Modell zur Vorhersage von Kundenabwanderung |
Systembeschreibung | Allgemeinverständliche Zusammenfassung der Funktion des Systems | Prognostiziert die Wahrscheinlichkeit, dass ein Kundenvertrag auf Grundlage von Nutzungsmustern und Support-Ticket-Verläufen nicht verlängert wird |
Systemkategorie | Klassifizierung des KI-Typs | Machine-Learning-Modell, regelbasiertes System, generative KI, robotergestützte Prozessautomatisierung, autonomer Agent |
Bereitstellungstyp | Wie das System bereitgestellt wird | Eigenentwicklung, SaaS eines Drittanbieters, eingebettete Anbieterfunktion, API-Dienst |
Zuständigkeit und Verantwortlichkeit
Feld | Beschreibung | Beispiel |
|---|---|---|
Geschäftsverantwortlicher | Person, die für die Nutzung des Systems verantwortlich ist | VP Customer Success |
Technischer Verantwortlicher | Person, die für den technischen Betrieb verantwortlich ist | Lead ML Engineer, Data Science Team |
Anbieter (falls zutreffend) | Drittanbieter | Acme Analytics Ltd |
Abteilung | Organisationseinheit, die das System nutzt | Customer Success |
Vertragsreferenz | Verweis auf den relevanten Beschaffungs- oder Lizenzvertrag | PO-2025-8831 |
Risiko- und Compliance-Klassifizierung
Feld | Beschreibung | Beispiel |
|---|---|---|
Risikokategorie gemäß EU AI Act | Inakzeptabel, Hoch, Begrenzt, Minimal | Begrenztes Risiko |
Anhang III-Kategorie (bei Hochrisiko) | Welche Kategorie des Anhangs III zutrifft | Beschäftigung - Lebenslauf-Sichtung |
Zuordnung im FS AI RMF (Finanzdienstleistungen) | Relevante Kontrollziele, Unterzuordnung zu GV-1.6 | Extern ausgerichtet, sensible Daten, kundenwirksam |
Verarbeitete Datentypen | Kategorien von Daten, die das System aufnimmt | Kundennutzungsdaten, Support-Ticket-Texte, Vertragsmetadaten |
Einbezogene personenbezogene Daten | Ob personenbezogene Daten verarbeitet werden und auf welcher Grundlage | Ja - berechtigtes Interesse, DPIA-Referenz DP-2025-019 |
Auswirkung auf Entscheidungen | Art der Entscheidungen, die vom System beeinflusst werden | Beratende Eingabe für das Verlängerungsteam, keine automatisierten Entscheidungen |
Betroffene Gruppen | Wer von den Systemausgaben betroffen ist | Unternehmenskunden (B2B), etwa 2.400 Konten |
Kennzeichnung für folgenschwere Entscheidungen | Trifft das System eine folgenschwere Entscheidung (Beschäftigung, Kredit, Versicherung, Wohnen usw.) oder beeinflusst es diese wesentlich? | Nein |
Technische und operative Details
Feld | Beschreibung | Beispiel |
|---|---|---|
Modelltyp / Algorithmus | Technischer Ansatz | Gradientenverstärkter Entscheidungsbaum (XGBoost) |
Abhängigkeit von Foundation Models | Wenn auf einem Foundation Model eines Drittanbieters aufgebaut: Anbieter, Version, Richtlinie zur Versionsbindung | Anthropic Claude Sonnet 4.6, gebunden an claude-sonnet-4-6 |
Zusammenfassung der Trainingsdaten | Beschreibung der Quellen und des Alters der Trainingsdaten | 36 Monate historische Kundendaten, zuletzt im März 2026 neu trainiert |
Infrastruktur | Wo das System ausgeführt wird | AWS eu-west-2, SageMaker-Endpunkt |
Integrationspunkte | Systeme, die Daten an diese KI liefern oder Ausgaben daraus erhalten | Salesforce CRM, interne Dashboards, Verlängerungs-Workflow |
Leistungskennzahlen | Wie die Wirksamkeit des Systems gemessen wird | AUC-ROC 0.87, Präzision 0.79, vierteljährlich überprüft |
Datum der letzten Überprüfung | Datum der jüngsten Governance-Überprüfung | 2026-02-15 |
Agentenspezifische Felder (falls zutreffend)
Feld | Beschreibung | Beispiel |
|---|---|---|
Handelt es sich hierbei um einen autonomen Agenten? | Ja | |
Autonomiestufe | 1 (unterstützend) bis 4 (vollautonom) | Stufe 3 - begrenzt autonom |
Referenz zur zulässigen Aktionsliste | Verweis auf den zulässigen Aktionsraum des Agenten | RUN-A042-actions.yaml |
Eskalationsauslöser | Definierte Bedingungen, die die Kontrolle an einen Menschen zurückgeben | Vertrauen < 0.8; Transaktion > 5.000 $; Tool-Fehler |
Ort des Audit-Trails | Wo die Begründungs- und Tool-Use-Protokolle des Agenten gespeichert werden | S3://enzai-audit/agents/A042/ |
Lebenszyklus und Status
Feld | Beschreibung | Beispiel |
|---|---|---|
Status | Aktueller Betriebszustand | Aktiv, Pilotbetrieb, außer Betrieb genommen, in Prüfung |
Bereitstellungsdatum | Wann das System produktiv ging | 2025-06-01 |
Datum der nächsten Überprüfung | Geplanter Termin für die nächste Governance-Überprüfung | 2026-08-15 |
Außerbetriebnahmeplan | Ob ein Ausstiegs- oder Sunset-Plan vorliegt | Dokumentiert im Runbook RB-2025-044 |
Auslöser für wesentliche Änderungen | Definierte Kriterien, die eine Konformitätsbewertung erneut auslösen würden | Änderung der Trainingsdatenquellen; Versionssprung des Foundation Models |
Nicht jedes Feld wird beim ersten Durchlauf für jedes System befüllt sein. Ein praxistauglicher Ansatz besteht darin, festzulegen, welche Felder bei der Erfassung verpflichtend sind (Systemname, Verantwortlicher, Bereitstellungstyp, Risikoklassifizierung) und welche bis zum ersten Governance-Review-Zyklus aufgeschoben werden können. Das KI-Inventarschema von Enzai setzt diesen gestuften Ansatz um, indem es erforderliche Erfassungsfelder von schrittweisen Anreicherungsfeldern trennt, damit Teams nicht entweder alles überspringen oder an einem Formular mit 22 Feldern für jedes der 200 Systeme blockieren. Ziel ist es, die Struktur zu schaffen und Lücken systematisch zu schließen, statt das Inventar so lange aufzuschieben, bis jedes Feld perfekt ausgefüllt werden kann.
Discovery-Methoden
Mit einem klaren Bild darüber, was zu erfassen ist, stellt sich als Nächstes die Frage, wie jedes im Unternehmen betriebene KI-System gefunden werden kann. Keine einzelne Methode erreicht eine vollständige Abdeckung. Ein wirksames Discovery-Programm kombiniert mehrere Ansätze miteinander.
Automatisiertes Scanning und technische Discovery - Die Analyse des Netzwerkverkehrs kann API-Aufrufe an bekannte KI-Dienstanbieter identifizieren, einschließlich großer Cloud-KI-Endpunkte von Anbietern wie OpenAI, Google, Anthropic und AWS. DNS-Protokolle, Proxy-Server-Aufzeichnungen und CASB-Tools können Verbindungen zu KI-Diensten kennzeichnen, die nicht formell freigegeben wurden. Softwarezusammensetzungsanalysen können KI-Bibliotheken und -Frameworks in intern entwickelten Anwendungen identifizieren.
Organisationen, die Plattformen wie Enzai nutzen, können automatisierte Discovery-Funktionen direkt in ihren Governance-Workflow integrieren, den erforderlichen manuellen Aufwand reduzieren und sicherstellen, dass neu erkannte Systeme sofort zur Klassifizierung und Überprüfung markiert werden.
Beschaffung und Lieferantenprüfung - Eine systematische Überprüfung von Beschaffungsunterlagen, Softwarelizenzverträgen und Anbieterverträgen legt KI-Systeme offen, die über formelle Kanäle erworben wurden. Dies sollte auch eine retrospektive Prüfung bestehender Verträge umfassen, da viele Anbieter KI-Funktionen zu früheren Nicht-KI-Produkten hinzugefügt haben. Beschaffungsteams sollten angewiesen werden, jede neue Anschaffung zu kennzeichnen, die KI- oder Machine-Learning-Funktionen enthält.
Mitarbeiterbefragungen und Selbstauskunft - Die direkte Ansprache von Geschäftsbereichen bleibt eine der wirksamsten Discovery-Methoden für Shadow AI. Eine strukturierte Umfrage, die Teams auffordert, alle Tools, Dienste oder Modelle zu identifizieren, die sie verwenden und die KI, Machine Learning, Natural Language Processing oder automatisierte Entscheidungsfindung beinhalten, wird zuverlässig Systeme offenlegen, die keine technische Scan-Methode erkennen würde. Die Umfrage sollte konstruktiv formuliert sein und Governance-Unterstützung statt Durchsetzung betonen, um ehrliche Offenlegung zu fördern.
Anbieterfragebögen - Bei bestehenden Drittanbieterbeziehungen identifiziert ein gezielter Fragebogen, der Anbieter fragt, ob bei der Leistungserbringung KI eingesetzt wird und, falls ja, welcher Typ und zu welchem Zweck, eingebettete und Drittanbieter-KI. Dies ist besonders wichtig für ausgelagerte Geschäftsprozesse, bei denen KI vom Anbieter ohne ausdrückliche Benachrichtigung des Kunden eingeführt werden kann.
Analyse von Netzwerk- und API-Traffic - Über das Scannen bekannter KI-Endpunkte hinaus kann eine tiefere Analyse von API-Traffic-Mustern KI-Systeme aufdecken, die über nicht offensichtliche Kanäle kommunizieren. Die Überwachung von Mustern, die mit Modell-Inferenzaufrufen übereinstimmen, etwa strukturierte JSON-Payloads, die an externe Endpunkte mit Latenzprofilen gesendet werden, wie sie für ML-Inferenz typisch sind, kann Systeme sichtbar machen, die andere Methoden übersehen.
Die robustesten Discovery-Programme führen diese Methoden parallel aus und wiederholen sie in regelmäßigen Zyklen. Ein einzelner Durchlauf erfasst den Großteil der Systeme, doch eine fortlaufende Discovery ist notwendig, um mit der Geschwindigkeit Schritt zu halten, mit der neue KI-Tools in die Organisation gelangen.
Aufbau des Inventarisierungsprozesses
Ein KI-Inventar ist nur so belastbar wie der Prozess und die Governance-Struktur, die es tragen. Ohne klare Zuständigkeit, funktionsübergreifende Einbindung und definierte Workflows wird selbst ein gründlicher Erstkatalog innerhalb weniger Monate an Wert verlieren.
Festlegung der Zuständigkeit - Eine einzelne Funktion muss das KI-Inventar als Unternehmenswert verantworten. In den meisten Organisationen liegt diese Verantwortung bei einer von drei Rollen: dem Chief AI Officer (sofern die Rolle existiert), dem Chief Information Security Officer oder dem Chief Compliance Officer. Die entscheidende Voraussetzung ist, dass die verantwortliche Stelle über ausreichende Autorität verfügt, um Auskünfte von allen Geschäftsbereichen einzufordern, und über genügend technische Glaubwürdigkeit, um mit Engineering-Teams bei Klassifizierung und Risikobewertung zu arbeiten.
Funktionsübergreifende Einbindung - Der Inventarisierungsprozess erfordert die aktive Beteiligung mehrerer Funktionen:
IT und Engineering stellen technische Discovery-Fähigkeiten bereit und können intern entwickelte KI-Systeme, Infrastrukturdaten und Integrationspunkte identifizieren.
Beschaffung kennzeichnet neue KI-Beschaffungen und prüft bestehende Lieferantenbeziehungen retrospektiv.
Recht und Compliance klassifizieren Systeme anhand regulatorischer Anforderungen, einschließlich der Risikokategorien des EU AI Act, der Kontrollziele des FS AI RMF und der Datenschutzpflichten.
Leiter der Geschäftsbereiche identifizieren KI-Tools, die in ihren Teams im Einsatz sind, und weisen jedem System einen geschäftlichen Verantwortlichen zu.
Datenschutz / Privacy bewertet die Verarbeitung personenbezogener Daten und stellt die Ausrichtung auf GDPR und gleichwertige Rahmenwerke sicher.
Interne Revision validiert die Vollständigkeit und Genauigkeit des Inventars in regelmäßigen Abständen.
Definition des Intake-Workflows - Jedes neue KI-System, ob beschafft, entwickelt oder durch Scanning entdeckt, sollte einen standardisierten Intake-Workflow durchlaufen. Dieser Workflow sollte die Erstregistrierung (Ausfüllen der Kernidentifikationsfelder), eine vorläufige Risikoklassifizierung, die Zuweisung geschäftlicher und technischer Verantwortlicher sowie die Planung eines vollständigen Governance-Reviews umfassen. Der Intake-Prozess sollte leichtgewichtig genug sein, damit er keinen Anreiz zur Umgehung schafft, und zugleich streng genug, dass kein System ohne grundlegende Governance-Dokumentation in die Produktion gelangt.
Festlegung des Governance-Rhythmus - Das Inventar sollte mindestens vierteljährlich formal überprüft werden. Jede Überprüfung sollte die Vollständigkeit bewerten (wurden seit dem letzten Zyklus neue Systeme hinzugefügt?), die Genauigkeit (sind die Angaben zu bestehenden Systemen noch korrekt?) und die Compliance-Lage (laufen irgendwelche Systeme außerhalb ihrer genehmigten Risikoparameter?).
Ein Prozess ohne klare Zuständigkeit ist eine Absichtserklärung. Ein Prozess mit Zuständigkeit, funktionsübergreifender Unterstützung und einem definierten Rhythmus ist ein Governance-Programm.
Das Inventar über die Zeit pflegen
Der erstmalige Aufbau ist der leichtere Teil der Herausforderung. Die Pflege eines genauen, lebenden Inventars erfordert Auslöser, Automatisierung und die Integration in das breitere organisatorische Change-Management.
Auslöser für Inventaraktualisierungen - Das Inventar sollte aktualisiert werden, sobald eines der folgenden Ereignisse eintritt:
Ein neues KI-System wird beschafft, entwickelt oder bereitgestellt
Ein bestehendes System wird wesentlich geändert (neue Datenquellen, geänderter Entscheidungsumfang, Modell-Retraining, Versionsänderung des Foundation Models)
Ein System wird außer Betrieb genommen oder ausgesetzt
Ein Anbieter meldet der Organisation die Ergänzung von KI-Funktionen zu einem bestehenden Produkt
Eine regulatorische Änderung verändert die Risikoklassifizierung eines bestehenden Systems
Ein Vorfall mit Beteiligung eines KI-Systems wird gemeldet
Eine organisatorische Umstrukturierung verändert die geschäftliche Zuständigkeit für ein System
Fortlaufende Discovery - Technische Discovery-Methoden sollten kontinuierlich laufen und nicht nur als periodische Einzelübungen. Automatisiertes Scanning von KI-API-Traffic, CASB-Warnungen zu neuen KI-SaaS-Tools und die Integration in Software-Deployment-Pipelines, um KI-Komponenten in neuen Releases zu kennzeichnen, tragen alle dazu bei, die Zeitspanne zwischen dem Eintritt eines Systems in die Organisation und seinem Erscheinen im Inventar zu verkürzen.
Integration in das Change-Management - Das KI-Inventar sollte in bestehende Change-Management- und IT-Service-Management-Prozesse eingebettet werden. Change Advisory Boards sollten den Einfluss auf das KI-Inventar als Standardbewertungskriterium einbeziehen. Software-Bereitstellungsprozesse sollten eine Prüfung auf KI-Komponenten enthalten. Workflows im Anbietermanagement sollten die Offenlegung von KI als standardmäßige vertragliche und prüfungsbezogene Anforderung enthalten.
Versionshistorie und Audit-Trail - Jede Änderung an einem Inventareintrag sollte mit Zeitstempel, Identität der Person, die die Änderung vorgenommen hat, und dem Grund für die Aktualisierung protokolliert werden. Dieser Audit-Trail ist nicht nur gute Praxis. Er ist eine ausdrückliche Anforderung mehrerer regulatorischer Rahmenwerke und wird von Prüfern und Aufsichtsbehörden erwartet werden.
An der Pflege scheitern die meisten KI-Inventare. Erfolgreich sind jene Organisationen, die das Inventar als lebendes System betrachten, das in operative Workflows integriert ist, und nicht als statisches Dokument, das einmal pro Jahr wieder aufgerufen wird.
Häufige Fallstricke
Selbst gut ausgestattete Organisationen stoßen beim Aufbau und der Pflege eines KI-Inventars auf vorhersehbare Fehlermuster. Das frühzeitige Erkennen dieser Muster erhöht die Wahrscheinlichkeit eines belastbaren Ergebnisses erheblich.
KI zu eng definieren. Organisationen, die ihr Inventar auf „Machine-Learning-Modelle“ beschränken, übersehen regelbasierte automatisierte Entscheidungssysteme, robotergestützte Prozessautomatisierung mit kognitiven Elementen, autonome Agenten und generative KI-Tools, die im Unternehmen informell genutzt werden. Die Definition dessen, was für Inventarzwecke als KI-System gilt, sollte bewusst breit angelegt und an regulatorischen Definitionen ausgerichtet sein, etwa an der umfassenden Fassung in Artikel 3 Absatz 1 des EU AI Act.[1]
Das Inventar als IT-Projekt behandeln. Wenn das Inventar ausschließlich von der IT verantwortet wird, wird die KI-Adoption auf der Geschäftsseite systematisch zu gering erfasst. Umgekehrt führt eine ausschließliche Verantwortung durch Compliance dazu, dass technische Details spärlich und unzuverlässig bleiben. Funktionsübergreifende Zuständigkeit ist nicht optional.
Perfektion beim ersten Durchlauf anstreben. Organisationen, die darauf bestehen, vor der Veröffentlichung des Inventars jedes Feld für jedes System auszufüllen, werden das Inventar nie veröffentlichen. Ein pragmatischer Ansatz akzeptiert unvollständige Datensätze im Erstaufbau und setzt ein strukturiertes Programm zur Schließung von Lücken in den darauffolgenden Überprüfungszyklen um.
Vendor-KI vernachlässigen. Die KI-Systeme mit dem größten Einfluss auf eine Organisation werden häufig von Dritten betrieben - die KI eines Anbieters für Hintergrundprüfungen, das Modell einer Auskunftei zur Bonitätsbewertung, die automatisierten Sicherheitstools einer Cloud-Plattform. Diese erfordern dieselbe Governance-Aufmerksamkeit wie intern entwickelte Systeme, und oft sogar mehr, angesichts der geringeren Sichtbarkeit.
Agentische Systeme übersehen. Die meisten älteren Inventare wurden für statische KI entwickelt - Modelle, die Vorhersagen oder Inhalte erzeugen, auf die Menschen reagieren. Agentische Systeme, die in mehrstufigen Workflows autonom Aktionen ausführen, erfordern zusätzliche Felder (Autonomiestufe, Aktionsliste, Eskalationsauslöser, Ort des Audit-Trails) und zusätzliche Governance-Disziplinen. Ein Inventar, das agentische Systeme nicht getrennt von statischen Modellen sichtbar macht, kann keine verhältnismäßige Governance unterstützen. Siehe Enzais Leitfaden zur Governance agentischer KI für den vollständigen Rahmen.
Das Inventar nicht mit Maßnahmen verknüpfen. Ein KI-Inventar, das als einmal jährlich überprüfte Tabelle existiert und von Risikobewertung, Incident Management und regulatorischen Berichtsprozessen entkoppelt ist, bietet kaum Governance-Nutzen. Das Inventar muss das operative Rückgrat des KI-Governance-Programms sein und nicht dessen Anhang.
Den Pflegeaufwand unterschätzen. Die Geschwindigkeit der KI-Adoption in den meisten Organisationen bedeutet, dass ein heute abgeschlossenes Inventar ohne aktive Pflegeprozesse innerhalb von drei bis sechs Monaten materiell unvollständig sein wird. Organisationen sollten laufenden Aufwand für die Pflege des Inventars einplanen, nicht nur für den Erstaufbau.
Der Unterschied zwischen einem KI-Inventar, das Governance-Wert liefert, und einem, das verstaubt, liegt nicht in der Raffinesse des Anfangskatalogs. Es ist die Strenge des Prozesses, der es aktuell hält und mit der Entscheidungsfindung verbindet.
Praktische Implikationen
Die regulatorische Entwicklung ist eindeutig. Der EU AI Act, ISO 42001, der NIST AI RMF, der Treasury FS AI RMF und eine wachsende Zahl sektorspezifischer Aufsichtsanforderungen laufen alle auf dieselbe grundlegende Anforderung hinaus: Organisationen müssen wissen, welche KI sie einsetzen, wo sie betrieben wird, wer dafür verantwortlich ist und welche Risiken sie birgt. Die Kosten für den Aufbau dieser Fähigkeit steigen mit jeder Verzögerung, da das Volumen an KI-Systemen in jedem Unternehmen schneller wächst als die Fähigkeit, sie rückwirkend zu katalogisieren.
Organisationen, die jetzt beginnen, selbst mit einem unvollkommenen ersten Durchlauf, sind materiell besser aufgestellt als jene, die auf einen regulatorischen Stichtag warten, der zum Handeln zwingt. Der in diesem Leitfaden beschriebene Vorlagenrahmen, die Discovery-Methoden und die Prozessstrukturen bieten einen konkreten Ausgangspunkt.
Die Wahl des richtigen Tool für das KI-Systeminventar ist entscheidend, um ein revisionssicheres System of Record aufrechtzuerhalten. Für Organisationen, die ihr KI-Inventar innerhalb einer speziell für KI-Governance, Risiko und Compliance entwickelten Plattform operationalisieren möchten, bietet Enzai einen strukturierten Ansatz für Discovery, Klassifizierung und fortlaufende Pflege. Demo buchen, um zu sehen, wie dies in der Praxis funktioniert.
Enzai ist die führende Plattform für unternehmensweite KI-Governance, die speziell dafür entwickelt wurde, Organisationen vom abstrakten Regelwerk zur operativen Aufsicht zu führen. Unsere KI-Risikomanagement-Plattform bietet die spezialisierte Infrastruktur, die erforderlich ist, um Governance für agentische KI zu steuern, ein umfassendes KI-Inventar zu pflegen und die Compliance mit dem EU AI Act sicherzustellen. Durch die Automatisierung komplexer Workflows ermöglicht Enzai Unternehmen, die KI-Adoption mit Zuversicht zu skalieren und gleichzeitig die Ausrichtung an globalen Standards wie ISO 42001 und NIST zu wahren.
Referenzen
Verordnung (EU) 2024/1689 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz (Artificial Intelligence Act). Amtsblatt der Europäischen Union, August 2024.
ISO/IEC 42001:2023 - Informationstechnik - Künstliche Intelligenz - Managementsystem. Internationale Organisation für Normung, Dezember 2023.
Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. National Institute of Standards and Technology, Januar 2023.
U.S. Department of the Treasury, „Treasury veröffentlicht zwei neue Ressourcen zur Orientierung beim KI-Einsatz im Finanzsektor“, 19. Februar 2026. Enthält das Financial Services AI Risk Management Framework und das AI Lexicon. Das KI-Inventar ist das Kontrollziel GV-1.6.
Bank of England, FCA, PRA und PSR, „Künstliche Intelligenz und maschinelles Lernen“, DP5/22, Oktober 2022; PRA Supervisory Statement SS1/23, 2023.
McKinsey & Company, „Der Stand der KI Anfang 2024: Gen-AI-Adoption schießt in die Höhe und beginnt, Wert zu schaffen“, Mai 2024.
Verordnung (EU) 2024/1689, Artikel 113-114 (Inkrafttreten und Anwendungsdaten). Der von der Europäischen Kommission im November 2025 vorgeschlagene Digital Omnibus zu KI könnte die Fristen für Anhang III verlängern, vorbehaltlich des Trilogs.
Colorado SB 24-205, zum Verbraucherschutz bei künstlicher Intelligenz, unterzeichnet im Mai 2024. Ursprüngliches Wirksamkeitsdatum 1. Februar 2026; vorbehaltlich anhängiger gesetzgeberischer Änderungen.
Ermöglichen Sie Ihrer Organisation die Einführung, Steuerung und Überwachung von KI mit unternehmensgerechtem Vertrauen. Entwickelt für regulierte Organisationen, die im großen Maßstab operieren.

