p5y

DOCS

APMF und Fehler-Taxonomie an einem Ort.
Strukturiert.

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

  1. Inputs werden gesammelt aus Dataset‑Metadaten, Antragstellerprofil, Nutzungskontext und regulatorischem Umfeld
  2. Inputs werden mit Regeln in der Autorisierungsmatrix abgeglichen
  3. Die Matrix bestimmt das Privacy Allowance Profile (z. B. „Keine direkten/indirekten PII“)
  4. Das System erstellt ein Data Access Certificate (DAC) mit Anforderungen, Restriktionen und Audit‑Metadaten
  5. Automatisierte Anonymisierungs-/Redaktions-/Scrubbing‑Pipelines transformieren die Daten entsprechend
  6. 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:

  1. Source Layer: Originaltext mit personenbezogenen Identifikationsinformationen (PII)
  2. Privacy Layer: Text, bei dem PII durch Privacy Tokens ersetzt sind (z. B. [NAME], [EMAIL])
  3. 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)

  1. ## 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.&nbsp;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
T-001
Fehlername
Overtriggered
Beschreibung
Token fälschlich als PII markiert
Beispiel[^2]
S: I like apple pie P: I like [COMPANY] pie G: I like apple pie
Code
T-002
Fehlername
Undertriggered
Beschreibung
Token fälschlich als nicht‑PII markiert, obwohl es PII enthält
Beispiel[^2]
S: Email to john.doe@email.com P: Email to john.doe@email.com G: Email to [EMAIL]

7. Error Taxonomy: Entity‑Span‑Fehler (S)

  1. ## 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
S-001
Fehlername
Overannotated
Beschreibung
Zu viele Tokens im Span
Beispiel
S: Dr. Sarah Johnson's research is outstanding P: [NAME] research is outstanding G: Dr. [NAME]’s research is outstanding
Code
S-002
Fehlername
Underannotated
Beschreibung
Zu wenige Tokens im Span
Beispiel
S: Dr. Sarah Johnson's research is outstanding P: Dr. Sarah [NAME]’s research is outstanding G: Dr. [NAME]’s research is outstanding
Code
S-003
Fehlername
Partially Overlapping
Beschreibung
Spans überlappen, Grenzen stimmen nicht
Beispiel
S: Dr. Sarah Johnson's research is outstanding P: Dr. Sarah [NAME] is outstanding G: Dr. [NAME]’s research is outstanding
Code
S-004
Fehlername
Span Fragmented
Beschreibung
Entität fälschlich in mehrere Entitäten gesplittet
Beispiel
S: I live in New York City P: I live in [LOCATION] [LOCATION] [LOCATION] G: I live in [LOCATION]
Code
S-005
Fehlername
Spans Merged
Beschreibung
Mehrere Entitäten zu einem Span zusammengeführt
Beispiel
S: Travel from Paris to London tomorrow P: Travel from [LOCATION] tomorrow G: Travel from [LOCATION] to [LOCATION] tomorrow
Code
S-006
Fehlername
Span Misaligned
Beschreibung
Entität erkannt, aber Grenzen komplett falsch
Beispiel
S: I live in New York P: I liv[LOCATION]ork G: I live in [LOCATION]

8. Error Taxonomy: Entity‑Nesting‑Fehler (N)

  1. ## 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
N-001
Fehlername
Missing Nested Entity
Beschreibung
Verschachtelte Entität innerhalb einer größeren Entität nicht erkannt
Beispiel
S: /home/john_doe/documents/contract.pdf P: [/home/john_doe/documents/contract.pdf]FILEPATH G: [/home[/john_doe]USERNAME/documents/ contract.pdf]FILEPATH
Code
N-002
Fehlername
Missing Larger Entity
Beschreibung
Größere Entität nicht erkannt
Beispiel
S: /home/john_doe/documents/contract.pdf P: /home[/john_doe]USERNAME/documents/ contract.pdf G: [/home[/john_doe]USERNAME/documents/ contract.pdf]FILEPATH

9. Error Taxonomy: Label‑Klassifikationsfehler (Single‑Label) (L)

  1. ## 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.&nbsp;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
L-001
Fehlername
Misclassified
Beschreibung
Komplett falsches Label
Beispiel
S: For support, call 555-1234 P: For support, call [PASSWORD] G: For support, call [PHONE]
Code
L-002
Fehlername
Imprecise
Beschreibung
Grobe/Fallback‑Kategorie statt feingranularem Label
Beispiel
S: I live in Paris P: I live in [LOCATION] G: I live in [CITY]
Code
L-003
Fehlername
Too Specific
Beschreibung
Feingranulares Label, obwohl grobes sinnvoller ist
Beispiel
S: Enter code 3456 P: Enter code [PASSWORD] G: Enter code [NUMERIC_ID]

10. Error Taxonomy: Label‑Klassifikationsfehler (Multi‑Label) (M)

  1. ## 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.&nbsp;B. „Jordan“ als NAME/LOCATION) oder Entitäten, die mehrere Informationen tragen (z.&nbsp;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
