DSGVO-konform mit kommerzieller KI: der lokale Vorfilter
Wie Sie kommerzielle Sprachmodelle nutzen, ohne sensible Daten preiszugeben: Ein lokaler Vorfilter pseudonymisiert vor dem Versand und setzt die echten Werte erst lokal wieder ein.
Kommerzielle Sprachmodelle sind stark, aber sensible Daten gehören nicht ungeschützt in fremde Clouds. Der Ausweg ist ein lokaler Vorfilter: Personendaten werden vor dem Versand durch Platzhalter ersetzt, das externe Modell arbeitet nur mit den Platzhaltern, und die echten Werte werden lokal wieder eingesetzt. So bleibt die Datenhoheit im Haus. Wichtig: Pseudonymisierung ist nicht dasselbe wie Anonymisierung.
Das Dilemma: starke KI, sensible Daten
Viele Organisationen in Verwaltung und Mittelstand wollen die Stärke kommerzieller Sprachmodelle nutzen, auch des europäischen Le Chat von Mistral. Sobald aber echte Personendaten in den Prompt wandern, wird es datenschutzkritisch: Namen, Adressen, Aktenzeichen oder Gesundheitsdaten würden an einen externen Anbieter übertragen.
Die naheliegende Antwort "wir verbieten das einfach" verschenkt Produktivität. Die andere "wir nutzen es trotzdem" verschenkt Datenhoheit. Es gibt einen Weg dazwischen.
Der Workflow in vier Schritten
Das Prinzip: Sensible Daten verlassen nie das eigene System.
- Lokaler Vorfilter. Ein LLM auf eigener Infrastruktur (etwa über Ollama) erkennt personenbezogene Angaben und ersetzt sie durch typisierte Platzhalter. Die Zuordnung zwischen Platzhalter und echtem Wert bleibt ausschließlich lokal.
- Cloud-Anfrage. Nur der pseudonymisierte Prompt geht an das kommerzielle Modell. Es sieht nie eine echte Person.
- Antwort. Das Modell arbeitet mit den Platzhaltern und liefert sein Ergebnis.
- Rück-Einsetzung. Lokal werden die Platzhalter wieder durch die echten Werte ersetzt. Die fertige Antwort entsteht erst auf dem eigenen System.
Wofür man das nutzt
Überall, wo ein Sprachmodell mit Texten helfen soll, die Personenbezug enthalten:
- Schriftverkehr: Entwürfe für Bürger- oder Kundenantworten formulieren, ohne Namen und Aktenzeichen preiszugeben.
- Akten und Protokolle: lange Vorgänge zusammenfassen oder in eine Struktur bringen.
- Bewerbungen: Lebensläufe sichten und vergleichen, ohne Bewerberdaten in die Cloud zu geben.
- Verträge und Bescheide: Klauseln erklären, Formulierungen prüfen, Textbausteine erzeugen.
- Support: eingehende Anfragen kategorisieren und Antwortvorschläge erstellen.
Bei besonders sensiblen Daten, etwa Gesundheits- oder Sozialdaten nach Art. 9 DSGVO, bleibt die Verarbeitung besser ganz lokal.
Womit sich das umsetzen lässt
Das Muster ist etablierte Praxis. Diese quelloffenen Werkzeuge decken die Bausteine ab:
- Microsoft Presidio: erkennt personenbezogene Daten (Namen, IBANs, Adressen und mehr), ersetzt sie durch Platzhalter und setzt sie nach der Antwort wieder ein.
- LLM Guard: kapselt denselben Ablauf als Gateway und verwaltet die Zuordnung in einem lokalen Vault.
- GLiNER: ein leichtgewichtiges Modell, das auch Entitätstypen findet, für die es keine festen Regeln gibt.
- Ollama: betreibt das lokale Sprachmodell auf eigener Hardware, ohne Cloud.
Einen einsatzfertigen Beispiel-Skill, der genau diesen Ablauf abbildet, stellen wir zum Download bereit: DSGVO-LLM-Vorfilter-Skill.
Was es nicht ist
- Nicht "anonym": Pseudonymisierte Daten bleiben unter der DSGVO personenbezogen (Art. 4 Nr. 5). Echte Anonymisierung ist irreversibel und damit etwas anderes.
- Nicht "narrensicher": Freitext kann im Einzelfall Rückschlüsse zulassen, und Modelle können aus Kontext Identitäten ableiten. Die Qualität der Erkennung entscheidet.
- Nicht "Rechtsersatz": Der Vorfilter ist eine technische Schutzmaßnahme, keine Bewertung der Auftragsverarbeitung oder der Rechtsgrundlage.
Grenzen und Governance
Das lokale Mapping ist ein Schutzgut: Wer es zusammen mit dem pseudonymisierten Text besitzt, kann re-identifizieren. Es gehört deshalb nur in die eigene Umgebung und wird nach Gebrauch gelöscht. Für besonders schützenswerte Daten (Art. 9 DSGVO) kann ein lokales Modell die Aufgabe auch vollständig übernehmen, dann entfällt der Cloud-Schritt ganz.
Als "Privacy by Design" im Sinne von Art. 25 DSGVO senkt dieser Aufbau das Risiko deutlich: Der Anbieter sieht nie Klardaten, und die Konformität entsteht durch die Architektur, nicht erst durch nachträgliche Audits.
Wie dieser Ansatz in die größere Strategie passt, lesen Sie in Digitale Souveränität in der Verwaltung.
Drei nächste Schritte
- Use Cases sammeln: Wo würde ein Sprachmodell echten Nutzen bringen, und welche Datenklassen wären betroffen?
- Erkennung testen: Den Vorfilter an realen, repräsentativen Texten prüfen, mit Blick auf deutschsprachige und fachspezifische Begriffe.
- Betrieb festlegen: Wo läuft das lokale Modell, wer verantwortet das Mapping, wie wird es gelöscht?
Gemeinsam umsetzen
Wenn Sie kommerzielle KI nutzen wollen, ohne die Datenhoheit aufzugeben: Wir bauen und erproben solche souveränen KI-Workflows und klären mit Ihnen Anwendungsfälle, Risiken und Betrieb.