db9c5b7482
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).
58 lines
2.6 KiB
Markdown
58 lines
2.6 KiB
Markdown
# 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):
|
|
|
|
1. `oeffentlich`
|
|
2. `intern`
|
|
3. `auftragsdaten`
|
|
4. `personenbezogen`
|
|
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.**
|
|
|
|
## 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.
|