Anonymisierung vor dem LLM, on-premise: PII-Erkennung, Pseudonymisierung und GPU-Bedarf

Wo die Anonymisierung in einer Private-AI-Plattform sitzt

Anonymisierung von Dokumenten on-premise bedeutet, Namen, Adressen, Kontonummern und andere personenbezogene Daten in Dokumenten und Prompts auf dem eigenen Server zu finden und zu ersetzen, bevor der Text indexiert oder an ein Sprachmodell geschickt wird. Drei Methoden finden die Daten: Muster für Daten mit festem Format, kleine PII-Erkennungsmodelle für Namen und Orte im Fließtext und ein LLM für die Fälle, die die ersten beiden übersehen. Die Erkennungsmodelle sind so klein, dass eine NVIDIA L4 sie trägt; die GPU-Frage wird erst größer, wenn ein LLM ganze Dokumente umschreibt.

Für das Schwärzen gibt es zwei naheliegende Stellen. Bei der Aufnahme für die Suche läuft es, bevor Dokumente zerlegt, eingebettet und gespeichert werden, sodass der Vektorindex nie Namen enthält; unser Leitfaden zu RAG auf Unternehmensdaten behandelt den Rest dieser Pipeline. Am LLM-Gateway läuft es auf jedem Prompt vor dem Modellaufruf und bei Bedarf auf jeder Antwort danach. LiteLLM bietet dafür zum Beispiel die Modi pre_call und post_call, wie unser Leitfaden zum LLM-Gateway mit Schlüsseln, Budgets und Abfrageprotokoll beschreibt. Am wichtigsten ist das Schwärzen auf Routen zu externen APIs; auf einer privaten Route kann es einen Namen entfernen, den eine Vertragsprüfung braucht, deshalb wird die Regel je Route festgelegt.

Die Ersetzung entscheidet, was später möglich ist. Maskieren schreibt eine Typbezeichnung wie <PERSON> und behält nichts. Pseudonymisieren schreibt einen gleichbleibenden Platzhalter, <PERSON_1> für jede Nennung derselben Person, und führt eine Zuordnungstabelle, sodass eine Antwort für berechtigte Nutzer wieder in Namen zurückübersetzt werden kann. Nur die zweite Variante hält eine Zusammenfassung lesbar, wenn mehrere Personen in einem Dokument vorkommen.

Drei Wege, personenbezogene Daten zu finden

Unsere Zusammenfassung. Fehlerbilder der Encoder-Modelle aus der Karte von OpenAIs Privacy Filter („missing uncommon names“, Überschwärzung, zerstückelte Treffer, neue Formate von Geheimnissen), gelesen am 24. Oktober 2026.

Muster sind exakt und billig und versagen still bei allem ohne Format. Encoder-Modelle klassifizieren jedes Token eines Textes in einem Durchgang und liefern Treffer mit Typ und Score; sie sind schnell, brauchen keinen Prompt, und ihr Ergebnis lässt sich Treffer für Treffer prüfen. Ein LLM liest den Kontext: Es erkennt, dass „die Inhaberin der einzigen Bäckerei im Ort“ eine Person identifiziert, was kein Muster und kaum ein Klassifikator leistet. Es ist aber auch die langsamste Option und am schwersten zu prüfen, weil ein Name, den das Modell stehen lässt, in seiner Ausgabe keine Spur hinterlässt.

Eine praktikable Reihenfolge ist: erst Muster, dann ein Encoder-Modell, dann ein LLM-Durchgang nur für Dokumente, bei denen die Scores des Encoders unsicher sind oder indirekte Identifizierung zählt, etwa bei Gerichtsentscheidungen. Unser Leitfaden zum KI-Server für Gerichte zeigt diesen Fall, in dem Mitarbeitende jede anonymisierte Entscheidung weiterhin prüfen.

Offene PII-Erkennungsmodelle im Oktober 2026

Hugging-Face-Karten und Dateilisten von openai/privacy-filter, OpenMed/privacy-filter-multilingual-v2, fastino/gliner2-privacy-filter-PII-multi, nvidia/gliner-PII und iiiorg/piiranha-v1-detect-personal-information, gelesen am 24. Oktober 2026. Größen laut Karte; Dateigrößen von den Seiten „Files“.

