DOCS

Un système structuré de politiques et de prise de décision qui détermine quelles données personnelles peuvent être accessibles pour une tâche donnée, par un demandeur donné, sous des contraintes réglementaires et éthiques spécifiques.

Ce cadre produit deux sorties lisibles par machine :

• Privacy Allowance Profile (PAP) – définit quelles classes de PII peuvent être incluses (directes, indirectes, sensibles)
• Data Access Certificate (DAC) – l’artefact d’autorisation formel qui accompagne les données

Objectif du cadre

• Faire respecter la minimisation des données, l’accès au moindre privilège et la limitation de la finalité
• Décider quelles classes de PII sont autorisées dans un contexte donné
• Décider quel processus d’anonymisation est nécessaire ou approprié
• S’intégrer aux workflows d’entreprise de Data Access Governance (DAG)
• Fournir la traçabilité pour les audits de confidentialité, la conformité, la gouvernance ML et le reporting
• Prendre en charge les données non structurées et les charges ML (chats, logs, transcriptions, prompts)

Portée

• S’applique à tout jeu de données non structuré ou à toute demande
• Couvre les outils de traitement internes et tiers (p. ex. LLMs dans le cloud)
• Couvre les demandeurs humains et automatisés
• Prend en compte la réglementation, l’éthique, le consentement et la politique de l’organisation
• Produit des certifications, des obligations et des transformations de PII

Comment ça fonctionne

1. Les entrées sont collectées depuis les métadonnées du jeu de données, le profil du demandeur, le contexte d’usage et l’environnement réglementaire
2. Les entrées sont confrontées aux règles dans la matrice d’autorisation
3. La matrice détermine le Privacy Allowance Profile (p. ex. « Pas de PII directes/indirectes »)
4. Le système produit un Data Access Certificate (DAC) avec exigences, restrictions et métadonnées d’audit
5. Des pipelines automatisés d’anonymisation/redaction/scrubbing transforment les données en conséquence
6. L’accès n’est accordé qu’à la vue transformée et approuvée des données

Cela s’intègre aux modèles existants de l’industrie (DAG, DLP, gouvernance ML, conformité confidentialité).

• P0 — Full Access: Direct/indirect/sensitive autorisés (audit/certification requis).
• P1 — No Direct IDs: Direct supprimées ; indirectes & sensibles peuvent rester.
• P2 — No Direct or Indirect IDs: Directes & indirectes supprimées ; sensibles peuvent rester
• P3 — No Direct and sensitive: Directes et sensibles supprimées ; indirectes peuvent rester
• P4 — No sensitive data: Directes & indirectes peuvent rester ; sensibles masquées ou supprimées
• P5 — Fully De-Identified / External Processor: Toutes les PII supprimées/redigées ; seuls des textes agrégés ou anonymisés de manière irréversible sont autorisés.
• P6 — Synthetic / Derived: Seules des données synthétiques ou entièrement dérivées sont autorisées.

Input information

Data source (automated from data metadata)

Informations qui doivent accompagner la source de données.

• Data type: Chats clients, emails, transcriptions d’appels, dossiers médicaux, documents financiers, dossiers employés, prompts, logs, autre
• Data domain: médical, financier, légal, gouvernemental, autre (préciser)
• Data include minors: oui / non / inconnu
• Moderation risks: présence de contenus illégaux, nuisibles ou potentiellement perturbants (nécessite une attention particulière, surtout si un accès humain est prévu, p. ex. annotateurs)
• PII classes in data: identifiants directs, identifiants indirects, attributs sensibles, aucun, inconnu
• Jurisdiction: localisation des données et des personnes concernées pour la juridiction
• Consent: consentement obtenu (oui/non/partiel – préciser l’usage consenti). Capturer les textes exacts de consentement, timestamps, périmètre (entraînement autorisé, marketing refusé) et source (UI, cookie, contrat). RGPD/CCPA exigent une preuve de base légale.
• Data policy: champ décrivant la politique d’accès et d’usage des données du fournisseur.
• Data provenance: rattache le dataset aux sources originales, versions et transformations pour audit et reproductibilité.
• Re-Use / Re-Training Flags: indicateur explicite si le dataset peut être utilisé pour des entraînements/affinages ultérieurs (oui/non/conditionnel).
• Access log: suivi de qui a accédé aux données, quand, …
• Storage: où sont stockées les données, copies éventuelles

