Leitfaden zu APIs zur PII-Schwärzung (2026): AWS, Google Cloud, Azure und Presidio für LLM-Apps im Vergleich
Eine API zur PII-Schwärzung nimmt Text entgegen, erkennt darin personenbezogene Daten wie Namen, E-Mail-Adressen, Telefonnummern, Kartennummern und amtliche Identifikationsnummern und gibt entweder deren Positionen oder eine Textkopie zurück, in der diese Daten maskiert, ersetzt oder tokenisiert sind. Für KI-Produktteams geht es vor allem darum, personenbezogene Daten zu entfernen oder zu pseudonymisieren, bevor Prompts, Dokumente und Logs ein LLM eines Drittanbieters erreichen. Die vier Optionen, die die meisten Teams evaluieren, sind Amazon Comprehend DetectPiiEntities, Google Cloud Sensitive Data Protection (ehemals Cloud DLP), Azure Language PII detection und die Open-Source-Lösung Microsoft Presidio.
Dieser Leitfaden vergleicht Endpunkte, Authentifizierung, unterstützte Sprachen, Abrechnungseinheiten und Ausgabeformate und enthält ausführbare Beispiele mit synthetischen Daten. Außerdem zeigt er tatsächliche Erkennungsergebnisse aus einem lokalen Presidio-Test, einschließlich übersehener Daten und falsch positiver Treffer, mit denen Sie rechnen sollten. Alle Anbieterangaben wurden am 27. Oktober 2026 anhand der offiziellen Dokumentation geprüft.
Flatkey bietet keine integrierte API zur PII-Schwärzung. Die folgenden Ansätze werden in Ihrem eigenen Dienst ausgeführt, bevor eine Anfrage an ein Modell-Gateway wie Flatkey gesendet wird. Die Richtlinien zu diesem Thema behandelt unser Leitfaden zu Schwärzungsrichtlinien für KI-APIs.
Schwärzung, Maskierung, Entitätserkennung und Tokenisierung: Was ist der Unterschied?
| Verfahren | Rückgabe | Umkehrbar? | Typischer Einsatz |
|---|---|---|---|
| Entitätserkennung | Entitätstyp, Konfidenzwert und Zeichenpositionen | Entfällt (Text bleibt unverändert) | Pro Entität über die Verarbeitung entscheiden; Datenflüsse prüfen |
| Schwärzung | Text, in dem PII entfernt oder durch eine Kennzeichnung wie [PERSON_1] ersetzt wurde |
Nein | Prompts für externe LLMs, Logs, Analysen |
| Maskierung | Text mit verdeckten Zeichen, etwa ***********1111 |
Nein | Support-Oberflächen, die einen Teil der Werte anzeigen müssen |
| Tokenisierung / Pseudonymisierung | Text, in dem PII durch ein konsistentes Token oder einen verschlüsselten Wert ersetzt wurde | Ja, mit dem Schlüssel oder der Zuordnungstabelle | LLM-Workflows, die echte Werte wieder in die Antwort einsetzen müssen |
| Schwärzung auf Feldebene | Bekannte Felder (etwa email in JSON), die anhand des Schemas entfernt oder ersetzt werden |
Kommt darauf an | Strukturierte Nutzdaten, bei denen bekannt ist, welche Felder PII enthalten |
Bei strukturierten Daten sind Regeln auf Feldebene schneller und zuverlässiger als jedes Modell. Verwenden Sie APIs zur PII-Erkennung für Freitext: Chatnachrichten, Supporttickets, Transkripte und Dokumente.
APIs zur PII-Schwärzung im Vergleich (Oktober 2026)
| Amazon Comprehend | Google Sensitive Data Protection | Azure Language PII | Microsoft Presidio | |
|---|---|---|---|---|
| Typ | Verwaltete API | Verwaltete API | Verwaltete API (auch als Container) | Open Source, selbst gehostet |
| Zentraler Aufruf | DetectPiiEntities |
projects.content.deidentify |
analyze-text mit PiiEntityRecognition |
AnalyzerEngine + AnonymizerEngine |
| Gibt geschwärzten Text direkt zurück | Nein, gibt Zeichenpositionen zurück (zur Schwärzung verwenden) | Ja | Ja (redactedText) |
Ja |
| Umkehrbare Tokenisierung | Nein | Ja (kryptografische Transformationen) | Nein | Ja (Operatoren encrypt / decrypt) |
| Sprachunterstützung für PII | Englisch und Spanisch | Viele infoTypes, teils länderspezifisch | Mehrere Sprachen laut Dokumentation | Abhängig vom geladenen NLP-Modell |
| Eingabelimit / Abrechnungseinheit | 100 KB pro Anfrage; Abrechnung pro 100 Zeichen, mindestens 3 Einheiten | Abrechnung pro GiB; mindestens 1 KB pro Anfrage | Abrechnung pro Textdatensatz | Eigene Rechenressourcen |
| Kostenloses Kontingent | 50K Einheiten (5M Zeichen) pro API und Monat für 12 Monate | Das erste 1 GiB pro Monat für die Prüfung | 5,000 Textdatensätze pro Monat (kostenloser Tarif) | Kostenlose Software |
| Daten verlassen Ihr Netzwerk | Ja (AWS) | Ja (Google Cloud) | Ja, sofern Sie keinen Container betreiben | Nein |
Quellen: Amazon Comprehend PII-Dokumentation, Comprehend-Preise, Google-Dokumentation zur Deidentifizierung, Sensitive Data Protection-Preise, Azure PII-Übersicht, Azure Language-Preise und Presidio-Dokumentation, alle geprüft am 27. Oktober 2026.
Was kostet das?
- Amazon Comprehend: Das AWS-Beispiel für Detect PII: 10,000 Kundenkommentare mit jeweils 550 Zeichen zählen als 6 Einheiten pro Anfrage. Damit kosten 60,000 Einheiten zu $0.0001 pro Einheit insgesamt $6 (Comprehend-Preise, Beispiel 7). Kurze Anfragen werden mit mindestens 3 Einheiten (300 Zeichen) abgerechnet. Kleine Nachrichten zu bündeln spart daher Geld.
- Google Sensitive Data Protection: Die Inhaltsprüfung ist für das erste 1 GiB pro Monat kostenlos. Danach kostet sie $3.00 pro GiB, bei höherem Volumen sinkt der Preis auf $2.00 pro GiB; für die Transformation sind $2.00 pro GiB und anschließend $1.00 angegeben. Pro Anfrage wird mindestens 1 KB abgerechnet.
- Azure Language: Die PII-Erkennung wird pro Textdatensatz abgerechnet. Der kostenlose Tarif umfasst 5,000 kostenlose Textdatensätze pro Monat. Die kostenpflichtigen Tarife finden Sie auf der Azure-Preisseite für Ihre Region.
- Presidio: Keine Lizenzgebühr; Sie bezahlen die Rechenressourcen für den Analyzer und das NLP-Modell.
Amazon Comprehend: DetectPiiEntities
Comprehend erkennt PII in englischen oder spanischen Texten. DetectPiiEntities gibt für jede Entität Type, Score, BeginOffset und EndOffset zurück; die maximale Eingabe beträgt 100 KB UTF-8-Text (API-Referenz). Geschwärzten Text gibt die API nicht zurück, daher ersetzen Sie die entsprechenden Textbereiche selbst.
import boto3
comprehend = boto3.client("comprehend", region_name="us-east-1")
text = "Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187."
resp = comprehend.detect_pii_entities(Text=text, LanguageCode="en")
# Replace from the end so earlier offsets stay valid
redacted = text
for e in sorted(resp["Entities"], key=lambda e: e["BeginOffset"], reverse=True):
if e["Score"] >= 0.5:
redacted = redacted[:e["BeginOffset"]] + f"[{e['Type']}]" + redacted[e["EndOffset"]:]
print(redacted)
Die Authentifizierung erfolgt über die üblichen AWS-Anmeldedaten (IAM-Rolle, SSO oder Zugriffsschlüssel) mit der Berechtigung comprehend:DetectPiiEntities.
Google Cloud Sensitive Data Protection: content.deidentify
Die Google-API prüft und transformiert Inhalte in einem einzigen Aufruf. Sie wählen infoTypes (etwa EMAIL_ADDRESS und PHONE_NUMBER) sowie eine Transformation: replaceWithInfoTypeConfig, redactConfig, characterMaskConfig oder eine kryptografische Pseudonymisierung (Dokumentation zur Deidentifizierung).
curl -X POST \
"https://dlp.googleapis.com/v2/projects/$PROJECT_ID/content:deidentify" \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
-d '{
"item": {"value": "Email dana.whitfield@example.com or call 212-555-0187."},
"inspectConfig": {
"infoTypes": [{"name": "EMAIL_ADDRESS"}, {"name": "PHONE_NUMBER"}, {"name": "PERSON_NAME"}]
},
"deidentifyConfig": {
"infoTypeTransformations": {
"transformations": [{"primitiveTransformation": {"replaceWithInfoTypeConfig": {}}}]
}
}
}'
Das Feld item.value in der Antwort enthält Text wie Email [EMAIL_ADDRESS] or call [PHONE_NUMBER]. Google empfiehlt, nur die benötigten infoTypes anzugeben, da die Prüfung auf den Standardsatz die Latenz erhöht.
Azure Language: PII-Entitätserkennung
Der Azure-Endpunkt analyze-text gibt sowohl die Entitäten als auch ein Feld redactedText zurück. Der Parameter redactionPolicies steuert die Ausgabe, etwa entityMask für Kennzeichnungen oder characterMask für Sternchen (REST-Referenz).
curl -X POST "$AZURE_LANGUAGE_ENDPOINT/language/:analyze-text?api-version=2026-05-01" \
-H "Ocp-Apim-Subscription-Key: $AZURE_LANGUAGE_KEY" \
-H "Content-Type: application/json" \
-d '{
"kind": "PiiEntityRecognition",
"parameters": {"redactionPolicies": [{"policyKind": "entityMask"}]},
"analysisInput": {"documents": [
{"id": "1", "language": "en", "text": "My name is John Doe My phone number is 424 878 9192"}
]}
}'
Die in der Microsoft-Dokumentation gezeigte Beispielantwort enthält "redactedText": "My name is [PERSON_1] My phone number is [PHONENUMBER_1]" sowie Kategorie, Zeichenposition, Länge und Konfidenzwert jeder Entität. Azure unterstützt außerdem die PII-Erkennung in Unterhaltungen und Dokumenten und bietet Container an, um das Modell in Ihrer eigenen Umgebung auszuführen.
Node.js-Version
const res = await fetch(
`${process.env.AZURE_LANGUAGE_ENDPOINT}/language/:analyze-text?api-version=2026-05-01`,
{
method: "POST",
headers: {
"Ocp-Apim-Subscription-Key": process.env.AZURE_LANGUAGE_KEY,
"Content-Type": "application/json",
},
body: JSON.stringify({
kind: "PiiEntityRecognition",
parameters: { redactionPolicies: [{ policyKind: "entityMask" }] },
analysisInput: {
documents: [{ id: "1", language: "en", text: "Call Dana at 212-555-0187." }],
},
}),
}
);
const data = await res.json();
console.log(data.results.documents[0].redactedText);
Microsoft Presidio: PII-Schwärzung mit Open Source
Presidio läuft vollständig in Ihrer eigenen Infrastruktur. Der Analyzer kombiniert NLP-basierte Eigennamenerkennung, reguläre Ausdrücke, Prüfsummen und Kontextwörter; der Anonymizer wendet Operatoren wie replace, mask, redact, hash und encrypt an. Die Dokumentation weist ausdrücklich darauf hin, dass eine automatisierte Erkennung nicht garantieren kann, alle sensiblen Daten zu finden. Planen Sie daher zusätzliche Schutzmaßnahmen ein.
Wir haben Presidio (Analyzer 2.2.365 mit dem spaCy-Modell en_core_web_lg) installiert und auf diesen synthetischen Satz angewendet:
Hallo, ich bin Dana Whitfield. Schreiben Sie an dana.whitfield@example.com oder rufen Sie 212-555-0187 an. Karte 4111 1111 1111 1111, SSN 078-05-1120. Bestellung #A-77231 wird an 42 Elm Street versandt.
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine
from presidio_anonymizer.entities import OperatorConfig
text = ("Hi, I'm Dana Whitfield. Email dana.whitfield@example.com or call 212-555-0187. "
"Card 4111 1111 1111 1111, SSN 078-05-1120. Order #A-77231 ships to 42 Elm Street.")
results = AnalyzerEngine().analyze(text=text, language="en")
for r in sorted(results, key=lambda r: r.start):
print(r.entity_type, repr(text[r.start:r.end]), round(r.score, 2))
out = AnonymizerEngine().anonymize(
text=text,
analyzer_results=results,
operators={
"DEFAULT": OperatorConfig("replace", {"new_value": "<REDACTED>"}),
"PERSON": OperatorConfig("replace", {"new_value": "<PERSON>"}),
"EMAIL_ADDRESS": OperatorConfig("replace", {"new_value": "<EMAIL>"}),
"CREDIT_CARD": OperatorConfig("mask", {"masking_char": "*", "chars_to_mask": 15, "from_end": False}),
},
)
print(out.text)
Was erkannt und was übersehen wurde
| Text | Erkannt als | Konfidenzwert | Bewertung |
|---|---|---|---|
| Dana Whitfield | PERSON | 0.85 | Korrekt |
| dana.whitfield@example.com | EMAIL_ADDRESS | 1.0 | Korrekt |
| example.com (innerhalb der E-Mail-Adresse) | URL | 0.5 | Falsch positiver Treffer, überschneidet sich mit der E-Mail-Adresse |
| 212-555-0187 | PHONE_NUMBER | 0.4 | Korrekt, aber geringe Konfidenz |
| 4111 1111 1111 1111 | CREDIT_CARD | 1.0 | Korrekt (Prüfsumme validiert) |
| 078-05-1120 | PHONE_NUMBER | 0.4 | Falscher Typ: Dies ist eine bekannte ungültige Beispiel-SSN, weshalb der SSN-Recognizer sie verworfen hat |
| Elm Street | LOCATION | 0.85 | Teilweise korrekt; die Hausnummer "42" blieb im Text stehen |
| A-77231 (Bestell-ID) | Nicht erkannt | Entfällt | Übersehen: Geschäftliche Kennungen benötigen eigene Regeln |
Drei Erkenntnisse aus diesem kleinen Test:
- Schwellenwerte bestimmen das Verhältnis zwischen übersehenen Daten und Fehlalarmen. Beim erneuten Durchlauf mit
score_threshold=0.5fiel die Telefonnummer (Konfidenzwert 0.4) heraus und blieb ungeschwärzt. Stimmen Sie Schwellenwerte pro Entitätstyp ab, statt sie global festzulegen. - Eigene Kennungen brauchen eigene Recognizer. Ein zusätzlicher
PatternRecognizerfür\bA-\d{5}\bmit dem Konfidenzwert 0.6 erkannte die Bestell-ID. Ein realistischer Wert im SSN-Format (536-90-4399) wurde alsUS_SSNmit 0.85 erkannt. - Umkehrbare Tokenisierung funktioniert. Mit dem Operator
encrypt, einem 128-Bit-Schlüssel und derDeanonymizeEnginemitdecryptließ sich der ursprüngliche Text exakt wiederherstellen.
Eine Pipeline zur PII-Schwärzung für LLM-Apps
Das übliche Muster für KI-Produkte lautet: schwärzen, das Modell aufrufen und anschließend die Werte wiederherstellen, die der Nutzer sehen muss:
- Zuerst Feldregeln anwenden. Entfernen oder ersetzen Sie bekannte PII-Felder in strukturierten Nutzdaten anhand des Schemas.
- PII in Freitext erkennen. Wenden Sie eine PII-API oder Presidio auf Nachrichten, Tickets und Dokumente an.
- Konsistent pseudonymisieren. Ersetzen Sie jede Entität durch einen stabilen Platzhalter (
<PERSON_1>) und bewahren Sie die Zuordnung in Ihrem Dienst auf, niemals im Prompt. - Das LLM aufrufen und dabei den geschwärzten Text verwenden.
- Platzhalter in der Modellausgabe auflösen, aber nur dort, wo der Nutzer die echten Werte sehen darf.
- Die geschwärzte Version und die Anzahl der Entitäten protokollieren statt des Originals.
import os, re
from openai import OpenAI
from presidio_analyzer import AnalyzerEngine
analyzer = AnalyzerEngine()
client = OpenAI(api_key=os.environ["FLATKEY_API_KEY"], base_url="https://router.flatkey.ai/v1")
def non_overlapping(results, min_score=0.35):
kept = []
# prefer higher scores, then longer spans; drop anything overlapping a kept span
for r in sorted(results, key=lambda r: (-r.score, -(r.end - r.start))):
if r.score >= min_score and all(r.end <= k.start or r.start >= k.end for k in kept):
kept.append(r)
return sorted(kept, key=lambda r: r.start, reverse=True)
def pseudonymize(text):
mapping, counters = {}, {}
for r in non_overlapping(analyzer.analyze(text=text, language="en")):
counters[r.entity_type] = counters.get(r.entity_type, 0) + 1
token = f"<{r.entity_type}_{counters[r.entity_type]}>"
mapping[token] = text[r.start:r.end]
text = text[:r.start] + token + text[r.end:]
return text, mapping
ticket = "Customer Dana Whitfield (dana.whitfield@example.com) says order A-77231 never arrived."
safe, mapping = pseudonymize(ticket)
reply = client.chat.completions.create(
model="claude-haiku-5-5",
messages=[{"role": "user", "content": f"Draft a short apology email for this ticket:\n{safe}"}],
).choices[0].message.content
for token, value in mapping.items(): # restore only on your side
reply = reply.replace(token, value)
print(reply)
Der Schritt non_overlapping ist wichtig: Ohne ihn führt die innerhalb der E-Mail-Adresse erkannte URL zu einer fehlerhaften Ersetzung. Mit diesem Schritt wurde unser Testticket zu Customer <PERSON_1> (<EMAIL_ADDRESS_1>) says order A-77231 never arrived. Die Bestell-ID wird weiterhin unverändert durchgereicht. Deshalb gehört der eigene Recognizer aus dem vorherigen Abschnitt in den Produktivbetrieb. Der Anonymizer von Presidio löst Überschneidungen selbst auf.
Fehlerbehandlung und Tests
| Risiko | Gegenmaßnahme |
|---|---|
| Zeitüberschreitung der PII-API oder 5xx-Fehler | Bei Fehlern blockieren: Den ungeschwärzten Text nicht an das LLM senden; in eine Warteschlange stellen und erneut versuchen |
| Erkennungen mit geringer Konfidenz | Schwellenwerte pro Entität; Stichproben wöchentlich prüfen |
| Nicht unterstützte Sprache | Zuerst die Sprache erkennen; AWS Comprehend PII unterstützt nur Englisch und Spanisch |
| Geschäftliche Kennungen (Bestell-IDs, Kontonummern) | Eigene Regex-Recognizer oder Feldregeln |
| Falsch positive Treffer verfälschen den Sinn | Positivlisten für Produktnamen und öffentliche Adressen |
| PII in der Modellausgabe | Antworten vor dem Protokollieren oder der Anzeige für andere Nutzer prüfen |
| Logs enthalten Originaldaten | Nur geschwärzten Text und die Anzahl der Entitäten protokollieren |
Erstellen Sie einen annotierten Testdatensatz mit synthetischen Nachrichten, die Ihrem tatsächlichen Datenverkehr ähneln, einschließlich Namen aus vielen Kulturen, internationalen Telefonnummernformaten und eigenen ID-Formaten. Messen Sie die Erkennungsrate pro Entitätstyp vor dem Start und nach jeder Regeländerung.
Eine API zur PII-Schwärzung auswählen
- Sie nutzen bereits AWS und verarbeiten englische oder spanische Texte: Amazon Comprehend ist bei geringem Volumen einfach und günstig.
- Sie benötigen umkehrbare Tokenisierung als verwalteten Dienst oder viele länderspezifische Kennungen: Google Sensitive Data Protection.
- Sie benötigen direkt geschwärzten Text, PII-Erkennung in Unterhaltungen oder Dokumenten oder Container für den Betrieb vor Ort: Azure Language PII.
- Daten dürfen Ihr Netzwerk nicht verlassen oder Sie benötigen volle Kontrolle über die Regeln: Presidio mit eigenen Recognizern und eigener Evaluation.
Viele Teams kombinieren diese Ansätze: Presidio oder Feldregeln im zeitkritischen Verarbeitungspfad und eine verwaltete API für die stapelweise Prüfung von Dokumenten.
So passt Flatkey dazu
Flatkey ist ein Modell-Gateway: ein Schlüssel und ein OpenAI-kompatibler Endpunkt für viele LLMs. Es erkennt und schwärzt PII nicht für Sie. Führen Sie die Schwärzung daher wie in der obigen Pipeline in Ihrer Anwendung aus, bevor Anfragen Ihren Dienst verlassen. Die Flatkey-Enterprise-Dokumentation beschreibt, dass Anfrageinhalte nicht gespeichert werden. Das verringert die Exposition, ersetzt aber keine Schwärzung. Weiterführende Artikel: Schwärzungsrichtlinien für KI-APIs, sichere Verwaltung von API-Schlüsseln, LLM-Kosten nachverfolgen und der Flatkey-Modellkatalog.
FAQ
Was ist eine API zur PII-Schwärzung?
Eine solche API erkennt personenbezogene Daten in Texten, etwa Namen, E-Mail-Adressen, Telefonnummern und Identifikationsnummern. Sie gibt die Positionen dieser Daten oder eine Textversion zurück, in der sie entfernt, maskiert oder ersetzt wurden.
Welche API zur PII-Schwärzung ist die beste?
Das hängt von Ihrem Technologie-Stack und Ihren Daten ab. Amazon Comprehend eignet sich für englische und spanische Texte auf AWS. Google Sensitive Data Protection ist besonders stark bei umkehrbarer Tokenisierung und vielen infoTypes. Azure gibt geschwärzten Text direkt zurück und läuft in Containern. Presidio ist die beste Wahl, wenn Daten in Ihrem Netzwerk bleiben müssen.
Gibt es eine kostenlose API zur PII-Schwärzung?
Presidio ist kostenlose Open-Source-Software. Die verwalteten Dienste bieten kostenlose Kontingente: AWS Comprehend umfasst 50K Einheiten (5M Zeichen) pro API und Monat für 12 Monate, bei Google ist das erste 1 GiB an Prüfungen pro Monat kostenlos und der kostenlose Azure-Tarif enthält 5,000 Textdatensätze pro Monat.
Sollte ich PII schwärzen, bevor ich Prompts an ChatGPT, Claude oder andere LLM-APIs sende?
Ja, wenn das Modell die echten Werte nicht benötigt. Pseudonymisieren Sie Namen, Kontaktdaten und IDs, senden Sie Platzhalter an das Modell und stellen Sie die Werte in Ihrem eigenen Dienst wieder her, wenn der Nutzer sie benötigt.
Lässt sich eine PII-Schwärzung rückgängig machen?
Einfache Schwärzung und Maskierung lassen sich nicht rückgängig machen. Tokenisierung oder verschlüsselungsbasierte Pseudonymisierung lassen sich mit dem Schlüssel oder der Zuordnungstabelle umkehren. Diese sollten Sie sicher und getrennt von den geschwärzten Daten speichern.
Wie genau sind APIs zur PII-Erkennung?
Keine ist perfekt. In unserem Presidio-Test erhielt eine Telefonnummer nur den Konfidenzwert 0.4, und eine Bestell-ID wurde erst nach dem Hinzufügen einer eigenen Regel erkannt. Messen Sie die Erkennungsrate mit Ihren eigenen synthetischen Daten und blockieren Sie die Weitergabe, wenn bei der Erkennung ein Fehler auftritt.
Schwärzt Flatkey PII?
Nein. Flatkey leitet Anfragen an Modelle weiter; die Schwärzung sollte in Ihrer Anwendung erfolgen, bevor die Anfrage gesendet wird.
