Data Masking and Anonymisation in the Orchestration Service

One optional module, one provider, two methods

The masking module in the orchestration service's config.modules.masking block is optional: skip it and the prompt reaches the model unmasked. When configured, it currently supports a single service, sap_data_privacy_integration, applied through one of two methods. Anonymization replaces personally identifiable information in a chosen category with a MASKED_ENTITY placeholder; because the original value is not retained anywhere in the request, it cannot be restored, and the model's own output cannot be unmasked either. Pseudonymization replaces the same categories with a numbered MASKED_ENTITY_ID placeholder (MASKED_PERSON_1, MASKED_PERSON_2) that the orchestration service checks for and substitutes back into the final response — including inside tool-call arguments, which matters the moment a masked value needs to reach a downstream action. The older masking_providers key that configured this is deprecated in favor of providers; requests still sending masking_providers need to migrate. C339 places this module inside the full nine-stage pipeline; this card is the deep dive on the module itself.

Why it matters

• A consultant who tells a customer 'masking handles GDPR' without reading the entity scope table is making a claim SAP itself does not make — profile-location and profile-address only cover the United States.
• Choosing anonymization when a downstream tool call needs the real value silently breaks the automation the customer asked for; the failure only shows up when someone inspects what the agent actually sent.
• mask_grounding_input defaults to off, so a masking configuration that looks complete on paper can still leak a name or an ID into whatever grounding retrieves from.

Key points

• One provider today: sap_data_privacy_integration. masking_providers is deprecated; use providers.
• Anonymization = irreversible MASKED_ENTITY; pseudonymization = numbered MASKED_ENTITY_ID, restored in the answer and in tool-call arguments.
• ~30 entity types, uneven regional scope: profile-person is English-only; profile-location/profile-address are US-only; profile-nationalid spans 20+ regions, profile-iban 70+.
• Anonymization destroys distinguishability between two entities of the same type in one input (SAP's own 'Michael and Donna' example).
• Replacement strategies: fabricated_data (plausible fake) or constant (fixed label, auto-numbered under pseudonymization). Custom regex entities require constant.
• allowlist exempts named values from masking regardless of entity type.
• mask_grounding_input (default disabled) masks the query sent to document grounding.
• PDF input requires an explicit mask_file_input_method: anonymization or skip.

Terms used on this page

Anonymization

Replaces personal data with an irreversible MASKED_ENTITY placeholder; the original value is not retained.

Pseudonymization

Replaces personal data with a numbered MASKED_ENTITY_ID placeholder, restored in the response and in tool-call arguments.

Allowlist

A list of exact string values exempted from masking regardless of entity type.

mask_grounding_input

A masking option (default disabled) that masks the query sent to document grounding before retrieval.

Custom entity

A masking entity defined by a regular expression instead of a named category; requires the constant replacement strategy.

profile-sensitive-data

A bundled entity covering nationality, religious group, gender, political group, pronoun gender, ethnicity and sexual orientation in one configuration line.

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)