ki-inventar

/ki-inventar

Zweck

Dieses Inventar dient der strukturierten Erfassung aller KI-Systeme einer Organisation nach Art. 6 ff. KI-VO (VO 2024/1689). Der zentrale Grundsatz: Rolle und Risikoklasse werden je KI-System bewertet, nicht je Unternehmen. Eine Organisation kann Anbieter von System A, Betreiber von System B und Einführer von System C sein. Jede Kombination löst nach der KI-VO unterschiedliche Pflichten aus (z. B. Art. 16 ff. für Anbieter, Art. 26 für Betreiber). Verstöße können nach Art. 99 KI-VO mit Bußgeldern bis zu 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes geahndet werden. Das Inventar dient als Basis für alle nachgelagerten Pflichten; die eigentliche Obligationenanalyse erfolgt im Gespräch, nicht aus einer fest codierten Tabelle.

Eingaben

• Konfiguration aus ~/.claude/plugins/config/claude-fuer-deutsches-recht/ki-governance/CLAUDE.md
• Bestehendes Inventar unter ki-systeme.yaml (gleicher Konfigurationspfad)
• Systembeschreibung des Nutzers oder vorhandene Unterlagen (technische Dokumentation, Verträge)

Ablauf

1. Konfiguration lesen. Prüfen, ob das Praxisprofil vorhanden und befüllt ist. Fehlen [PLATZHALTER]-Marker, Nutzer an /ki-governance:cold-start-interview verweisen.

2. Inventar lesen. Liegt unter ki-systeme.yaml. Existiert die Datei nicht, bei erstem add-Befehl mit leerem systeme:-Block anlegen.

3. Befehl ausführen:

   • Kein Argument oder list → Inventartabelle anzeigen (siehe Listenformat)
   • add → Aufnahmefluss starten
   • edit <id> → aktuellen Datensatz zeigen, Änderungsfrage stellen, ein Feld ändern, bestätigen, schreiben
   • classify <id> → Klassifizierungsdurchlauf für bestehenden Datensatz starten, rolle, klasse, rollenbasis und klassenbasis aktualisieren
   • show <id> → vollständigen Datensatz anzeigen

4. Nach list Dashboard anbieten: „Dashboard gewünscht? Filterbar nach Status / Klasse / EU-Nexus / Eigentümer. Auf Wunsch."

5. Jede Aktion mit Anschlusshinweis abschließen:

   Erfasst. Wenn Sie die Pflichten für dieses System durcharbeiten möchten, fragen Sie einfach – ich führe die Analyse im Gespräch durch und markiere, wo die Artikel-Zuordnung Ihre Verifizierung erfordert. Pflichten werden nicht aus einer Tabelle abgeleitet, weil die Zuordnung komplex und die KI-VO noch in der Einführungsphase (bis 2027) ist.

Listenformat

Kompakte Tabelle:

ID	Name	Eigentümer	Status	EU-Nexus	Rolle	Klasse	Nächste Prüfung
sys-001	Lebenslauf-Screening	HR / Schmidt	in_produktion	ja	Betreiber	hochrisiko	2026-08-01
sys-002	E-Mail-Drafting-Assistent	IT / Meier	in_produktion	nein	Betreiber	begrenzt	2026-12-01

Unter der Tabelle: Zählung nach Klasse und: „N Systeme zur Prüfung innerhalb von 30 Tagen." Außerdem: Bußgeldrahmen kurz einblenden: Art. 99 Abs. 3 KI-VO – bis 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes bei schwerwiegenden Verstößen [gegen aktuellen KI-VO-Text prüfen].

Aufnahmefluss (Interview)

Felder einzeln abfragen (oder Einfügen akzeptieren). Pflichtfelder: name, eigentümer, beschreibung, status, eu_nexus. Rest kann zurückgestellt werden – explizit darauf hinweisen: „Sie können die Klassifizierung mit /ki-governance:ki-inventar classify <id> nachholen."

