deklarix/rules/OPEN.md

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.