Files

noroot 8a8295dacd feat: Löschfristen je Datenklasse, Passwort-Zurücksetzen, DPF-Recherche

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

2026-09-01 07:38:12 +02:00

4.9 KiB

Raw Blame History

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:

oeffentlich
intern
auftragsdaten
personenbezogen
berufsgeheimnis
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.

4.9 KiB Raw Blame History