1. Autorisierungs- & PII-Minimierungs-Framework (APMF)
Ein strukturiertes Policy- und Entscheidungssystem, das festlegt, auf welche personenbezogenen Daten für eine bestimmte Aufgabe durch einen bestimmten Antragsteller unter spezifischen regulatorischen und ethischen Einschränkungen zugegriffen werden darf.
Dieses Framework erzeugt zwei maschinenlesbare Ausgaben:
- Privacy Allowance Profile (PAP) – definiert, welche PII enthalten sein dürfen (direkt, indirekt, sensibel)
- Data Access Certificate (DAC) – das formale Autorisierungsartefakt, das mit den Daten mitgeführt wird
Zweck des Frameworks
- Durchsetzen von Datenminimierung, Least Privilege und Zweckbindung
- Festlegen, welche PII-Klassen erlaubt sind, abhängig vom Kontext
- Festlegen, welcher Anonymisierungsprozess notwendig oder angemessen ist
- Integration in unternehmensweite Data Access Governance (DAG)-Workflows
- Nachvollziehbarkeit für Datenschutz-Audits, Compliance, ML‑Governance und Reporting
- Unterstützung unstrukturierter Daten und ML‑Workloads (Chats, Logs, Transkripte, Prompts)
Geltungsbereich
- Gilt für jede unstrukturierte Datenmenge oder Anfrage
- Umfasst interne und Drittanbieter‑Processing‑Tools (z. B. Cloud‑LLMs)
- Umfasst menschliche und automatisierte Antragsteller
- Berücksichtigt Regulierung, Ethik, Einwilligung und Organisationspolitik
- Liefert Zertifizierungen, Verpflichtungen und PII‑Transformationen
So funktioniert es
- Inputs werden gesammelt aus Dataset‑Metadaten, Antragstellerprofil, Nutzungskontext und regulatorischem Umfeld
- Inputs werden mit Regeln in der Autorisierungsmatrix abgeglichen
- Die Matrix bestimmt das Privacy Allowance Profile (z. B. „Keine direkten/indirekten PII“)
- Das System erstellt ein Data Access Certificate (DAC) mit Anforderungen, Restriktionen und Audit‑Metadaten
- Automatisierte Anonymisierungs-/Redaktions-/Scrubbing‑Pipelines transformieren die Daten entsprechend
- Zugriff wird nur auf die transformierte und genehmigte Datenansicht gewährt
Dies passt in bestehende Industry‑Modelle für DAG, DLP, ML‑Governance und Datenschutz‑Compliance.
2. APMF: PAPs
- P0 — Full Access: Direkt/indirekt/sensibel erlaubt (Audit/Zertifizierung erforderlich).
- P1 — No Direct IDs: Direkt entfernt; indirekt & sensibel dürfen verbleiben.
- P2 — No Direct or Indirect IDs: Direkt & indirekt entfernt; sensibel darf verbleiben
- P3 — No Direct and sensitive: Direkt und sensibel entfernt; indirekt darf verbleiben
- P4 — No sensitive data: Direkt & indirekt dürfen verbleiben; sensibel maskiert oder entfernt
- P5 — Fully De-Identified / External Processor: Alle PII entfernt/redigiert; nur aggregierter oder irreversibel anonymisierter Text erlaubt.
- P6 — Synthetic / Derived: Nur synthetische oder vollständig abgeleitete Daten erlaubt.
3. APMF: Framework-Spezifikation (Eingaben)
Input information
Data source (automated from data metadata)
Informationen, die die Datenquelle begleiten sollten.
- Data type: Kundenchats, E‑Mails, Call‑Transkripte, Gesundheitsakten, Finanzdokumente, Mitarbeiterdaten, Prompts, Logs, anderes
- Data domain: medizinisch, finanziell, rechtlich, staatlich, anderes (spezifizieren)
- Data include minors: ja / nein / unbekannt
- Moderation risks: illegale, schädliche oder potenziell verstörende Inhalte (erfordert besondere Sorgfalt, v. a. bei menschlichem Zugriff, z. B. Labeler)
- PII classes in data: direkte IDs, indirekte IDs, sensible Attribute, keine, unbekannt
- Jurisdiction: Standort von Daten und betroffenen Personen für die Jurisdiktion
- Consent: Einwilligung vorhanden (ja/nein/teilweise – Nutzung spezifizieren). Exakte Consent‑Strings, Zeitstempel, Scope (Training erlaubt, Marketing untersagt) und Quelle (UI, Cookie, Vertrag) erfassen. DSGVO/CCPA erfordern Nachweis der Rechtsgrundlage.
- Data policy: Feld für Policy zum Zugriff und zur Nutzung der Daten vom Provider.
- Data provenance: verbindet Dataset mit Originalquelle(n), Versionen und Transformationen für Audit und Reproduzierbarkeit.
- Re-Use / Re-Training Flags: explizites Flag, ob das Dataset für nachfolgendes Training/Fine‑Tuning genutzt werden darf (ja/nein/bedingt).
- Access log: Monitoring, wer wann auf die Daten zugegriffen hat, …
- Storage: wo die Daten gespeichert sind, eventuelle Kopien
Requester (automated from requester profile)
- Human or automated: Mensch, Agent/Tool/Programm
- Party: intern / Drittanbieter (Name & Region) / Regulator / betroffene Person
- Role: Data Scientist, Annotator, Analyst, …
- Permissions: Training, Zugriffsstufe
Request (requester needs to provide)
- Purpose of access: Training (Modell), Test/Evaluation, Debugging, Produktion (User‑Serving), Analytics, Legal/Compliance, anderes (spezifizieren).
- Processing location: On‑Prem, Cloud (Provider: …), hybrid.
- Processing tool: internes Tool, Drittanbieter‑LLM/Tool (ja/nein. Falls ja: Provider, Vertragsstatus (DPA/BAA/SCCs))
- Sensitivity of decisions: automatisierte Entscheidungen? (ja/nein); Nutzer‑Impact? (ja/nein); …
- PII classes requested: direkte Identifikatoren / indirekte Identifikatoren / sensible Informationen
Regulations (automated)
- Jurisdiction: basierend auf Standort von Daten/Nutzern sowie Verarbeitungs-/Deployment‑Ort – EU, US, UK, anderes (spezifizieren).
- Regulations: anwendbare Regelwerke basierend auf allen verfügbaren Informationen
- Ethical risks: erwartetes Bias‑Risiko (niedrig/mittel/hoch) und Bedenken
4. APMF: Framework-Spezifikation (Ausgaben)
Privacy Allowance Profile (PAP)
Maschinenlesbar: weist die Maschine an, die Daten gemäß dem erlaubten Profil aufzubereiten.
- Allowed classes of PII: direkte Identifikatoren / indirekte Identifikatoren / sensible Informationen
- Anonymization required: automatisierte Workflows, die vor dem Zugriff gemäß DAC anzuwenden sind: Redaction, Obfuscation, …
Data Access Certificate (DAC)
Begleitet die Daten und ist sowohl menschen- als auch maschinenlesbar, um Audits und die automatische Erkennung von Policy‑Verstößen zu ermöglichen.
- Request summary: Details zu den Daten und wofür Zugriff gewährt wird (wer darf zugreifen, wie lange, erlaubte/unerlaubte Nutzung, relevante Regelwerke, ethische Risiken …).
- Re-identification risk score: automatischer Score zur Messung der Effektivität der De‑Identifikation (nützlich für Regulatoren und Auditoren).
- Derivative policies: Policies für Daten-/Modell‑Outputs, die aus Originaldaten abgeleitet werden. Model Inversion und Embedding Leakage sind bekannte Industry‑Risiken.
- Retention and deletion policy: wie lange die gewährte Ansicht/der Extract oder ein abgeleitetes Modell bestehen darf. Ausgabe an Ablauf koppeln.
Permissions checklist
Skizziert, welche Berechtigungen erforderlich sind und welche fehlen, um gemäß Anfrage Zugriff zu erhalten. Das erleichtert die Anfrage, indem klar wird, welche Berechtigungen benötigt werden und wo sie zu beantragen sind.
5. Fehlercode-Management & Taxonomie
Dieses Dokument definiert die Management-Methodik und die Fehlercode-Taxonomie zur kontinuierlichen Verbesserung von Daten‑Anonymisierungsprozessen.
Management-Framework
Überblick
Dieses Framework bietet einen systematischen Ansatz zur Steuerung und Verbesserung der Qualität von Daten‑Anonymisierung durch kontinuierliche Fehlererkennung, Messung und Reduktion. Inspiriert von Six Sigma[^1] ermöglicht es Organisationen, eine nahezu perfekte Anonymisierung zu erreichen, indem Fehler über die Zeit minimiert werden – als Teil eines Privacy Information Management System (PIMS).
Prozessarchitektur
Die Anonymisierungs-Pipeline besteht aus drei Schichten:
- Source Layer: Originaltext mit personenbezogenen Identifikationsinformationen (PII)
- Privacy Layer: Text, bei dem PII durch Privacy Tokens ersetzt sind (z. B. [NAME], [EMAIL])
- Output Layer: Finaler Text nach Unmasking und ggf. Transformationen (z. B. Übersetzung, Zusammenfassung)
Zentrale Erkennungsfunktion
FUNCTION DetectErrors( inputs: { source: String, actual-mask: PrivacyMask=[ List <{Start , End, Label, Index }>], computed-mask:PrivacyMask=[ List <{Start , End, Label, Index }>]} ) -> ErrorMatrix [ List<{ activation: Code, explanation: String }> ]:Ziel: Die Fehlerfunktion minimieren, während Volumen und Komplexität der Anfragen steigen.
Qualitätsmanagement-Workflow
- Inference Stage: Aus Source Text und Label‑Taxonomie Privacy Mask berechnen
- Evaluation Stage: Berechnete Mask mit Gold‑Standard‑Annotationen vergleichen
- Post‑Processing Stage: String‑Replacement anwenden und Output‑Qualität validieren
- Analysis Stage: Fehler nach Typ klassifizieren, Metriken berechnen, Verbesserungsbereiche identifizieren
- Improvement Stage: Modelle, Regeln und Prozesse anhand von Fehlermustern verbessern
6. Error Taxonomy: Token-Klassifikationsfehler (T)
- ## Token-Klassifikationsfehler (T)
Description: Binäre Klassifikationsfehler auf Token‑Ebene, bei denen einzelne Texteinheiten fälschlich als PII enthaltend (oder nicht) erkannt werden. Token meint hier die Einheiten, die z. B. nach Tokenisierung entstehen.
Application: Gilt für alle Anonymisierungsaufgaben in der initialen Token‑Detektionsphase.
Evaluation:
- Severity: 5/5 — Undertriggering verursacht direkte Datenschutzverletzungen; Overtriggering reduziert die Datennutzbarkeit und kann legitime Use Cases blockieren
- Metrics: Precision, Recall, F1 auf Token‑Ebene; False Positive Rate (FPR), False Negative Rate (FNR)
| Code | Fehlername | Beschreibung | Beispiel[^2] | |
|---|---|---|---|---|
| T-001 | Overtriggered | Token fälschlich als PII markiert | S: I like apple pie P: I like [COMPANY] pie G: I like apple pie | |
| T-002 | Undertriggered | Token fälschlich als nicht‑PII markiert, obwohl es PII enthält | S: Email to john.doe@email.com P: Email to john.doe@email.com G: Email to [EMAIL] |
[COMPANY] pie G: I like apple pie[EMAIL]7. Error Taxonomy: Entity‑Span‑Fehler (S)
- ## Entity‑Span‑Fehler (S)
Description: Fehler beim Bestimmen korrekter Grenzen von PII‑Entitäten. Das System erkennt PII, erfasst aber nicht den vollständigen Span oder erfasst falsche Teile des umgebenden Textes. Eine Entität ist ein Informationsteil, der zur Identifikation beitragen oder sensible Details offenbaren kann. Entitäten können als Spans über ein oder mehrere Tokens realisiert sein.
Application: Gilt für alle entitätsbasierten Anonymisierungssysteme, insbesondere für NER und Boundary‑Detection bei Multi‑Token‑Entitäten.
Evaluation:
- Severity: 4/5 — Moderater Einfluss auf Datenschutz (Underannotation) und Nutzen (Overannotation). Kann in Label‑Klassifikationsfehler kaskadieren
- Metrics: Exact Match Accuracy, Partial Match Score, Character‑level F1, Boundary IoU
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| S-001 | Overannotated | Zu viele Tokens im Span | S: Dr. Sarah Johnson's research is outstanding P: [NAME] research is outstanding G: Dr. [NAME]’s research is outstanding |
| S-002 | Underannotated | Zu wenige Tokens im Span | S: Dr. Sarah Johnson's research is outstanding P: Dr. Sarah [NAME]’s research is outstanding G: Dr. [NAME]’s research is outstanding |
| S-003 | Partially Overlapping | Spans überlappen, Grenzen stimmen nicht | S: Dr. Sarah Johnson's research is outstanding P: Dr. Sarah [NAME] is outstanding G: Dr. [NAME]’s research is outstanding |
| S-004 | Span Fragmented | Entität fälschlich in mehrere Entitäten gesplittet | S: I live in New York City P: I live in [LOCATION] [LOCATION] [LOCATION] G: I live in [LOCATION] |
| S-005 | Spans Merged | Mehrere Entitäten zu einem Span zusammengeführt | S: Travel from Paris to London tomorrow P: Travel from [LOCATION] tomorrow G: Travel from [LOCATION] to [LOCATION] tomorrow |
| S-006 | Span Misaligned | Entität erkannt, aber Grenzen komplett falsch | S: I live in New York P: I liv[LOCATION]ork G: I live in [LOCATION] |
[NAME] research is outstanding G: Dr. [NAME]’s research is outstanding[NAME]’s research is outstanding G: Dr. [NAME]’s research is outstanding[NAME] is outstanding G: Dr. [NAME]’s research is outstanding[LOCATION] [LOCATION] [LOCATION] G: I live in [LOCATION][LOCATION] tomorrow G: Travel from [LOCATION] to [LOCATION] tomorrow[LOCATION]ork G: I live in [LOCATION]8. Error Taxonomy: Entity‑Nesting‑Fehler (N)
- ## Entity‑Nesting‑Fehler (N)
Description: Fehler beim Erkennen und Repräsentieren hierarchischer Beziehungen, in denen eine Entität eine andere enthält oder enthalten ist.
Application: Gilt primär für strukturierte Datenkontexte (Dateipfade, URLs, Adressen, organisatorische Hierarchien) und Systeme mit Nested Entities. Nicht anwendbar auf „flache“ Entity‑Modelle.
Evaluation:
- Severity: 3/5 — Kann verschachtelte PII exponieren; oft bietet die übergeordnete Entität ausreichend Schutz. Der Impact variiert je nach Tiefe und Entity‑Typen
- Metrics: Nested Entity Recognition Rate, Hierarchy Completeness Score, Parent‑Child Match Accuracy
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| N-001 | Missing Nested Entity | Verschachtelte Entität innerhalb einer größeren Entität nicht erkannt | S: /home/john_doe/documents/contract.pdf P: [/home/john_doe/documents/contract.pdf]FILEPATH G: [/home[/john_doe]USERNAME/documents/ contract.pdf]FILEPATH |
| N-002 | Missing Larger Entity | Größere Entität nicht erkannt | S: /home/john_doe/documents/contract.pdf P: /home[/john_doe]USERNAME/documents/ contract.pdf G: [/home[/john_doe]USERNAME/documents/ contract.pdf]FILEPATH |
[/home/john_doe/documents/contract.pdf]FILEPATH G: [/home[/john_doe]USERNAME/documents/ contract.pdf]FILEPATH[/john_doe]USERNAME/documents/ contract.pdf G: [/home[/john_doe]USERNAME/documents/ contract.pdf]FILEPATH9. Error Taxonomy: Label‑Klassifikationsfehler (Single‑Label) (L)
- ## Label‑Klassifikationsfehler (Single‑Label) (L)
Fehler beim Zuweisen der korrekten PII‑Kategorie zu einer Entität. Spans sind korrekt, aber der Typ/die Kategorie ist falsch oder die Granularität ist unangemessen.
Description: Fehler beim Zuweisen der korrekten PII‑Kategorie, wenn nur ein Label erlaubt ist. Der Span ist korrekt erkannt, aber falscher Typ oder falsche Granularität.
Application: Gilt für alle klassifikationsbasierten Anonymisierungssysteme. Kritisch, wenn unterschiedliche Entity‑Typen unterschiedlich behandelt werden müssen (z. B. Retention Policies, Verschlüsselungsmethoden).
Evaluation:
- Severity: 3/5 — meist geringeres Risiko, da die Entität weiterhin geschützt ist, kann aber Downstream‑Processing, Policy‑Compliance und Analytics‑Utility beeinflussen
- Metrics: Label Accuracy, Confusion Matrix, Macro/Micro F1 pro Klasse, Granularity Appropriateness Score
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| L-001 | Misclassified | Komplett falsches Label | S: For support, call 555-1234 P: For support, call [PASSWORD] G: For support, call [PHONE] |
| L-002 | Imprecise | Grobe/Fallback‑Kategorie statt feingranularem Label | S: I live in Paris P: I live in [LOCATION] G: I live in [CITY] |
| L-003 | Too Specific | Feingranulares Label, obwohl grobes sinnvoller ist | S: Enter code 3456 P: Enter code [PASSWORD] G: Enter code [NUMERIC_ID] |
[PASSWORD] G: For support, call [PHONE][LOCATION] G: I live in [CITY][PASSWORD] G: Enter code [NUMERIC_ID]10. Error Taxonomy: Label‑Klassifikationsfehler (Multi‑Label) (M)
- ## Label‑Klassifikationsfehler (Multi‑Label) (M)
Description: Fehler beim Zuweisen und Ranken mehrerer valider PII‑Kategorien, wenn Entitäten legitimerweise zu mehreren Klassen gehören. Fehler umfassen fehlende Labels, falsches Confidence‑Ranking oder ungültige Labels.
Application: Gilt nur für Systeme mit Multi‑Label‑Klassifikation, typischerweise für ambige Entitäten (z. B. „Jordan“ als NAME/LOCATION) oder Entitäten, die mehrere Informationen tragen (z. B. „Janet“ als NAME/(wahrscheinlich)GENDER oder die italienische SSN „RSSRRT60R27F205X“, die auch Teile von NAME, DoB, CITY und GENDER enthält). Nicht anwendbar auf strikt Single‑Label‑Systeme.
Evaluation:
- Severity: 2/5 — beeinflusst Downstream‑Entscheidungen und sensitive‑data‑aware Processing, aber die Entität bleibt vermutlich durch mindestens ein Label geschützt
- Metrics: Ranking: nDCG oder LRAP; Label Assignment: Precision/Recall
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| M-001 | Overranked | Label möglich, aber mit zu hoher Confidence gerankt | S: I want to visit Jordan P: I want to visit Jordan[NAME:0.9, COUNTRY:0.8] G: I want to visit Jordan[COUNTRY:0.8, NAME:0.4] |
| M-002 | Underranked | Label möglich, aber mit zu niedriger Confidence gerankt | S: I want to visit Jordan P: I want to visit Jordan[NAME:0.4, COUNTRY:0.3] G: I want to visit Jordan[COUNTRY:0.8, NAME:0.4] |
| M-003 | Underlabeled | Zu wenige Labels; valide Labels fehlen | S: I want to visit Jordan P: I want to visit Jordan[COUNTRY:0.8, ] G: I want to visit Jordan[COUNTRY:0.8, NAME:0.4] |
| M-004 | Overlabeled | Zu viele Labels; einige kontextuell ungültig | S: I want to visit my friend Jordan P: I want to visit my friend Jordan[NAME:0.9, COUNTRY:0.4] G: I want to visit my friend Jordan[NAME:0.9] |
[NAME:0.9, COUNTRY:0.8] G: I want to visit Jordan[COUNTRY:0.8, NAME:0.4][NAME:0.4, COUNTRY:0.3] G: I want to visit Jordan[COUNTRY:0.8, NAME:0.4][COUNTRY:0.8, ] G: I want to visit Jordan[COUNTRY:0.8, NAME:0.4][NAME:0.9, COUNTRY:0.4] G: I want to visit my friend Jordan[NAME:0.9]11. Error Taxonomy: Privacy‑Token‑Fehler (K)
- ## Privacy‑Token‑Fehler (K)
Description: Fehler in Struktur von Privacy Tokens, deren Verknüpfung mit Source Text und Coreference über das Dokument hinweg. Das betrifft Token‑Integrität, Traceability und Konsistenz von Identitäten. Tritt auf bei Misalignment zwischen Source‑ und Privacy‑Layer oder wenn Identitäten nicht korrekt erkannt werden.
Application: Gilt für alle tokenbasierten Anonymisierungssysteme, die Mappings zwischen Privacy Tokens und Original‑Entitäten pflegen. Kritisch für reversible Anonymisierung und Multi‑Mention‑Szenarien.
Evaluation:
- Severity: 4/5 — hoch, da Fehler Unmasking brechen, PII durch schlecht geformte Tokens exponieren oder wiederholte Mentions nicht schützen können
- Metrics: Token‑Span Alignment Accuracy, Coreference Resolution F1, Token Format Compliance Rate
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| K-001 | Incorrect token length | Token‑Länge entspricht nicht dem tatsächlichen Span | P: Contact Dr. Smith[NAME] Privacy token: [NAME]byte:12-13 Privacy token: [NAME]byte:12-17 |
| K-002 | Incorrect token anchors | Token ist mit falschem Span (oder keinem) verknüpft | P: Contact Dr. Smith[NAME] Privacy token: [NAME]byte:4-8 Privacy token: [NAME]byte:12-17 |
| K-003 | Missing Coreference | Mehrfachreferenzen nicht auf gleiche Entität gemappt | S: Hannah Smith was born in 1956. Dr. Smith studied in Edinburgh P: [NAME_1] was born in 1956. Dr. [SURNAME_2] studied in Edinburgh G: [NAME_1] was born in 1956. Dr. [SURNAME_1] studied in Edinburgh |
| K-004 | Incorrect token label | Token falsch benannt (Label, Code) | S: Patient SSN is 123-45-6789 P: Patient SSN is [SocialNum_001] G: Patient SSN is [SSN_1] |
| K-005 | Token label includes PII | Token‑Label enthält personenbezogene Informationen | S: Janet Smith’s passport number is DG456789 P:[NAME_FEMALE_1]’s passport number is [US_PASSPORTNO_1] G:[NAME_1]’s passport number is[PASSPORTNO_1] |
[NAME] Privacy token: [NAME]byte:12-13 Privacy token: [NAME]byte:12-17[NAME] Privacy token: [NAME]byte:4-8 Privacy token: [NAME]byte:12-17[NAME_1] was born in 1956. Dr. [SURNAME_2] studied in Edinburgh G: [NAME_1] was born in 1956. Dr. [SURNAME_1] studied in Edinburgh[SocialNum_001] G: Patient SSN is [SSN_1][NAME_FEMALE_1]’s passport number is [US_PASSPORTNO_1] G:[NAME_1]’s passport number is[PASSPORTNO_1]12. Error Taxonomy: Output‑Text‑Fehler (O)
- ## Output‑Text‑Fehler (O)
Description: Fehler beim Unmasking und der Output‑Generierung, bei denen Privacy Tokens falsch ersetzt, falsch positioniert oder grammatikalisch inkorrekt gerendert werden.
Application: Gilt nur für reversible Anonymisierungssysteme mit Unmasking und für Pipelines mit Texttransformation (Übersetzung, Zusammenfassung, Style Transfer) nach dem Masking.
Evaluation:
- Severity: 3/5 — mittel. Erzeugt keine Privacy Breaches, beeinträchtigt jedoch Nutzbarkeit, Verständnis und Vertrauen stark. O‑001 mit falschem Entity‑Wert kann Verwirrung oder Desinformation verursachen
- Metrics: Unmasking Accuracy, BLEU/ROUGE (Fluency), Edit Distance, Grammaticality
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| O-001 | Mask mit falschem Entity‑Wert gefüllt | Falscher/kein Wert beim Unmasking eingefügt | S: We met John Doe at the conference P: We met [NAME] at the conference O: We met Janet at the conference G: We met John Doe at the conference |
| O-002 | Mask nicht ersetzt | Privacy Token bleibt im Output statt unmasked zu werden | S: We met John Doe at the conference P: We met [NAME] at the conference O: We met [NAME] at the conference G: We met John Doe at the conference |
| O-003 | Span falsch ersetzt | Entity‑Wert an falscher Position ersetzt | S: We met John Doe at the conference P: We met [NAME] at the conference O: We met at the John Doe conference G: We met John Doe at the conference |
| O-004 | Unmasked Entity‑Wert ungrammatisch | Wert nicht an Kontext angepasst (z. B. falscher Kasus) | S: Helena's book is excellent P: [NAME] book is excellent O: Helena Buch ist ausgezeichnet G: Helenas Buch ist ausgezeichnet (German possessive ‘s’) |
| O-005 | Umgebender Output ungrammatisch | Unmasking erzeugt linguistische/Kohärenzfehler, oft weil Masking kritische Infos entfernte (Gender, Numerus, Kasus, Coreference) | S: Residency: United States P: Residency: [COUNTRY] O: I live in United States G: I live in the United States |
| O-006 | Unmasked Entity‑Wert nicht übersetzt | Entity‑Wert nicht an Ausgabesprache angepasst | S: Janet has recently married P: [NAME] has recently [MARITAL_STATUS] O: Janet si è married da poco G: Janet si è sposata da poco |
[NAME] at the conference O: We met Janet at the conference G: We met John Doe at the conference[NAME] at the conference O: We met [NAME] at the conference G: We met John Doe at the conference[NAME] at the conference O: We met at the John Doe conference G: We met John Doe at the conference[NAME] book is excellent O: Helena Buch ist ausgezeichnet G: Helenas Buch ist ausgezeichnet (German possessive ‘s’)[COUNTRY] O: I live in United States G: I live in the United States[NAME] has recently [MARITAL_STATUS] O: Janet si è married da poco G: Janet si è sposata da poco13. Error Taxonomy: Personalisierungsfehler (P)
- ## Personalisierungsfehler (P)
Description: Fehler bei der Anwendung nutzer- oder policy‑spezifischer Anonymisierungspräferenzen, die zu falscher Behandlung gemäß individueller Anforderungen oder Organisationsrichtlinien führen.
Application: Gilt nur für Systeme mit personalisierten Regeln (z. B. user‑definierte Sensitivitätslevels, Custom‑Entity‑Types, Jurisdiktionsanforderungen).
Evaluation:
- Severity: 4/5 — hoch, da dies Erwartungen und Policy‑Compliance direkt verletzt und zu regulatorischen Verstößen oder Vertrauensverlust führen kann
- Metrics: Policy Compliance Rate, Preference Application Accuracy, User Satisfaction Score
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| P-001 | Preference Not Applied | Präferenz ignoriert | S: My IP address is 192.168.1.1 User Preference: Anonymise all IP addresses P: My IP address is 192.168.1.1 G: My IP address is [IP_ADDRESS] |
| P-002 | Wrong Preference Applied | Falsches Regelset/Policy angewendet | S: Patient : E12345 Applied Policy: Healthcare (anonymise) P: Employee ID: [EMPLOYEE_ID] Correct Policy: Internal HR (retain) G: Employee ID: E12345 |
[IP_ADDRESS][EMPLOYEE_ID] Correct Policy: Internal HR (retain) G: Employee ID: E1234514. Error Taxonomy: Prozessfehler in Privacy‑Projekten (E)
- ## Prozessfehler in Privacy‑Projekten (E)
Description: Organisatorische und Workflow‑Fehler, die widerspiegeln, wie Privacy‑Anonymisierung in breitere Datenverarbeitungsaktivitäten integriert ist.
Application: Gilt auf Prozess-/Workflow‑Ebene statt als technische Implementierung. Relevant für Audits, Privacy Impact Assessments und die Bewertung der PIMS‑Reife.
Evaluation:
- Severity: 5/5 — höchste Schwere, da es sich um systemische Fehler handelt, die alle Datenverarbeitungsaktivitäten betreffen können und auf grundlegende Kulturprobleme hindeuten
- Metrics: Privacy Impact Assessment Scores, Process‑Compliance‑Audit‑Ergebnisse, Incident Rate, Time‑to‑Privacy
| Code | Fehlername | Beschreibung | Beispiel |
|---|---|---|---|
| E-001 | Privacy Ignored | Anonymisierung nicht berücksichtigt, obwohl erforderlich | Dev‑Team teilt Produktionsdatenbank mit PII für Tests ohne Anonymisierung |
| E-002 | Anonymization as Blocker | Anonymisierung so restriktiv, dass legitime Arbeit verhindert wird | Over‑Anonymisierung macht Datensätze für notwendige Analysen unbrauchbar |
| E-003 | Privacy as Blocker | Fehlende/ungenügende Anonymisierung macht Daten unbenutzbar | Datensätze unbenutzbar aufgrund von Privacy‑Risiken |
| E-004 | Inappropriate Technique Selection | Falsche Technik für Sensitivitätslevel | Tokenisierung, wo volle Anonymisierung/Pseudonymisierung nötig ist; reversibles Masking für hochsensible Daten |
| E-005 | Inferability Risk | Information bleibt aus Kontext/Metadaten/Mask‑Eigenschaften ableitbar | Token‑Länge verrät Gender („male/female“), statistische Inferenz aus Quasi‑Identifikatoren |
[^1]: Six Sigma ist eine datengetriebene Qualitätsmanagement‑Methodik, die nahezu perfekte Ergebnisse anstrebt, indem Defekte minimiert und Variation in Prozessen reduziert wird.
[^2]: S: Source Text; P: Privacy Layer; O: Output Layer nach Unmasking/Processing; G: Gold Standard