Azure AI Content Safety: Filter & Best Practices

Azure AI Content Safety ist Microsofts KI-gestützter Dienst zur Erkennung schädlicher Inhalte in nutzergenerierten und KI-generierten Texten und Bildern. Er dient als integriertes Inhaltsfiltersystem für alle Azure OpenAI und Foundry Modell-Deployments und prüft sowohl Prompts als auch Antworten über ein Ensemble von Klassifikationsmodellen. Der Dienst ist als eigenständige API verfügbar und tief in das Microsoft Foundry Portal integriert. Er wurde stark erweitert und bietet inzwischen neben seinen zentralen Klassifikatoren für Schadenskategorien auch Schutz vor Prompt Injection, Halluzinationserkennung, Urheberrechtsschutz und PII-Filterung.

Meiner Meinung nach hat Microsoft mit diesem Dienst hervorragende Arbeit geleistet.

Der zentrale Inhaltsfilter: vier Schadenskategorien mit Schweregrad-Bewertung

Das Rückgrat von Content Safety ist ein neuronales Mehrklassen-Klassifikationssystem, das Inhalte über vier Schadenskategorien hinweg bewertet. Jede Kategorie liefert einen Schweregrad-Score, und ein einzelner Textabschnitt kann mehrere Kategorien gleichzeitig auslösen.

Die vier Kategorien sind:

• Hate and Fairness (Hate): Angriffe oder diskriminierende Sprache gegen Identitätsgruppen (Ethnie, Geschlecht, sexuelle Orientierung, Religion, Behinderung usw.). Umfasst auch Belästigung und Mobbing.
• Sexual (Sexual): Inhalte zu sexuellen Handlungen, anatomischen Bezügen, erotischen Inhalten, Pornografie, Ausbeutung und Grooming.
• Violence (Violence): Sprache, die körperliche Schädigung, Waffen, Terrorismus, Einschüchterung, Stalking und gewaltbereiten Extremismus darstellt.
• Self-Harm (SelfHarm): Inhalte zu Selbstverletzung, Suizid, Essstörungen sowie damit verbundenes Mobbing oder entsprechende Anleitungen.

So funktionieren die Schweregrade

Das System verwendet eine interne Skala von 0–7, die für Filterentscheidungen auf vier handlungsrelevante Stufen reduziert wird:

Schweregrad	Score	Bedeutung
Safe	0	Kein schädliches Material; unterliegt keiner Filterung und ist nicht konfigurierbar
Low	2	Positive Darstellung, allgemeine Bezüge, fiktionale Kontexte, Erwähnungen mit geringer Intensität
Medium	4	Beleidigungen, Mobbing, Einschüchterung, Entmenschlichung, moderate grafische Inhalte
High	6	Hasspropaganda, explizite schädliche Anleitungen, Terrorismusinhalte, extrem grafisches Material

Das Textmodell unterstützt intern den vollen Bereich von 0–7 (Mapping [0,1]→0, [2,3]→2, [4,5]→4, [6,7]→6). Das Bildmodell liefert nur die reduzierte Skala 0/2/4/6. Das multimodale Modell unterstützt beides.

Die Standardkonfiguration filtert beim Schwellenwert Medium – Inhalte mit Score Medium (4) oder High (6) werden blockiert; Low (2) und Safe (0) werden durchgelassen. Das gilt sowohl für Prompts als auch für Antworten. Bei Serverless-Bildmodell-Deployments ist die Voreinstellung mit dem Low-Schwellenwert strenger.

Schwellenwerte konfigurieren

Kunden können die Schweregrad-Schwellenwerte frei zwischen drei Stufen anpassen (Low+Medium+High, Medium+High, nur High). Das vollständige Deaktivieren der Filter oder die Nutzung des Modus „Nur annotieren“ (liefert Scores zurück, ohne zu blockieren) erfordert einen formellen Genehmigungsprozess über das Formular „Azure OpenAI Limited Access Review: Modified Content Filters“.

Jenseits der Schadenskategorien: das Arsenal der erweiterten Filter

Content Safety wurde weit über die vier Kernkategorien hinaus zu einer Sammlung spezialisierter Filter ausgebaut, von denen jeder einen eigenen Bedrohungsvektor adressiert.

Prompt Shields (GA) – Abwehr von Injection-Angriffen

