b1b121bb23
Reine Auswertungslogik in internal/rules, operiert auf rules.Antworten (geparst aus antrag.antworten) und den drei Regelwerken aus Schritt 1 — ohne DB-/Web-Zugriff, vollständig isoliert testbar. - EvaluateDatenklasse: "höchste zutreffende Stufe gewinnt" (höherer Rang). Trifft keine Stufe zu (z. B. B7 fälschlich "nein" trotz keiner anderen Kategorie), wird konservativ "intern" angenommen statt "oeffentlich" — im Zweifel mehr Schutz. Nicht fachlich bestätigt, siehe rules/OPEN.md Punkt 5. - EvaluateEinstufung: Prüfreihenfolge wie im Regelwerk (verboten zuerst = K.-o.-Prüfung), erste zutreffende Stufe/Variante gewinnt. IstVerboten prüft die K.-o.-Bedingung direkt. - DeriveAnforderungen: Anforderungsprofil aus Datenklasse+Einstufung. - FilterWerkzeuge/ErfuelltAnforderung: harter Filter gegen einen Werkzeugkatalog. WerkzeugEigenschaften ist ein eigener, schlanker Typ statt store.Werkzeug — internal/rules bleibt unabhängig von internal/store. Nur technische Werkzeug-Eigenschaften (avv_erforderlich, eu_verarbeitung, kein_training_auf_eingabe) werden hart gefiltert; Prozess-Anforderungen (menschliche_aufsicht, kennzeichnungspflicht, dsfa_erforderlich) sortieren kein Werkzeug aus, sondern werden später als Auflage vermerkt — Annahme, siehe rules/OPEN.md Punkt 6. rules/OPEN.md um Punkt 4 (Auswirkung der fehlenden Löschfristen auf den Filter), Punkt 5 (Datenklasse-Fallback) und Punkt 6 (welche Anforderungen hart filtern) ergänzt — Annahmen dokumentiert statt geraten, damit Schritt 3 nicht auf die fachliche Klärung warten musste. 16 neue Tests gegen die ECHTEN rules/*.yaml-Dateien (nicht nur synthetische Fixtures) — deckt Rang-Konflikte, "Unsicher zählt wie Ja", alle vier Einstufungsstufen inkl. Auffangregel, Anforderungs-Ableitung und Werkzeug-Filterung ab. Noch nicht ans Web angebunden (Schritt 4).
86 lines
4.2 KiB
Markdown
86 lines
4.2 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
|
|
|
|
Die Spezifikation sagt "höchste zutreffende Stufe gewinnt", gibt aber
|
|
keine expliziten Rangzahlen vor. `rules/datenklasse.yaml` nimmt aktuell
|
|
diese Reihenfolge an (niedrigster zu höchstem Rang):
|
|
|
|
1. `oeffentlich`
|
|
2. `intern`
|
|
3. `auftragsdaten`
|
|
4. `personenbezogen`
|
|
5. `berufsgeheimnis`
|
|
6. `besondere_kategorie`
|
|
|
|
Begründung der Annahme: 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. **Nicht
|
|
bestätigt.**
|
|
|
|
## 2. Anforderung `kein_training_auf_eingabe` und `auftragsdaten`
|
|
|
|
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` aktuell explizit
|
|
ein (Kundendaten sollten aus denselben Gründen wie Geschäftsgeheimnisse
|
|
nicht zum Training verwendet werden) — **Annahme, nicht bestätigt.**
|
|
|
|
## 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. **Weiterhin offen:** ob diese drei
|
|
Varianten fachlich vollständig sind (deckt das wirklich alle "verboten"-
|
|
Fälle aus Art. 5 KI-VO ab?) — das war nie Teil dieser Klärung.
|
|
|
|
## 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
|
|
|
|
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. **Nicht fachlich
|
|
bestätigt**, nur eine sichere Standardannahme.
|
|
|
|
## 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.
|