Requester (automated from requester profile)

• Human or automated: humain, agent/outillage/programme
• Party: interne / tiers (nom & région) / régulateur / personne concernée
• Role: data scientist, annotateur, analyste, …
• Permissions: entraînement, niveau d’accès

Request (requester needs to provide)

• Purpose of access: entraînement (modèle), test/évaluation, débogage, service en production, analytique, légal/conformité, autre (préciser).
• Processing location: on‑prem, dans le cloud (fournisseur : …), hybride.
• Processing tool: outil interne, LLM/outillage tiers (oui/non. Si oui : fournisseur, statut contractuel (DPA/BAA/SCCs))
• Sensitivity of decisions: décisions automatisées ? (oui/non) ; impactant des utilisateurs ? (oui/non) ; …
• PII classes requested: identifiants directs / identifiants indirects / informations sensibles

Regulations (automated)

• Jurisdiction: basée sur la localisation des données/utilisateurs et des lieux de traitement/déploiement – UE, US, UK, autre (préciser).
• Regulations: applicables, sur la base des informations disponibles
• Ethical risks: risque de biais attendu (faible/moyen/élevé) et préoccupations

Privacy Allowance Profile (PAP)

Lisible par machine : indique à la machine comment préparer les données selon le profil autorisé.

• Allowed classes of PII: identifiants directs / identifiants indirects / informations sensibles
• Anonymization required: workflows automatisés à appliquer (redaction, obfuscation, …) avant d’accorder l’accès dans le cadre du DAC

Data Access Certificate (DAC)

Accompagne les données ; lisible par l’humain et la machine, pour permettre les audits et la détection automatique de violations.

• Request summary: détails sur les données et l’accès accordé (qui peut accéder, pour combien de temps, usages autorisés/interdits, réglementations respectées, risques éthiques …).
• Re-identification risk score: score automatisé mesurant l’efficacité de la désidentification (utile pour régulateurs et auditeurs).
• Derivative policies: politiques pour les sorties données/modèles dérivées. L’inversion de modèle et les fuites via embeddings sont des préoccupations connues.
• Retention and deletion policy: durée de conservation de la vue/extrait ou d’un modèle dérivé. Lier l’émission à une date d’expiration.

Permissions checklist

Liste les permissions requises et toute permission manquante pour accéder aux données selon la demande. Cela facilite la demande en clarifiant ce qui est requis et où l’obtenir.

Ce document définit la méthodologie de gestion et la taxonomie des codes d’erreur pour l’amélioration continue des processus d’anonymisation des données.

Cadre de gestion

Vue d’ensemble

Ce cadre fournit une approche systématique pour gérer et améliorer la qualité d’anonymisation des données via la détection, la mesure et la réduction continues des erreurs. Inspiré des principes du Six Sigma[^1], il permet aux organisations d’atteindre une anonymisation quasi parfaite en minimisant les erreurs dans le temps, dans le cadre d’un système de gestion de l’information de confidentialité (PIMS).

Architecture du processus

Le pipeline d’anonymisation comprend trois couches :

1. Couche source : texte original contenant des informations personnelles identifiables (PII)
2. Couche confidentialité : texte dont les PII sont remplacées par des jetons de confidentialité (p. ex. [NAME], [EMAIL])
3. Couche sortie : texte final après démasquage et transformations éventuelles (p. ex. traduction, résumé)

Fonction de détection principale

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 }> ]:

Objectif : minimiser la fonction d’erreur à mesure que le volume et la complexité des requêtes augmentent.

Workflow de gestion de la qualité