Prompt Shields ist eine einheitliche API, die feindliche Prompt Injection vor der Inhaltsgenerierung erkennt. Besonders relevant wird das für agentische Systeme wie Microsoft IQ, bei denen das Modell über Kontext schlussfolgert und auf Basis von Nutzereingaben Aktionen auslöst. Es ersetzt die ältere Funktion „Jailbreak risk detection“ und liefert eine binäre Klassifikation (Angriff erkannt oder nicht).

Zwei Shield-Typen:

1. Direkte Angriffe (Jailbreak-Erkennung) – Zielt auf bewusste Versuche, Systemregeln zu umgehen. Erkennt Versuche, Systemregeln zu ändern, eingebettete Konversations-Mockups, Rollenspiel-Exploits und Encoding-Angriffe (Chiffren, Zeichentransformationen). Standardmäßig aktiviert.
2. Indirekte Angriffe (XPIA / Cross-Domain Prompt Injection) – Erkennt schädliche Anweisungen, die in Dokumenten, E-Mails oder Webinhalten eingebettet sind, die das LLM verarbeitet. Deckt manipulierte Inhalte, unbefugte Zugriffsversuche, Informationssammlung, Betrug, Malware-Verteilung und Verfügbarkeitsangriffe ab. Standardmäßig deaktiviert – erfordert das Einbetten und Formatieren von Dokumenten in den Prompts.

Beide können entweder auf „Nur annotieren“ oder „Annotieren und blockieren“ konfiguriert werden. Trainiert auf Englisch, Chinesisch, Französisch, Deutsch, Spanisch, Italienisch, Japanisch und Portugiesisch.

Eine neuere Unterfunktion namens Spotlighting (Preview, angekündigt auf der Build 2025) versieht Eingabedokumente mit spezieller Formatierung, um vertrauenswürdige von nicht vertrauenswürdigen Eingaben zu unterscheiden, und stärkt so den Schutz vor indirekten Angriffen.

Groundedness-Erkennung – der Kampf gegen Halluzinationen

Erkennt, ob LLM-Textantworten in den vom Nutzer bereitgestellten Quellmaterialien verankert sind. Verwendet ein eigenes Sprachmodell, um Aussagen gegen die Quelldaten zu bewerten. Wichtige Eckdaten:

• Nur in Streaming-Szenarien verfügbar
• Unterstützte Regionen: Central US, East US, France Central, Canada East
• Nur Englisch
• Maximale Anzahl an Grounding-Quellen: 55.000 Zeichen pro API-Aufruf
• Maximaler Text/Query: 7.500 Zeichen; minimaler Query: 3 Wörter
• Korrekturfunktion (Preview): Schreibt nicht verankerten Text automatisch um und liefert ein an den Quellen ausgerichtetes correctedText-Feld zurück
• Standard: Aus – muss explizit aktiviert werden

Protected-Material-Erkennung (GA für Text; Preview für Code)

Protected Material for Text identifiziert und blockiert bekannte urheberrechtlich geschützte Inhalte (Songtexte, Artikel, Rezepte, ausgewählte Webinhalte) in Modellantworten. Nur Englisch. Maximale Inferenz-Eingabe: 1K Zeichen. Inhaberrechtsinhaber können Texte über ein Antragsformular zum Schutz einreichen. Standardmäßig aktiviert.

Protected Material for Code erkennt Quellcode, der mit öffentlichen GitHub-Repositories übereinstimmt, unterstützt durch GitHub Copilot. Im Annotate-Modus aktiviert, zeigt es Zitations-URLs neben dem erkannten Code an. Der Index des Code-Scanners reicht nur bis zum 6. April 2023 – neuerer Code wird nicht erkannt. Diese Funktion kann für die Abdeckung durch Microsofts Customer Copyright Commitment erforderlich sein. Standardmäßig aktiviert.

PII-Erkennung (als integrierter Filter verfügbar)

Erkennt personenbezogene Daten – Namen, Adressen, Telefonnummern, E-Mail-Adressen, Sozialversicherungsnummern, Führerscheinnummern, Reisepassnummern – in Modellantworten. Wurde als integrierte Inhaltsfilter-Option hinzugefügt. Standard: Aus.

Eigene Blocklists