OpenAIs Privacy Filter ist ein bidirektionaler Token-Klassifikator mit acht Transformer-Blöcken und einer dünn besetzten Mixture of Experts, 128 Experten, davon vier je Token aktiv, und einem Kontext von 128.000 Token. Seine acht Kategorien sind Kontonummern, private Adressen, E-Mail-Adressen, Personen, Telefonnummern, URLs, Datumsangaben und Geheimnisse. Die Karte nennt das Modell „a redaction and data minimization aid“ und hält fest, dass es kein Werkzeug für Anonymisierung oder Compliance ist; sie beschreibt seine Fehlerbilder und verlangt für Medizin, Recht, Finanzen, Personalwesen, Bildung und Verwaltung eine Evaluierung im eigenen Bereich und menschliche Prüfung. Außerdem warnt sie, dass die Leistung bei nicht englischem Text sinken kann. OpenMeds Fine-Tune erweitert es auf 54 Kategorien in 16 Sprachen, darunter Deutsch, Französisch, Italienisch, Spanisch, Portugiesisch und Niederländisch, und nennt Deutsch unter seinen stärksten Sprachen, ohne einen deutschen Wert zu veröffentlichen.

Fastinos Modell, abgeleitet von GLiNER2 mit einer Basis von 205M Parametern, deckt Englisch, Französisch, Spanisch, Deutsch, Italienisch, Portugiesisch und Niederländisch ab, mit 42 Entitätstypen von der Identität über Steuernummern und Bankdaten bis zu Zugangsdaten. NVIDIAs gliner-PII, veröffentlicht am 28. Oktober 2025, arbeitet nur auf Englisch. Piiranha deckt sechs Sprachen einschließlich Deutsch ab und liest höchstens 256 Token auf einmal, seine Lizenz CC BY-NC-ND 4.0 schließt aber kommerzielle Nutzung aus; für die Pipeline eines Unternehmens kommt es deshalb nicht in Frage.

Keine der fünf Karten nennt Durchsatz, Latenz oder GPU-Speicherbedarf. NVIDIAs Karte nennt eine A100 als Testhardware und führt Ampere-, Blackwell-, Hopper- und ältere GPUs sowie x86-CPUs auf; OpenAIs Karte schreibt, das Modell laufe „in a web browser or on a laptop“.

Was die veröffentlichten Werte aussagen

Modellkarten melden ihre besten Werte auf Daten, die ihrem Training nahe sind. NVIDIAs gliner-PII erreicht einen strikten F1-Wert von 0,87 auf NVIDIAs eigenem Datensatz Nemotron-PII, 0,70 auf Argilla PII und 0,64 auf AI4Privacy. Fastinos Paper vom Mai 2026 hat fünf Modelle auf seinem SPY-Benchmark verglichen, exakte Treffer in juristischen und medizinischen Dokumenten.

Fastino Labs, „GLiNER2-PII: A Multilingual Model for Personally Identifiable Information Extraction“, arXiv 2605.09973, Tabelle 2, gelesen am 24. Oktober 2026. Benchmark und siegreiches Modell stammen von denselben Autoren; das Paper nennt weder Werte je Sprache noch einen Durchsatz.

Für die Planung zählen zwei Punkte. Exakte Trefferwertung ist streng, die absoluten Werte wirken deshalb niedrig, und die Rangfolge ist die der Autoren. Aufschlussreicher ist das Muster: Auf dem juristischen Teil erreichte OpenAIs Privacy Filter einen Recall von 0,640 bei einer Precision von 0,250, entfernt also viele personenbezogene Daten und viel anderen Text mit; Fastinos Modell kam auf einen Recall von 0,722 bei 0,354. Beim Schwärzen schützt der Recall die Personen, die Precision hält den Text brauchbar. Welches Verhältnis Sie brauchen, hängt von der Route ab: vor einer externen API der Recall, innerhalb einer privaten Plattform beides.

Wir liefern L4-Karten für Server, die Sie bereits betreiben, und bauen GPU-Server für Private-AI-Plattformen; schicken Sie uns Ihre Dokumentarten, Sprachen und die tägliche Menge, und unser Team antwortet mit einer Modellauswahl für den Test und der passenden Karte.

Pseudonymisierung oder Anonymisierung nach der DSGVO

Die DSGVO verwendet die beiden Begriffe für unterschiedliche Ergebnisse. Artikel 4 Nummer 5 definiert Pseudonymisierung als die Verarbeitung personenbezogener Daten in einer Weise, dass sie „ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können“, sofern diese zusätzlichen Informationen „gesondert aufbewahrt werden“ und technischen und organisatorischen Maßnahmen unterliegen. Nach Erwägungs­grund 26 sollten pseudonymisierte Daten, die sich durch solche zusätzlichen Informationen einer Person zuordnen lassen, „als Informationen über eine identifizierbare natürliche Person betrachtet werden“, und „die Grundsätze des Datenschutzes sollten daher nicht für anonyme Informationen gelten“, bei denen die Person nicht oder nicht mehr identifiziert werden kann. Ob jemand identifizierbar ist, richtet sich nach allen Mitteln, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, unter Berücksichtigung von Kosten, Zeitaufwand und verfügbarer Technologie.

