# Offene fachliche Fragen zum Regelwerk

Diese Punkte wurden beim Anlegen der Regelwerk-YAML-Dateien (Phase 1)
bewusst nicht geraten, sondern hier notiert — vor Phase 3 (Ableitungen
und harte Filter) mit dem fachlich Verantwortlichen (z. B. der/dem
betrieblichen Datenschutzbeauftragten) klären.

## 1. Rangfolge der Datenklassen — BESTÄTIGT (2026-08-29)

Die Spezifikation sagt "höchste zutreffende Stufe gewinnt", gibt aber
keine expliziten Rangzahlen vor. `rules/datenklasse.yaml` nimmt diese
Reihenfolge an (niedrigster zu höchstem Rang) — **vom Produktverantwortlichen
bestätigt, keine Änderung nötig:**

1. `oeffentlich`
2. `intern`
3. `auftragsdaten`
4. `personenbezogen`
5. `berufsgeheimnis`
6. `besondere_kategorie`

Begründung: DSGVO Art. 9 (besondere Kategorien) gilt allgemein als
striktester Datenschutz-Tatbestand, § 203 StGB (Berufsgeheimnis) hat
eigene strafrechtliche Relevanz — beide vor "normalen" personenbezogenen
Daten eingeordnet. `auftragsdaten` unter `personenbezogen` einsortiert,
weil vertragliche Geheimhaltung in der Regel schwächer sanktioniert ist
als DSGVO-Bußgelder.

## 2. Anforderung `kein_training_auf_eingabe` und `auftragsdaten` — BESTÄTIGT (2026-08-29)

Die Spezifikation formuliert "aus intern, personenbezogen und höher" —
das lässt offen, ob `auftragsdaten` (zwischen `intern` und
`personenbezogen` einsortiert, siehe Punkt 1) eingeschlossen sein soll.
`rules/anforderungen.yaml` schließt `auftragsdaten` ein (Kundendaten
sollten aus denselben Gründen wie Geschäftsgeheimnisse nicht zum
Training verwendet werden) — **vom Produktverantwortlichen bestätigt,
keine Änderung nötig.**

## 3. Genaue Fragebogen-Fakten für "verboten" (KI-VO Art. 5) — ERLEDIGT

~~Fragebogen-Abschnitt C stellt nur eine einzelne Frage...~~ Mit Phase 2
(Fragebogen, `internal/web/templates/antrag_neu.html`) gelöst: C3 hat
jetzt eine Folgefrage `c3_art` mit den Werten
`emotionserkennung_arbeitsplatz`, `social_scoring`,
`biometrische_kategorisierung` und `keine` — exakt die Werte, die
`rules/kivo_einstufung.yaml` bereits erwartete. Feldnamen sind damit
final, nicht mehr Platzhalter. Ob diese drei Varianten fachlich
vollständig sind, wurde am 2026-08-29 vom Produktverantwortlichen
**bestätigt (keine Ergänzung nötig).**

## 4. `loeschfrist_max_tage` — konkrete Fristen je Datenklasse

Die Spezifikation nennt `loeschfrist_max_tage` als Anforderung "aus
Datenklasse", ohne die konkreten Tageswerte pro Stufe zu nennen.
`rules/anforderungen.yaml` listet die Anforderung nur als grundsätzlich
anwendbar (welche Datenklassen sie überhaupt auslösen), ohne
Zahlenwerte — die eigentlichen Fristen (z. B. "personenbezogen: 90
Tage") müssen vor Phase 3 fachlich festgelegt werden. **Auswirkung auf
Schritt 3 (`internal/rules.ErfuelltAnforderung`):** ohne Zahlenwerte
wird diese Anforderung aktuell NICHT hart gegen Werkzeuge gefiltert
(jedes Werkzeug gilt hier als "erfüllt") — sobald Fristen feststehen,
muss die Filterfunktion entsprechend erweitert werden.

## 5. Fallback, wenn keine Datenklasse zutrifft — BESTÄTIGT (2026-08-29)

Wenn ein Antrag bei allen B-Fragen "nein" beantwortet — auch bei B7
("nur allgemein zugängliche/erfundene Inhalte") — trifft laut Tabelle
keine Stufe zu (ein eigentlich widersprüchlicher Zustand: irgendeine
Kategorie sollte immer zutreffen). `internal/rules.EvaluateDatenklasse`
nimmt in diesem Fall konservativ `intern` an, nicht `oeffentlich` — im
Zweifel mehr Schutzanforderungen, nicht weniger. **Vom
Produktverantwortlichen bestätigt, keine Änderung nötig.**

## 6. Welche Anforderungen werden hart gegen ein Werkzeug gefiltert?

`internal/rules.ErfuelltAnforderung` filtert aktuell hart nur
`avv_erforderlich`, `eu_verarbeitung` und `kein_training_auf_eingabe` —
das sind technische Eigenschaften eines Werkzeugs
(`werkzeug.avv_verfuegbar`, `verarbeitungsort`, `training_standard`).
`menschliche_aufsicht`, `kennzeichnungspflicht` und `dsfa_erforderlich`
betreffen dagegen einen Prozess rund um die Nutzung, nicht das Werkzeug
selbst — ein Werkzeug wird deswegen nicht aussortiert, das wird
stattdessen als Auflage vermerkt (geplant für Schritt 4/5). **Diese
Aufteilung ist eine Annahme von Schritt 3, nicht ausdrücklich in der
Spezifikation so festgelegt** — vor Schritt 4 gegenprüfen, ob das der
gewünschten Produktlogik entspricht.