Ist ein Embedding schützenswert?

Wir entwickeln unter anderem eine Verwaltungssoftware für Psychotherapiepraxen. Datenschutz und Datensicherheit nehmen wir immer sehr ernst, aber in diesem Umfeld sind diese Themen natürlich essenziell. Therapiedokumentation ist Art.-9-Material nach DSGVO und fällt zusätzlich unter das strafbewehrte Berufsgeheimnis. § 203 Abs. 3 S. 2 StGB zieht Softwareanbieter mit Zugriffsmöglichkeit ausdrücklich in den Schutzbereich hinein.

Entsprechend unserer Firmenkultur versuchen wir immer neue Technologien einzusetzen, wenn sie sinnvoll sind, und eine semantische Suche finden wir in einem Verwaltungsprogramm sehr hilfreich. Die Technologie ist inzwischen auch weit verbreitet und die Umsetzung dementsprechend kein Hexenwerk. Nach der initialen Idee hat mich aber eine Frage nachts geweckt und nicht mehr schlafen lassen. Wie sensibel sind denn die Daten in einem Embedding? Es sind doch nur Zahlen wie ein Hash und für Menschen nicht lesbar – aber im Kern sind es ja Vektoren, die Eigenschaften abbilden…

Nach längerem Grübeln im Bett habe ich das Thema am nächsten Tag genauer unter die Lupe genommen. Ich hole hier erst ein bisschen aus und zeige dann die Ergebnisse meiner Recherchen.

Erste Prüfung: Wie viel Information trägt ein Vektor?

Die naheliegende Einordnung wäre, ein Embedding wie einen Hash oder einen technischen Suchindex zu behandeln. Undurchsichtig, nicht menschenlesbar, ein Hilfsmittel. Das passt aber nur auf den ersten Blick.

Ein Embedding ist keine Einwegfunktion

Ein kryptographischer Hash hat zwei Eigenschaften, auf die man sich verlässt. Er ist praktisch nicht rückrechenbar, und die kleinste Eingabeänderung erzeugt eine völlig andere Ausgabe. Bei einem Embedding ist die zweite Eigenschaft konstruktiv ausgeschlossen. Ähnliche Texte sollen ähnliche Vektoren ergeben, das ist der gesamte Zweck. Wo Ähnlichkeit erhalten bleibt, bleibt Information erhalten.

Ein Embedding ist keine Verschlüsselung

Verschlüsselung ist es ebenfalls nicht, weil es keinen Schlüssel gibt. Wer das Modell kennt, und bei Open-Weights-Modellen oder kommerziellen APIs kennt es jeder, kann Vektoren erzeugen und vergleichen.

Ein Embedding ist keine Anonymisierung

Anonymisierung scheidet aus demselben Grund aus. Ein deterministisch erzeugter Vektor ist ein Fingerabdruck. Derselbe Text ergibt immer denselben Vektor, was Verkettung über Bestände hinweg erlaubt.

Die Datenschutzkonferenz formuliert das in ihrer Orientierungshilfe zu RAG-Systemen relativ einfach: Die erzeugten Vektoren repräsentieren die Bedeutung der jeweiligen Informationen. Genau deshalb funktioniert semantische Suche, und genau deshalb ist der Vektor kein neutrales Hilfsmittel.

Damit war die grundsätzliche Richtung klar. Unklar war mir noch, wie belastbar eine Rekonstruktion tatsächlich ist, denn davon hängt ab, wie streng man das Schutzniveau ansetzen muss.

Zweite Prüfung: Der Forschungsstand

Ich habe in Literatur zu Embedding-Inversion recherchiert. Am meisten überzeugt hat dabei nicht die Trefferquote der einzelnen Verfahren, sondern die Richtung, in die sich die Voraussetzungen entwickeln.

