Files

noroot db9c5b7482 feat: Fragebogen mit adaptiver Logik (Schritt 2 der Baureihenfolge)

Ebene 2 ("Antrag stellen") als einseitiges Formular statt mehrseitigem
Assistenten — jede zusätzliche Seite kostet Zeit, und laut Spezifikation
wird ein Antrag umgangen, wenn er länger als fünf Minuten dauert.

- GET /antraege/neu: Fragebogen-Formular (Abschnitte A-D exakt nach
  Spezifikation). Adaptive Folgefragen (C2: welche Art von Entscheidung,
  C3: welche Art von Erkennung) werden rein per CSS :has() ein-/
  ausgeblendet, kein JavaScript nötig — visuell mit Chromium-Screenshots
  verifiziert (unchecked vs. checked).
- POST /antraege: legt an und reicht direkt ein (entwurf->eingereicht in
  einem Schritt, kein Zwischenspeichern als Entwurf für v1). Die
  antworten-JSON nutzt exakt dieselben Fakten-Schlüssel wie
  rules/*.yaml (b1-b7, c1-c5, c2_folge, c3_art) — Schritt 3 kann sie
  direkt auswerten, ohne Felder umzubenennen. "Unsicher" wird bewusst
  NICHT zu "ja" normalisiert (das ist eine Auswertungsregel für Schritt
  3, keine Speicherregel) — der Antrag hält fest, was der Mitarbeiter
  tatsächlich geantwortet hat.
- GET /antraege: eigene Anträge (Ebene 2 sieht nur eigene, nicht die
  des ganzen Mandanten — dafür neue Store-Methode
  ListAntraegeForUser, getrennt von ListAntraegeForAccount für den
  späteren Ebene-3-Posteingang).
- GET /antraege/{id}: Detail, fremder Antrag liefert 404 (nicht 403,
  gleiches Muster wie überall sonst im Projekt).
- betreiber-Rolle wird von allen Antrags-Routen weggeleitet (Ebene 5
  ist technisch getrennt vom Mandantenbereich).

rules/OPEN.md Punkt 3 (fehlende Fragebogen-Unterscheidung für die
"verboten"-Varianten) damit geklärt: c3_art existiert jetzt mit den
bereits in rules/kivo_einstufung.yaml erwarteten Werten.

Volle Testsuite inkl. echter Postgres-Tests grün; End-to-End gegen
einen laufenden Server verifiziert (Antrag anlegen, antworten-JSON in
der DB korrekt, Detail-/Listenansicht, Mandantentrennung).

2026-08-28 23:09:24 +02:00

2.6 KiB

Raw Blame History

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

oeffentlich
intern
auftragsdaten
personenbezogen
berufsgeheimnis
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.

2.6 KiB Raw Blame History