Aufbau Ihres KI-Inventars bis zum 2. August 2026: Praxisleitfaden für EU-KMU

Auf einen Blick

Die wesentlichen Pflichten der KI-Verordnung greifen ab dem 2. August 2026 — Hochrisiko-Anforderungen nach den Artikeln 8 bis 15, Anbieterpflichten nach den Artikeln 16 bis 22, Betreiberpflichten nach Artikel 26, Transparenzpflichten nach Artikel 50 sowie die Eintragung in die EU-Datenbank nach Artikel 49. Keine dieser Pflichten lässt sich erfüllen, ohne dass jedes erfasste KI-System einzeln im Bestand geführt wird, einer benannten Person zugeordnet ist und auf aktuellem Stand gehalten wird. Die Verbote des Artikels 5 sind seit dem 2. Februar 2025 durchsetzbar, die GPAI-Pflichten seit dem 2. August 2025 (Art. 113). Ein heute aufgebautes Inventar muss daher von Anfang an die Prüfung auf verbotene Praktiken, die Verarbeitung der GPAI-Anbieterinformationen für Betreiber und die Risikoklassifizierung nach Risikostufen tragen. Die gute Nachricht für ressourcenknappe KMU: Sie führen mit großer Wahrscheinlichkeit längst vergleichbare Verzeichnisse — das Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO, das NIS2-Vermögenswertregister und das ISO 27001 Anhang A.5.9-Asset-Register. Das KI-Inventar baut man am sinnvollsten als Erweiterung dieser Register, nicht als getrenntes Parallel-Dokument. Dieser Leitfaden liefert das Inventarschema, eine Wiederverwendungslandkarte, drei KMU-Praxisbeispiele, die Lücken, in die Organisationen typischerweise tappen, und einen 60-Tage-Plan, der das Verzeichnis vor dem Stichtag fertigstellt.

Warum ein KI-Inventar bis zum 2. August 2026 unverzichtbar ist

Die KI-Verordnung kennt keine ausdrückliche Pflicht mit dem Namen „Inventar". Sie kennt aber mehr als ein Dutzend Pflichten, die ohne Inventar nicht erfüllbar sind — weil eine Compliance-Funktion erst dann wissen kann, welche KI-Systeme im Hause laufen, wer sie betreibt, was sie tun und welcher Risikoklasse sie unterfallen, wenn diese Informationen strukturiert vorliegen. Das Risikomanagementsystem nach Artikel 9 setzt eine Liste der Systeme voraus, an denen es ansetzen kann. Die technische Dokumentation nach Artikel 11 setzt voraus, dass die in den Anwendungsbereich fallenden Systeme überhaupt identifiziert sind. Die Betreiberpflichten nach Artikel 26 — menschliche Aufsicht, Monitoring, Protokollierung, Information betroffener Beschäftigter — knüpfen pro System an und lassen sich nicht systemweise erfüllen, ohne dass es ein Verzeichnis pro System gibt. Die Eintragung in die EU-Datenbank nach Artikel 49 ist selbst eine systembezogene Pflicht. Ohne Inventar lässt sich der Rest weder priorisieren noch belegen.

Die Bußgelder sind so kalibriert, dass die Lücke teuer wird. Artikel 99 setzt die Obergrenzen bei 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes für Verstöße gegen die Verbote (Art. 99 Abs. 3), bei 15 Mio. EUR oder 3 % für Verstöße gegen die Hochrisiko-Pflichten (Art. 99 Abs. 4) und bei 7,5 Mio. EUR oder 1 % für falsche, unvollständige oder irreführende Auskünfte gegenüber benannten Stellen und zuständigen Behörden (Art. 99 Abs. 5). Für KMU mildert Artikel 99 Abs. 6 den Schlag teilweise ab — angesetzt wird der niedrigere der beiden Werte (Absolutbetrag oder Prozentsatz), nicht der höhere. Die Erleichterung beseitigt aber weder die Bußgeld-Obergrenze noch greift sie für den schädlichsten Fehlertyp: nämlich erst im Verlauf einer behördlichen Prüfung festzustellen, dass man gar nicht weiß, welche KI im Haus läuft. Ein unvollständiges Inventar ist die Voraussetzung dafür, dass jede Antwort an die Behörde notwendig eine Schätzung wird — und die dritte Bußgeldkategorie ist genau dafür gemacht.

Hinzu kommt eine marktzugangsbezogene Dimension. Artikel 79 erlaubt der Marktüberwachungsbehörde, korrigierende Maßnahmen für nicht konforme Hochrisiko-Systeme anzuordnen — bis hin zur Marktrücknahme im EU-Binnenmarkt. Für einen B2B-SaaS-Anbieter, dessen Enterprise-Verträge Compliance-Zusicherungen enthalten und dessen Großkunden ab der zweiten Jahreshälfte 2025 die KI-VO-Konformität in der Lieferanten-Due-Diligence abfragen, wird das Fehlen eines auf Knopfdruck vorlegbaren System-Inventars zur kommerziellen Schwäche, lange bevor es zur regulatorischen Schwäche wird. Die Kunden, die als Erste danach fragen, sind die deutschen, französischen und niederländischen Großunternehmen mit reifen DSGVO-Lieferanten-Prüfprozessen. Dort wird man im späten 2026 nicht mehr auf die Antwort „Wir sind noch beim Mapping" warten.

Was als „KI-System" nach Artikel 3 Nummer 1 gilt

Artikel 3 Nummer 1 definiert ein KI-System als ein maschinengestütztes System, das für den Betrieb mit unterschiedlichen Graden von Autonomie ausgelegt ist, das nach Inbetriebnahme anpassungsfähig sein kann und das aus den Eingaben für explizite oder implizite Ziele ableitet, wie Ausgaben — etwa Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen — erzeugt werden, die physische oder virtuelle Umgebungen beeinflussen können. Die Definition lehnt sich bewusst eng an die 2023 überarbeitete OECD-Definition an und ist absichtlich weit gezogen. Wer den Wortlaut sorgfältig liest, kommt zu derselben ersten Reaktion: die Reichweite ist breiter, als sie auf den ersten Blick scheint.