2020 zeigen Song und Raghunathan, dass sich über die Hälfte der Eingabewörter aus einem Satz-Embedding zurückgewinnen lässt. Ohne Reihenfolge, aber die Wörter sind da. Dazu Attribut-Inferenz für Merkmale wie Geschlecht oder Herkunft.

2023 erscheint Vec2Text von Morris et al., ein iteratives Verfahren aus Hypothese und Korrektur. Bei 32-Token-Eingaben erreicht es 92 Prozent exakte Rekonstruktion bei einem BLEU-Score von 97,3, auch gegen kommerzielle APIs.

Der naheliegende Einwand an dieser Stelle lautet, dass ein Angreifer dafür große Mengen Trainingsmaterial aus dem konkreten Vektorraum bräuchte.

2025 entkräftet ALGEN diesen Einwand. Eine Handvoll geleakter Vektoren genügt, und die zugehörigen Originaltexte muss der Angreifer nicht kennen. Er trainiert einen Decoder auf öffentlichen Daten und lernt eine lineare Abbildung vom Ziel-Vektorraum in seinen eigenen. Frühere Verfahren brauchten dafür zwischen 8.000 und fünf Millionen Beispiele.

2026 entfällt mit Zero2Text auch diese Hürde. Kein Training, keine geleakten Paare. Blackbox-Zugriff auf das Embedding-Modell reicht, und damit lassen sich auch geschlossene Modelle wie OpenAIs text-embedding-3 invertieren. Differential-Privacy-Rauschen als Verteidigung wirkt dagegen nicht.

Also geht es in eine klare Richtung – ähnlich wie bei Verschlüsselungsverfahren. Wer Daten längere Zeit speichert, kann darauf hoffen, bald mit minimalen Mitteln an den eigentlichen Inhalt zu kommen.

Dritte Prüfung: Was das Standardrezept mitliefert

Parallel dazu haben wir uns angesehen, was die üblichen Implementierungsmuster eigentlich in die Datenbank schreiben.

Neben dem Vektor liegt der Chunk im Klartext. Das ist kein Versehen der Frameworks, sondern notwendig, weil der Text nach dem Retrieval ins Prompt muss. Die DSK beschreibt genau diese Struktur als Normalfall und spricht von Tripeln aus Chunk, Tokensequenz und Vektor.

Für viele Anwendungen ist das unproblematisch. Für Therapiedokumentation bedeutet es, dass das Standardrezept eine Klartextkopie des sensibelsten Bestands anlegt, den ein solches System hat, und zwar außerhalb der Schutzmechanismen, die für die Primärakte gelten. Ein No-Go.

Das ist der Punkt, an dem klar wurde, dass wir vom Standardweg abweichen. Nicht wegen exotischer Inversionsangriffe, sondern weil schon das Muster, das die meisten Standard-Ansätze mitbringen, für unseren Datenkontext nicht passt.

Vierte Prüfung: Das Bedrohungsmodell

Wir haben das Bedrohungsmodell für das Retrieval-Subsystem eigenständig aufgeschrieben, unabhängig von den restlichen Systembestandteilen.

Similarity Probing ist der wahrscheinlichste Angriff. Wer weiß, welches Embedding-Modell im Einsatz ist, berechnet den Vektor zu einem hypothetischen Satz, etwa einer Diagnoseformulierung, und sucht die nächstliegenden Chunks. Kein Angriffsmodell, kein Training, ein Aufruf gegen die eigene Suchfunktion des Systems.

Membership Inference ist bei einer Psychotherapiepraxis schon für sich genommen schwerwiegend. Die Frage, ob zu einer Person überhaupt eine Akte existiert, ist eine Offenbarung im Sinne des § 203 StGB, ganz ohne Akteninhalt. Die DSK nennt diesen Angriffsvektor ausdrücklich.

Attribut-Inferenz liefert einzelne sensible Merkmale auch ohne Volltextrekonstruktion.

