Anonymisierung-API: Was Ihre Integration wirklich leisten soll

Beginnen Sie mit Ihrem Anwendungsfall: Soll eine Antwort wieder Namen enthalten? Benötigt die Analyse stabile Personenbezüge? Müssen Sie eine Datei öffentlich teilen? Diese Fragen entscheiden, ob reversible Platzhalter oder ein Verfahren ohne Zuordnung geeignet sind. Echte Anonymität hängt auch von verbliebenem Kontext und verfügbaren Zusatzinformationen ab.

Bei einer Pseudonymisierungs-API benötigen Sie neben dem ersetzten Text nachvollziehbare Fundstellen und ein klares Mapping. Prüfen Sie Authentifizierung, Eingabelimits, Fehlerantworten und die Verarbeitung Ihrer Texte. Testen Sie die Erkennung an Ihren Formaten, statt nur anhand der Anzahl unterstützter Kategorien zu entscheiden.

POST /v1/pseudonymize erwartet ein JSON-Objekt mit text und einen Bearer-API-Key. Die Antwort enthält den pseudonymisierten Text in masked, die Fundstellen in spans, die Zuordnung in mapping und einen sensitivity-Wert. Der folgende Request ist ein ausführbares Muster mit einem fiktiven Text; hinterlegen Sie Ihren API-Key nur in einer geschützten Umgebung.

curl https://persona-api.mind-verse.de/v1/pseudonymize \
  -H "Authorization: Bearer $PERSONA_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"text":"Frau Anna Vogel ist unter anna@example.org erreichbar."}'

Das Mapping enthält Originalwerte. Behandeln Sie es mindestens so sorgfältig wie den Eingangstext. Geben Sie an das LLM nur masked weiter, beschränken Sie den Zugriff auf die Zuordnung und legen Sie eine passende Löschfrist fest. Für die Wiederherstellung erwartet /v1/reidentify text und mapping.

Tokens werden innerhalb eines Pseudonymisierungsaufrufs konsistent vergeben. Verlassen Sie sich nicht darauf, dass ⟨PERSON_1⟩ in verschiedenen Requests dieselbe Person bezeichnet. Für eine Unterhaltung mit mehreren Aufrufen brauchen Sie eine eigene sichere Zuordnungsstrategie. Vermischen Sie niemals Mappings unterschiedlicher Nutzer oder Vorgänge.

Definieren Sie vor dem produktiven Einsatz, was bei Timeout, ungültigem API-Key oder erreichtem Kontingent geschieht. Ein automatischer Fallback, der den Originaltext an das LLM sendet, würde den Schutz ausgerechnet im Fehlerfall umgehen. Besser sind eine verständliche Fehlermeldung, ein begrenzter Wiederholungsversuch oder eine manuelle Prüfung.

Protokollieren Sie Status, Dauer und eine technische Vorgangskennung statt vollständiger Textinhalte. Prüfen Sie außerdem, ob nachgelagerte Systeme den bearbeiteten Text unverändert weitergeben oder Originalfelder wieder ergänzen. Die API ist ein Verarbeitungsschritt; Zugriffsschutz, Rechtsgrundlage und eine angemessene Gesamtarchitektur gehören weiterhin zu Ihrer Anwendung.

1. API-Key serverseitig hinterlegen.
2. Antwortstatus und Antwortstruktur prüfen.
3. Nur masked in den Modellkontext übernehmen.
4. Mapping mit Vorgang und Berechtigung verknüpfen.
5. Fehlerpfad und Re-Identifikation mit fiktiven Daten testen.

Die technische Beschreibung bezieht sich auf die Persona-Werkzeuge und ihre dokumentierten Grenzen. Prüfen Sie Erkennung und Export vor der Verwendung mit Ihren eigenen Dokumenttypen.

• DSGVO im amtlichen Volltext: Begriffe, Datenminimierung und Sicherheitsmaßnahmen, insbesondere Art. 4, 5, 25 und 32.
• Persona-API-Dokumentation: Endpunkte, Authentifizierung und Antwortfelder.
• Pseudonymisierung und Anonymisierung unterscheiden: Einordnung von Platzhaltern und Zuordnung.