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 (Uebersicht der effektiven Zugriffsrechte).
Sub-Tab: Anonymisierung
Vierstufige Anonymisierung zum Schutz sensibler Daten. Die Schichten werden
nacheinander ausgefuehrt — jede erkennt Entitaeten, die vorherige Schichten
verpasst haben. Erkannte Entitaeten 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 (Entitaeten-Anzahl, Kategorien, Route). | Aktiviert lassen — noetig fuer DSGVO-Nachweispflicht. |
Max. Content-Klasse fuer Cloud |
Radio-Gruppe | LOW (3) |
Bestimmt, welche Inhalte an Cloud-LLMs gesendet werden duerfen: LOW (3): Nur technische Dokumentation. MEDIUM (2): + Einkauf/Logistik. HIGH (1): + Finanzen/Personal. |
LOW empfohlen — minimiert das Risiko. Nur erhoehen, 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). Nuetzlich fuer Firmennamen, Produktbezeichnungen, Abteilungskuerzel. | Beispiel: KIara, SAP, HR |
Schicht 1: ERP-Stammdaten (Aho-Corasick)
Deterministischer Pattern-Matching-Algorithmus. Laedt Kunden, Lieferanten, Mitarbeiter und Produkte aus CSV-Dateien und erkennt sie in <10ms — auch bei 50.000+ Eintraegen.
| Feld | Typ | Standard | Beschreibung | Empfehlung |
|---|---|---|---|---|
ERP-Import aktiv |
Checkbox | Aus | Aktiviert den Aho-Corasick-Automaten fuer 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-Pruefung |
Checkbox | An | Verhindert Teiluebereinstimmungen: »Mueller« wird nicht in »Benzmueller« erkannt. | Immer aktiviert lassen. Deaktivierung fuehrt zu vielen False Positives. |
Mindestlaenge fuer Treffer |
Zahl | 3 |
Minimum Zeichenlaenge fuer eine Erkennung (1–20). | 3 ist ein guter Wert. Niedriger = mehr Treffer (inkl. False Positives). |
Benutzerdefinierte Eintraege |
Textarea (JSON) | [] |
Zusaetzliche Eintraege im Format:[{"text": "Firmenname", "type": "ORG", "key": "K-001"}]
|
Fuer Eintraege, die nicht in den ERP-Stammdaten stehen. |
Stammdaten-Format (CSV)
# Semikolon-getrennt, eine Entitaet 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 | Laedt 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 ueber regulaere Ausdruecke: IBAN, Telefonnummern, E-Mail-Adressen, Steuer-IDs etc. Zusaetzlich koennen benutzerdefinierte Muster hinzugefuegt 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 Entitaeten, die von den vorherigen Schichten verpasst wurden (z.B. unbekannte Personennamen, Organisationen). Laeuft 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 noetig ist. |
Modell |
Text | (leer = Standard-LLM) | Optionales dediziertes Modell fuer die PII-Erkennung. | Leer lassen — das Standard-LLM ist meist ausreichend. |
Confidence-Schwellwert |
Zahl | 0.7 |
Entitaeten unter diesem Wert (0.0–1.0) werden verworfen. | 0.7 ist ein guter Kompromiss. Hoeher = 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 fuer die meisten Texte. |
Cache-Groesse |
Zahl | 256 |
LRU-Cache fuer bereits analysierte Texte (0–10.000). | 256. Reduziert wiederholte LLM-Calls bei aehnlichen Anfragen. |
Context-Window |
Zahl | 4096 |
Kontextfenster des LLMs fuer die PII-Erkennung (512–131.072). | 4096 reicht fuer einzelne Benutzer-Anfragen. |
Test-Funktion
Der Button »Anonymisierung testen...« oeffnet ein Modal, in dem ein beliebiger Text eingegeben und die Anonymisierungspipeline live getestet werden kann.
Das Ergebnis zeigt:
- Anonymisierter Text: Alle Pseudonyme hervorgehoben
- Entitaeten-Tabelle: Original → Pseudonym fuer jeden Treffer
- Statistik: Gesamtzahl erkannter Entitaeten
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 | Zugehoerige Chat-Session. | Nein |
| Frage | Gekuerzt (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 vollstaendige Prompt (bei Agent: Message-Array)
- Tool-Calls: Tool-Name, Iteration, Parameter (JSON), Ergebnis
- KI-Output: Vollstaendige Antwort
- Meta-Daten: Modell, Chunks, anonymisierte Entitaeten, Dauer
- Cloud-Audit: Provider, Modell, Tokens (In/Out), Entitaeten vor Cloud-Versand
/audit/{id} — mit Form-View (strukturiert) und Raw-View
(expandierbarer JSON). Nuetzlich fuer 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 Entitaeten | Gesamtzahl der in 30 Tagen anonymisierten Entitaeten. |
| Aktive Nutzer | Anzahl unterschiedlicher Benutzer in 30 Tagen. |
VVT — Verzeichnis der Verarbeitungstaetigkeiten (DSGVO Art. 30)
Der Button »VVT generieren« erstellt ein vollstaendiges Verzeichnis der Verarbeitungstaetigkeiten 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
- Empfaenger: Interne Mitarbeiter, ggf. Cloud-KI-Anbieter (nur anonymisiert)
- Loeschfristen: 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-Folgenabschaetzung (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, Massnahmen
- Ergebnis: »AKZEPTABEL (mit Massnahmen)« oder »Keine DSFA erforderlich«
Sub-Tab: Berechtigungsmatrix
Read-only-Uebersicht 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 vollstaendige API-Referenz wird dynamisch aus der Admin-Registry generiert:
- Compliance-API — Audit-Trail, Berichte (VVT/DSFA), Dashboard, Berechtigungsmatrix, Anonymisierungsstatistik