Data Poisoning ist der Weg in die Gegenrichtung. Wer Einträge in die Vektordatenbank einbringen kann, steuert, welche Kontexte ein Sprachmodell zu sehen bekommt. Für eine Funktion, die Dokumentations- oder Gutachtenentwürfe erzeugt (zur Diskussion in diesem Bereich schreibe ich noch einen gesonderten Artikel), ist das ein Integritätsrisiko und damit ein fachliches, nicht nur ein datenschutzrechtliches Problem.

Fünfte Prüfung: Der regulatorische Rahmen

Die rechtliche Einordnung hat die technische Einschätzung bestätigt und an einer Stelle Spielraum eröffnet, mit dem wir nicht gerechnet hatten.

Embeddings personenbezogener Dokumente sind personenbezogene Daten. Art. 4 Nr. 1 DSGVO in Verbindung mit Erwägungsgrund 26, der auf Mittel abstellt, die nach allgemeinem Ermessen wahrscheinlich genutzt werden.

Der EuGH hat mit Urteil vom 4. September 2025 in der Rechtssache C-413/23 P (EDSB/SRB) die Relativität des Personenbezugs bestätigt. Dieselben pseudonymisierten Daten können für einen Empfänger ohne Schlüssel nicht-personenbezogen sein und für den Absender personenbezogen bleiben. Das wird gelegentlich als Argument für eine entspannte Einstufung von Embeddings zitiert. Für den Betreiber eines eigenen Aktenbestands – wie wir es umsetzen – trägt es nicht, denn wer Vektordatenbank und Personenzuordnung selbst hält, hat nichts zu relativieren.

Art. 9 DSGVO ist kein Ausschlusskriterium. Das war die Erleichterung. Die DSK hält fest, dass bei Erfüllung der Anforderungen auch Daten nach Art. 9 und Art. 10 in einem RAG-System verarbeitet werden können, gerade weil sie separat in Referenzdokumenten und Vektordatenbank liegen und nicht dauerhaft im Sprachmodell verbleiben, solange kein Training oder Nachtraining stattfindet.

Das ist die klarste Architekturaussage der Aufsichtsbehörden zu diesem Thema. RAG ja, Fine-Tuning mit Aktendaten nein. Wer sensible Bestände in Modellgewichte einbrennt, verliert Löschbarkeit, Auskunftsfähigkeit und Zweckbindung in einem Zug.

Die Betroffenenrechte sind derselbe Gedanke aus anderer Richtung. Die DSK stellt fest, dass Einträge in der Vektordatenbank direkt adressierbar und damit gezielt löschbar sind. Art. 15, 16 und 17 bleiben umsetzbar, sofern das Löschkonzept Embeddings, Chunks, Caches und Backups gleichermaßen erfasst. Ein Löschlauf, der die Akte entfernt und den Vektor stehen lässt, ist keine Löschung. Auch zum Thema Datenhaltung und Löschung folgt demnächst ein Artikel.

Dazu gehört eine Abwägung, die man früh treffen sollte. § 630f Abs. 3 BGB verlangt zehn Jahre Aufbewahrung der Patientenakte. Entweder der Vektorbestand bildet diese Fristen nach, oder er wird bewusst kürzer gehalten. Die Aufbewahrungspflicht gilt der Akte, nicht einem Suchindex darüber.

Der Rest ist Pflichtprogramm. Art. 32 nennt Verschlüsselung ausdrücklich, mit risikobasiertem Maßstab, der bei Art.-9-Daten hoch liegt. Art. 35 Abs. 3 lit. b macht die Datenschutz-Folgenabschätzung praktisch verbindlich. Und die DSK stellt klar, dass ein RAG-System ein KI-System nach Art. 3 Nr. 1 der KI-Verordnung ist, womit mindestens Transparenz- und Kompetenzpflichten greifen. Für Personalverwaltungsmodule lohnt zusätzlich der Blick auf Anhang III Nr. 4.