Unterstützt exakten Textabgleich für bestimmte Begriffe. Enthält eine integrierte Profanity-Blocklist. Mehrere Blocklists können in einer einzigen Filterkonfiguration kombiniert und auf Eingabefilter, Ausgabefilter oder beide angewendet werden. Kein semantischer Abgleich und keine Bildabgleichsfunktion. Vom Kunden bereitgestellte Blocklists werden vom Dienst gespeichert (eine Ausnahme von der allgemeinen No-Storage-Richtlinie).

Eigene Kategorien – zwei Ansätze

Custom Categories (Standard) API (Preview): ML-basiert. Definiere eine Kategorie, stelle 50–5.000 positive Beispiele bereit (plus optionale negative, bis zu 10.000 insgesamt), trainiere ein Modell (kann mehrere Stunden dauern) und nutze dann die analyzeCustomCategory-API. Liefert einen Boolean. Nur Text, nur Englisch. Limit: 3 Kategorien pro Nutzer, 3 Versionen pro Kategorie.

Custom Categories (Rapid) API (Preview): LLM-basiert, kein Training nötig. Erstelle ein „Incident“-Objekt mit einer Textbeschreibung, lade Text- oder Bildbeispiele hoch (bis zu 1.000 pro Incident, max. 100 Incidents pro Ressource). Verwendet semantischen Textabgleich (Embedding-Suche + leichtgewichtiger Klassifikator) und Bildabgleich (Objekt-Tracking-Modell + Embedding-Suche). Funktioniert für Text und Bilder, in allen unterstützten Sprachen.

Task Adherence

Die neueste Funktion identifiziert Abweichungen zwischen dem Verhalten eines LLM und seiner zugewiesenen Aufgabe, einschließlich fehlausgerichteter Tool-Aufrufe und Inkonsistenzen zwischen Antworten und Nutzerabsicht. Ermöglicht das Blockieren fehlausgerichteter Aktionen oder die Eskalation an menschliche Prüfer.

So konfigurierst du Inhaltsfilter im Azure AI Foundry Portal

Der Konfigurationsablauf Schritt für Schritt:

1. Melde dich bei Microsoft Foundry unter ai.azure.com an
2. Navigiere zu deinem Projekt → Guardrails + controls → Tab Content filters
3. Wähle + Create content filter
4. Basic Information: Gib einen Filternamen ein und wähle die Verbindung (Azure AI Services Ressource)
5. Seite Input filters: Konfiguriere Filter für Nutzer-Prompts – setze Schweregrad-Schwellenwerte für jede der vier Schadenskategorien (Low, Medium, High), konfiguriere Prompt Shields (Nur annotieren oder Blockieren), aktiviere/deaktiviere die Protected-Material-Erkennung
6. Seite Output filters: Konfiguriere Filter für Modellantworten – dieselben Schweregrad-Steuerungen plus Streaming-Modus-Option, Groundedness-Erkennung, Protected Material (Text und Code) und PII-Erkennung
7. Blocklist-Konfiguration: Aktiviere Blocklists für Eingabe- oder Ausgabefilter, wähle eigene Blocklists oder die integrierte Profanity-Blocklist
8. Seite Connection: Verknüpfe den Filter mit bestimmten Modell-Deployments (kann auch später erfolgen)
9. Review and create

Inhaltsfilter werden auf Hub-/Ressourcenebene erstellt und können mit einem oder mehreren Deployments verknüpft werden. Jedes Deployment kann immer nur eine aktive Filterkonfiguration gleichzeitig haben.

Content Safety Studio

Es gibt außerdem das Content Safety Studio, in dem du einem ähnlichen Ablauf folgen kannst, um das Codebeispiel zu generieren.

Override auf Request-Ebene

Microsoft Foundry unterstützt einen x-policy-id Request-Header, um auf Ebene des API-Aufrufs einen eigenen Inhaltsfilter anzugeben und die Deployment-Konfiguration zu überschreiben. Nicht verfügbar für Bildeingabe-Szenarien (Chat mit Bildern).

Integration mit Azure OpenAI Modellen – API-Verhalten

Wie sich die Filterung in API-Antworten zeigt

Wenn ein Prompt gefiltert wird (schädliche Eingabe erkannt): Liefert einen HTTP-400-Fehler mit Fehlercode content_filter und Fehlerparameter prompt.

