4dd9bd88cb
Rangfolge der Datenklassen, auftragsdaten bei kein_training_auf_eingabe, Vollständigkeit der drei "verboten"-Varianten und der intern-Fallback wurden vom Produktverantwortlichen bestätigt (rules/OPEN.md). Weiterhin offen: konkrete Löschfristen in Tagen, harte Filterung von menschliche_aufsicht/kennzeichnungspflicht/dsfa_erforderlich. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
87 lines
4.3 KiB
Markdown
87 lines
4.3 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
|
|
|
|
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.
|