b4d4ee8d3c
Deklarix war eine Pre-Publish-Kennzeichnungsprüfung für Werbe-Content
(UWG/MStV). Dieser Scope wird komplett verworfen und durch eine
KI-Antragsprüfung ersetzt: Mitarbeitende beschreiben ein KI-Vorhaben,
das System leitet Datenklasse und KI-VO-Einstufung ab, gleicht sie
gegen einen Werkzeugkatalog ab und erzeugt einen Entscheidungsvorschlag
mit Herleitung — ein Mensch entscheidet, das System bereitet nur vor.
BREAKING CHANGE: Migration 0008 droppt alle werberechtsspezifischen
Tabellen (submission, finding, extraction, evidence_package,
participant, platform_connection, asset). account/app_user/session/
audit_log bleiben (Mandantentrennung, Login, Protokollierung sind
produktunabhängig) — app_user.role wechselt von
creator/agentur/marke/kanzlei/admin zu den fünf neuen Rollen
mitarbeiter/verantwortlicher/pruefer/admin/betreiber (vier
Mandanten-Rollen + eine plattformweite, siehe CLAUDE.md).
Entfernt: internal/extract, internal/dossier, internal/evidence,
internal/socialconnect, alte rules/*.yaml (UWG-Regeln), testdata/golden
— alles ausschließlich für das alte Produkt.
Neu, Phase 1 der Baureihenfolge ("Datenmodell, Regelwerk als YAML,
Katalogstruktur"):
- Store: abteilung (Stammdaten), werkzeug + werkzeug_sperre (der
eigentliche Wert des Produkts — zentral gepflegter Katalog mit
mandantenspezifischen Ergänzungen/Sperrungen, Pflichtfelder
letzte_pruefung/quelle für jede Zusicherung), antrag (Fragebogen-
Grundgerüst, Antworten als JSONB für den adaptiven Fragebogen aus
Phase 2).
- internal/rules komplett neu: lädt und validiert drei YAML-
Regelwerke (Datenklasse-Ableitung, KI-VO-Einstufung, Anforderungs-
profil) aus rules/*.yaml — noch ohne Auswertungslogik gegen echte
Fragebogen-Antworten (das ist Phase 3, bewusst erst nach dem
Fragebogen aus Phase 2, der die exakten Fakten-Feldnamen festlegt).
Offene fachliche Annahmen (Rangfolge der Datenklassen, Fragebogen-
Lücke für die "verboten"-Varianten) explizit in rules/OPEN.md
dokumentiert statt geraten.
- Web-Layer auf Minimalgerüst reduziert, das kompiliert und die neue
Rollenwelt trägt: Firma-Registrierung (Ebene 1, erster Nutzer wird
admin), Login/Logout, Plattform-Bereich (Ebene 5, nur betreiber:
Dashboard, Accounts-Übersicht, Audit-Log) — Fragebogen (Ebene 2) und
Fachebene (Ebene 3) folgen in den nächsten Phasen.
- CLAUDE.md komplett neu geschrieben: Produktbeschreibung, Fünf-Ebenen-
Rollenmodell, Fragebogen-Spezifikation, Ableitungstabellen,
Werkzeugkatalog, Bewertungslogik (geplant), Onboarding, offene
Punkte (u. a. Postgres-RLS-Frage aus der Frontend-Spezifikation
noch nicht entschieden, "Admin und Verantwortlicher gleichzeitig"
beim Onboarding noch nicht datenmodelliert).
Volle Testsuite inkl. echter Postgres-Tests grün. End-to-End gegen
einen laufenden Server verifiziert: Firma-Registrierung legt Account +
admin-Nutzer an, Betreiber-Login leitet zu /betreiber, mandanten-
übergreifende Accounts-Liste sichtbar für betreiber, 404 für
mitarbeiter auf /betreiber, 303 zu /login ohne Sitzung.
65 lines
2.7 KiB
Markdown
65 lines
2.7 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)
|
|
|
|
Fragebogen-Abschnitt C stellt nur eine einzelne Frage (C3: "Erkennt
|
|
oder bewertet es Emotionen, Verhalten oder biometrische Merkmale?")
|
|
ohne Folgefragen, die zwischen den drei in der Bewertungslogik
|
|
genannten Auslösern für "verboten" unterscheiden:
|
|
|
|
- Emotionserkennung am Arbeitsplatz
|
|
- Social Scoring
|
|
- Biometrische Kategorisierung
|
|
|
|
`rules/kivo_einstufung.yaml` geht davon aus, dass Phase 2 (Fragebogen)
|
|
für C3 eine Folgefrage ergänzt, die zwischen diesen dreien (und "keins
|
|
davon") unterscheidet — analog zur bereits spezifizierten Folgefrage
|
|
bei C2. Die Feldnamen `c3_art` und dessen Werte
|
|
(`emotionserkennung_arbeitsplatz`, `social_scoring`,
|
|
`biometrische_kategorisierung`) sind Platzhalter, bis Phase 2 das
|
|
festlegt.
|
|
|
|
## 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.
|