d82f86fc95
CI / detect-changes (pull_request) Successful in 9s
CI / branch-name (pull_request) Successful in 1s
CI / guardrail-integrity (pull_request) Successful in 7s
CI / secret-scan (pull_request) Successful in 11s
CI / dep-audit (pull_request) Failing after 58s
CI / sbom-scan (pull_request) Failing after 1m4s
CI / build-sha-integrity (pull_request) Successful in 6s
CI / validate-canonical-controls (pull_request) Successful in 4s
CI / loc-budget (pull_request) Successful in 25s
CI / go-lint (pull_request) Failing after 22s
CI / python-lint (pull_request) Failing after 13s
CI / nodejs-lint (pull_request) Failing after 1m15s
CI / nodejs-build (pull_request) Successful in 3m12s
CI / test-go (pull_request) Successful in 57s
CI / iace-gt-coverage (pull_request) Successful in 16s
CI / test-python-backend (pull_request) Successful in 25s
CI / test-python-document-crawler (pull_request) Successful in 14s
CI / test-python-dsms-gateway (pull_request) Successful in 10s
- Add .infisical.json linking the repo to the breakpilot-compliance project on the self-hosted secrets.meghsakha.com instance. - Add Makefile with infisical-aware targets (make dev, dev-build, dev-down, secrets, secrets-set). `make dev` runs `infisical run --env=dev -- docker compose up`, so secrets are injected at run time and .env files no longer touch disk. - Add INFISICAL_SETUP.md with per-developer onboarding (CLI install, login, verify project link, run targets, Claude Code usage patterns, troubleshooting). - Update README Quick Start to drop the cp .env.example .env step and point at make dev + INFISICAL_SETUP.md. - Remove HashiCorp Vault references from CLAUDE.md (core-services list + sensitive-files list) and compliance-checklist.md TOM section; replace with Infisical. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
3.9 KiB
3.9 KiB
Compliance-Checkliste
Wann diese Checkliste anwenden?
AUTOMATISCH bei:
- Neuen Features mit Nutzerdaten
- Änderungen an Datenflüssen
- KI/ML-Funktionen
- Neuen API-Endpoints
- Datenbankschema-Änderungen
1. DSGVO-Check (Datenschutz-Grundverordnung)
Rechtsgrundlage klären
| Rechtsgrundlage | Wann verwenden |
|---|---|
| Einwilligung (Art. 6 Abs. 1a) | Optionale Features, Marketing, Analytics |
| Vertragserfüllung (Art. 6 Abs. 1b) | Kernfunktionen der Plattform |
| Berechtigtes Interesse (Art. 6 Abs. 1f) | Sicherheit, Betrugsprävention |
| Rechtliche Verpflichtung (Art. 6 Abs. 1c) | Aufbewahrungspflichten |
Datenminimierung
- Werden nur notwendige Daten erhoben?
- Gibt es Felder, die optional sein könnten?
- Werden Daten nach Zweckerfüllung gelöscht?
Besondere Kategorien (Art. 9)
ACHTUNG bei:
- Gesundheitsdaten (Krankheitstage, Atteste)
- Biometrische Daten (Gesichtserkennung, Stimme)
- Religiöse Überzeugungen
- Politische Meinungen
→ Explizite Einwilligung erforderlich!
Minderjährige (Art. 8)
Breakpilot-spezifisch:
- Unter 16 Jahren: Einwilligung der Eltern
- Altersverifikation implementieren
- Kindgerechte Datenschutzerklärung
Betroffenenrechte sicherstellen
- Auskunft (Art. 15): Kann der Nutzer seine Daten einsehen?
- Berichtigung (Art. 16): Kann der Nutzer Daten korrigieren?
- Löschung (Art. 17): Kann der Nutzer Löschung beantragen?
- Datenportabilität (Art. 20): Export in maschinenlesbarem Format?
2. AI Act Check (KI-Verordnung)
Risikokategorie bestimmen
| Kategorie | Beispiele | Anforderungen |
|---|---|---|
| Unakzeptabel | Social Scoring, Manipulation | ❌ VERBOTEN |
| Hochrisiko | Bildungszugang, Prüfungsbewertung | Strenge Auflagen |
| Begrenzt | Chatbots, Empfehlungen | Transparenzpflicht |
| Minimal | Spam-Filter, Autokorrektur | Keine Auflagen |
Breakpilot KI-Features prüfen
| Feature | Risiko | Maßnahmen |
|---|---|---|
| Klausur-OCR | Begrenzt | Transparenz, Human-in-Loop |
| KI-Korrekturvorschläge | Hochrisiko | Audit-Log, Erklärbarkeit |
| Lernempfehlungen | Begrenzt | Transparenz |
| Spracherkennung | Begrenzt | Consent, Transparenz |
Hochrisiko-KI Anforderungen
Wenn Hochrisiko:
- Risikomanagementsystem dokumentiert
- Qualität der Trainingsdaten sichergestellt
- Technische Dokumentation vorhanden
- Audit-Logging aktiviert
- Human Oversight möglich
- Genauigkeit/Robustheit getestet
3. Technische Maßnahmen (TOM)
Verschlüsselung
- Transit: TLS 1.3 für alle Verbindungen
- Rest: Datenbank-Verschlüsselung
- Secrets: Infisical (
secrets.meghsakha.com) für Credentials
Zugriffskontrollen
- RBAC implementiert
- Least Privilege Prinzip
- Session-Timeouts
Audit-Logging
# Beispiel: Audit-Event loggen
audit_log.info({
"action": "data_export",
"user_id": user.id,
"timestamp": datetime.utcnow(),
"data_categories": ["grades", "personal"],
"legal_basis": "Art. 20 DSGVO"
})
4. Dokumentationspflichten
Bei neuen Features aktualisieren
| Dokument | URL | Wann aktualisieren |
|---|---|---|
| VVT | https://macmini:3002/sdk/vvt | Neue Verarbeitung |
| TOM | https://macmini:3002/sdk/tom | Neue Schutzmaßnahme |
| DSFA | https://macmini:3002/sdk/dsfa | Hochrisiko-Verarbeitung |
| Löschfristen | https://macmini:3002/sdk/loeschfristen | Neue Datenkategorie |
5. Schnell-Check (5 Fragen)
Vor jedem Feature diese 5 Fragen beantworten:
- WER sind die Betroffenen? (Schüler, Lehrer, Eltern)
- WAS für Daten werden verarbeitet?
- WARUM werden sie verarbeitet? (Rechtsgrundlage)
- WIE LANGE werden sie gespeichert?
- WER hat Zugriff?
Können alle 5 Fragen beantwortet werden? → Feature ist dokumentierbar.