Grounding, data masking and content filtering in depth

Three modules decide whether a generative AI application is fit for an enterprise: grounding (does it answer from our facts?), masking (does personal data leak to the model?) and content filtering (can it be abused or produce harmful output?). This lesson goes through each with what SAP documents, its limits, and how Contoso configures the IDoc Explainer.

Grounding

SAP's grounding module "integrates external, domain-specific, or real-time data into generative AI workflows." It works in two phases. To index documents, it splits them into chunks, converts the chunks into vectors (embeddings) and stores them in a vector database. At question time, it converts the query into a vector, finds similar chunks and supplies them to the model as context. You prepare the knowledge base in one of two ways: upload documents to a supported repository and run a data pipeline (Pipelines API), or push pre-chunked content directly (Vector API). Retrieval runs through the Retrieval API or the grounding module in orchestration.

Setup needs a resource group for grounding and, for the pipeline route, a generic secret with the repository credentials (SAP's August 2026 guidance asks SFTP users to replace ssh-dss keys and recommends ED25519). The JavaScript SDK package for document grounding is marked beta by SAP; check the status of the SDK you plan to use. And remember that grounding retrieves what is in the repository: if the runbook is wrong or outdated, the answer will be confidently wrong in the same way.

Data masking

The masking module uses SAP Data Privacy Integration to mask personally identifiable information for selected entity types before the prompt reaches the model. There are two methods. Anonymization replaces values with a MASKED_ENTITY-style placeholder and can't be reversed. Pseudonymization uses a MASKED_ENTITY_ID-style placeholder, and the masked values are restored in the response. Entity types include person names, organizations, locations, phone numbers, US addresses, e-mail addresses, SAP user IDs, national IDs, IBANs, credit card numbers and others; custom entities can be defined with regular expressions.

Content filtering

The filtering module screens input, output or both. It supports two services. Azure Content Safety classifies hate, violence, sexual and self-harm content with severity levels 0, 2, 4 and 6 (you set the threshold per category), detects prompt attacks with Prompt Shield, and offers protected material detection for code on output (which needs more than 110 characters of input). Llama Guard 3 recognizes 14 categories, including privacy, specialized advice, defamation and code interpreter abuse. You can combine one Azure filter and one Llama Guard filter, but not two of the same type; each filter type is a separate, billed request.

Two details from SAP's documentation matter in practice. First, for all Azure OpenAI models a global filter on the Azure platform already removes input and output classified as medium (4) or high (6) severity, whatever you configure. Second, SAP advises against writing explicit content-filtering rules into your prompts when you use the module, because examples of restricted content can cause false positives. Since August 2026, system and developer messages are excluded from Prompt Shield checks, so a system prompt that merely describes attacks no longer triggers the filter.