grok-bot
63589e684a
AI Act/OWASP und Residenz/Log-TTL in Kap. 19–20, Framing- und Taxonomie-Fixes quer durch Manuskript und Templates, Kap.-10-Anker im Assembler; Handoff fortgeschrieben.
15 KiB
Privacy, Compliance, Trust
Security-Gates und Tool-Rechte stehen (Kapitel 19). Trotzdem blockiert Legal den Launch: „Wohin gehen die Tickettexte?“, „Wie lange liegen Embeddings?“, „Können wir den Modell-Entscheid erklären?“, „Was sieht der Support in den Traces?“ Parallel verliert der Nutzer Vertrauen, weil unklar ist, ob die Antwort Entwurf oder verbindlich ist — und ob die Chat-Historie ewig lebt.
Dieses Kapitel ist Engineering-Praxis zu Privacy, Compliance-Anforderungen und Trust-Design. Keine Rechtsberatung. Regulierung und Verträge sind jurisdiction- und fallabhängig; holt Counsel/DPO für Verbindliches. Stichtag für Produktclaims: August 2026 — eure Policies und AVVs prüfen, nicht dieses Kapitel zitieren.
Kern in einem Satz: Behandelt Context, Logs und Provider-Egress als Datenflüsse mit Klasse, Residenz, Retention und Zweck — Redaction und Auditability im Harness bauen; Trust durch ehrliche UX und beherrschbare Nachvollziehbarkeit, nicht durch Marketing-Claims.
Bridge: Klassisches SE → AI Engineering
| Klassisches SE | Privacy/Trust bei LLM-Features … |
|---|---|
| Datenfluss-Diagramme / DPIA-Inputs | plus Prompt, Retrieval-Chunks, Embeddings, Tool-I/O, Model-Provider |
| PII in DB/Logs | PII zusätzlich in Prompts, Traces, Eval-Sets, Vector stores |
| Retention & Löschung | Chat-Historie, Memory, Index, Provider-side retention |
| Encryption / Access control | gleiche Basics + wer darf Prompt-Logs sehen? |
| Subprocessor list | Model-API, Hosting, Observability, Eval-SaaS |
| User transparency | Kennzeichnung AI, Limits, Mensch-Option |
| Audit logs | Trajectory, Policy-Entscheidungen, Versionen — redacted |
Die Brücke: bekannte Privacy-Hygiene, mehr Speicherorte und ein externer Inferenz-Partner.
Datenflüsse, die Teams vergessen
User content ──► Orchestrator ──► Provider (model API)
│ │
│ ├──► Vector DB / files (RAG)
│ ├──► Memory / session store
│ ├──► Tool backends
│ └──► Logs, traces, eval stores
▼
Support tools / analytics / training opt-in (?)
Datenklassen (pragmatisch)
| Klasse | Beispiele | Default-Haltung |
|---|---|---|
| Öffentlich | Hilfe-Center-Text | freier im Context |
| Intern | Prozessdocs | Tenant/ACL; oft ok on-prem/VPC-model |
| Vertraulich / PII | Name, Ticket, Vertrag | minimieren, redaction, Zweckbindung |
| Secrets / Credentials | Keys, Tokens | nie in Prompt/Log/Index |
| Besonderes Risiko | je Domäne (Gesundheit, Kinder, …) | Counsel + strengste Gates |
Klassifiziert vor dem ersten Prod-Prompt — nicht nach dem ersten Audit.
Residenz und Provider-Egress
Residenz: wo Daten physisch/rechtlich verarbeitet und gespeichert werden.
Egress: was eure Grenze zum Model-Provider (und anderen Subprozessoren) verlässt.
| Frage | Engineering-Implikation |
|---|---|
| Darf Content Region X verlassen? | Endpoint/Region wählen; ggf. self-host / VPC |
| Werden Inputs zum Training genutzt? | Contract/Opt-out; schriftlich, nicht aus dem Blog |
| Zero-retention / short retention? | Produktfeature des Anbieters prüfen (Stand + Vertrag) |
| Dürfen Snippets in SaaS-Eval-Tools? | oft nein ohne BAA/AVV und Redaction |
| Cross-border Support-Zugriff? | ACL auf Prompt-Logs |
Residenz ≠ Transfer-Ende. Ein EU-Endpoint löst allein keinen Drittlandtransfer: Subprocessors, Support-Zugriff, Telemetrie und Backup-Regionen können Daten trotzdem grenzüberschreitend berühren. Transfer-Instrumente (z. B. SCC), Transfer Impact Assessments und die Subprocessor-Liste gehören zum Hosting-ADR — nicht nur die Region im Dashboard.
Model-Hosting-ADR (templates/adr-model-hosting.md) hält die Entscheidung fest: API vs. hosted vs. self, Region, Datenklassen, Subprocessors.
Vendor-agnostisch: die Fragen sind stabil; die Häkchen bei Anbietern ändern sich — Stichtag und Vertrag schlagen Kapiteltext.
Retention, Löschung, Memory
| Artefakt | Retention-Thema |
|---|---|
| Chat-/Session-Historie | User-Erwartung vs. Support vs. Training-Verbot |
| „Memory“-Profile | explizit, löschbar, zweckgebunden (Kapitel 10) |
| Embeddings / Chunks | abgeleitete personenbezogene Daten möglich → Index-Löschpfad |
| Traces / Prompt-Logs | kurz, redacted, role-based access |
| Golden Sets / Eval | anonymisieren; Produktions-PII nicht „für immer zum Testen“ |
| Provider-side | vertragliche Retention; eigene Kopie steuern |
Praktische Defaults (Startpunkte, keine Legal-Garantie)
- Prod-Prompt-Logs: aggressiv redaction + kurze TTL + ACL
- Memory: opt-in oder klar deklariert; Delete-API
- RAG: keine Secrets; PII nur wenn Job es zwingt und Index-Policy es trägt
- Eval-Export: transform/anonymize pipeline, nicht Roh-Dump
Decision Frame: kurze Prompt-Log-TTL vs. Audit-Minima
Kurze TTL und harte Redaction schützen Nutzer und Support-ACL. Audit, Incidents und manche Branchenregeln brauchen länger haltbare Nachweise — oft ohne Roh-PII.
| Bedarf | Eher … | Nicht … |
|---|---|---|
| Debug / Quality-Sampling | kurze TTL, stark redacted, Sampling | „alles forever im Klartext“ |
| Incident / Security-Forensik | befristetes Evidence-Pack mit ACL, dann löschen | unbegrenzte Prod-Prompt-Dumps |
| Compliance-Audit (was geschah?) | redacted Audit-Trail: Versionen, Tools, Outcome, HITL, Datenklassen | CoT und Volltext als „rechtliche Erklärung“ |
| Rechts-/Branchen-Minima | Counsel + getrennter Store, Zweckbindung | Ops-Trace und Audit vermischen |
Default-Tendenz: Roh-Prompts mit PII kurz und eng; Audit-Felder länger, aber redacted und zugriffsbeschränkt. „Log forever“ und „TTL null ohne Audit“ sind beide Anti-Patterns.
Löschgesuche (je Rechtsrahmen) brauchen einen technischen Pfad: DB, Index, backups-Policy, Caches — „wir haben den Chat gelöscht“ bei lebendem Embedding ist unvollständig.
Redaction und Minimierung
Data minimization: nur die Felder in den Context, die der Task braucht (T4 als Hebel und Privacy-Hebel).
| Technik | Einsatz |
|---|---|
| Feld-Whitelist vor Prompt | statt „ganzes CRM-Objekt“ |
| Maskierung (IBAN, Email, …) | wo Task ohne Klartext geht |
| Tokenisierung / Pseudonyme | mit sicherem Mapping außerhalb des Model-Context |
| Chunk-Filter | sensible Sources nicht indexieren |
| Output-Filter | keine unnötige PII in Antworten/Logs |
| Separate stages | zuerst intern anreichern, User-Antwort minimieren |
Redaction in Logs ≠ Redaction vor dem Modell. Beides spezifizieren: Was darf das Modell sehen? Was dürfen Engineers sehen?
Auditability und „Erklärbarkeit“
Nutzer, Auditoren und On-Call brauchen unterschiedliche Nachvollziehbarkeit.
| Bedarf | Liefert ihr … |
|---|---|
| Support: „Was hat das System getan?“ | Trajectory, Tool-calls, Outcome, Versionen (redacted) |
| Security: „Wer hat freigegeben?“ | HITL-Entscheider, Policy-decision |
| Compliance: „Welche Daten wohin?“ | Datenfluss + Subprocessor + Retention |
| User: „Warum diese Antwort?“ | Citations, „basierend auf …“, Unsicherheits-Framing — kein Fake-Chain-of-Thought als Rechtfertigung |
| Eval: „Welche Version war live?“ | model_id, prompt_version, index_version |
Wichtig: Token-Wahrscheinlichkeiten und CoT sind selten „rechtliche Erklärung“. Verlässlicher sind Quellen, Regeln, Policy-Gates und menschliche Freigaben.
Audit-Log-Mindestinhalt (redacted)
- request/trace id, tenant, actor
- capability, versions (prompt/model/index/policy)
- tools invoked (names + decision allow/deny)
- outcome, HITL yes/no
- data classes touched (nicht Roh-PII)
EU AI Act — Transparenz und Rollen (knapp, Stand August 2026)
Keine Rechtsberatung — nur Engineering-Orientierung. Der EU AI Act regelt u. a. Transparenz und Kennzeichnung von KI-Interaktionen; Artikel 50 adressiert Pflichten, Nutzer über den KI-Charakter und bestimmte synthetische Inhalte zu informieren (Details und Ausnahmen jurisdiction- und stichtagsabhängig — Counsel/DPO).
Für Teams mit Model-APIs ist die Rollenunterscheidung hilfreich:
| Rolle (vereinfacht) | Typische Situation | Engineering-Hebel |
|---|---|---|
| Provider (Anbieter des Modells/Systems) | Foundation-Model-Anbieter, ggf. Systemintegrator | technische Doku, Systemkarten, Provider-Transparenz |
| Deployer (Betreiber im eigenen Produkt) | ihr, wenn ihr das Modell in eure App einbettet | UX-Kennzeichnung, Limits, Mensch-Option, Logging-Policy |
High-risk-Pflichten gelten nicht pauschal für jedes Chat-Feature „heute“. Ob ein Use Case hochriskant ist, steuern Anhang/Klassifikation und Zeitpläne — inkl. möglicher Omnibus-/Anpassungen. Nicht aus Blog-Überschriften ableiten; Counsel + eure Feature-Ampel.
Was ihr sofort bauen könnt, ohne auf die nächste Rechtsmeinung zu warten: ehrliche AI-Kennzeichnung, Entwurf-vs.-verbindlich, Escape zu Mensch, redacted Auditability (siehe unten und Trust-UX).
Trust in der UX
Trust ist Produktqualität, nicht nur Policy-PDF.
| Praxis | Wirkung |
|---|---|
| AI kennzeichnen | keine Täuschung über menschlichen Support |
| Entwurf vs. verbindlich | Labels, Disable send-without-review wo nötig |
| Grenzen kommunizieren | „kann irren“, Domain-Scope |
| Mensch erreichbar | Escape Hatch bei Gelb/Rot |
| Citations / Quellen | nachvollziehbare Grounding-Features |
| Kontrolle über Memory/Historie | einsehen, löschen, pausieren |
| Stabile Fehler | ehrliches unable statt selbstbewusster Fiktion |
Überzogene Claims („immer korrekt“, „DSGVO-garantiert durch Prompt“) zerstören Trust beim ersten Fehler — und erzeugen Legal-Risiko.
Patterns und Trade-offs
Pattern: Privacy classes in the feature spec
Jede Capability listet Datenklassen, Egress, Retention, Log-Policy (templates/ai-feature-spec.md).
Trade-off: etwas Spec-Arbeit; weniger Launch-Überraschung.
Pattern: Two contexts
Model context (minimiert, zweckgebunden) vs. ops context (stärker redacted, ACL). Nicht dasselbe JSON überall hin loggen.
Trade-off: zwei Pipelines; deutlich sicherere Ops.
Pattern: Retrieval ACL before similarity
Tenant- und Rechtefilter vor oder hart in der Query — nie „Top-k global, Modell filtert“.
Trade-off: Index-Design; verhindert cross-tenant leakage.
Pattern: Contract-backed provider choice
Hosting-ADR + periodische Re-Zertifizierung der Annahmen (Region, training use, subprocessors).
Trade-off: Prozesslast; passt zu T9 (Provider-Change = Change).
Decision Frame: Darf das in den Prompt?
| Frage | Wenn nein → |
|---|---|
| Braucht der Task das Feld wirklich? | weglassen |
| Darf es den Provider verlassen? | anderes Hosting / transform / refuse feature |
| Dürfen wir es 30 Tage loggen? | redaction / kürzer / sample |
| Wäre ein Leak meldepflichtig/peinlich? | strengste Klasse anwenden |
Trade-off: Nutzen aus Personalization vs. Privacy
| Mehr Memory/Historie | Weniger |
|---|---|
| bessere UX-Kontinuität | weniger Risiko und Komplexität |
| schwerere Lösch-/Auskunftspfade | einfachere Compliance-Story |
| höheres Leak-Impact | spartanischer Context |
Default: wenig speichern, explizit erweitern wenn der Job es trägt (T4, T10).
Anti-Patterns
| Anti-Pattern | Symptom | Besser |
|---|---|---|
| Privacy by prompt | „gebe keine PII preis“ als einzige Maßnahme | Minimierung + Filter + ACL |
| Log full prompts forever | unbegrenzte Traces mit Klartext | TTL, redaction, ACL |
| Eval on raw prod dumps | PII in Notebooks | anonymisierte Pipelines |
| Global vector soup | ein Index, alle Tenants | harte Isolation |
| Trust theater | Badge „AI-powered“ ohne Limits | ehrliche UX + HITL |
| Legal later | Launch first | Datenklassen + ADR vor Traffic |
| Secrets in system prompt | Keys im Template | Secret store, nie Context |
| Unclear subprocessors | niemand kennt Eval-SaaS | Inventar + Verträge |
| Explainability cosplay | CoT als Compliance | Quellen, Gates, Audit |
| Delete = UI only | Index/Memory bleibt | technischer Löschpfad |
Production Notes
Cost. Redaction, getrennte Stores und striktere Hosting-Optionen kosten Geld und Latenz. Das ist Feature-Envelope, nicht Overhead ohne Nutzen (T7). Datenpannen und Launch-Blockaden sind teurer.
Latency. Schwere PII-Classifier auf dem Hot Path messen; oft: deterministische Masken zuerst, async deep checks für Ops.
Observability. Privacy und Obs spannen: zu viel Log = Risiko, zu wenig = blind. Minimum-Felder ohne Roh-PII (observability-minimum.md); Privacy-Events (redaction_applied, egress_blocked) zählen.
Security. Privacy-Fehler sind oft Security-Incidents (Leakage). Gemeinsames Review mit security-review-ai.md (T8).
Lifecycle. Neue Region, neuer Provider, neues Eval-Tool, längeres Memory = erneute Datenfluss-Prüfung (T9). Owner für Datenklassen und Log-Policy (T10). Production-Ready: production-ready-checklist.md.
Key Takeaways
- Keine Rechtsberatung — Engineering liefert Datenflüsse, Klassen, Controls und Auditability für echte Compliance-Arbeit.
- Context, Embeddings, Logs, Eval und Provider sind eigene Speicher-/Egress-Pfade.
- Residenz, Retention, Redaction, Minimierung vor Feinschliff am Prompt; Residenz allein beendet keinen Drittlandtransfer.
- Auditability: Versionen, Trajectories, Policy/HITL — redacted und zugriffsbeschränkt; Roh-PII-Logs ≠ Audit-Trail.
- Trust und AI-Act-Transparenz: Kennzeichnung, Grenzen, Mensch-Option — keine Garantie-Rhetorik; High-risk nicht pauschal annehmen.
- Hosting- und Datenentscheidungen in ADRs und Feature-Specs festhalten.
Praktische nächste Schritte
- Zeichnet den Datenfluss eurer Top-Capability inkl. Provider, Index, Logs, Eval.
- Vergibt Datenklassen und erlaubt/verbietet Egress schriftlich (Spec oder ADR).
- Setzt Retention + Redaction für Prompt-Logs; prüft ACL (wer sieht was?).
- Definiert Löschpfad für Chat, Memory und zugehörige Embeddings.
- UX-Review: AI-Kennzeichnung, Entwurf/verbindlich, Escape zu Mensch.
- Hosting-Annahmen gegen Vertrag/Konsole prüfen (Stand heute, nicht „damals im Blog“).
- Teil IV abschließen: Checklisten security-review-ai.md + production-ready-checklist.md; Betrieb vertiefen ab Deployment und Serving.