Für eine Schwärzungspipeline heißt das: Platzhalter mit Zuordnungstabelle erzeugen pseudonymisierte Daten, und der Index oder das Prompt-Protokoll, das daraus entsteht, bleibt personenbezogen. Erwägungs­grund 28 ergänzt, die Pseudonymisierung „kann die Risiken für die betroffenen Personen senken“, und die Artikel 25 Absatz 1 und 32 Absatz 1 Buchstabe a nennen sie als Maßnahme für Datenschutz durch Technikgestaltung und für die Sicherheit der Verarbeitung. Wer jede Kennung entfernt und die Zuordnung löscht, bewegt sich in Richtung Anonymisierung, doch indirekte Merkmale wie ein Beruf, ein Ort oder ein seltenes Ereignis können weiter auf eine Person zeigen; deshalb bleibt im Beispiel der Gerichte ein Mensch in der Prüfung. Der Europäische Datenschutzausschuss führt seine Guidelines 01/2025 on Pseudonymisation mit Datum 17. Januar 2025 auf seiner Seite der Leitlinien.

Speichern Sie die Zuordnungstabelle auf einem anderen System oder unter einem anderen Schlüssel als den geschwärzten Text, mit Zugriff nur für den Dienst, der Namen für berechtigte Nutzer wiederherstellt. Was als ausreichend gilt, entscheidet Ihr Datenschutz­beauftragter; unser Leitfaden zur DSFA für ein internes LLM zeigt, wo das Schwärzen in der Folgenabschätzung auftaucht. Das ist eine allgemeine Information mit Stand Oktober 2026 auf Grundlage des DSGVO-Textes auf EUR-Lex, keine Rechtsberatung.

Deutsche Namen, Adressen und Kennungen

Deutscher Text ist schwieriger als die englischen Beispiele der meisten Modellkarten. Viele Nachnamen sind gewöhnliche Wörter wie Bauer, Koch, Wolf oder Klein, und ein Klassifikator muss „Herr Koch“ von „der Koch“ unterscheiden. Adressen verbinden Straße, Hausnummer, Postleitzahl und Ort in einer Zeile, und Geburtsdaten erscheinen als „geb. 03.04.1961“. Steuer-IDs, Sozialversicherungsnummern, IBANs und Kfz-Kennzeichen haben feste Formate; Muster fangen sie ab, bevor das Modell den Text sieht.

Von den Modellen oben nennen Fastinos GLiNER2 PII und OpenMeds mehrsprachiger Fine-Tune Deutsch unter ihren Trainingssprachen, das Basismodell von OpenAI und NVIDIAs gliner-PII nicht. Keine Karte veröffentlicht einen deutschen Wert. Ein deutscher Testsatz aus einigen hundert eigenen, von Hand annotierten Dokumenten ist deshalb der erste Schritt für eine EU-Plattform, und dasselbe gilt für polnische, tschechische oder ungarische Texte.

GPU-Bedarf: L4, RTX PRO 4500 Server Edition oder eine MIG-Instanz

Encoder-PII-Modelle sind klein im Vergleich zu den Karten, die wir liefern. Nach unserer Regel für Nutzer je Karte, 90 Prozent des vom Treiber gemeldeten Speichers abzüglich 3 GiB, hält eine L4 mit eingeschaltetem ECC 17,2 GiB und eine RTX PRO 4500 Server Edition 25,7 GiB, wie unsere Leitfäden zum 8× L4-Server und zum Server mit 8× RTX PRO 4500 Server Edition herleiten.

Unsere Schätzung nach der Regel für Nutzer je Karte. Dateigrößen von den Hugging-Face-Seiten „Files“, gelesen am 24. Oktober 2026; gpt-oss-20b 13,76 GB (12,82 GiB) mit 24 KiB 16-Bit-Cache je Token, 0,1875 GiB je Dokument mit 8.192 Token, wie in unseren Modellleitfäden.

