chemenu/kb/concepts/Privacy and Governance.md

---
type: types/concept.md
concept_type: workflow
tags: [privacy, security, governance, audit]
created: 2026-07-26
modified: 2026-08-29
related: [LLM Wiki Pattern, Filter on Ingest, Audit Trail, Bulk Operations]
sources: [Source - LLM Wiki v2]
confidence: 0.90
confidence_base: 0.90
provenance: sourced
summary: Rahmenwerk zur Absicherung von Wiki-Inhalten über Datenfilterung beim Ingest, Audit-Trail-Protokollierung und umkehrbare Massenoperationen.
---
# Privacy and Governance

**Typ:** Workflow (Knowledge Security and Accountability)

## Definition

Privacy and Governance behandelt die Realität, dass **Quellen oft sensitive Informationen enthalten** (API-Schlüssel, Anmeldedaten, private Gespräche, PII) und dass Wiki-Operationen **Nachverfolgbarkeit und Umkehrbarkeit** benötigen. Das ursprüngliche Pattern erwähnt dies nicht, aber es ist kritisch für die Produktionsnutzung.

## Kernpunkte

### Das Problem

Ohne Privacy und Governance:
- Sensitive Daten (API-Schlüssel, Passwörter, Token) können in das Wiki erfasst werden
- Private Gespräche oder PII können offengelegt werden
- Kein Datensatz darüber, wer was und wann geändert hat
- Keine Möglichkeit, Massenoperationen rückgängig zu machen
- Keine Rechenschaftspflicht für Wiki-Änderungen

### Die Lösung: Drei Ebenen

**1. Filterung beim Erfassen**
Bevor etwas in das Wiki gelangt, **sensitive Daten automatisch entfernen**:

**Filterkategorien:**
- **API-Schlüssel und Token:** AWS-Schlüssel, GitHub-Token, Datenbankpasswörter, etc.
- **Anmeldedaten:** Benutzernamen, Passwörter, Secrets
- **PII:** Persönlich identifizierbare Informationen (E-Mail, Telefon, Adresse, SSN)
- **Private Gespräche:** Slack-Nachrichten, interne E-Mails
- **Markiert als privat:** Alles, das explizit als privat/vertraulich markiert ist

**Implementierung:**
- Regex-basierte Mustererkennung
- ML-basierte PII-Erkennung
- Zulassungs-/Blockliste für spezifische Muster
- **Automatisch, nicht manuell** - dies muss automatisch geschehen

**Beispielmuster zum Filtern:**
```
- AWS: AKIA[0-9A-Z]{16,}
- GitHub: ghp_[0-9a-zA-Z]{36,}
- Generic API key: [a-zA-Z0-9]{32,}
- Email: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
- Credit card: \d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}
```

**2. Audit Trail**
Jede Operation im Wiki sollte **protokolliert** werden mit:

| Feld | Beschreibung | Beispiel |
|-------|-------------|---------|
| Zeitstempel | Wann die Operation auftrat | 2026-07-26 14:30:00 |
| Operationstyp | ingest, edit, delete, query | ingest |
| Benutzer/Agent | Wer die Operation durchführte | Mistral Vibe |
| Ziel | Was wurde geändert | raw/articles/Source - LLM Wiki v2.md |
| Beschreibung | Was geändert wurde und warum | Ingested LLM Wiki v2 article |
| Metadaten | Zusätzlicher Kontext | Source type: article |

**Protokollformat:** Nur anfügen (log-Einträge niemals ändern)

**Implementierung:**
- Zentrales `kb/log.md` für alle Operationen
- Strukturiertes Format für einfaches Parsing
- Vorher/Nachher für Änderungen einschließen
- Link zu verwandten Seiten

**Anwendungsfälle:**
- Wenn etwas falsch aussieht: "Wie ist das hierher gekommen?"
- Bei der Untersuchung der Knowledge-Evolution
- Beim Debugging von Wiki-Problemen
- Für Compliance und Rechenschaftspflicht

**3. Massenoperationen mit Governance**
Wenn das Wiki wächst, sind Massenoperationen durchzuführen:

| Operation | Beschreibung | Governance |
|-----------|-------------|------------|
| Massenlöschung | Alte Inhalte entfernen | Geprüft, umkehrbar |
| Export | Subset des Wiki exportieren | Geprüft |
| Merge | Duplizierte Entities zusammenführen | Geprüft, umkehrbar |
| Archiv | Alte Inhalte archivieren | Geprüft, umkehrbar |

**Governance-Anforderungen:**
- **Geprüft:** Jede Massenoperation im Audit Trail protokolliert
- **Umkehrbar:** Möglichkeit, Massenoperationen rückgängig zu machen
- **Genehmigt:** Menschliche Genehmigung für destruktive Operationen erforderlich
- **Begrenzt:** Möglichkeit, Massenoperationen auf spezifische Kategorien zu beschränken

## Implementierung

Basierend auf [[Agent Memory]] und Produktionserfahrung:

1. **Filterung vor dem Erfassen:** Automatische sensitive Datenenfernung
2. **Überprüfung nach dem Erfassen:** Manuelle Stichprobenprüfung erfasster Inhalte
3. **Zentrales Protokollieren:** Alle Operationen zu `kb/log.md`
4. **Umkehrbare Operationen:** Undo/Redo für alle Änderungen implementieren
5. **Zugriffskontrolle:** Optionale Benutzer-/Agent-Berechtigungen

## Vorteile

- **Sicherheit:** Sensitive Daten betreten das Wiki nie
- **Compliance:** Erfüllt Datenschutzanforderungen
- **Rechenschaftspflicht:** Vollständiger Audit Trail aller Änderungen
- **Sicherheit:** Massenoperationen sind umkehrbar
- **Vertrauen:** Benutzer können Wiki-Integrität überprüfen

## Wann zu verwenden

- Jedes produktive Wiki
- Wikis mit sensiblen Daten
- Multi-User-Umgebungen
- Compliance-sensitive Domänen

## Wann NICHT zu verwenden

- Persönliche, nicht-sensitive Wikis
- Vollständig vertrauenswürdige Umgebungen
- Situationen, in denen der Overhead nicht gerechtfertigt ist

## Verwandte Concepts

- [[LLM Wiki Pattern]] - Gesamtmuster
- [[Filter on Ingest]] - Der Filtermechanismus
- [[Audit Trail]] - Der Protokollierungsmechanismus
- [[Bulk Operations]] - Gouvernanzoperationen
- [[Event-Driven Automation]] - Für automatisierte Governance

## Siehe auch

- [[Privacy and Governance]] (diese Seite)
- [[Multi-Agent Collaboration]] (für Multi-Agent-Sicherheit)
- [[Quality and Self-Correction]] (für Qualitätsaspekte)