Wenn eine Antwort gefiltert wird (schädliche Ausgabe erkannt): Der finish_reason der Antwort wird auf content_filter gesetzt. Im Non-Streaming-Modus wird kein Inhalt zurückgegeben. Im Streaming-Modus wird der Inhalt gestreamt, bis das gefilterte Segment erkannt wird.

Wenn das Inhaltsfiltersystem ausgefallen ist: Der Request wird ohne Filterung abgeschlossen, und Fehlerinformationen erscheinen im content_filter_results-Objekt.

Standardantworten enthalten ein content_filter_results-Objekt mit Annotationen pro Kategorie, die die Schweregrad-Scores anzeigen.

Integration mit Azure API Management

Das Policy-Element llm-content-safety (GA seit April 2025) ermöglicht die Durchsetzung von Content Safety auf Ebene des API-Gateways:

<llm-content-safety backend-id="name" shield-prompt="true" enforce-on-completions="true">
  <categories output-type="FourSeverityLevels">
    <category name="Hate" threshold="4" />
    <category name="Violence" threshold="4" />
  </categories>
  <blocklists>
    <id>blocklist-identifier</id>
  </blocklists>
</llm-content-safety>

Liefert HTTP 403, wenn Content Safety schädliche Inhalte erkennt. Dies ermöglicht eine zentralisierte Durchsetzung von Content Safety über mehrere KI-Endpunkte hinweg.

Performance-Überlegungen

• Synchroner Modus (Standard): Filter laufen sequenziell – fügt 100–300 ms Latenz pro Request hinzu
• Asynchroner Modus: Filter laufen parallel, während die LLM-Antwort gestreamt wird, was die Latenz deutlich reduziert. Empfohlen für produktive Streaming-Anwendungen.

Enterprise-Best-Practices und Praxisleitfaden

Empfehlungen für Schweregrad-Schwellenwerte nach Szenario

Kundenorientierte Chatbots (B2C): Beginne mit dem Standard-Schwellenwert Medium. Aktiviere Prompt Shields im Block-Modus. Aktiviere Protected Material und die Groundedness-Erkennung. Füge eigene Blocklists für markenspezifische Begriffe hinzu.

Interne Enterprise-Tools (B2B): Erwäge den Schwellenwert Low – blockiere nur die schwerwiegendsten Inhalte. Fachinhalte (Engineering-, medizinische, juristische Terminologie) lösen bei niedrigeren Schwellenwerten häufig False Positives aus. Praktiker bei Pondhouse Data dokumentierten Fälle, in denen Engineering-Inhalte über „database killing“ als Selbstverletzung blockiert wurden und elektrotechnische Richtlinien Self-Harm-Filter auslösten.

Plattformen für Kinder/Bildung: Setze die Schwellenwerte auf High – maximale Einschränkung. Aktiviere alle Sicherheitsfunktionen. Setze eigene Blocklists konsequent ein.

Healthcare-Anwendungen: Beginne mit Medium und kalibriere. Medizinische Terminologie löst routinemäßig Self-Harm- und Violence-Filter aus. Nutze eigene Kategorien für domänenspezifische Anliegen. Implementiere eine menschliche Prüfung für Grenzfälle.

Zentrale Fallstricke, die du vermeiden solltest

1. Zu aggressive Standardfilterung – Teste mit domänenspezifischen Daten vor dem Produktivbetrieb. Engineering-, medizinische und juristische Inhalte lösen beim Medium-Schwellenwert False Positives aus.
2. Latenzauswirkungen ignorieren – Synchrone Filterung fügt 100–300 ms hinzu. Nutze im Produktivbetrieb den asynchronen Streaming-Modus.
3. Prompt Shields auslassen – Prompt Injection ist die LLM-Bedrohung Nr. 1 laut OWASP. Selbst Konfigurationen mit minimaler Filterung sollten Prompt Shields aktiviert lassen (sehr niedrige False-Positive-Rate).
4. Statische „Set and forget“-Konfiguration – Überwache Blockraten, Kategorienverteilungen und False Positives kontinuierlich. Passe Schwellenwerte und Blocklists regelmäßig an.
5. Keine Eskalation an menschliche Prüfung – Automatisierte Moderation allein frustriert Nutzer, wenn legitime Inhalte blockiert werden. Baue Einspruchsmechanismen und Human-in-the-Loop-Prüfung auf.
6. Dieselben Filter für Eingabe und Ausgabe – Konfiguriere Eingabe- und Ausgabefilter getrennt. Eingabefilter sollten sich auf Prompt Injection konzentrieren; Ausgabefilter auf schädliche Generierung, Groundedness und Urheberrecht.
7. Unzureichendes Logging – Protokolliere alle Content-Safety-Ereignisse mit vollständigen Metadaten für Compliance-Audits und die Verbesserung des Systems. Integriere Azure Monitor und Microsoft Purview.

