# 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 — GELÖST (2026-09-01, konfigurierbar statt fest)

Ursprünglich war unklar, wer die konkreten Tageswerte je Datenklasse
festlegt. Recherche (2026-09-01) ergab: die DSGVO selbst nennt **keine**
festen Speicherfristen — Art. 5 Abs. 1 lit. e verlangt nur, Daten "so
lange wie für den Zweck nötig" zu speichern (Grundsatz der
Speicherbegrenzung). Es gibt daher keinen einzelnen "richtigen"
Zahlenwert, den man fest in `rules/anforderungen.yaml` hätte eintragen
können. Lösung: **pro Mandant einstellbar**, vom Datenschutzbeauftragten
festgelegt (`loeschfrist_einstellung`, Migration 0020, `GET/POST
/verwaltung/loeschfristen`) statt einer globalen YAML-Konstante. Jede
neue Firma wird mit risikogestaffelten Vorschlagswerten vorbelegt
(`oeffentlich` 365 / `intern` 180 / `auftragsdaten` 90 / `personenbezogen`
90 / `berufsgeheimnis` 30 / `besondere_kategorie` 30 Tage) — eigene
Einschätzung, keine Rechtsvorgabe, frei editierbar.

**Auswirkung auf Schritt 3 (`internal/rules.ErfuelltAnforderung`):** die
Anforderung wird jetzt hart gefiltert, sobald für die betroffene
Datenklasse eine Frist konfiguriert ist — ein Werkzeug ohne bezifferte
Aufbewahrungsdauer erfüllt eine gesetzte Frist NICHT (fail closed, wie
bei `eu_verarbeitung`). Ist keine Frist konfiguriert, bleibt das
Verhalten wie zuvor (nicht gefiltert).

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