Drei Konsequenzen ergeben sich für den Zuschnitt des Inventars. Erstens ist „maschinelles Lernen" keine Voraussetzung. Auch ein regelbasiertes Expertensystem, das Ausgaben aus Eingaben gegen eine Wissensbasis ableitet, fällt unter die Definition — selbst wenn die wenigsten Ingenieurinnen und Ingenieure das System „KI" nennen würden. Erwägungsgrund 12 nimmt einige klassische statistische und Optimierungsverfahren ohne inferenziellen Anteil aus, die Ausnahme ist allerdings eng gefasst und an den Rändern umstritten. Im Zweifel gilt: ins Inventar aufnehmen und schriftlich begründen, warum keine Risikoklassifizierung erforderlich ist.

Zweitens bedeutet „unterschiedliche Grade von Autonomie", dass die Grenze zwischen KI und konventioneller Software nicht entlang der Linie „Mensch in der Schleife" verläuft. Auch ein System mit zwingender menschlicher Freigabe für jede Ausgabe bleibt ein KI-System, sofern es Ausgaben inferiert. Die menschliche Aufsicht nach Artikel 14 ist dann eine Designeigenschaft des KI-Systems, kein Ausstieg aus dem Anwendungsbereich der Verordnung. Lebenslauf-Vorsortierung, die der Recruiting-Abteilung eine sortierte Auswahl präsentiert, bleibt ein KI-System — auch wenn die Personalverantwortlichen die endgültige Entscheidung formal treffen.

Drittens zieht die Formulierung „Ausgaben, die physische oder virtuelle Umgebungen beeinflussen können" eine lange Liste betrieblicher Software in den Anwendungsbereich, die in den meisten Häusern bisher nicht als KI etikettiert wird: dynamische Preisbildungsmodule, Fraud-Scoring, Kundenabwanderungs-Vorhersagen, Inhaltsmoderation, Empfehlungssysteme, automatische E-Mail-Klassifizierung, Bedarfsprognosen, vorausschauende Instandhaltung. Die meisten dieser Systeme landen nach der Klassifizierung im Bereich des minimalen Risikos — sie gehören aber trotzdem ins Inventar. Sinn des Verzeichnisses ist es, die Klassifizierung zu belegen, und nicht nur jene Systeme zu listen, die sich als hochriskant herausstellen.

Zuordnung des Inventars zu den KI-VO-Risikostufen

Jeder Eintrag im Inventar trägt eine Risikostufe, und diese Stufe steuert den Rest der Akte. Die fünf Kategorien — unzulässig, hochriskant, begrenztes Risiko, minimales Risiko und das GPAI-Overlay — sitzen auf demselben Verzeichnis, wobei ein einzelnes Produkt durchaus mehrere Inventar-Einträge erzeugen kann, wenn es mehrere unterschiedliche KI-Anwendungsfälle bündelt. Die Einträge sind als Compliance-Arbeitseinheiten zu behandeln, nicht als Lieferanten-Katalog.

Systeme mit unzulässigem Risiko nach Artikel 5 — acht verbotene Familien, die manipulative Techniken, Ausnutzung von Schutzbedürftigkeit, Social Scoring, rein profilingbasiertes Predictive Policing, ungezielte Auswertung von Gesichtsbildern, Emotionserkennung am Arbeitsplatz und in Bildungseinrichtungen, biometrische Kategorisierung nach sensiblen Merkmalen sowie biometrische Echtzeitidentifikation in öffentlich zugänglichen Räumen für Strafverfolgungszwecke umfassen — dürfen nicht als aktive Inventar-Einträge geführt werden. Trifft ein bestehendes System oder eine geplante Beschaffung auf eines der Verbote, dient der Inventar-Eintrag ausschließlich der Dokumentation der Stilllegungsentscheidung. Die Verbote sind seit dem 2. Februar 2025 durchsetzbar, also keine Zukunftspflicht mehr.

Hochrisiko-Einträge — Anhang-III-Kategorien plus Sicherheitsbauteile von Anhang-I-Produkten nach Artikel 6 Abs. 1 — tragen das schwerste Feldset. Der Pflichtenkatalog der Artikel 9 bis 49 erzeugt einen Dokumentationsumfang, den ein dünn geführter Inventar-Eintrag nicht halten kann. Bei Hochrisiko-Einträgen ist das Inventar daher am besten als Index zu führen, der auf eine separate technische Akte nach Artikel 11 und Anhang IV verweist; der Inventar-Eintrag selbst trägt nur die Metadaten, die eine Auditorin braucht, um zur Akte zu navigieren. Die materiellen Pflichten gelten ab dem 2. August 2026 für Hochrisiko-Systeme nach Anhang III und ab dem 2. August 2027 für die Produktsicherheits-Linie nach Anhang I in Verbindung mit Art. 6 Abs. 1.

Innerhalb von Anhang III greift ein zweiter Filter. Artikel 6 Abs. 3 enthält eine Ausnahme für Anhang-III-Systeme, die kein erhebliches Risiko erzeugen, weil sie eine eng umrissene Verfahrensaufgabe erfüllen, das Ergebnis einer zuvor abgeschlossenen menschlichen Tätigkeit verbessern, Entscheidungsmuster oder Abweichungen erkennen, ohne die menschliche Beurteilung zu ersetzen, oder eine vorbereitende Tätigkeit zu einer Anhang-III-Bewertung darstellen. Profiling natürlicher Personen schließt die Ausnahme in jedem Fall aus. Jeder Anhang-III-Eintrag braucht eine schriftliche Art.-6-Abs.-3-Analyse — entweder einen positiven Befund mit der konkret herangezogenen Variante und der dazugehörigen Begründung, oder einen negativen Befund, der bestätigt, dass das System weiterhin als hochriskant geführt wird.

Einträge mit begrenztem Risiko — Chatbots, Werkzeuge zur Erstellung von Deepfakes, KI-generierte Texte oder Medien, Emotionserkennung außerhalb der Verbotszone — tragen die Transparenzpflichten nach Artikel 50. Pro System muss das Inventar den Offenlegungsmechanismus festhalten: den Ort des Chat-Hinweises, die Wasserzeichen-Technik bei synthetischen Ausgaben, das redaktionelle Prüfprotokoll für KI-generierte Texte zu Themen von öffentlichem Interesse, die Hinweismechanik beim Einsatz von Deepfakes auf Betreiberseite. Die Pflichten des begrenzten Risikos gelten ebenfalls ab dem 2. August 2026. Anders als bei Hochrisiko gibt es hier keinen Ausnahmepfad: Jeder Chatbot braucht einen Hinweis, und das Inventar muss diesen belegen.