Datenschutz und Compliance

• Keine Datenspeicherung: Eingabetexte/-bilder werden während der Erkennung nicht gespeichert (außer Kunden-Blocklists)
• Kein Training mit Nutzerdaten: Nutzereingaben werden niemals zum Training der Content-Safety-Modelle verwendet
• Regionale Datenresidenz: Die gesamte Verarbeitung bleibt innerhalb der gewählten Azure-Region

Preise und technische Spezifikationen

• Preisstufen: F0 (kostenlos) und S0 (Standard) für den eigenständigen Dienst
• Rate Limits: Standardmäßig 1.000 Requests pro 10 Sekunden (modellabhängig)
• Eingabelimit für Textmoderation: 10K Zeichen pro Übermittlung; Standardminimum von 110 Zeichen für das Scannen von LLM-Antworten
• Sprachunterstützung: Die zentralen Schadenskategorien sind auf 8 Sprachen trainiert und funktionieren in 100+ Sprachen mit unterschiedlicher Qualität. Protected Material, Groundedness und Custom Categories (Standard) sind nur auf Englisch verfügbar.
• SDKs: C# (NuGet), Python (PyPI), Java (Maven), JavaScript (npm)

Codebeispiel für den eigenständigen Dienst

#
# Copyright (c) Microsoft. All rights reserved.
# To learn more, please visit the documentation - Quickstart: Azure Content Safety: https://aka.ms/acsstudiodoc
#

import enum
import json
import requests
from typing import Union


class MediaType(enum.Enum):
    Text = 1
    Image = 2


class Category(enum.Enum):
    Hate = 1
    SelfHarm = 2
    Sexual = 3
    Violence = 4


class Action(enum.Enum):
    Accept = 1
    Reject = 2


class DetectionError(Exception):
    def __init__(self, code: str, message: str) -> None:
        """
        Exception raised when there is an error in detecting the content.

        Args:
        - code (str): The error code.
        - message (str): The error message.
        """
        self.code = code
        self.message = message

    def __repr__(self) -> str:
        return f"DetectionError(code={self.code}, message={self.message})"


class Decision(object):
    def __init__(
        self, suggested_action: Action, action_by_category: dict[Category, Action]
    ) -> None:
        """
        Represents the decision made by the content moderation system.

        Args:
        - suggested_action (Action): The suggested action to take.
        - action_by_category (dict[Category, Action]): The action to take for each category.
        """
        self.suggested_action = suggested_action
        self.action_by_category = action_by_category


