LLM-Plattform unter Art.-9-DSGVO - Architektur einer self-hosted Auswertung
Case Study: Plattform für besonders schützenswerte Daten - self-hosted, verschlüsselt, mit regulatorischer Grenze als CI-Gate statt Richtlinie.
LLM Plattform unter Art. 9 DSGVO Architektur einer self hosted Auswertung
<p data speakable Der schwierige Teil an Sprachmodellen in regulierten Umgebungen ist nicht das Modell es ist die Grenze, die es nicht überschreiten darf. Diese Case Study beschreibt eine Plattform, die Dokumente mit besonders schützenswerten personenbezogenen Daten nach Art. 9 DSGVO verarbeitet: vollständig self hosted, personenbezogene Felder verschlüsselt und trotzdem durchsuchbar, und mit einer regulatorischen Abgrenzung, die als Test in der CI Pipeline erzwungen wird statt als Richtlinie zu existieren. Alle Angaben sind auf die Architektur beschränkt; Produktinhalte bleiben außen vor.</p
Ausgangslage
Ein Produkt sollte hochgeladene Dokumente auswerten und die Ergebnisse verständlich aufbereiten. Die Dokumente enthalten Daten, die nach Art. 9 DSGVO zu den besonderen Kategorien personenbezogener Daten zählen die strengste Klasse, die die Verordnung kennt.
Daraus ergaben sich drei Anforderungen, die sich gegenseitig im Weg standen:
1. Die Daten dürfen die eigene Infrastruktur nicht verlassen. Damit fällt jede Verarbeitung über einen Dritt SaaS Anbieter weg auch mit Auftragsverarbeitungsvertrag. 2. Die Ausgabe darf keine individuelle Einordnung darstellen. Sobald ein System den Zustand einer konkreten Person bewertet, kann es in den Anwendungsbereich der EU Medizinprodukteverordnung fallen. Das war ausdrücklich nicht das Ziel. 3. Sprachmodelle tun genau das von selbst. Die individuelle Einordnung ist die naheliegendste Antwortform, die ein LLM auf solche Eingaben produziert.
Anforderung 2 und 3 zusammen sind der eigentliche Kern. Man kann einem Modell nicht per Systemprompt verlässlich abgewöhnen, wozu es strukturell neigt.
Entscheidung 1: Self hosted, vollständig
Der komplette Stack läuft auf eigener Infrastruktur: Container Orchestrierung, Postgres mit Vektor Erweiterung, Redis als Queue Backend, S3 kompatibler Objektspeicher, Reverse Proxy mit Forward Auth vor allen internen Werkzeugen. Kein Datenbank Port ist nach außen exponiert; der einzige externe Zugang für Wartung läuft über einen SSH Tunnel.
Das ist teurer in der Wartung als Managed Services. Bei dieser Datenklasse gibt es aber keine Alternative, die man einem Datenschutzbeauftragten erklären könnte.
Was daraus folgt und gern unterschätzt wird: Backups, Restore Drills, Zertifikats Rotation, Monitoring und Log Retention werden zu eigenen Arbeitspaketen. Ein Backup ohne dokumentierten, tatsächlich einmal durchgeführten Restore ist kein Backup.
Entscheidung 2: Verschlüsselt speichern, trotzdem suchen
Personenbezogene Felder liegen AES 256 GCM verschlüsselt in der Datenbank. Das allein wäre unbrauchbar man kann auf verschlüsselten Feldern nicht suchen, und ein Login braucht genau das.
Die Lösung ist ein zweites Feld neben dem verschlüsselten Wert:
feld encrypted AES 256 GCM, der eigentliche Inhalt feld hmac HMAC SHA 256 über denselben Klartext, deterministisch
Für einen Lookup bildet die Anwendung den HMAC der Suchanfrage und vergleicht Hashes. Der Klartext existiert nie in der Datenbank, Gleichheitssuchen bleiben indexierbar und schnell.
Die Einschränkung gehört zur Ehrlichkeit dazu: Bereichsabfragen und Teilstring Suchen funktionieren so nicht. Wer LIKE '%muster%' braucht, braucht ein anderes Verfahren.
Dazu kommt eine Regel, die in jedem Logging Pfad gilt: personenbezogene Daten erscheinen ausschließlich als Hash. Adressen als SHA 256, IP Adressen gehasht und auf 16 Hex Zeichen gekürzt. Ein Log, das im Fehlerfall Klartext ausspuckt, macht die Verschlüsselung in der Datenbank wertlos.
Entscheidung 3: Die Regel Engine entscheidet, das Modell formuliert
Das ist der Kern der regulatorischen Abgrenzung.
Jede Aussage, die einer Einordnung nahekommt, entsteht deterministisch in einer regelbasierten Engine mit fest hinterlegten Referenzbereichen. Kein Sprachmodell ist an dieser Stelle beteiligt. Gleiche Eingabe ergibt garantiert gleiche Ausgabe, der Pfad ist nachvollziehbar und im Test abgedeckt.
Das Sprachmodell bekommt eine strikt eingegrenzte Aufgabe: aus vorgegebenen, belegten Bausteinen lesbaren Text erzeugen. Es wählt Formulierungen, es trifft keine Entscheidungen.
Konkrete Konsequenzen in der Umsetzung:
Erklärtexte sind generisch formuliert und beginnen nicht in der zweiten Person. Ein Satz über einen Wert beschreibt den Wert, nicht die Person. Es gibt keine Textvarianten, die nach dem individuellen Ergebnis ausgewählt werden. Die Karte zeigt denselben generischen Text, unabhängig vom Resultat. Abschnittsüberschriften sind rein positional formuliert, ohne wertende Sprache. Ergänzende Hinweise erscheinen als vollständige, ergebnisunabhängige Tabelle zum Selbstablesen, nicht als personalisierte Zeile.
Jede dieser Regeln sieht nach Detail aus. Zusammen sind sie der Unterschied zwischen einem Informationsangebot und einem regulierten Produkt.
Entscheidung 4: RAG mit Zitationspflicht
Die Wissensbasis speist sich ausschließlich aus freigegebenen Quelldokumenten. Kein Chunk kommt ohne zwei Pflichtfelder in den Index:
source ref Quelldokument plus Seitenangabe content hash Hash des Inhalts, für Drift Erkennung
Ohne Citation kein Insert. Web Recherche und Modellwissen sind als Quelle ausgeschlossen nicht empfohlen, sondern durch die Ingestion Pipeline verhindert.
Auf der Ausgabeseite steht eine zentrale Output Policy als einzige Quelle der Wahrheit für Scrubbing und Validierung. Sie entfernt Fremdmarken und Quellen Footer, erkennt durchgesickerte Quellennamen und wirft eine Violation, wenn eine Antwort nicht gegen die Wissensbasis gedeckt ist. Wichtig ist das Wort zentral : dieselben Regex Regeln an zwei Stellen zu pflegen bedeutet, dass sie nach drei Monaten auseinanderlaufen.
Der dritte Baustein ist ein Drift Audit . Es vergleicht die Quelldateien mit dem, was tatsächlich im Vektorindex liegt. Der Anlass war konkret: eine Reihe von Inhalten existierte zwei Wochen lang in den Quelldateien, aber nie in der Datenbank die Nutzer bekamen währenddessen eine unvollständige Antwort, ohne dass irgendein Test angeschlagen hätte. Seitdem läuft das Audit lokal vor jedem Push und auf dem Standby System vor jedem Traffic Wechsel.
Entscheidung 5: Compliance als ausführbarer Test
Der Punkt, der aus meiner Sicht am weitesten trägt.
Die anwaltlich definierte Grenze ist nicht als Richtlinie dokumentiert, sondern als Regressionstest implementiert. Er scannt Konfigurationsdateien, Regelwerke und Wissensbasis Inhalte gegen unzulässige Formulierungen und Muster. Findet er einen neuen Verstoß, schlägt die Pipeline fehl.
Bekannte Altlasten stehen in einer Allowlist mit einer Regel, die den Unterschied macht: die Allowlist darf ausschließlich schrumpfen. Ein Eintrag hinzuzufügen ist nicht vorgesehen. Damit ist der einzige mögliche Pfad der in Richtung sauber.
Warum das mehr wert ist als ein Dokument im Wiki:
Eine Richtlinie wird beim Onboarding gelesen und danach nie wieder. Ein Test läuft bei jedem Commit. Ein neuer Mitarbeiter kann die Grenze nicht versehentlich überschreiten der Build sagt es ihm in zwei Minuten. Bei einer Prüfung ist die Frage „wie stellen Sie das sicher?" mit einem Testlauf beantwortet statt mit einer Absichtserklärung.
Das Muster ist branchenunabhängig. Überall dort, wo Textausgaben rechtlichen Grenzen unterliegen Finanzberatung, Versicherung, Rechtsdienstleistung funktioniert derselbe Ansatz.
Entscheidung 6: Blue/Green statt Wartungsfenster
Deployment läuft als Blue/Green Wechsel: Die neue Version fährt parallel hoch, ein Healthcheck prüft sie bevor Traffic umgeleitet wird, Hintergrund Worker werden vorher kontrolliert geleert, damit keine laufenden Jobs abbrechen. Rollback ist ein Schalter, kein erneutes Deployment.
Der Healthcheck prüft dabei nicht nur, ob der Prozess antwortet, sondern ob die Wissensbasis auf dem Standby System vollständig indexiert ist. Ein technisch gesunder Dienst mit halb geladenem Index ist der teurere Fehler.
Was davon übertragbar ist
Die Plattform ist ein Spezialfall. Die Muster sind es nicht:
| Muster | Überträgt sich auf | | | | | Verschlüsselt speichern, per HMAC Index suchen | Jede Anwendung mit personenbezogenen Login Feldern | | Deterministische Engine trifft Entscheidungen, LLM formuliert | Jede regulierte Textausgabe | | Zitationspflicht pro Chunk plus zentrale Output Policy | Jedes RAG System mit Haftungsrelevanz | | Grenze als Regressionstest mit schrumpfender Allowlist | Jede Compliance Anforderung an Inhalte | | Drift Audit zwischen Quelle und Index | Jede Wissensbasis, die aus Dateien gespeist wird | | Blue/Green mit Pre Traffic Healthcheck | Jeder Dienst mit Hintergrundjobs |
Wer in einer Branche mit Verschwiegenheitspflicht arbeitet Kanzleien, Steuerberatung, Versicherung, Pflege trifft auf dieselben drei Fragen: Dürfen die Daten raus? Wer haftet für die Ausgabe? Wie beweist man beides bei einer Prüfung?
Die Antworten sind Architektur Entscheidungen, keine Tool Entscheidungen.
Zwei Regelwerke führen besonders häufig auf genau diesen Weg. Für Berufsgeheimnisträger ist es § 203 StGB, der die Frage von der Vertrags auf die Architekturebene verschiebt. Für Betreiber in den NIS2 Sektoren ist es die Lieferkettenbetrachtung, die einen externen KI Dienst vom Werkzeug zum bewertungspflichtigen Lieferanten macht.
Den Baustein aus Entscheidung 5 habe ich separat ausführlicher beschrieben, weil er branchenunabhängig funktioniert: Compliance als ausführbarer Test.
Hinweis zur Darstellung
Diese Case Study beschreibt ausschließlich Architektur, Datenhaltung und Auslieferung. Produktinhalte, Auswertungslogik im fachlichen Sinn und Nutzerdaten sind bewusst nicht Gegenstand der Darstellung. Das Projekt befindet sich in geschlossener Beta; Kennzahlen beziehen sich auf das System, nicht auf Nutzung.