Einträge mit minimalem Risiko bilden den größten Anteil des Verzeichnisses. Die KI-Verordnung sieht für sie keine zwingenden Pflichten vor — gleichwohl muss der negative Befund festgehalten werden: die schriftlich begründete Feststellung, dass das System nicht in Anhang III fällt, nicht direkt mit natürlichen Personen interagiert und keine synthetischen Medien erzeugt. Die KI-Kompetenzpflicht nach Artikel 4 gilt unabhängig von der Risikostufe, sodass das Inventar den jeweiligen Mitarbeiter-Kreis pro System dokumentieren und bestätigen muss, dass er von der KI-Schulung erfasst ist.

GPAI ist kein eigener Tier, sondern eine Querverklammerung. Praktisch jeder KMU-Inventar-Eintrag, der auf ein Foundation Model — GPT-4o, Claude, Gemini, Mistral Large, Llama, Command — zurückgreift, ist ein Betreiber-Eintrag im Sinne von Artikel 53 Abs. 1 Buchst. b, der die Anbieterinformationen aus der vorgelagerten Wertschöpfungsstufe übernimmt. Das Inventar braucht ein eigenes Feld für die Identität und Version des vorgelagerten Modells, den Anbieter, den Verweis auf die veröffentlichte Trainingsdaten-Zusammenfassung und das Datum, zu dem die jüngste Anbieter-Anweisung für die Verwendung zuletzt geprüft wurde. Zwei Regelungsstränge sind dabei sauber zu trennen. Artikel 25 verlagert die Hochrisiko-Anbieterpflichten in drei Konstellationen auf einen nachgelagerten Akteur — beim Inverkehrbringen eines Hochrisiko-Systems unter eigenem Namen oder Kennzeichen, bei einer wesentlichen Veränderung eines bereits in Verkehr gebrachten Hochrisiko-Systems oder bei einer Änderung der Zweckbestimmung eines Nicht-Hochrisiko-Systems (einschließlich eines GPAI), durch die das System nach Artikel 6 zu einem Hochrisiko-System wird. Erwägungsgrund 109 adressiert einen anderen Fall: eine Organisation, die ein GPAI feinabstimmt oder anderweitig modifiziert, ohne daraus ein Hochrisiko-System zu machen. Hier sind die Pflichten des nachgelagerten Akteurs auf die Modifikation selbst beschränkt — typischerweise auf die Ergänzung der vorgelagerten technischen Dokumentation um die Informationen über die vorgenommenen Änderungen, einschließlich der hinzugekommenen Trainingsdatenquellen. Die meisten KMU überschreiten weder die eine noch die andere Schwelle, doch das Inventar ist der einzige Ort, an dem diese Trennlinie pro System dokumentiert wird.

Erforderliche Inventarfelder

Ein belastbares KI-Inventar arbeitet mit etwa fünfzehn Feldern pro Eintrag. Widerstehen Sie der Versuchung, mehr aufzunehmen — jedes zusätzliche Feld erhöht die Pflegelast, und nachhaltig ist nur das Verzeichnis, das die Mitarbeitenden bei jeder System-Änderung tatsächlich aktualisieren. Die folgende Liste ist die Mindestmenge, die die ab dem 2. August 2026 anwendbaren Pflichten trägt.

• Systemname und eindeutige Kennung — ein stabiles Etikett, das in der technischen Akte, in der EU-Datenbank-Eintragung, in Lieferantenverträgen und in den internen Change-Tickets einheitlich verwendet wird.
• Verantwortliche/r — eine namentlich benannte Einzelperson im Hause, die für die Aktualität des Eintrags und für das Auslösen einer erneuten Klassifizierung bei wesentlichen Änderungen einsteht. Eine Abteilung oder ein Team ist keine verantwortliche Person.
• Eigenentwicklung oder Drittanbieter — ob das System inhouse gebaut, als SaaS bezogen oder in ein größeres Produkt eingebettet ist. Diese Information steuert, ob Sie nach den Artikeln 25 und 26 als Anbieter, als Betreiber oder als beides auftreten.
• KI-VO-Risikostufe — unzulässig, hochriskant (mit Verweis auf Art. 6 Abs. 1 oder Art. 6 Abs. 2 in Verbindung mit dem konkreten Anhang-III-Punkt), begrenztes Risiko (mit dem konkreten Absatz aus Artikel 50), minimales Risiko, plus GPAI-Overlay-Kennzeichen, wo einschlägig.
• Begründung der Klassifizierung — eine kurze, prosafähige Rechtfertigung einschließlich eventueller Berufung auf die Ausnahme nach Artikel 6 Abs. 3. Vage Begründungen halten dem Audit nicht stand; der Maßstab lautet „dokumentiert, weil begründet".
• Vorgelagertes Modell — bei GPAI-Betreiber-Einträgen die Identität und Version des Modells, der Anbieter und das Datum, an dem die Anbieter-Anweisungen für die Verwendung nach Artikel 53 Abs. 1 Buchst. b zuletzt geprüft wurden.
• Zweckbestimmung — der konkrete Anwendungsfall in der Sprache der Anweisungen für die Verwendung nach Artikel 13. Die Drift zwischen Zweckbestimmung und tatsächlichem Einsatz gehört zu den häufigsten Audit-Befunden.
• DSGVO-Rechtsgrundlage — bei jedem System, das personenbezogene Daten verarbeitet, die Grundlage nach Art. 6 DSGVO (und gegebenenfalls die Bedingung nach Art. 9 bei besonderen Datenkategorien). Querverweis auf den entsprechenden VVT-Eintrag nach Art. 30 DSGVO.
• Herkunft der Trainingsdaten — Provenienz-Zusammenfassung mit Quelle, Lizenzbedingungen, Einhaltung der Urheberrechts-Opt-out-Vorgaben und etwaiger Datenminimierung oder Pseudonymisierung. Bei GPAI-Betreiber-Einträgen kann das Feld auf die veröffentlichte Trainingsdaten-Zusammenfassung des Anbieters verweisen.
• Art der Ausgabe — Vorhersage, Empfehlung, Klassifizierung, Inhaltserzeugung, Entscheidung. Die Ausgabeart steuert die Transparenzpflichten nach Artikel 50 und die Prüfung nach Art. 22 DSGVO.
• Auswirkung auf Entscheidungen — ob Ausgaben folgenreiche Entscheidungen über identifizierbare natürliche Personen beeinflussen, und falls ja, der betroffene Kreis (Beschäftigte, Bewerbende, Kundinnen und Kunden, Patientinnen und Patienten, Begünstigte). Dieses Feld signalisiert, wann eine separate DSFA nach Art. 35 DSGVO oder eine Grundrechte-Folgenabschätzung nach Artikel 27 KI-VO ausgelöst wird.
• Konzeption der menschlichen Aufsicht — die nach Artikel 14 tatsächlich umgesetzten Maßnahmen: Vorab-Prüfung vor Inbetriebnahme, Output-Validierung, Eingriffsmöglichkeit, Eskalationsschwellen, Eskalationswege. Generische Einträge wie „ein Mensch sieht das Ergebnis" bestehen den Audit-Maßstab nicht.
• Konformitätsbewertung — bei Hochrisiko-Einträgen das gewählte Verfahren (interne Kontrolle nach Anhang VI, Drittstellenbewertung nach Anhang VII bei Biometrie, integriertes Verfahren bei Anhang-I-Produkten), das Datum der jüngsten Bewertung und das Aktenzeichen der EU-Konformitätserklärung nach Artikel 47.
• EU-Datenbank-Registrierung — bei Hochrisiko-Einträgen, die unter Artikel 49 fallen, die Registrierungs-ID und das Datum der letzten Aktualisierung.
• Letzte Prüfung und nächster Auslöser — das Kalenderdatum der jüngsten Klassifizierungs-Überprüfung sowie die Ereignisse, die eine erneute Prüfung erzwingen (Modellwechsel, Änderung der Trainingsdaten, Erweiterung der Zweckbestimmung, Einbindung in einen neuen Geschäftsprozess).

