DSGVO-konform mit lokalem LLM: Wo Powerbrain den Unterschied macht
Lokal heißt nicht automatisch konform. Zwischen 'läuft on-prem' und 'übersteht ein Audit' liegen Policies, ein Vault für personenbezogene Daten und ein nachvollziehbares Audit-Log. Eine Einordnung am Beispiel des Open-Source-Projekts Powerbrain.
"Wir hosten das Modell selbst, also sind wir DSGVO-konform" - dieser Satz fällt in jedem zweiten Erstgespräch. Er ist ungefähr so genau wie "wir haben einen Server, also haben wir Backup". Lokale Inferenz ist eine notwendige, aber lange keine hinreichende Bedingung.
Was DSGVO und EU AI Act tatsächlich verlangen
Die regulatorische Realität in 2026 setzt vier Anforderungen an jeden produktiven KI-Einsatz mit personenbezogenen Daten:
- Zweckbindung und Rollenkontext. Nicht jeder Mitarbeitende darf jeden Datensatz sehen, nur weil er im Modellkontext landen könnte.
- Recht auf Löschung. Personenbezug muss nachträglich entfernt werden können - auch aus Embeddings und Vektorindizes.
- Nachvollziehbarkeit. Wer hat wann welchen Datensatz an welches Modell weitergegeben?
- Menschliche Kontrolle. Es muss einen funktionierenden Notaus geben, kein "wir starten den Container neu".
Ein blank installiertes Ollama mit angedocktem Vektorstore erfüllt davon nichts.
Wo ein Context-Engine wie Powerbrain ansetzt
Powerbrain ist eine Open-Source-Schicht zwischen Datenbestand und Agent. Sie liefert Kontext über das Model Context Protocol (MCP) aus - jede Anfrage prüft eine Policy-Engine. Vier Bausteine sind aus Compliance-Sicht relevant:
- Policy-Engine (OPA). Klassifikationsstufen (public, internal, confidential, restricted) werden je Agent-Rolle ausgewertet. Compliance steht als ausführbare Regel im Repository, nicht als PDF im Qualitätsmanagement.
- Sealed Vault. Personenbezogene Daten werden bei der Ingestion erkannt (Microsoft Presidio), pro Projekt mit eigenem Salt pseudonymisiert und in einem zweischichtigen Vault gespeichert. Art. 17-Löschung heißt: Vault-Mapping entfernen, Pseudonyme werden irreversibel.
- Audit-Hashchain. Jeder Zugriff landet in einem fortlaufend gehashten Log mit Append-Only-Garantie. Manipulationen fallen beim Verifizieren auf.
- Circuit Breaker und Approval Queue. Ein einziger HTTP-Call hält alle Datentools an. Confidential-Anfragen ohne Admin-Rolle landen in einer Review-Queue, statt durchgewunken zu werden.
Was das im Alltag verschiebt
Drei Dinge ändern sich gegenüber einem klassischen DIY-RAG-Stack spürbar:
- Audit-Vorbereitung dauert Stunden, nicht Wochen. Der "Annex IV"-Generator zieht Modelle, Policies, Audit-Stand und Risikoregister live aus dem laufenden System.
- Datenschutz-Diskussionen werden konkret. Statt "kann das die KI sehen?" gibt es Rego-Regeln, die geprüft, kommentiert und versioniert werden.
- Modellwechsel kostet weniger Mut. Wer die Policies trennt, kann Embeddings, Reranker oder LLM tauschen, ohne die Kontrollschicht neu zu zertifizieren.
Wann sich der Aufwand lohnt
Nicht jede interne Wissens-Suche braucht diese Tiefe. Die Schwelle erreichen wir typischerweise bei drei Konstellationen: regulierter Sektor (Recht, Gesundheit, Personal), gemischte Vertraulichkeitsstufen im selben Index oder mehr als ein Agent, der auf denselben Bestand zugreift. Ab dort ist die Investition in eine separate Context-Engine günstiger als jede dritte Audit-Runde mit handgepflegten Excel-Listen.
Wer heute mit lokalem RAG startet, sollte die Frage "wo läuft das Modell?" früh ergänzen um "wer entscheidet, was es zu sehen bekommt - und wer kann es nachweisen?".