Data Masking, Anonymisation and Content Filtering in the Orchestration Service
As of 2026-09-25
The orchestration service runs data masking and content filtering as two separate, composable modules answering two different questions — what data leaves the tenant, and what content is safe to exchange. This module works from SAP's own orchestration documentation to define the masking module's anonymization-vs-pseudonymization decision, its DPI entity list and its coverage limits, custom entities and allowlists, and grounding-input masking; then Azure Content Safety's four severity-scored harm categories and PromptShield versus Llama Guard 3's 14 binary categories, and how both can filter input and output independently or together. It closes with how to test a configuration against false negatives and false positives rather than trust it on day one, and positions masking and filtering as one documented control layer inside a GDPR/EU AI Act compliance picture, not complete compliance by themselves. Three exercises and a self-assessment gate the move to M365.
What you will learn
- Explain what data masking protects versus what content filtering protects, and why an orchestration config needs both, configured separately
- Choose anonymization or pseudonymization correctly for a stated use case, and state what breaks silently when the choice is wrong
- Write a complete masking_module_config: provider, method, entities, a custom entity with a regex and replacement strategy, and an allowlist
- Compare Azure Content Safety's four severity-scored categories with Llama Guard 3's 14 binary categories, and configure input and output filtering for a stated channel
- Design a minimal test set (known-positive, known-negative, edge cases) that catches false negatives and false positives in a masking or filtering configuration
- Position data masking and content filtering as one documented control layer within a broader GDPR/EU AI Act compliance picture, not as complete compliance on their own
Module overview
Who this is for. M333 named data masking and content filtering as two of the orchestration service's six modules; M325 called them by name in its hands-on tour. This module is where you actually configure them — the exact JSON, the exact entity list, the exact severity thresholds — because "we have guardrails" is not an answer a data-protection officer accepts, and neither is a config nobody has read since the day it was copied from a sample.
Prerequisites
- M333 (AI & LLM Fundamentals) and, ideally, M325 (SAP Generative AI Hub — Hands-on: Orchestration, Grounding, Masking, Filtering) for the orchestration pipeline's six-module structure
- Basic familiarity with JSON configuration and the concept of an orchestration_config request body
- Optional: a generative AI hub trial to run the exercises against a real orchestration config
Outcomes
- Write a masking_module_config and a filtering_module_config a data-protection officer could read and understand without further explanation
- Correctly diagnose whether a given use case needs anonymization or pseudonymization, before writing any configuration
- Choose Azure Content Safety or Llama Guard 3 (or both) and set thresholds/categories appropriate to a stated audience and channel
- Design and defend a test set that would catch a masking or filtering regression before a client does
Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.