Wiederverwendung vorhandener Strukturen

Das günstigste KI-Inventar ist dasjenige, das aus bestehenden Verzeichnissen erweitert wird, anstatt von Grund auf neu entstehen zu müssen. Drei vorhandene Artefakte decken die meisten Felder oben ab und bringen die nötige Pflegedisziplin gleich mit.

Das Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO (VVT) bildet die personenbezogene Datenachse jedes KI-Systems ab, das Daten über identifizierbare natürliche Personen verarbeitet. Das VVT enthält die Rechtsgrundlage, die Datenkategorien, die Kategorien der betroffenen Personen, die Empfänger, die Drittlandübermittlungen und die Aufbewahrungsfristen — sämtlich Felder, die das KI-Inventar entweder spiegeln oder per Referenz binden muss. Pragmatisch heißt das: im VVT eine Spalte „KI-System-Referenz" ergänzen und im KI-Inventar auf den entsprechenden VVT-Eintrag verweisen, statt die personenbezogenen Felder erneut zu erfassen. DSFAs nach Art. 35 DSGVO und Grundrechte-Folgenabschätzungen nach Artikel 27 KI-VO — anwendbar auf Betreiber, die öffentliche Stellen oder private Erbringer öffentlicher Dienstleistungen sind, sowie gesondert auf jede/n Betreiber/in (öffentlich oder privat) eines Anhang-III-§-5-Buchst.-b-Bonitätssystems oder eines Anhang-III-§-5-Buchst.-c-Risikobewertungs- oder Tarifierungssystems der Lebens- oder Krankenversicherung — verlinken aus dem Inventar-Eintrag heraus, statt im Eintrag selbst kopiert zu werden.

NIS2-Vermögenswertregister bilden, sofern vorhanden, die operative und informationssicherheitsbezogene Achse ab. NIS2-Umsetzungsgesetze der Mitgliedstaaten — die Umsetzungsfrist endete am 17. Oktober 2024, die Europäische Kommission eröffnete im November 2024 Vertragsverletzungsverfahren gegen 23 Mitgliedstaaten, die diese versäumt hatten; die Umsetzung lief in Wellen durch 2025 und 2026 weiter — verpflichten wesentliche und wichtige Einrichtungen zur Pflege eines IKT-Vermögens- und Abhängigkeitsregisters. Bei KMU im NIS2-Anwendungsbereich enthält dieses Register typischerweise bereits die Cloud-Plattformen, die SaaS-Abhängigkeiten und die kritischen Softwaresysteme, auf denen KI-Workloads laufen. Eine KI-Kennzeichnung im NIS2-Register und ein Rückverweis auf das KI-Inventar verzahnen beide Regime und verhindern den allzu häufigen Zustand, in dem das NIS2-Register einen externen SaaS-Dienst zeigt, ohne kenntlich zu machen, dass dieser Dienst einen KI-Anwendungsfall im Anwendungsbereich der KI-Verordnung umfasst.

ISO/IEC 27001:2022 fordert in Anhang A.5.9 (vormals A.8.1.1 in der Fassung von 2013) ein Verzeichnis von Informationen und sonstigen damit verbundenen Werten, einschließlich Software, Diensten und Information selbst. Bei ISO-zertifizierten KMU ist das nach A.5.9 geführte Asset-Inventar der natürliche Träger des KI-Verzeichnisses. Die von ISO 27001 geforderte Audit-Spur — Verantwortliche/r, Klassifizierung, Änderungshistorie — bildet bereits die KI-VO-Felder ab. Das KI-Inventar als Teilmenge des ISO-27001-Asset-Inventars zu behandeln, statt es als neues Artefakt zu führen, spart doppelte Pflege, koppelt das KI-Verzeichnis an die bestehende ISMS-Überprüfungs-Kadenz und verhindert den verbreiteten Zustand, in dem ISMS-Asset-Register und KI-Inventar in zueinander widersprüchliche Versionen auseinanderdriften.