class ContentSafety(object):
    def __init__(self, endpoint: str, subscription_key: str, api_version: str) -> None:
        """
        Creates a new ContentSafety instance.

        Args:
        - endpoint (str): The endpoint URL for the Content Safety API.
        - subscription_key (str): The subscription key for the Content Safety API.
        - api_version (str): The version of the Content Safety API to use.
        """
        self.endpoint = endpoint
        self.subscription_key = subscription_key
        self.api_version = api_version

    def build_url(self, media_type: MediaType) -> str:
        """
        Builds the URL for the Content Safety API based on the media type.

        Args:
        - media_type (MediaType): The type of media to analyze.

        Returns:
        - str: The URL for the Content Safety API.
        """
        if media_type == MediaType.Text:
            return f"{self.endpoint}/contentsafety/text:analyze?api-version={self.api_version}"
        elif media_type == MediaType.Image:
            return f"{self.endpoint}/contentsafety/image:analyze?api-version={self.api_version}"
        else:
            raise ValueError(f"Invalid Media Type {media_type}")

    def build_headers(self) -> dict[str, str]:
        """
        Builds the headers for the Content Safety API request.

        Returns:
        - dict[str, str]: The headers for the Content Safety API request.
        """
        return {
            "Ocp-Apim-Subscription-Key": self.subscription_key,
            "Content-Type": "application/json",
        }

    def build_request_body(
        self,
        media_type: MediaType,
        content: str,
        blocklists: list[str],
    ) -> dict:
        """
        Builds the request body for the Content Safety API request.

        Args:
        - media_type (MediaType): The type of media to analyze.
        - content (str): The content to analyze.
        - blocklists (list[str]): The blocklists to use for text analysis.

        Returns:
        - dict: The request body for the Content Safety API request.
        """
        if media_type == MediaType.Text:
            return {
                "text": content,
                "blocklistNames": blocklists,
            }
        elif media_type == MediaType.Image:
            return {"image": {"content": content}}
        else:
            raise ValueError(f"Invalid Media Type {media_type}")

    def detect(
        self,
        media_type: MediaType,
        content: str,
        blocklists: list[str] = [],
    ) -> dict:
        """
        Detects unsafe content using the Content Safety API.

        Args:
        - media_type (MediaType): The type of media to analyze.
        - content (str): The content to analyze.
        - blocklists (list[str]): The blocklists to use for text analysis.

        Returns:
        - dict: The response from the Content Safety API.
        """
        url = self.build_url(media_type)
        headers = self.build_headers()
        request_body = self.build_request_body(media_type, content, blocklists)
        payload = json.dumps(request_body)

        response = requests.post(url, headers=headers, data=payload)
        print(response.status_code)
        print(response.headers)
        print(response.text)

        res_content = response.json()

        if response.status_code != 200:
            raise DetectionError(
                res_content["error"]["code"], res_content["error"]["message"]
            )

        return res_content

    def get_detect_result_by_category(
        self, category: Category, detect_result: dict
    ) -> Union[int, None]:
        """
        Gets the detection result for the given category from the Content Safety API response.

        Args:
        - category (Category): The category to get the detection result for.
        - detect_result (dict): The Content Safety API response.

        Returns:
        - Union[int, None]: The detection result for the given category, or None if it is not found.
        """
        category_res = detect_result.get("categoriesAnalysis", None)
        for res in category_res:
            if category.name == res.get("category", None):
                return res
        raise ValueError(f"Invalid Category {category}")

    def make_decision(
        self,
        detection_result: dict,
        reject_thresholds: dict[Category, int],
    ) -> Decision:
        """
        Makes a decision based on the Content Safety API response and the specified reject thresholds.
        Users can customize their decision-making method.

        Args:
        - detection_result (dict): The Content Safety API response.
        - reject_thresholds (dict[Category, int]): The reject thresholds for each category.

        Returns:
        - Decision: The decision based on the Content Safety API response and the specified reject thresholds.
        """
        action_result = {}
        final_action = Action.Accept
        for category, threshold in reject_thresholds.items():
            if threshold not in (-1, 0, 2, 4, 6):
                raise ValueError("RejectThreshold can only be in (-1, 0, 2, 4, 6)")

            cate_detect_res = self.get_detect_result_by_category(
                category, detection_result
            )
            if cate_detect_res is None or "severity" not in cate_detect_res:
                raise ValueError(f"Can not find detection result for {category}")

            severity = cate_detect_res["severity"]
            action = (
                Action.Reject
                if threshold != -1 and severity >= threshold
                else Action.Accept
            )
            action_result[category] = action
            if action.value > final_action.value:
                final_action = action

        if (
            "blocklistsMatch" in detection_result
            and detection_result["blocklistsMatch"]
            and len(detection_result["blocklistsMatch"]) > 0
        ):
            final_action = Action.Reject

        print(final_action.name)
        print(action_result)

        return Decision(final_action, action_result)


if __name__ == "__main__":

    # Replace the placeholders with your own values
    endpoint = "<endpoint>"
    subscription_key = "<subscription_key>"
    api_version = "2024-09-01"

    # Initialize the ContentSafety object
    content_safety = ContentSafety(endpoint, subscription_key, api_version)

    # Set the media type and blocklists
    media_type = MediaType.Text
    blocklists = []

    # Set the content to be tested
    content = "<test_content>"

    # Detect content safety
    detection_result = content_safety.detect(media_type, content, blocklists)

    # Set the reject thresholds for each category
    reject_thresholds = {
        Category.Hate: 4,
        Category.SelfHarm: 4,
        Category.Sexual: 4,
        Category.Violence: 4,
    }

    # Make a decision based on the detection result and reject thresholds
    decision_result = content_safety.make_decision(detection_result, reject_thresholds)