Masquage et anonymisation des données dans le service d'orchestration

Un module facultatif, un fournisseur, deux méthodes

Le module de masquage dans le bloc config.modules.masking du service d'orchestration est facultatif : si on l'omet, le prompt atteint le modèle sans masquage. Configuré, il ne prend en charge à ce jour qu'un seul service, sap_data_privacy_integration, appliqué selon l'une de deux méthodes. L'anonymisation remplace les informations personnelles identifiables d'une catégorie choisie par un placeholder MASKED_ENTITY ; comme la valeur d'origine n'est conservée nulle part dans la requête, elle ne peut être rétablie, et la sortie du modèle elle-même ne peut pas non plus être démasquée. La pseudonymisation remplace les mêmes catégories par un placeholder numéroté MASKED_ENTITY_ID (MASKED_PERSON_1, MASKED_PERSON_2) que le service d'orchestration recherche et remet en place dans la réponse finale — y compris à l'intérieur des arguments d'appels d'outils, ce qui compte dès qu'une valeur masquée doit atteindre une action en aval. L'ancienne clé masking_providers qui configurait cela est dépréciée au profit de providers ; les requêtes qui envoient encore masking_providers doivent migrer. C339 place ce module dans le pipeline complet à neuf étapes ; cette fiche est le plongeon en profondeur sur le module lui-même.

Pourquoi c'est important

• Un consultant qui affirme à un client « le masquage gère le RGPD » sans avoir lu le tableau de portée des entités fait une promesse que SAP lui-même ne fait pas — profile-location et profile-address ne couvrent que les États-Unis.
• Choisir l'anonymisation quand un appel d'outil en aval a besoin de la vraie valeur casse silencieusement l'automatisation demandée par le client ; l'échec ne se voit que lorsque quelqu'un inspecte ce que l'agent a réellement envoyé.
• mask_grounding_input est désactivé par défaut, donc une configuration de masquage qui paraît complète sur le papier peut quand même laisser fuiter un nom ou un identifiant dans ce que le grounding va chercher.

Points clés

• Un seul fournisseur à ce jour : sap_data_privacy_integration. masking_providers est déprécié ; utiliser providers.
• Anonymisation = MASKED_ENTITY irréversible ; pseudonymisation = MASKED_ENTITY_ID numéroté, rétabli dans la réponse et dans les arguments d'appels d'outils.
• ~30 types d'entités, portée régionale inégale : profile-person en anglais seulement ; profile-location/profile-address aux États-Unis seulement ; profile-nationalid sur 20+ régions, profile-iban sur 70+.
• L'anonymisation détruit la distinction entre deux entités du même type dans une même entrée (l'exemple SAP « Michael et Donna »).
• Stratégies de remplacement : fabricated_data (fausse valeur plausible) ou constant (libellé fixe, numéroté automatiquement en pseudonymisation). Les entités personnalisées par regex exigent constant.
• allowlist exempte des valeurs nommées du masquage quel que soit le type d'entité.
• mask_grounding_input (désactivé par défaut) masque la requête envoyée au grounding documentaire.
• L'entrée PDF exige un mask_file_input_method explicite : anonymization ou skip.

Termes employés sur cette page

Anonymisation

Remplace les données personnelles par un placeholder MASKED_ENTITY irréversible ; la valeur d'origine n'est pas conservée.

Pseudonymisation

Remplace les données personnelles par un placeholder MASKED_ENTITY_ID numéroté, rétabli dans la réponse et dans les arguments d'appels d'outils.

Allowlist

Une liste de valeurs textuelles exactes exemptées du masquage quel que soit le type d'entité.

mask_grounding_input

Une option de masquage (désactivée par défaut) qui masque la requête envoyée au grounding documentaire avant la recherche.

Entité personnalisée

Une entité de masquage définie par une expression régulière plutôt qu'une catégorie nommée ; exige la stratégie de remplacement constant.

profile-sensitive-data

Une entité groupée couvrant nationalité, groupe religieux, genre, groupe politique, pronom de genre, ethnicité et orientation sexuelle en une seule ligne de configuration.

Sources

1. SAP AI Core docs (SAP-docs GitHub, Sep 2026) — Data Masking (full entity catalog, scope, anonymization vs pseudonymization)
2. SAP AI Core docs — Enhancing Model Consumption with Data Masking (allowlist, replacement strategies, custom entities, mask_grounding_input, PDF input)