Über diese drei hinaus lohnt der Blick auf zwei angrenzende Verzeichnisse: das Lieferanten-Register der Beschaffung (das in der Regel jeden externen SaaS-Dienst enthält und oft der schnellste Weg zu einer vollständigen Schatten-KI-Sichtung ist) und das Datenschutzeinwilligungs- bzw. Vertragsgrundlagen-Verzeichnis (das die DSGVO-Seite kundenbezogener KI-Systeme bereits trägt). Wenn das KI-Inventar als Föderation von Querverweisen über diese vorhandenen Verzeichnisse aufgesetzt wird statt als neue Tabelle, halbiert sich der Pflegeaufwand grob, und die regimeübergreifende Konsistenz, nach der Auditorinnen suchen, ergibt sich von selbst.

Drei KMU-Inventarbeispiele

Drei kurze Praxisfälle schärfen die Disziplin: ein HR-Tech-Anbieter, ein FinTech und ein MedTech-KMU — typisch für die jungen europäischen Unternehmen, die der Stichtag 2. August 2026 am stärksten trifft.

HR-Tech: SaaS-Anbieter mit 50 Beschäftigten in München

Das Produkt ist ein Bewerbermanagement-System mit zwei KI-getriebenen Funktionen: einer Lebenslauf-Zusammenfassung auf Basis von GPT-4o und einer internen Bewerber-Rangfolge, die auf den historischen Einstellungsdaten der Kunden trainiert wurde. Das Inventar enthält zwei getrennte Einträge, nicht einen. Eintrag A — Lebenslauf-Zusammenfassung — ist für sich genommen ein System mit begrenztem Risiko (Artikel 50 Abs. 1 Chatbot-ähnliche Transparenz, weil die Recruiterin eine als KI-erzeugt klar gekennzeichnete Zusammenfassung sieht), mit einem GPAI-Betreiber-Overlay, das auf OpenAI als vorgelagerten Anbieter verweist. Eintrag B — Bewerber-Rangfolge — ist eindeutig hochriskant nach Anhang III Nr. 4 Buchst. a (Beschäftigung, Personalbeschaffung, Bewerber-Auswahl), mit dem Anbieter in der Anbieterrolle, weil das System unter eigenem Namen im Binnenmarkt in Verkehr gebracht wird. Eintrag B trägt den vollen Pflichtenkatalog der Artikel 9 bis 49; Eintrag A trägt nur den Hinweis nach Art. 50 Abs. 1 plus den GPAI-Anbieter-Datensatz. Verantwortlicher beider Einträge ist die Produktleitung, mit einer designierten KI-VO-Verantwortlichkeit im Rechtsteam als Stellvertretung. Der Inventar-Eintrag verweist für beide Systeme auf das ISO-27001-Asset-Register (das Unternehmen ist zertifiziert) und auf das VVT für die personenbezogenen Felder. Beide Einträge führen den 2. August 2026 als Auslöser für die Fertigstellung der technischen Akte nach Artikel 11 und Anhang IV.

FinTech: Konsumkredit-Start-up mit 30 Beschäftigten in Vilnius

Das Produkt ist eine Konsumkredit-Antragsstrecke mit zwei KI-Komponenten: einem Kreditscoring-Modell, das auf internen Daten und Open-Banking-Signalen trainiert wurde, und einem Betrugserkennungsmodell, das auf der Transaktions-Telemetrie aufsetzt. Das Kreditscoring-Modell landet in Anhang III Nr. 5 Buchst. b — Bonitätsprüfung natürlicher Personen — und ist damit standardmäßig hochriskant; das Unternehmen tritt als Anbieter auf, bringt das System auf der eigenen Plattform in Verkehr und führt eine Konformitätsbewertung mittels interner Kontrolle nach Anhang VI durch. Das Betrugserkennungsmodell nimmt die Textebenen-Ausnahme in Anspruch, die direkt in Anhang III §5 Buchst. b geschrieben steht und „KI-Systeme, die zur Aufdeckung von Finanzbetrug eingesetzt werden", bereits aus der Bonitätskategorie ausschließt — das ist eine andere Ausnahme als die Verfahrensaufgaben-Ausnahme nach Art. 6 Abs. 3, die Anhang-III-Systeme allgemein filtert; der Inventar-Eintrag muss klar machen, welcher der beiden Ausstiege gewählt wird. Weil die Textebenen-Ausnahme eng zugeschnitten ist (sie deckt Betrugserkennung ab, nicht jedes Transaktions-Risikoscoring), hält das Rechtsteam vorsorglich einen reduzierten Hochrisiko-Kontrollsatz auf dem Betrugsmodell und löst eine Neuklassifizierung aus, sobald sich die Zweckbestimmung über die Betrugserkennung hinaus erweitert. Der Grenzfall ist ein auf Mistral Large gebauter Kunden-Support-Chatbot — er wird zu Eintrag C mit begrenztem Risiko und GPAI-Betreiber-Overlay. Der Querverweis auf das VVT ist hier entscheidend, weil Artikel 22 DSGVO (automatisierte Einzelentscheidungen) für den Kreditscoring-Eintrag einschlägig ist und das Inventar belegen muss, dass die betroffene Person das Recht auf menschliches Eingreifen, auf eigene Stellungnahme und auf Anfechtung der Entscheidung hat. Auch Artikel 27 KI-VO greift hier — jeder Betreiber eines Bonitätssystems nach Anhang III §5 Buchst. b muss eine Grundrechte-Folgenabschätzung durchführen, unabhängig davon, ob er öffentlich oder privat ist. Verantwortliche der beiden Hochrisiko-Einträge ist die Datenschutzbeauftragte; den Chatbot verantwortet die Leitung der Kundenoperationen.

MedTech: Remote-Monitoring-Start-up mit 20 Beschäftigten in Dublin