• Étape d’inférence : à partir du texte source et de la taxonomie d’étiquettes, calculer le masque de confidentialité
• Étape d’évaluation : comparer le masque calculé aux annotations « gold standard »
• Post-traitement : appliquer les remplacements de chaînes et valider la qualité de sortie
• Analyse : classifier les erreurs par type, calculer des métriques, identifier des axes d’amélioration
• Amélioration : affiner modèles, règles et processus en fonction des motifs d’erreur

1. ## Erreurs de classification de tokens (T)

Description : échecs de classification binaire au niveau du token, lorsque des unités de texte individuelles sont identifiées à tort comme contenant (ou non) des PII. Le terme « token » désigne ici les unités de texte obtenues, par exemple, après passage d’un tokenizer.

Application : s’applique à toutes les tâches d’anonymisation durant la phase initiale de détection au niveau token.

Évaluation :

• Sévérité : 5/5 — le sous-déclenchement crée des violations directes de confidentialité ; le sur‑déclenchement réduit l’utilité des données et peut bloquer des usages légitimes
• Métriques : précision, rappel, F1 au niveau token ; taux de faux positifs (FPR), taux de faux négatifs (FNR)

1. ## Erreurs d’étendue d’entité (S)

Description : erreurs dans la détermination des limites correctes des entités PII. Le système reconnaît qu’une PII existe, mais ne capture pas l’étendue complète ou capture des portions incorrectes du texte environnant. Une entité désigne ici un élément d’information pouvant contribuer à identifier une personne ou révéler des détails sensibles. Les entités peuvent être réalisées par des spans composés d’un ou plusieurs tokens.

Application : s’applique à tous les systèmes d’anonymisation basés sur des entités. Particulièrement pertinent pour la NER et la détection de frontières pour des entités multi‑tokens.

Évaluation :

• Sévérité : 4/5 — impact modéré sur la confidentialité (sous‑annotation) et l’utilité (sur‑annotation). Peut entraîner des erreurs de classification d’étiquette
• Métriques : exact match accuracy, partial match score, F1 au niveau caractère, Boundary IoU

1. ## Erreurs d’imbrication d’entités (N)

Description : échecs dans la reconnaissance et la représentation des relations hiérarchiques où une entité contient (ou est contenue dans) une autre entité.

Application : s’applique principalement aux contextes de données structurées (chemins de fichiers, URLs, adresses, hiérarchies organisationnelles) et aux systèmes supportant les entités imbriquées. Non applicable aux modèles d’entités « plates ».

Évaluation :

• Sévérité : 3/5 — peut exposer des PII imbriquées, mais l’entité englobante fournit souvent une protection suffisante. L’impact varie selon la profondeur d’imbrication et les types d’entités
• Métriques : Nested Entity Recognition Rate, Hierarchy Completeness Score, Parent‑Child Match Accuracy

1. ## Erreurs de classification d’étiquette (label) (mono‑label) (L)

Erreurs d’attribution de la bonne catégorie PII à une entité. Elles surviennent lorsque le span est correctement identifié, mais que le mauvais type/catégorie est assigné ou que le niveau de granularité est inadapté.

Description : erreurs d’attribution de la catégorie PII correcte lorsqu’une seule étiquette doit (ou peut) être appliquée. Le span est correct, mais le type assigné ou la granularité est erronée.

Application : s’applique à tous les systèmes d’anonymisation basés sur la classification. Critique lorsque des types d’entités différents exigent des traitements différents (p. ex. politique de rétention, méthodes de chiffrement).

Évaluation :

• Sévérité : 3/5 — risque généralement plus faible car l’entité reste protégée, mais peut affecter le traitement downstream, la conformité et l’utilité analytique
• Métriques : exactitude des labels, matrice de confusion, F1 macro/micro par classe, score d’adéquation de granularité

1. ## Erreurs de classification d’étiquette (multi‑label) (M)

Description : erreurs d’attribution et de classement de plusieurs catégories PII valides lorsque des entités appartiennent légitimement à plusieurs classes. Échecs possibles : labels manquants, mauvais classement, labels invalides.