M-001
Fehlername
Overranked
Beschreibung
Label möglich, aber mit zu hoher Confidence gerankt
Beispiel
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]
Code
M-002
Fehlername
Underranked
Beschreibung
Label möglich, aber mit zu niedriger Confidence gerankt
Beispiel
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]
Code
M-003
Fehlername
Underlabeled
Beschreibung
Zu wenige Labels; valide Labels fehlen
Beispiel
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]
Code
M-004
Fehlername
Overlabeled
Beschreibung
Zu viele Labels; einige kontextuell ungültig
Beispiel
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]

11. Error Taxonomy: Privacy‑Token‑Fehler (K)

  1. ## 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
K-001
Fehlername
Incorrect token length
Beschreibung
Token‑Länge entspricht nicht dem tatsächlichen Span
Beispiel
P: Contact Dr. Smith[NAME] Privacy token: [NAME]byte:12-13 Privacy token: [NAME]byte:12-17
Code
K-002
Fehlername
Incorrect token anchors
Beschreibung
Token ist mit falschem Span (oder keinem) verknüpft
Beispiel
P: Contact Dr. Smith[NAME] Privacy token: [NAME]byte:4-8 Privacy token: [NAME]byte:12-17
Code
K-003
Fehlername
Missing Coreference
Beschreibung
Mehrfachreferenzen nicht auf gleiche Entität gemappt
Beispiel
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
Code
K-004
Fehlername
Incorrect token label
Beschreibung
Token falsch benannt (Label, Code)
Beispiel
S: Patient SSN is 123-45-6789 P: Patient SSN is [SocialNum_001] G: Patient SSN is [SSN_1]
Code
K-005
Fehlername
Token label includes PII
Beschreibung
Token‑Label enthält personenbezogene Informationen
Beispiel
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]

12. Error Taxonomy: Output‑Text‑Fehler (O)

  1. ## 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
O-001
Fehlername
Mask mit falschem Entity‑Wert gefüllt
Beschreibung
Falscher/kein Wert beim Unmasking eingefügt
Beispiel
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
Code
O-002
Fehlername
Mask nicht ersetzt
Beschreibung
Privacy Token bleibt im Output statt unmasked zu werden
Beispiel
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
Code
O-003
Fehlername
Span falsch ersetzt
Beschreibung
Entity‑Wert an falscher Position ersetzt
Beispiel
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
Code
O-004
Fehlername
Unmasked Entity‑Wert ungrammatisch
Beschreibung
Wert nicht an Kontext angepasst (z.&nbsp;B. falscher Kasus)
Beispiel
S: Helena's book is excellent P: [NAME] book is excellent O: Helena Buch ist ausgezeichnet G: Helenas Buch ist ausgezeichnet (German possessive ‘s’)
Code
O-005
Fehlername
Umgebender Output ungrammatisch
Beschreibung
Unmasking erzeugt linguistische/Kohärenzfehler, oft weil Masking kritische Infos entfernte (Gender, Numerus, Kasus, Coreference)
Beispiel
S: Residency: United States P: Residency: [COUNTRY] O: I live in United States G: I live in the United States
Code
O-006
Fehlername
Unmasked Entity‑Wert nicht übersetzt
Beschreibung
Entity‑Wert nicht an Ausgabesprache angepasst
Beispiel
S: Janet has recently married P: [NAME] has recently [MARITAL_STATUS] O: Janet si è married da poco G: Janet si è sposata da poco

13. Error Taxonomy: Personalisierungsfehler (P)

  1. ## 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.&nbsp;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
P-001
Fehlername
Preference Not Applied
Beschreibung
Präferenz ignoriert
Beispiel
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]
Code
P-002
Fehlername
Wrong Preference Applied
Beschreibung
Falsches Regelset/Policy angewendet
Beispiel
S: Patient : E12345 Applied Policy: Healthcare (anonymise) P: Employee ID: [EMPLOYEE_ID] Correct Policy: Internal HR (retain) G: Employee ID: E12345

14. Error Taxonomy: Prozessfehler in Privacy‑Projekten (E)

  1. ## 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
E-001
Fehlername
Privacy Ignored
Beschreibung
Anonymisierung nicht berücksichtigt, obwohl erforderlich
Beispiel
Dev‑Team teilt Produktionsdatenbank mit PII für Tests ohne Anonymisierung
Code
E-002
Fehlername
Anonymization as Blocker
Beschreibung
Anonymisierung so restriktiv, dass legitime Arbeit verhindert wird
Beispiel
Over‑Anonymisierung macht Datensätze für notwendige Analysen unbrauchbar
Code
E-003
Fehlername
Privacy as Blocker
Beschreibung
Fehlende/ungenügende Anonymisierung macht Daten unbenutzbar
Beispiel
Datensätze unbenutzbar aufgrund von Privacy‑Risiken
Code
E-004
Fehlername
Inappropriate Technique Selection
Beschreibung
Falsche Technik für Sensitivitätslevel
Beispiel
Tokenisierung, wo volle Anonymisierung/Pseudonymisierung nötig ist; reversibles Masking für hochsensible Daten
Code
E-005
Fehlername
Inferability Risk
Beschreibung
Information bleibt aus Kontext/Metadaten/Mask‑Eigenschaften ableitbar
Beispiel
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