Das Produkt ist eine Anwendung zur Remote-Patienten-Überwachung mit einem einzigen KI-Anwendungsfall: einem Algorithmus, der klinisch relevante Veränderungen der Vitalwerte aus kontinuierlicher Wearable-Telemetrie erkennt. Das System ist als Medizinprodukt nach Verordnung (EU) 2017/745 (MDR) geregelt und trägt das CE-Kennzeichen unter diesem Regime. Der KI-Inventar-Eintrag ist hochriskant nach Artikel 6 Abs. 1 — die KI ist Sicherheitsbauteil eines Produkts, das von einer Anhang-I-EU-Harmonisierungsrechtsvorschrift (Medizinprodukte) erfasst wird und eine Drittstellen-Konformitätsbewertung erfordert. Die materiellen Hochrisiko-Pflichten der KI-VO greifen für diesen Eintrag erst ab dem 2. August 2027, nicht ab dem 2. August 2026 — wegen des verzögerten Anwendungsstarts für Art. 6 Abs. 1 nach Artikel 113. Die Konformitätsbewertung läuft integriert mit dem bestehenden MDR-Verfahren; die unter MDR tätige benannte Stelle deckt auch die KI-spezifische Bewertung ab, wobei die KI-VO-spezifischen Lieferungen (technische Dokumentation nach Artikel 11, Risikomanagement nach Artikel 9, Transparenz für medizinisches Fachpersonal nach Artikel 13) auf die bestehende technische Akte aufgesetzt werden. Der Inventar-Eintrag verweist auf die MDR-technische Akte, statt sie zu duplizieren; QMS-Verantwortlicher ist dieselbe Person, die bereits die MDR-Artikel-10-Qualitätsmanagement-Verantwortung trägt; das VVT für die Verarbeitung von Gesundheitsdaten nach Art. 9 Abs. 2 Buchst. h DSGVO ist verlinkt. Die Falle ist hier der verzögerte Stichtag: Ein MedTech-Unternehmen, das den 2. August 2026 fälschlich als Auslöser ansieht, läuft die parallele Konformitätsarbeit zwölf Monate zu früh.

Lücken, in die KMU oft tappen

Drei Lückenmuster tauchen in der KMU-Inventararbeit immer wieder auf, und jedes einzelne unterspült das Verzeichnis still, sofern es nicht aktiv gejagt wird.

Schatten-KI ist die größte Lücke. Marketing-Teams nehmen Jasper, ChatGPT Team oder Copy.ai für Content-Entwürfe in Betrieb. Vertriebsteams hängen Gong, Apollo oder Lavender an Anrufmitschnitte und E-Mail-Outreach. Engineering-Teams arbeiten ohne förmliche Beschaffung mit GitHub Copilot, Cursor oder Codeium. HR fährt Mitarbeitendenbefragungen über ChatGPT und führt offene Antworten durch Sentiment-Klassifizierer. Jede dieser Praktiken ist ein KI-Anwendungsfall nach Artikel 3 Nr. 1, fast immer im Bereich des begrenzten oder minimalen Risikos für sich genommen, doch unsichtbar für das zentrale Inventar, solange niemand fragt. Die Antwort ist verfahrensförmig: ein einseitiges Erklärungsformular, das jede Abteilungsleitung quartalsweise alle eingesetzten KI-Werkzeuge der vergangenen sechs Monate auflistet, mit Abgleich gegen die Beschaffungs-Kreditkartenabrechnung und das SaaS-Ausgabenbuch. Die erste Erklärungsrunde fördert in einem typischen 50-Personen-SaaS-Unternehmen zwischen zwölf und zwanzig KI-Werkzeuge zutage, die der zentralen Compliance bislang unbekannt waren.

Eingebettete KI in SaaS-Produkten ist die zweite Lücke. Zunehmend hat das B2B-SaaS-Standardprodukt, das die Organisation seit Jahren nutzt, in den Jahren 2024 und 2025 unauffällig KI-Funktionen erhalten — Salesforce Einstein, HubSpot AI, Notion AI, Slack AI, Zoom AI Companion, Microsoft 365 Copilot, Google-Workspace-Gemini-Funktionen, Atlassian Intelligence. Die nutzende Organisation ist Betreiberin jeder dieser KI-Teilsysteme, auch wenn die Beschaffung sich ursprünglich auf die zugrundeliegende Produktivitäts-Software bezog. Das Inventar muss jede KI-Teilfunktion als eigenen Eintrag führen — nicht als unspezifische Sammelposition unter dem SaaS-Hauptprodukt. Jeder Anbieter ist seinerseits GPAI-Betreiber oberhalb eines vorgelagerten Modell-Anbieters, sodass die Anbieterkette über drei Ebenen läuft: Foundation Model (OpenAI/Anthropic/Google) → SaaS-Anbieter (HubSpot/Microsoft/Slack) → nutzende Organisation. Der Inventar-Eintrag muss alle drei Ebenen benennen, damit die Betreiberpflichten durchsetzbar sind.

Modellwechsel sind die dritte und tückischste Lücke. Ein SaaS-Anbieter wechselt das vorgelagerte GPAI-Modell — etwa von GPT-4 auf GPT-4o oder von Claude 3.5 auf Claude 4 — ohne die Produktoberfläche zu verändern, und der KI-Inventar-Eintrag auf der Betreiberseite wird im Stillen falsch. Die Antwort ist ein Inventarfeld „Modellversion fixiert" plus eine Neuklassifizierungs-Auslösung, sobald sich das vorgelagerte Modell ändert. Bei reifen Anbietern wird die Änderung über einen Release-Notes-Kanal bekanntgegeben, den das Beschaffungsteam abonnieren sollte; bei weniger reifen Anbietern muss der Inventar-Eintrag explizit festhalten, dass die Identität des vorgelagerten Modells volatil ist, und die Prüfungs-Kadenz ist dichter zu setzen (quartalsweise statt jährlich).

Häufige Probleme bei der Verantwortlichkeitszuweisung

Der häufigste Grund, warum ein KI-Inventar in die Bedeutungslosigkeit driftet, ist die Zuweisung der Verantwortung an ein Team oder eine Abteilung statt an eine namentlich benannte Person. „Das Produktteam verantwortet Eintrag 7" ist keine Antwort, wenn sich das System wesentlich ändert und niemand den Eintrag aktualisiert — weil niemand persönlich zur Aktualisierung verpflichtet war. Die Disziplin, die jedes andere regulatorische Verzeichnis zusammenhält — die namentlich benannte DSB hinter dem VVT, die namentlich benannte CISO hinter dem ISO-27001-Asset-Register, die namentlich benannte NIS2-Kontaktstelle in der Mitgliedstaaten-Meldung — ist auch die Disziplin, die das KI-Inventar braucht.