Die Frage, auf die alles hinausläuft

Mit den gesammelten Informationen war die Sicherheitsstufe schon ziemlich klar. Aber die Frage „Müssen wir den Vektor verschlüsseln?" ist mehrdeutig, weil Verschlüsselung hier zwei verschiedene Dinge bezeichnet.

Verschlüsselung at Rest, also verschlüsseltes Volume oder Transparent Data Encryption, ist für die Datenbank transparent. Die Engine entschlüsselt beim Lesen, der ANN-Index arbeitet auf Klartextvektoren im Arbeitsspeicher. Sie schützt gegen entwendete Datenträger, kopierte Backups und den Infrastrukturbetreiber. Die Vektorsuche funktioniert unverändert.

Feldverschlüsselung in der Anwendung verschlüsselt den Vektor, bevor er in die Datenbank geschrieben wird. Abstände zwischen verschlüsselten Vektoren sind bedeutungslos, jeder ANN-Index wird wertlos. Die datenbankseitige Suche entfällt.

Die eigentliche Entscheidung lautet also:

Soll die Datenbank-Engine zur Laufzeit Klartext sehen dürfen?

Als Entscheidungsregel hat sich für uns ein Konsistenzgedanke bewährt. Eine Ableitung erbt das Schutzniveau ihrer Quelle. Der Vektor ist eine verlustbehaftete Ableitung der Akte. Er kann nicht schützenswerter sein als diese, und er darf nicht schwächer geschützt sein. Wo die Akte at Rest verschlüsselt ist, wäre Feldverschlüsselung allein für den Vektor inkonsistenter Aufwand. Wo sie feldverschlüsselt ist, muss der Vektor mitziehen, sonst wird die Verschlüsselung der Akte weitgehend symbolisch.

Für Behandlungsdokumentation fällt diese Abwägung wegen § 203 StGB zugunsten der Feldverschlüsselung aus.

Was das kostet, und warum weniger als erwartet

Feldverschlüsselung bedeutet, auf pgvector und Verwandte als Suchmaschine zu verzichten. Das klingt nach einem erheblichen Problem. Das Nachrechnen hat mich hier aber überrascht und meine Bedenken deutlich verringert.

100.000 Chunks bei 768 Dimensionen als float32 sind rund 300 MB. Eine exakte Brute-Force-Cosinus-Ähnlichkeit darüber ist ein einziges Matrix-Vektor-Produkt. Mit NumPy und BLAS liegt das bei 15 bis 30 Millisekunden, begrenzt durch die Speicherbandbreite. Exakt statt näherungsweise, was der fachlichen Nachvollziehbarkeit entgegenkommt.

ANN-Indizes rentieren sich ab einigen Millionen Vektoren. Eine einzelne Praxis erreicht diese Größenordnung auch über die gesamte Aufbewahrungsfrist nicht. Der Index, auf den man verzichtet, löst in dieser Domäne ein Problem, das gar nicht auftritt.

Der teure Teil ist die Entschlüsselung. 300 MB durch AES-GCM kosten auch mit AES-NI einige hundert Millisekunden – pro Kern, also nicht pro Abfrage.

Die Lösung ist ein Per-Mandant-Index im Anwendungsspeicher. Beim ersten Zugriff einer Praxis werden deren Vektoren geladen, mit dem mandantenspezifischen Schlüssel – oder wie bei uns sogar mit einem patientenspezifischen Schlüssel – entschlüsselt und als reines float32-Array im Prozessspeicher gehalten, mit TTL und Eviction. Jede weitere Suche kostet nur noch das Matrixprodukt. Der Schlüssel bleibt im Key-Management und nie in der Datenbank.

Drei Eigenschaften ergeben sich daraus, von denen zwei über die ursprüngliche Anforderung hinausgehen:

Die Mandantentrennung wird strukturell statt filterbasiert. Ein fremder Mandant ist nicht ausgefiltert, sondern nicht entschlüsselbar. Das entspricht dem, was die DSK unter Mandantentrennung versteht, und es ist deutlich besser auditierbar als eine Bedingung in einer Query. In unserem Fall werden patientenspezifische Schlüssel benutzt und diese mandantenspezifisch gesichert abgelegt – also noch eine weitere Stufe.

Crypto-Shredding wird möglich. Schlüssel vernichten, Daten sind unwiederbringlich weg, Backups eingeschlossen. Darauf basiert unser Löschkonzept.

Similarity Probing scheitert bereits an der Vorstufe, weil ohne Schlüssel keine Abstände berechenbar sind.

Ergänzend gehört zum Retrieval-Subsystem:

• Zugriffsrechte müssen die Suche einschränken, bevor Ähnlichkeitswerte berechnet werden – sonst lässt sich aus den Scores ablesen, dass ein Dokument existiert, auch wenn es nicht zurückgegeben wird.
• Keine Rohvektoren in APIs, Logs, Traces oder Exporten. Nur IDs und Scores.
• Embedding-Modell on-premise und auf deutschsprachigen Texten trainiert. Die DSK weist ausdrücklich darauf hin, dass die Sprachpassung die Chunk-Zuordnung beeinflusst. Nebeneffekt: Kein Klartext-Chunk verlässt die Infrastruktur.
• Rate Limiting und Auditlog auf dem Retriever. Serien knapp variierter Abfragen sind ein Signal.
• Ein Systemprompt, der das Modell auf die referenzierten Quellen festlegt, als Gegenmaßnahme dagegen, dass ein Sprachmodell bei Widersprüchen sein Trainingswissen gegen die Referenzdokumente durchsetzt.
• Quellennachweis in der Ausgabe. Für Dokumentations- und Gutachtenfunktionen ohnehin fachlich geboten, und laut DSK das, was an Transparenz in einem RAG-System erreichbar ist.

Weitere geprüfte, aber verworfene Optionen

Rauschen auf den Vektoren. Reduziert die Inversionstreue, kostet aber erhebliche Retrieval-Qualität, sobald das Privacy-Budget streng genug ist, um zu wirken. Gegen Zero2Text wirkt es ohnehin nicht. Gezieltere Forschungsansätze wie SPARSE oder TextCrafter existieren, sind aber kein Produktionsbaustein.

Homomorph verschlüsselte Vektorsuche. Funktioniert, aber die Latenzen sind für ein interaktives Fachverfahren wahrscheinlich nicht tragbar.

Geheime Rotationsmatrix pro Mandant. Eine orthogonale Transformation erhält die Cosinus-Ähnlichkeit und erschwert Standard-Inversionswerkzeuge ohne Kenntnis der Matrix erheblich. Als zusätzliche Härtungsschicht brauchbar, aber ausdrücklich keine kryptographische Maßnahme. In einer Datenschutz-Folgenabschätzung sollte man sie nicht als solche darstellen.

Confidential Computing. Ausführung in einer hardwaregestützten Enklave, die Datenbank sieht Klartext, Hypervisor und Betreiber nicht. Der realistische Weg, falls die Datenmengen die Brute-Force-Variante irgendwann übersteigen. Derzeit steht der Betriebsaufwand nicht im Verhältnis zum Zusatznutzen.

Fazit

Die Antwort auf die Ausgangsfrage ist kurz: Ja, das Embedding ist schützenswert, und zwar auf demselben Niveau wie das Dokument, aus dem es entstanden ist.

Der Weg dorthin war länger als erwartet, und das lag nicht an der Komplexität der Sache. Es lag daran, dass die Anleitungen für semantische Suche, die ich gefunden habe, die Frage schlicht nicht stellen. Wer den Tutorials folgt, bekommt eine funktionierende Suche und eine Klartextkopie seiner Daten an einer Stelle, an die vielen nicht bewusst ist.