1. Name. Kurzbezeichnung des Systems.
2. Eigentümer. Person oder Team, das täglich für das System verantwortlich ist.
3. Beschreibung. Ein bis zwei Sätze: Was tut es, und mit welchen Daten?
4. Status. geplant | in_entwicklung | in_produktion | ausgemustert
5. EU-Nexus. Wird das System in der EU/EWR betrieben, EU/EWR-Nutzern angeboten oder erzeugt es Ausgaben, die Personen in der EU/EWR betreffen? Wenn ja, gilt die KI-VO. Transparenzpflichten nach Art. 50 KI-VO beachten (z. B. Offenlegung bei Chatbots, Deepfake-Kennzeichnung).
6. Klassifizierung jetzt? Anbieten, den Durchlauf sofort zu starten oder zurückzustellen.

ID vergeben: sys-NNN (nächste aufsteigende Nummer in der Datei).

Klassifizierungsdurchlauf

Der Durchlauf ergibt rolle, rollenbasis, klasse, klassenbasis. Beide Begründungen werden markiert [gegen aktuellen KI-VO-Text prüfen] – nicht als Absicherung, sondern weil die Artikel-Zuordnung komplex ist und die KI-VO noch in der Einführungsphase ist. Der Anwalt trägt die Verantwortung für die Verifizierung.

Schritt 1: Rolle

Wer macht was mit diesem System?

Optionen mit unterscheidendem Merkmal:

• Anbieter (Art. 3 Nr. 3 KI-VO) – Sie entwickeln das KI-System (oder lassen es entwickeln) und bringen es unter eigenem Namen oder Warenzeichen auf den EU-Markt oder in Betrieb.
• Betreiber (Art. 3 Nr. 4 KI-VO) – Sie nutzen das KI-System in eigener Verantwortung, nicht zu rein persönlichen nicht-beruflichen Zwecken. (Häufigster Fall innerhalb von Unternehmen.) Betreiberpflichten: Art. 26 KI-VO.
• Einführer (Art. 3 Nr. 6 KI-VO) – Sie bringen ein KI-System aus einem Nicht-EU-Anbieter in die EU/EWR.
• Händler (Art. 3 Nr. 7 KI-VO) – Sie machen ein KI-System auf dem EU-Markt verfügbar, ohne Anbieter oder Einführer zu sein.
• Bevollmächtigter (Art. 3 Nr. 5 KI-VO) – Sie handeln im Auftrag eines Nicht-EU-Anbieters und sind in der EU/EWR ansässig.
• Produkthersteller (Art. 3 Nr. 15 KI-VO) – Sie integrieren ein KI-System in ein Produkt unter eigenem Namen/Warenzeichen. Werden wie ein Anbieter behandelt.

Doppelrollen-Flag. Wenn der Nutzer ein Anbieter-System wesentlich ändert (Fine-Tuning auf eigenen Daten, Änderung des vorgesehenen Verwendungszwecks, Rebranding), kann er zum Anbieter des geänderten Systems werden – auch wenn er als Betreiber begann. Hinweis geben, wann immer eine Änderung über die Konfiguration hinausgeht. [gegen aktuellen KI-VO-Text prüfen – Art. 25 KI-VO, Anbieterpflichten und wesentliche Änderung]

Rolle schreiben. rollenbasis in einem Satz schreiben.

Schritt 2: Risikoklasse

Was tut das System, und fällt der Anwendungsfall in eine regulierte Kategorie?

In dieser Reihenfolge prüfen:

A. Art. 5 KI-VO – Verbotene Praktiken [gegen aktuellen KI-VO-Text prüfen – Art. 5]

Zusammenfassungen, kein endgültiger Text:

• Unterschwellige oder täuschende Techniken, die das Verhalten wesentlich verzerren
• Ausnutzung von Schwachstellen (Alter, Behinderung, sozioökonomische Lage) zur wesentlichen Verhaltensbeeinflussung
• Social Scoring durch öffentliche Stellen mit nachteiligen Folgen
• Echtzeit-Fernidentifizierung biometrischer Merkmale in öffentlich zugänglichen Räumen zur Strafverfolgung (enge Ausnahmen)
• Biometrische Kategorisierung zur Ableitung von Rasse, politischen Meinungen, Gewerkschaftszugehörigkeit, religiösen oder weltanschaulichen Überzeugungen, Sexualleben oder sexueller Orientierung
• Emotionserkennung am Arbeitsplatz oder in Bildungseinrichtungen (Ausnahmen: Medizin, Sicherheit)
• Anlegen von Gesichtserkennungs-Datenbanken durch Scraping aus Internet oder CCTV
• Prädiktive Polizeiarbeit allein auf Basis von Persönlichkeitsmerkmalen