Drei Modelle bewähren sich in der Praxis. Das erste ist eine zentrale KI-VO-Verantwortlichkeit, üblicherweise in der Rechts- oder Compliance-Funktion verortet, die das zentrale Verzeichnis hält und für die Einträge mit dem höchsten Risiko (die Hochrisiko-Anhang-III-Systeme, deren technische Akte nach Artikel 11 funktionsübergreifend gefüllt werden muss) als benannte Person eintritt. Das zweite ist ein föderiertes Modell, in dem die KI-VO-Verantwortlichkeit das Verzeichnis und die Methodik trägt, während die Produkt- oder Feature-Verantwortlichen pro Eintrag namentlich genannt werden — angemessen für SaaS-Organisationen, in denen jedes Quartal neue KI-Features ausgerollt werden und eine zentrale Eintrags-Verantwortung zum Engpass würde. Das dritte ist ein Co-Verantwortlichkeits-Modell, in dem jeder Hochrisiko-Eintrag eine fachliche Verantwortliche (das Produktmanagement oder die Leitung der jeweiligen Funktion) und eine kontrollierende Verantwortliche (DSB oder KI-VO-Lead) hat — die fachliche Verantwortliche ist für die Aktualität des Eintrags bei Systemveränderungen verantwortlich, die kontrollierende Verantwortliche dafür, dass der Pflichtenkatalog erfüllt wird. Jedes der drei Modelle ist verteidigungsfähig; nicht verteidigungsfähig ist es, Einträge mit Team-Verantwortung oder ohne Verantwortliche zu führen.

Ein zweites Problem der Verantwortlichkeitszuweisung ist die fehlende Gegenseite bei funktionsübergreifenden Einträgen. Das HR-Tech-Beispiel oben ist der Lehrbuchfall: Die Produktverantwortliche der Bewerber-Rangfolge ist von der Aufgabe her bestens platziert, die technische Akte aktuell zu halten — die Pflicht zur Information betroffener Beschäftigter nach Artikel 26 Abs. 7 trifft jedoch die HR-Funktion auf der Betreiberseite des Kunden, nicht den Anbieter. Wenn der Anbieter im Inventar-Eintrag keine Gegenseite-Verantwortliche bei jedem Kunden benennen lässt, sind die kaskadierenden Betreiberpflichten nach Artikel 26 nicht belegbar, und auch die eigenen Anweisungen für die Verwendung nach Artikel 13 lassen sich nicht ordnungsgemäß adressieren. Onboarding-Dokumente und Master-Service-Vertrag brauchen eine Klausel, die den Kunden zur Benennung einer KI-VO-Betreiber-Verantwortlichen vor Aktivierung verpflichtet.

Artikel 26 Abs. 5 verdient eine abschließende Erwähnung, weil er zu den wenigen Betreiberpflichten gehört, die selbst diszipliniert geführte Inventare auf dem falschen Fuß erwischen. Betreiber von Hochrisiko-KI-Systemen müssen den Betrieb des Systems anhand der Anweisungen für die Verwendung überwachen und gegebenenfalls die Anbieter nach Artikel 72 informieren. Haben Betreiber Anlass zu der Annahme, dass die Verwendung gemäß den Anweisungen dazu führen kann, dass das System ein Risiko im Sinne von Artikel 79 Abs. 1 darstellt, müssen sie unverzüglich den Anbieter oder Vertreiber sowie die zuständige Marktüberwachungsbehörde informieren — und die Verwendung des Systems aussetzen. Praktisch heißt das: Jeder Hochrisiko-Inventar-Eintrag braucht eine namentlich benannte Monitoring-Verantwortliche auf der Betreiberseite, einen dokumentierten Eskalationsweg, der bei der zuständigen nationalen Behörde endet, und ein schriftliches Aussetzungs-Protokoll, das ohne weitere interne Freigabe ausgelöst werden kann. Das Versäumen dieser Benennungen — erst nach Inbetriebnahme — gehört zu den häufigsten Compliance-Befunden in den frühen Vollzugsverfahren.

Der 60-Tage-Aufbauplan

Sechzig Tage reichen für eine belastbare Erstversion des Inventars, sofern die Arbeit sauber sequenziert ist, die Geschäftsleitung sich von Beginn an auf den Takt verpflichtet und vorhandene Verzeichnisse wiederverwendet statt verdoppelt werden. Der Plan unten unterstellt ein typisches 30- bis 100-Personen-KMU ohne bisherige KI-Governance-Funktion und mit einer funktionsübergreifend benannten KI-VO-Verantwortlichkeit für die Arbeit.

Tag 1 bis 10 — Reichweite und Wiederverwendungs-Zuordnung. Die KI-VO-Verantwortlichkeit holt das vorhandene VVT, das ISO-27001-Asset-Inventar (sofern einschlägig), das NIS2-Register (sofern im Anwendungsbereich), die Beschaffungs-Lieferantenliste und das SaaS-Ausgabenbuch zusammen. Jeder Eintrag in diesen Verzeichnissen wird auf KI-Relevanz gesichtet, KI-berührte Einträge werden für das Inventar markiert. Die Verantwortliche entwirft das Inventarschema — die fünfzehn Felder oben, mit organisationsspezifischen Erweiterungen — und legt es der DSB, der CISO (sofern vorhanden) und einer Sponsorin auf der Geschäftsleitung zur Freigabe vor. Im selben Zeitfenster wird die Werkzeugfrage geklärt: Tabelle, GRC-Plattform oder Erweiterung der VVT-Werkzeuge. Für KMU ohne GRC-Plattform genügt für die Erstversion eine strukturierte Tabelle unter Versionskontrolle mit Pflicht-Prüffeldern.

