diff --git a/CLAUDE.md b/CLAUDE.md index 5c7a82c..44733c3 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -734,16 +734,24 @@ journalctl -u deklarix -f ## Offene Punkte -- **Rangfolge der Datenklassen und Grenzfälle im Anforderungsprofil** - (siehe `rules/OPEN.md`, Punkte 1/2/5/6) — mit dem/der fachlich - Verantwortlichen (z. B. Datenschutzbeauftragte/r) bestätigen. Schritt - 3 ist trotzdem schon umgesetzt (auf Basis dieser dokumentierten - Annahmen) — nicht auf die Klärung gewartet, um nicht blockiert zu - bleiben, aber die Ableitung kann sich noch ändern. +- ~~Rangfolge der Datenklassen~~ (`rules/OPEN.md`, Punkt 1) — **am + 2026-08-29 vom Produktverantwortlichen bestätigt**, keine Änderung + nötig. +- ~~Anforderung `kein_training_auf_eingabe` und `auftragsdaten`~~ + (`rules/OPEN.md`, Punkt 2) — **bestätigt**, `auftragsdaten` bleibt + eingeschlossen. - ~~Genaue Fragebogen-Felder für die drei "verboten"-Varianten~~ — - **erledigt in Schritt 2**, C3 hat jetzt eine Folgefrage `c3_art`. - Weiterhin offen: ob die drei Varianten fachlich vollständig sind - (siehe `rules/OPEN.md`, Punkt 3). + **erledigt in Schritt 2**, C3 hat jetzt eine Folgefrage `c3_art`. Ob + die drei Varianten fachlich vollständig sind, wurde am 2026-08-29 + ebenfalls **bestätigt** (siehe `rules/OPEN.md`, Punkt 3). +- ~~Fallback ohne zutreffende Datenklasse~~ (`rules/OPEN.md`, Punkt 5) + — **bestätigt**, `intern` bleibt die konservative Standardannahme. +- **Welche Anforderungen hart gegen ein Werkzeug gefiltert werden** + (`rules/OPEN.md`, Punkt 6 — `avv_erforderlich`/`eu_verarbeitung`/ + `kein_training_auf_eingabe` hart, `menschliche_aufsicht`/ + `kennzeichnungspflicht`/`dsfa_erforderlich` nur als Auflage vermerkt) + — weiterhin nicht ausdrücklich bestätigt, aber plausibel, keine + Rückmeldung dazu bisher eingeholt. - **Löschfristen je Datenklasse** (konkrete Tageswerte für `loeschfrist_max_tage`) — noch nicht fachlich festgelegt. - **Mandantenisolation auf Datenbankebene (Postgres Row-Level Security)** diff --git a/rules/OPEN.md b/rules/OPEN.md index d3c91bd..2fe0ee4 100644 --- a/rules/OPEN.md +++ b/rules/OPEN.md @@ -5,11 +5,12 @@ 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 +## 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 aktuell -diese Reihenfolge an (niedrigster zu höchstem Rang): +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` @@ -18,22 +19,22 @@ diese Reihenfolge an (niedrigster zu höchstem Rang): 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.** +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` +## 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` aktuell explizit -ein (Kundendaten sollten aus denselben Gründen wie Geschäftsgeheimnisse -nicht zum Training verwendet werden) — **Annahme, nicht bestätigt.** +`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 @@ -43,9 +44,9 @@ 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. +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 @@ -60,15 +61,15 @@ 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 +## 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. **Nicht fachlich -bestätigt**, nur eine sichere Standardannahme. +Zweifel mehr Schutzanforderungen, nicht weniger. **Vom +Produktverantwortlichen bestätigt, keine Änderung nötig.** ## 6. Welche Anforderungen werden hart gegen ein Werkzeug gefiltert?