Trifft zu → Klasse ist verboten. Anwendungsfall als Stopp markieren und an den Prohibited-Practice-Workflow des Governance-Teams übergeben.

B. Anhang III – Hochrisiko-Bereiche [gegen aktuellen KI-VO-Text prüfen – Anhang III]

1. Biometrische Identifizierung und Kategorisierung
2. Kritische Infrastruktur (digitale Infrastruktur, Straßenverkehr, Wasser, Gas, Heizung, Strom)
3. Allgemeine und berufliche Bildung (Zugang, Bewertung, Proctoring, Überwachung auf unerlaubtes Verhalten)
4. Beschäftigung, Arbeitnehmerverwaltung, Selbständigkeit – Einstellung, Auswahl, Beförderung, Kündigung, Aufgabenzuweisung, Überwachung, Leistung
5. Wesentliche private und öffentliche Dienste (Sozialleistungen, Kreditwürdigkeit natürlicher Personen, Risikobewertung und -bepreisung bei Leben-/Krankenversicherung, Notfallmanagement)
6. Strafverfolgung (Risikobewertung, Polygraphie, Deepfake-Erkennung, Zuverlässigkeit von Beweisen, Profiling)
7. Migration, Asyl, Grenzkontrolle (Risikobewertung, Reisedokumentenprüfung, Antragsbearbeitung)
8. Justiz und demokratische Prozesse (Recherche und Auslegung, Beeinflussung von Wahlen)

Trifft zu → Klasse ist hochrisiko. Anhang-III-Bereich und Unterabschnitt notieren. Betreiber-Pflichten gemäß Art. 26 KI-VO prüfen; bei öffentlichen Stellen oder öffentlich finanzierten Diensten gilt Art. 27 KI-VO (FRIA – Folgenabschätzung für Grundrechte).

C. Allzweck-KI (Art. 51 KI-VO und folgende) [gegen aktuellen KI-VO-Text prüfen]

• Allzweck-KI: Auf großen Datenmengen trainiertes Modell, auf Allgemeinheit ausgelegt, in der Lage, kompetent eine breite Palette verschiedener Aufgaben zu erfüllen.
• Allzweck-KI + systemisches Risiko: Kumulierter Rechenaufwand > 10^25 FLOPs oder von der Kommission als systemisch eingestuft.

D. Begrenzte Risikoklasse. Chatbots im Kontakt mit natürlichen Personen, Deepfakes, Emotionserkennung und biometrische Kategorisierung außerhalb des Anwendungsbereichs von Art. 5 – Transparenzpflichten nach Art. 50 KI-VO gelten.

E. Minimale Risikoklasse. Alles andere.

Klasse schreiben. klassenbasis in einem Satz schreiben unter Angabe des Artikels oder Anhang-Eintrags, markiert [gegen aktuellen KI-VO-Text prüfen].

Schritt 3: Empfehlungen

Drei nächste Schritte anbieten:

1. „Möchten Sie, dass ich die Pflichten für dieses System durcharbeite? Ich mache das im Gespräch – keine Tabelle."
2. „Möchten Sie /ki-governance:aia-generation starten, um eine vollständige KI-Folgenabschätzung zu erstellen?"
3. „Möchten Sie ein nächstes Prüfdatum setzen? Ich füge es dem Inventar hinzu."

Datensatzformat

systeme:
  - id: sys-001
    name: "Lebenslauf-Screening-Tool"
    eigentümer: "HR / Schmidt"
    beschreibung: "Filtert eingehende Lebensläufe nach Stellenkriterien"
    status: in_produktion          # geplant | in_entwicklung | in_produktion | ausgemustert
    eu_nexus: true                 # betrieben, angeboten oder betrifft Personen in der EU/EWR
    rolle: betreiber               # anbieter | betreiber | einführer | händler | bevollmächtigter | produkthersteller
    rollenbasis: "Wir lizenzieren von AnbieterX und betreiben intern [gegen aktuellen KI-VO-Text prüfen]"
    klasse: hochrisiko             # verboten | hochrisiko | begrenzt | minimal | allzweck | allzweck_systemisch
    klassenbasis: "Anhang III Nr. 4 lit. a – Beschäftigung, Einstellungsauswahl [gegen aktuellen KI-VO-Text prüfen]"
    pflichten_bewertet: false
    pflichten_hinweis: "Zu prüfen als Betreiber eines hochriskanten Systems: menschliche Aufsicht (Art. 14 KI-VO), Eingabedatenqualität, Überwachung, Aufzeichnung, Unterrichtung von Arbeitnehmern, FRIA wenn öffentliche Stelle/Dienst (Art. 27 KI-VO) [gegen aktuellen KI-VO-Text prüfen]"
    art50_transparenz: "Offenlegungspflicht prüfen (Art. 50 KI-VO) [prüfen]"
    naechste_pruefung: "2026-08-01"
    pruef_ausloeser: "bei wesentlicher Änderung oder jährlich"
    erstellt: "2026-05-18"
    aktualisiert: "2026-05-18"