Tag 11 bis 30 — Erfassung und Befüllung. Die Schatten-KI-Sichtung läuft in diesem Zeitfenster: ein einseitiges Erklärungsformular an jede Abteilungsleitung, ein Abgleich mit den SaaS-Ausgaben und strukturierte Interviews mit jeder Funktionsleitung (Produkt, Engineering, Marketing, Vertrieb, Kundenservice, HR, Finanzen, Operations). Aus jeder Erklärung wird ein vorläufiger Inventar-Eintrag. Die KI-VO-Verantwortlichkeit befüllt die Metadatenfelder dort, wo das vorhandene VVT und das Asset-Register die Daten bereits enthalten, und öffnet eine eigene Datenerhebung nur für die genuin KI-spezifischen Felder (Zweckbestimmung, Ausgabeart, vorgelagertes Modell, Trainingsdaten-Herkunft, Konzeption der menschlichen Aufsicht). Bis zum Ende von Tag 30 hat jeder bekannte KI-Anwendungsfall einen vorläufigen Inventar-Eintrag, auch wenn die Risikoklassifizierung vorläufig und die Begründung skelettartig ist.

Tag 31 bis 50 — Klassifizierung und Lückenanalyse. Die KI-VO-Verantwortlichkeit führt jeden vorläufigen Eintrag durch den Entscheidungsbaum (acht Fragen zu Artikel 5, Anhang III, Artikel 6 Abs. 1, Artikel 6 Abs. 3, Anbieter-/Betreiber-Status, GPAI-Overlay, Wechselwirkung mit Art. 50 Abs. 1, Art. 50 Abs. 2/4 zu synthetischen Inhalten und Art. 51 zu systemischem Risiko). Jeder Eintrag erhält eine Risikostufe mit schriftlicher Begründung. Für Hochrisiko- und Begrenzte-Risiko-Einträge führt die Verantwortlichkeit eine Lückenanalyse gegen den jeweiligen Pflichtenkatalog durch: bei Hochrisiko der dreizehn-Punkte-Basisrahmen aus den Artikeln 9 bis 49, bei begrenztem Risiko die vier Hinweispflichten nach Artikel 50. Aus jeder Lücke wird eine Behebungsaufgabe mit benannter Verantwortlichkeit und Zieldatum, das gegen den 2. August 2026 (oder den 2. August 2027 für Anhang-I-Art.-6-Abs.-1-Einträge) gesetzt wird. Auch der Umfang der DSFA und der Grundrechte-Folgenabschätzung wird in diesem Zeitfenster festgelegt: Jeder Hochrisiko-Eintrag, der personenbezogene Daten verarbeitet, löst eine DSFA-Prüfung aus, und jeder Hochrisiko-Eintrag, der von einer öffentlichen Stelle, von einem privaten Anbieter öffentlicher Dienste oder von jedem/jeder Betreiber/in eines Bonitätssystems nach Anhang III §5 Buchst. b oder eines Lebens- oder Krankenversicherungs-Risikosystems nach Anhang III §5 Buchst. c eingesetzt wird, löst eine Grundrechte-Folgenabschätzung nach Artikel 27 aus.

Tag 51 bis 60 — Freigabe und Betriebs-Kadenz. Inventar und Behebungs-Backlog werden der Geschäftsleitung zur Freigabe vorgelegt. Der Tagesordnungspunkt KI-Verordnung wird als wiederkehrender quartalsweiser Aufsichtsrat-Tagesordnungspunkt verankert. Die Verantwortlichen jedes Hochrisiko-Eintrags werden schriftlich förmlich benannt, und die Monitoring-Verantwortlichen nach Artikel 26 Abs. 5 mit Aussetzungsbefugnis werden bestätigt. Kundenseitige Verträge und Onboarding-Unterlagen werden auf die Anweisungen für die Verwendung nach Artikel 13 und die Betreiber-Weitergabe-Klauseln nach Artikel 26 hin überprüft. Das KI-Schulungsprogramm nach Artikel 4 wird abgesteckt und das Inventar dafür genutzt, die Mitarbeitenden-Kohorten zu identifizieren, die jedes System bedienen oder nutzen. Für das Ende des ersten Quartals 2027 wird ein erstes internes Inventar-Audit angesetzt — sechs Monate, nachdem die Pflichten greifen, lange genug, dass der Live-Betrieb erste Befunde liefert, und kurz genug, um Lücken vor dem ersten externen Audit-Zyklus noch zu schließen. Die Zweitversion-Überprüfung des Inventars selbst wird für das Ende des zweiten Quartals 2027 angesetzt.

Fazit und nächste Schritte

Der Stichtag 2. August 2026 ist fest und asymmetrisch: Der Preis, beim Inventar zu spät zu sein, ist deutlich höher als der Preis, früh zu sein — denn fast jede andere Pflicht der KI-Verordnung hängt am Inventar. Die Arbeit ist zugleich ungewöhnlich gut auf das ausgerichtet, was europäische KMU bereits gut beherrschen — Verarbeitungsverzeichnisse nach Art. 30 DSGVO, NIS2-Vermögenswertregister, ISO-27001-Asset-Inventare —, sodass der zusätzliche Aufwand spürbar geringer ausfällt, als die Schlagzeile der Verordnung suggeriert. Die Falle besteht darin, das KI-Inventar als getrenntes Parallel-Dokument zu führen, statt es als Erweiterung der ohnehin geführten Verzeichnisse anzulegen. Bauen Sie es als Föderation, weisen Sie pro Eintrag eine Einzelperson als Verantwortliche aus und behandeln Sie Schatten-KI, eingebettete SaaS-KI und Modellwechsel als die drei Lückenkategorien, die das Verzeichnis still aushöhlen, sofern sie nicht aktiv aufgespürt werden.

Praktisch sehen die nächsten sechzig Tage für ein KMU vom Nullzustand so aus: in der ersten Woche die KI-VO-Verantwortlichkeit benennen, in der zweiten Woche das Schema und den Wiederverwendungs-Plan festziehen, in den Wochen drei und vier die Schatten-KI-Sichtung fahren, in den Wochen vier und fünf eine erste vollständige Verzeichnisversion befüllen, in den Wochen sechs und sieben jeden Eintrag klassifizieren und auf Lücken prüfen, in der neunten Woche das freigegebene Verzeichnis und die Behebungs-Roadmap der Geschäftsleitung vorlegen. Bis zur zehnten Woche ist das Inventar kein Projekt mehr — es ist ein operatives Standardelement mit quartalsweiser Prüfungs-Kadenz und einer benannten Verantwortlichen pro Eintrag. Genau diese Haltung honoriert der Stichtag 2. August 2026, und sie ist es auch, die den verbleibenden Pflichten-Backlog der KI-Verordnung handhabbar macht.