docs: fachliche Annahmen im Regelwerk bestätigt

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>

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)**

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?