Für gpt-oss-20b auf einer L4 bleiben 17,2 − 12,82 = 4,38 GiB für den Cache, genug für 23 Dokumente mit 8.192 Token gleichzeitig; auf der RTX PRO 4500 Server Edition bleiben 12,88 GiB, 68 Dokumente. Die L4 ist eine passive, flache, einslotige Karte mit 72 W an PCIe 4.0, ohne MIG, und passt damit in fast jeden Server mit freiem Steckplatz. Die RTX PRO 4500 Server Edition mit 165 W teilt sich in zwei MIG-Hälften zu 16 GB, eine für den Encoder und eine für Embedding oder ein Guard-Modell, wie unser Leitfaden zu Guardrail-Modellen und GPU-Bedarf darlegt. In einer größeren Plattform erledigt eine MIG-Instanz mit 24 GB auf einer RTX PRO 6000 Server Edition dieselbe Aufgabe.

Keine Encoder-Karte nennt einen Durchsatz; messen Sie deshalb Dokumente pro Sekunde mit Ihren eigenen Texten, bevor Sie für Volumen planen. Für den LLM-Weg gibt es veröffentlichte Raten. In MLPerf® Inference v6.1, Closed Division, Rechenzentrum, Eintrag 6.1-0050, erzeugte ein HPE ProLiant Compute DL380a Gen12 mit acht RTX PRO 6000 Blackwell Server Edition im Offline-Szenario 15.256 Token pro Sekunde auf gpt-oss-120b und 50.965,3 auf Llama 3.1 8B, abgerufen von mlcommons.org am 24. Oktober 2026, results verified by MLCommons Association. Durch acht geteilt sind das etwa 1.907 und 6.371 Token pro Sekunde je Karte, unsere Division des Systemergebnisses und keine MLPerf-Kennzahl. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Nehmen Sie 10.000 Dokumente pro Tag als Beispiel. Listet das LLM nur die gefundenen personenbezogenen Daten auf, etwa 300 Ausgabetoken je Dokument, braucht der Tag 3 Millionen Ausgabetoken: nach unserer Schätzung bei der halben veröffentlichten Rate je Karte etwa 16 Minuten auf einer RTX PRO 6000 Server Edition mit einem Modell der 8B-Klasse und etwa 52 Minuten mit gpt-oss-120b, gezählt nur die Ausgabetoken. Schreibt es jedes Dokument mit 2.000 Token um, braucht gpt-oss-120b etwa 5,8 Stunden. Die Benchmark-Eingaben sind nicht Ihre Dokumente, und MLPerf v6.1 enthält keinen L4-Eintrag; die Rate eines LLM-Schwärzers auf der L4 ist deshalb ein Wert, den Sie messen.

Test mit einer annotierten Stichprobe

Wählen Sie 200 bis 500 Dokumente, die den echten Eingang abbilden, einschließlich Scans nach OCR, E-Mails mit Signaturen und Tabellen. Zwei Personen annotieren jedes personenbezogene Datum mit seinem Typ; wo sie sich uneinig sind, entscheidet eine dritte. Dann lassen Sie jede Kandidaten-Pipeline laufen und zählen je Entitätstyp, wie viele annotierte Einträge sie gefunden hat (Recall) und wie viele ihrer Treffer personenbezogen waren (Precision). Listen Sie die übersehenen Einträge vollständig auf, denn ein übersehenes Gesundheitsdetail wiegt schwerer als zehn zu viel geschwärzte Datumsangaben.

Stimmen Sie die Schwellenwerte auf diesen Satz ab. NVIDIAs Karte wertet gliner-PII bei einer Schwelle von 0,3 aus und nutzt im Beispiel 0,5, und OpenAIs Privacy Filter bietet voreingestellte Arbeitspunkte zwischen Precision und Recall. Wiederholen Sie den Test nach jedem Wechsel von Modell oder Schwelle, und halten Sie den annotierten Satz aus jedem Fine-Tuning heraus. Unser Engineering-Partner Vixen.UNO baut Schwärzungsschritte im Rahmen unseres Private-AI/ML-Service in RAG-Aufnahme und LLM-Gateways ein; nennen Sie uns, wo die Daten in Ihre Plattform kommen und welche Routen sie verlassen, und wir richten den Test ein und dimensionieren die Hardware nach seinen Ergebnissen.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration auf Ihre Arbeitslast und Ihr Budget aus und antwortet innerhalb eines Werktages. Wir liefern die NVIDIA L4, die RTX PRO 4500 Server Edition und die RTX PRO 6000 Server Edition als GPUs für Server, die Sie bereits betreiben, oder in KI-Servern auf Bestellung, vor der Lieferung montiert und getestet, über einen EU-Vertrag und eine Rechnung mit Herstellergarantie auf jede Komponente. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch; Schwärzungspipeline, Gateway und Modelle sind Teil unseres Service Private AI/ML.

FAQ