WikiGuide: Compliance

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

FeldTypStandardBeschreibungEmpfehlung
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.

FeldTypStandardBeschreibungEmpfehlung
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
Tipp: Die Varianten-Spalte (Pipe-getrennt) ist entscheidend für die Erkennungsrate. Typische Varianten: Abkürzungen, andere Schreibweisen, mit/ohne Rechtsform. Der Aho-Corasick-Automat wird nach dem Laden der Stammdaten automatisch neu gebaut.

Schicht 2: LDAP / Active Directory

FeldTypStandardBeschreibung
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.

FeldTypBeschreibungBeispiel
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

MusterErkenntPseudonym-Kategorie
IBANDE89 3704 0044 0532 0130 00[IBAN_001]
E-Mailmax.mueller@firma.de[EMAIL_001]
Telefon+49 171 1234567[TELEFON_001]
Steuer-IDDE123456789[STEUER_ID_001]
IP-Adresse192.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.

FeldTypStandardBeschreibungEmpfehlung
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.
Achtung: Die LLM-Erkennung erhöht die Latenz um 1–5 Sekunden pro Anfrage. Sie ist als letzte Verteidigungslinie gedacht, nicht als primäre Erkennungsmethode. Für die meisten Installationen reichen die Schichten 1–3 aus.

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
Tipp: Vor dem Aktivieren der Cloud-Backends immer einen Anonymisierungstest mit realistischem Text durchführen. Typischer Testtext: Ein internes Protokoll mit Kundennamen, IBAN, E-Mail-Adressen und Mitarbeiternamen.

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

FilterTypBeschreibung
Von / BisDatumZeitraum eingrenzen.
ModusButton-GruppeAlle / Standard / Unchained / Agent.
RouteButton-GruppeAlle / Lokal / Cloud.
SucheTextVolltextsuche in Frage-Excerpts (ILIKE).

Tabellen-Spalten

SpalteBeschreibungSortierbar
IDLaufende Nummer.Ja
ZeitstempelDatum und Uhrzeit der Anfrage.Ja
BenutzerBenutzername des Anfragenden.Ja
ModusBadge: Standard (blau), Unchained (orange), Agent (lila).Ja
RouteBadge: Lokal / Cloud / MCP.Ja
Chat-IDZugehörige Chat-Session.Nein
FrageGekürzt (max. 60 Zeichen).Nein
DauerVerarbeitungszeit in ms.Ja
DetailLink 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
Tipp: Die Detail-Ansicht gibt es auch als vollständige Seite unter /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

KPIBeschreibung
Anfragen (30 Tage)Gesamtzahl der KI-Anfragen im letzten Monat.
Cloud-AnteilProzentsatz der Anfragen, die an Cloud-LLMs gerouted wurden.
Anonymisierte EntitätenGesamtzahl der in 30 Tagen anonymisierten Entitäten.
Aktive NutzerAnzahl 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«
Tipp: VVT und DSFA werden dynamisch aus der aktuellen Systemkonfiguration generiert. Wenn z.B. ein Cloud-Backend hinzugefügt oder die Anonymisierung geändert wird, ändern sich auch die Berichte. Es empfiehlt sich, nach jeder wesentlichen Config-Änderung die Berichte neu zu generieren und zu archivieren.

Sub-Tab: Berechtigungsmatrix

Read-only-Übersicht der effektiven Zugriffsstruktur: Welche LDAP-Gruppe hat Zugriff auf welche Datenquellen und welche Tools?

Matrix-Aufbau

AchseBeschreibung
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.
Tipp: Die Matrix ist eine Zusammenführung aus zwei Quellen: Datenquellen-Gruppen (konfiguriert im Datenquellen-Tab) und Tool-Berechtigungen (konfiguriert im Tools-Tab). Änderungen werden nicht hier vorgenommen, sondern in den jeweiligen Tabs. Die Matrix dient der Übersicht und Kontrolle.

API-Endpunkte

Die vollständige API-Referenz wird dynamisch aus der Admin-Registry generiert:

  • Compliance-API — Audit-Trail, Berichte (VVT/DSFA), Dashboard, Berechtigungsmatrix, Anonymisierungsstatistik