Data Masking, Anonymisierung und Content Filtering im Orchestration Service
Stand 2026-09-25
Der Orchestration Service führt Data Masking und Content Filtering als zwei getrennte, kombinierbare Module aus, die zwei unterschiedliche Fragen beantworten — welche Daten den Tenant verlassen und welcher Inhalt sicher auszutauschen ist. Dieses Modul folgt SAPs eigener Orchestration-Dokumentation, um die Anonymisierung-vs-Pseudonymisierung-Entscheidung des Masking-Moduls, seine DPI-Entitätenliste und ihre Abdeckungsgrenzen, benutzerdefinierte Entitäten und Allowlists sowie das Masking von Grounding-Input zu definieren; danach Azure Content Safetys vier schweregradbewertete Schadenskategorien und PromptShield gegenüber Llama Guard 3s 14 binären Kategorien, und wie beide Input und Output unabhängig oder gemeinsam filtern können. Es schließt damit, wie eine Konfiguration gegen Falsch-Negative und Falsch-Positive getestet wird, statt ihr am ersten Tag zu vertrauen, und positioniert Masking und Filtering als eine dokumentierte Kontrollschicht innerhalb eines DSGVO-/EU-AI-Act-Compliance-Bilds, nicht als vollständige Compliance für sich genommen. Drei Übungen und eine Selbsttest bedingen den Übergang zu M365.
Was Sie lernen
- Erklären, was Data Masking schützt gegenüber dem, was Content Filtering schützt, und warum eine Orchestration-Config beides braucht, getrennt konfiguriert
- Anonymisierung oder Pseudonymisierung korrekt für einen genannten Anwendungsfall wählen, und sagen, was bei falscher Wahl still kaputtgeht
- Eine vollständige masking_module_config schreiben: Provider, method, entities, eine benutzerdefinierte Entität mit Regex und Ersetzungsstrategie, und eine Allowlist
- Azure Content Safetys vier schweregradbewertete Kategorien mit Llama Guard 3s 14 binären Kategorien vergleichen und Input- und Output-Filterung für einen genannten Kanal konfigurieren
- Einen minimalen Testsatz (bekannt-positiv, bekannt-negativ, Grenzfälle) entwerfen, der Falsch-Negative und Falsch-Positive in einer Masking- oder Filtering-Konfiguration erfasst
- Data Masking und Content Filtering als eine dokumentierte Kontrollschicht innerhalb eines breiteren DSGVO-/EU-AI-Act-Compliance-Bilds positionieren, nicht als vollständige Compliance für sich genommen
Modulüberblick
Für wen dieses Modul gedacht ist. M333 hat Data Masking und Content Filtering als zwei der sechs Module des Orchestration Service benannt; M325 nannte sie beim Namen in seiner praktischen Tour. Dieses Modul ist der Ort, an dem Sie sie tatsächlich konfigurieren — das exakte JSON, die exakte Entitätenliste, die exakten Schwellenwerte —, denn "wir haben Guardrails" ist keine Antwort, die ein Datenschutzbeauftragter akzeptiert, und eine Konfiguration, die niemand seit dem Tag gelesen hat, an dem sie aus einem Beispiel kopiert wurde, auch nicht.
Voraussetzungen
- M333 (KI- und LLM-Grundlagen) und idealerweise M325 (SAP Generative AI Hub in der Praxis — Orchestration, Grounding, Masking, Filtering) für die Sechs-Module-Struktur der Orchestration-Pipeline
- Grundlegende Vertrautheit mit JSON-Konfiguration und dem Konzept eines orchestration_config-Request-Bodys
- Optional: ein Generative-AI-Hub-Trial, um die Übungen an einer echten Orchestration-Konfiguration durchzuführen
Lernergebnisse
- Eine masking_module_config und eine filtering_module_config schreiben, die ein Datenschutzbeauftragter ohne weitere Erklärung lesen und verstehen könnte
- Korrekt diagnostizieren, ob ein gegebener Anwendungsfall Anonymisierung oder Pseudonymisierung braucht, bevor irgendeine Konfiguration geschrieben wird
- Azure Content Safety oder Llama Guard 3 (oder beide) wählen und Schwellenwerte/Kategorien passend zu einem genannten Publikum und Kanal setzen
- Einen Testsatz entwerfen und begründen, der eine Masking- oder Filtering-Regression erfassen würde, bevor ein Kunde es tut
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.