Application : s’applique uniquement aux systèmes supportant le multi‑label, typiquement pour des entités ambiguës (p. ex. « Jordan » comme NAME/LOCATION) ou pour des entités portant plusieurs informations (p. ex. « Janet » NAME/(probable)GENDER ou le SSN italien « RSSRRT60R27F205X » contenant aussi des éléments de NAME, DoB, CITY et GENDER). Non applicable aux systèmes strictement mono‑label.

Évaluation :

• Sévérité : 2/5 — affecte la décision downstream et le traitement sensible aux données, mais l’entité reste probablement protégée par au moins un label
• Métriques : classement : nDCG ou LRAP ; attribution : précision/rappel

1. ## Erreurs de jeton de confidentialité (K)

Description : erreurs dans la structure des jetons de confidentialité, leurs liens au texte source et la coréférence à travers le document. Elles affectent l’intégrité des jetons, la traçabilité et la cohérence d’identité. Elles surviennent en cas de désalignement entre couche source et couche confidentialité, ou lorsque les identités ne sont pas correctement reconnues.

Application : s’applique à tous les systèmes d’anonymisation basés sur des jetons qui maintiennent des correspondances entre jetons et entités originales. Critique pour l’anonymisation réversible et les mentions multiples.

Évaluation :

• Sévérité : 4/5 — élevée, car ces erreurs peuvent casser le démasquage, exposer des PII via des jetons mal formés ou ne pas protéger les mentions répétées
• Métriques : Token‑Span Alignment Accuracy, Coreference Resolution F1, Token Format Compliance Rate

1. ## Erreurs de texte de sortie (O)

Description : erreurs lors du démasquage et de la génération de sortie, où des jetons de confidentialité sont remplacés de façon incorrecte, mal positionnés ou rendent le texte final agrammatical.

Application : s’applique uniquement aux systèmes d’anonymisation réversible avec démasquage et aux pipelines incluant une transformation de texte (traduction, résumé, style transfer) après masquage.

Évaluation :

• Sévérité : 3/5 — moyenne. Ne crée pas de fuite de confidentialité mais dégrade fortement l’utilité, la compréhension et la confiance. O‑001 avec une mauvaise valeur peut créer de la confusion ou de la désinformation
• Métriques : exactitude de démasquage, scores BLEU/ROUGE (fluidité), distance d’édition, scores de grammaticalité

1. ## Erreurs de personnalisation (P)

Description : erreurs dans l’application de préférences spécifiques (utilisateur/politique), entraînant un traitement incorrect selon des exigences individuelles ou des politiques organisationnelles.

Application : s’applique uniquement aux systèmes supportant des règles personnalisées (p. ex. niveaux de sensibilité définis, types d’entités custom, exigences de juridiction).

Évaluation :

• Sévérité : 4/5 — élevée, car ces erreurs violent directement attentes et conformité. Peut entraîner des violations réglementaires ou une perte de confiance
• Métriques : taux de conformité politique, exactitude d’application des préférences, score de satisfaction utilisateur

1. ## Erreurs de processus liées aux projets de confidentialité (E)

Description : erreurs organisationnelles et de workflow reflétant l’intégration de l’anonymisation dans les activités plus larges de traitement de données.

Application : s’applique au niveau processus/workflow plutôt qu’à l’implémentation technique. Pertinent pour les audits, DPIA/PIA et l’évaluation de maturité PIMS.

Évaluation :

• Sévérité : 5/5 — la plus élevée, car ces erreurs sont systémiques, affectent l’ensemble des traitements et révèlent des faiblesses de culture confidentialité
• Métriques : scores d’évaluation d’impact, résultats d’audit de conformité process, taux d’incidents, time‑to‑privacy

[^1]: Six Sigma est une méthodologie de management de la qualité orientée données visant à minimiser les défauts et la variation des processus afin d’atteindre des résultats quasi parfaits.

[^2]: S : texte source ; P : couche confidentialité ; O : couche sortie après démasquage/traitement ; G : gold standard