Quellen und Zitierweise

Verbindliche Zitierweise gemäß ../references/zitierweise.md.

Leitende Normen:

• Art. 3 Nr. 3, 4, 5, 6, 7 KI-VO (VO 2024/1689) – Definitionen [Primärquelle – EUR-Lex]
• Art. 5 KI-VO – Verbotene Praktiken [Primärquelle – EUR-Lex]
• Art. 6 KI-VO i.V.m. Anhang III – Hochrisiko-KI-Systeme [Primärquelle – EUR-Lex]
• Art. 14, 16, 26 KI-VO – Betreiber- und Anbieterpflichten [Primärquelle – EUR-Lex]
• Art. 27 KI-VO – Folgenabschätzung für Grundrechte (FRIA) [Primärquelle – EUR-Lex]
• Art. 50 KI-VO – Transparenzpflichten [Primärquelle – EUR-Lex]
• Art. 99 KI-VO – Bußgeldrahmen [Primärquelle – EUR-Lex]

Ausgabeformat

• List: Kompakte Inventartabelle mit Zählung nach Klasse und 30-Tage-Flag
• Add/Edit/Classify: YAML-Datensatz + Durchlauf-Protokoll im Gespräch
• Show: Vollständiger Datensatz mit allen Feldern

Beispiel

/ki-governance:ki-inventar classify sys-001

Klassifizierungsdurchlauf – sys-001: Lebenslauf-Screening-Tool

Schritt 1: Rolle Sie lizenzieren das System von VendorX und setzen es intern für HR ein. Sie bestimmen den Verwendungszweck und tragen die operative Verantwortung → Betreiber nach Art. 3 Nr. 4 KI-VO [gegen aktuellen KI-VO-Text prüfen]. Rollenbasis: „Lizenziertes System von VendorX, interner Betrieb durch HR-Team."

Schritt 2: Risikoklasse Kein Treffer in Art. 5 (kein Verbot erkennbar). Anhang III Nr. 4 lit. a: KI-Systeme für Einstellung, Auswahl, Beförderung → hochrisiko [gegen aktuellen KI-VO-Text prüfen]. Klassenbasis: „Anhang III Nr. 4 lit. a KI-VO – Einstellungsauswahl."

Empfehlungen:

1. Pflichten als Betreiber eines hochriskanten Systems durcharbeiten? (Art. 26, 14 KI-VO)
2. KI-Folgenabschätzung erstellen? /ki-governance:aia-generation
3. Nächstes Prüfdatum: 2027-05-18 (Jahresprüfung)?

Risiken / typische Fehler

• Stille Klassifizierung. Klassifizierungsdurchlauf muss sichtbar sein; kein Auto-Klassifizieren aus einer Systembeschreibung.
• [prüfen]-Markierungen entfernen. Diese sind kein Hedge, sondern der Mechanismus. Nicht in Ausgaben entfernen.
• Wesentliche Änderung ignorieren. Wenn ein System über die Konfiguration hinaus geändert wird, /ki-inventar classify erneut ausführen – Änderungen können die Rolle verschieben.
• Pflichten aus Tabelle ableiten. Bei Anfragen die Analyse im Gespräch durchführen und an /aia-generation für alles weiterleiten, das einen formellen Nachweis benötigt.
• Art. 99 KI-VO unterschätzen. Bußgeldrahmen von bis zu 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes nicht als theoretisch behandeln – im Kontext jeder Klassifizierung erwähnen. [Modellwissen – prüfen]