8a8295dacd
- Löschfristen (Migration 0020): pro Mandant einstellbar statt fest im Regelwerk, da die DSGVO selbst keine festen Fristen nennt (Art. 5 Abs. 1 lit. e). Jede Firma wird mit risikogestaffelten Vorschlagswerten vorbelegt, loeschfrist_max_tage wird jetzt tatsächlich hart gegen Werkzeuge gefiltert (schließt rules/OPEN.md Punkt 4). - Neues internal/mail-Paket (SMTP-Versand + Test-Doppel) und darauf aufbauend Passwort-Zurücksetzen (Migration 0019) - bisher nur als Absicht in der Rollentabelle genannt, nie gebaut. - dpf_zertifiziert für alle 20 Katalogeinträge gegen das offizielle DPF-Register recherchiert und in der Produktions-DB aktualisiert (12 zertifiziert, 5 recherchiert-nicht-gefunden, 3 nicht anwendbar). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
97 lines
4.9 KiB
Markdown
97 lines
4.9 KiB
Markdown
# 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.
|