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:ki-governance-kaltstart-interview verweisen.

1. Inventar lesen. Liegt unter ki-systeme.yaml. Existiert die Datei nicht, bei erstem

add-Befehl mit leerem systeme:-Block anlegen.

1. Befehl ausführen:
2. Kein Argument oder list → Inventartabelle anzeigen (siehe Listenformat)
3. add → Aufnahmefluss starten
4. 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

1. Nach list Dashboard anbieten:

"Dashboard gewünscht? Filterbar nach Status / Klasse / EU-Nexus / Eigentümer. Auf Wunsch."

1. 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; den Pinpoint im Quellenlog auf EUR-Lex vermerken.

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).

1. 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 brauchen eine sichtbare Quellenbasis mit Artikel, Anhangspunkt und Datum der Prüfung, 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 finale 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

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-Ablauf des Governance-Teams übergeben.

B. Anhang III – Hochrisiko-Bereiche

1. Biometrische Identifizierung und Kategorisierung
2. Kritische Infrastruktur (digitale Infrastruktur, Straßenverkehr, Wasser, Gas, Heizung,

Strom)

1. Allgemeine und berufliche Bildung (Zugang, Bewertung, Proctoring, Überwachung auf

unerlaubtes Verhalten)

1. Beschäftigung, Arbeitnehmerverwaltung, Selbständigkeit – Einstellung, Auswahl, Beförderung,

Kündigung, Aufgabenzuweisung, Überwachung, Leistung

1. Wesentliche private und öffentliche Dienste (Sozialleistungen, Kreditwürdigkeit natürlicher

Personen, Risikobewertung und -bepreisung bei Leben-/Krankenversicherung, Notfallmanagement)

1. Strafverfolgung (Risikobewertung, Polygraphie, Deepfa