Compliance
Der Compliance-Tab umfasst vier Bereiche: Anonymisierung (4-stufige Pipeline zum Schutz sensibler Daten), Audit-Trail (durchsuchbares Protokoll aller KI-Anfragen), DSGVO-Berichte (VVT und DSFA) und die Berechtigungsmatrix (Übersicht der effektiven Zugriffsrechte).
Sub-Tab: Anonymisierung
Vierstufige Anonymisierung zum Schutz sensibler Daten. Die Schichten werden
nacheinander ausgeführt — jede erkennt Entitäten, die vorherige Schichten
verpasst haben. Erkannte Entitäten werden durch deterministische Pseudonyme
ersetzt (z.B. [KUNDE_001], [IBAN_002]).
Allgemeine Einstellungen
| Feld | Typ | Standard | Beschreibung | Empfehlung |
|---|---|---|---|---|
Anonymisierung aktivieren |
Checkbox | An | Globale Aktivierung der gesamten Anonymisierungspipeline. | Immer aktiviert lassen, insbesondere wenn Cloud-Backends konfiguriert sind. |
Audit-Log aktivieren |
Checkbox | An | Protokolliert jede Anonymisierung (Entitäten-Anzahl, Kategorien, Route). | Aktiviert lassen — nötig für DSGVO-Nachweispflicht. |
Max. Content-Klasse für Cloud |
Radio-Gruppe | LOW (3) |
Bestimmt, welche Inhalte an Cloud-LLMs gesendet werden dürfen: LOW (3): Nur technische Dokumentation. MEDIUM (2): + Einkauf/Logistik. HIGH (1): + Finanzen/Personal. |
LOW empfohlen — minimiert das Risiko. Nur erhöhen, wenn die Anonymisierung nachweislich greift und der Cloud-Provider vertraglich abgesichert ist. |
Ausgeschlossene Begriffe |
Textarea | (leer) | Begriffe, die nicht anonymisiert werden sollen (einer pro Zeile). Nützlich für Firmennamen, Produktbezeichnungen, Abteilungskürzel. | Beispiel: KIara, SAP, HR |
Schicht 1: ERP-Stammdaten (Aho-Corasick)
Deterministischer Pattern-Matching-Algorithmus. Lädt Kunden, Lieferanten, Mitarbeiter und Produkte aus CSV-Dateien und erkennt sie in <10ms — auch bei 50.000+ Einträgen.
| Feld | Typ | Standard | Beschreibung | Empfehlung |
|---|---|---|---|---|
ERP-Import aktiv |
Checkbox | Aus | Aktiviert den Aho-Corasick-Automaten für ERP-Stammdaten. | Aktivieren, sobald Stammdaten-CSVs bereitgestellt sind. |
Stammdaten-Pfad |
Text | /etc/kiara/stammdaten |
Verzeichnis mit CSV/JSON-Dateien. | Standard belassen. Dateien dort ablegen. |
Wortgrenzen-Prüfung |
Checkbox | An | Verhindert Teilübereinstimmungen: »Mueller« wird nicht in »Benzmueller« erkannt. | Immer aktiviert lassen. Deaktivierung führt zu vielen False Positives. |
Mindestlänge für Treffer |
Zahl | 3 |
Minimum Zeichenlänge für eine Erkennung (1–20). | 3 ist ein guter Wert. Niedriger = mehr Treffer (inkl. False Positives). |
Benutzerdefinierte Einträge |
Textarea (JSON) | [] |
Zusätzliche Einträge im Format:[{"text": "Firmenname", "type": "ORG", "key": "K-001"}]
|
Für Einträge, die nicht in den ERP-Stammdaten stehen. |
Stammdaten-Format (CSV)
# Semikolon-getrennt, eine Entität pro Zeile
# Spalten: key;type;value;variants
K-12345;ORG;Schmidt GmbH;Schmidt|Fa. Schmidt
L-67890;SUPPLIER;Mueller AG;Mueller AG|Fa. Mueller
E-11111;EMPLOYEE;Max Mueller;Mueller, Max|Mueller
P-99999;PRODUCT;Hydraulikzylinder HZ-50;HZ-50|Zylinder HZ50
Schicht 2: LDAP / Active Directory
| Feld | Typ | Standard | Beschreibung |
|---|---|---|---|
LDAP/AD-Mitarbeiter einbeziehen |
Checkbox | An | Lädt Vor-/Nachnamen aller LDAP-Benutzer in den Anonymisierungs-Automaten. Erfordert eine konfigurierte LDAP-Verbindung (siehe Benutzerverwaltung → LDAP). |
Schicht 3: Regex-Muster
Erkennt strukturierte personenbezogene Daten über reguläre Ausdrücke: IBAN, Telefonnummern, E-Mail-Adressen, Steuer-IDs etc. Zusätzlich können benutzerdefinierte Muster hinzugefügt werden.
| Feld | Typ | Beschreibung | Beispiel |
|---|---|---|---|
Benutzerdefinierte Regex-Muster |
Textarea (JSON) |
Array von Mustern im Format:[{"name": "...", "pattern": "...", "type": "..."}]
|
[
{
"name": "Mitarbeiter-Nr",
"pattern": "MA-\\d{5}",
"type": "INTERNAL_CODE"
}
]
|
Eingebaute Regex-Muster
| Muster | Erkennt | Pseudonym-Kategorie |
|---|---|---|
| IBAN | DE89 3704 0044 0532 0130 00 | [IBAN_001] |
max.mueller@firma.de | [EMAIL_001] | |
| Telefon | +49 171 1234567 | [TELEFON_001] |
| Steuer-ID | DE123456789 | [STEUER_ID_001] |
| IP-Adresse | 192.168.1.100 | [IP_001] |
Schicht 4: LLM-Erkennung
Probabilistische PII-Erkennung durch ein Sprachmodell. Erkennt Entitäten, die von den vorherigen Schichten verpasst wurden (z.B. unbekannte Personennamen, Organisationen). Läuft nur auf noch nicht maskiertem Text.
| Feld | Typ | Standard | Beschreibung | Empfehlung |
|---|---|---|---|---|
LLM-Erkennung aktivieren |
Checkbox | Aus | Aktiviert die 4. Anonymisierungsschicht. | Nur aktivieren wenn Cloud-Backends genutzt werden und maximale Anonymisierung nötig ist. |
Modell |
Text | (leer = Standard-LLM) | Optionales dediziertes Modell für die PII-Erkennung. | Leer lassen — das Standard-LLM ist meist ausreichend. |
Confidence-Schwellwert |
Zahl | 0.7 |
Entitäten unter diesem Wert (0.0–1.0) werden verworfen. | 0.7 ist ein guter Kompromiss. Höher = weniger False Positives, niedriger = mehr Recall. |
Temperatur |
Zahl | 0.1 |
LLM-Temperatur. Niedrig = deterministischer. | 0.1 — Anonymisierung soll reproduzierbar sein. |
Timeout |
Zahl | 10 |
Maximale Wartezeit pro Anfrage (1–60 Sekunden). | 10s reicht für die meisten Texte. |
Cache-Größe |
Zahl | 256 |
LRU-Cache für bereits analysierte Texte (0–10.000). | 256. Reduziert wiederholte LLM-Calls bei ähnlichen Anfragen. |
Context-Window |
Zahl | 4096 |
Kontextfenster des LLMs für die PII-Erkennung (512–131.072). | 4096 reicht für einzelne Benutzer-Anfragen. |
Test-Funktion
Der Button »Anonymisierung testen...« öffnet ein Modal, in dem ein beliebiger Text eingegeben und die Anonymisierungspipeline live getestet werden kann.
Das Ergebnis zeigt:
- Anonymisierter Text: Alle Pseudonyme hervorgehoben
- Entitäten-Tabelle: Original → Pseudonym für jeden Treffer
- Statistik: Gesamtzahl erkannter Entitäten
Sub-Tab: Audit-Trail
Durchsuchbares Protokoll aller KI-Anfragen. Anfrageinhalte werden als SHA256-Hash gespeichert, nicht als Klartext — der Audit-Trail selbst ist datenschutzkonform.
Filter
| Filter | Typ | Beschreibung |
|---|---|---|
| Von / Bis | Datum | Zeitraum eingrenzen. |
| Modus | Button-Gruppe | Alle / Standard / Unchained / Agent. |
| Route | Button-Gruppe | Alle / Lokal / Cloud. |
| Suche | Text | Volltextsuche in Frage-Excerpts (ILIKE). |
Tabellen-Spalten
| Spalte | Beschreibung | Sortierbar |
|---|---|---|
| ID | Laufende Nummer. | Ja |
| Zeitstempel | Datum und Uhrzeit der Anfrage. | Ja |
| Benutzer | Benutzername des Anfragenden. | Ja |
| Modus | Badge: Standard (blau), Unchained (orange), Agent (lila). | Ja |
| Route | Badge: Lokal / Cloud / MCP. | Ja |
| Chat-ID | Zugehörige Chat-Session. | Nein |
| Frage | Gekürzt (max. 60 Zeichen). | Nein |
| Dauer | Verarbeitungszeit in ms. | Ja |
| Detail | Link zur Vollansicht (neuer Tab). | Nein |
Detail-Ansicht (Expandable)
Klick auf eine Zeile zeigt (lazy-loaded):
- Prompt an KI-Backend: Der vollständige Prompt (bei Agent: Message-Array)
- Tool-Calls: Tool-Name, Iteration, Parameter (JSON), Ergebnis
- KI-Output: Vollständige Antwort
- Meta-Daten: Modell, Chunks, anonymisierte Entitäten, Dauer
- Cloud-Audit: Provider, Modell, Tokens (In/Out), Entitäten vor Cloud-Versand
/audit/{id} — mit Form-View (strukturiert) und Raw-View
(expandierbarer JSON). Nützlich für die Fehleranalyse bei unerwarteten Antworten.
Sub-Tab: Berichte (VVT & DSFA)
Generiert DSGVO-konforme Berichte auf Knopfdruck, basierend auf der aktuellen Systemkonfiguration.
KPI-Dashboard
| KPI | Beschreibung |
|---|---|
| Anfragen (30 Tage) | Gesamtzahl der KI-Anfragen im letzten Monat. |
| Cloud-Anteil | Prozentsatz der Anfragen, die an Cloud-LLMs gerouted wurden. |
| Anonymisierte Entitäten | Gesamtzahl der in 30 Tagen anonymisierten Entitäten. |
| Aktive Nutzer | Anzahl unterschiedlicher Benutzer in 30 Tagen. |
VVT — Verzeichnis der Verarbeitungstätigkeiten (DSGVO Art. 30)
Der Button »VVT generieren« erstellt ein vollständiges Verzeichnis der Verarbeitungstätigkeiten mit:
- Verarbeitungszweck und Rechtsgrundlage (Art. 6 Abs. 1 lit. f DSGVO)
- Betroffene Personen: Mitarbeiter, Kunden, Lieferanten
- Datenkategorien: Technische Dokumentation, Benutzeranfragen (SHA256-Hash), anonymisierte Antwort-Excerpts, Nutzungsstatistiken
- Empfänger: Interne Mitarbeiter, ggf. Cloud-KI-Anbieter (nur anonymisiert)
- Löschfristen: query_log (90 Tage), cloud_audit_log (365 Tage), chat_messages (365 Tage, user-deletable), anonymisierung_audit (365 Tage)
- TOM: Pseudonymisierung, Aho-Corasick, Inhaltsklassifizierung, RBAC/LDAP, HTTPS/TLS, Audit-Logging, Budget-Limitierung, lokale VectorDB
- Anonymisierungsverfahren: Deterministische Pseudonymisierung, Engine: Aho-Corasick + Regex-Fallback, 14 Kategorien
DSFA — Datenschutz-Folgenabschätzung (DSGVO Art. 35)
Der Button »DSFA generieren« erstellt eine Risikoanalyse. Eine DSFA ist erforderlich, wenn Cloud-KI-Backends konfiguriert sind.
- Erforderlichkeit: Ja (wenn Cloud aktiv) / Nein (rein lokal)
- Risiko-Katalog: Re-Identifikation, API-Key-Verlust, Datenverlust, Modell-Halluzination
- Pro Risiko: Eintrittswahrscheinlichkeit, Schwere, Maßnahmen
- Ergebnis: »AKZEPTABEL (mit Maßnahmen)« oder »Keine DSFA erforderlich«
Sub-Tab: Berechtigungsmatrix
Read-only-Übersicht der effektiven Zugriffsstruktur: Welche LDAP-Gruppe hat Zugriff auf welche Datenquellen und welche Tools?
Matrix-Aufbau
| Achse | Beschreibung |
|---|---|
| Zeilen | LDAP-Gruppen mit Mitglieder-Anzahl. |
| Spalten (links) | Datenquellen — Zugriff per Datenquellen-Zuweisung (siehe Datenquellen-Guide). |
| Spalten (rechts) | Tools — Zugriff per Tool-Berechtigungen (siehe Tools-Guide). |
| Zellen | ✓ = Zugriff, — = kein Zugriff. |
API-Endpunkte
Die vollständige API-Referenz wird dynamisch aus der Admin-Registry generiert:
- Compliance-API — Audit-Trail, Berichte (VVT/DSFA), Dashboard, Berechtigungsmatrix, Anonymisierungsstatistik