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).
4.2 KiB
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):
oeffentlichinternauftragsdatenpersonenbezogenberufsgeheimnisbesondere_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.