Créez et associez une politique de service

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs de compte peuvent contrôler l'accès à cette fonctionnalité depuis la page Aperçus de la console de compte. Consultez Gérer les aperçus Databricks.

Pour un aperçu des politiques de service, voir politiques de service pour les éléments sécurisables d'IA.

Vous créez une politique de service et l’attachez à un service MCP, un service de modèle ou un service de fournisseur de modèle via l’interface utilisateur de Unity Gateway . La politique régit chaque interaction à deux points d’évaluation :

La phase d’entrée (ON CALL) avant que Databricks n’appelle le service.
La phase de sortie (ON RESULT) après la réponse du service.

Choisissez un type de politique

Type de politique	Utilisation	Ce que vous fournissez
Garde-fou intégré	Risques courants, tels que les contenus dangereux, les tentatives de jailbreak, les hallucinations et les données sensibles.	Rien. Vous sélectionnez le garde-fou et l'associez.
LLM-as-a-judge personnalisé	Semantic rules that you can describe in plain language, such as keeping an assistant on topic.	Une invite qui décrit les éléments à signaler.
Fonction SQL personnalisée	Les règles déterministes, telles que les vérifications des noms d'outils, des arguments d'outils ou de l'identité de l'appelant, ainsi que la mise en attente d'un appel pour approbation humaine (`ASK`).	Une fonction définie par l'utilisateur (UDF) SQL enregistrée dans Unity Catalog.
Externe	Application des décisions d’un fournisseur tiers de garde-fous que vous utilisez déjà.	Une connexion HTTP Unity Catalog vers l’endpoint du fournisseur.

Type de politique	Utilisation	Ce que vous fournissez
Garde-fou intégré	Risques courants, tels que les contenus dangereux, les tentatives de jailbreak, les hallucinations et les données sensibles.	Rien. Vous sélectionnez le garde-fou et l'associez.
LLM-as-a-judge personnalisé	Semantic rules that you can describe in plain language, such as keeping an assistant on topic.	Une invite qui décrit les éléments à signaler.
Fonction SQL personnalisée	Les règles déterministes, telles que les vérifications des noms d'outils, des arguments d'outils ou de l'identité de l'appelant, ainsi que la mise en attente d'un appel pour approbation humaine (`ASK`).	Une fonction définie par l'utilisateur (UDF) SQL enregistrée dans Unity Catalog.
Externe	Application des décisions d’un fournisseur tiers de garde-fous que vous utilisez déjà.	Une connexion HTTP Unity Catalog vers l’endpoint du fournisseur.

Start avec un garde-fou intégré lorsqu'il couvre votre risque. Pour une règle qu'aucun élément intégré ne couvre, utilisez une politique LLM en tant que juge personnalisée, ou une fonction SQL lorsque la règle doit être déterministe ou dépend de l'appelant.

Vous pouvez associer plusieurs politiques à un service. Chaque association a une priorité (rang), et un DENY à un certain rang arrête l'évaluation de tous les rangs suivants. Lors de la phase d'entrée, les rangs sont évalués par ordre croissant (du plus bas au plus haut). Lors de la phase de sortie, ils sont évalués dans l'ordre inverse. Les politiques ayant le même rang peuvent toutes s'exécuter même après qu'l'une d'entre elles a refusé. Voir Ordre d'évaluation.

Prérequis

Un administrateur de compte doit activer la version bêta pour votre compte à partir de la page **Previews** dans la console du compte.
Pour attacher une politique à un service : MANAGE sur l'élément sécurisable du service cible.
Pour un garde-fou intégré ou une politique LLM-as-a-judge personnalisée avec un évaluateur autre que default : EXECUTE sur le service de modèle d’évaluateur que vous choisissez, ainsi que USE CATALOG et USE SCHEMA sur son catalogue et son schéma. See Grant access to a model service.
Pour une politique SQL personnalisée : privilège CREATE FUNCTION sur le schéma cible pour créer la fonction de politique, et EXECUTE sur la fonction de politique pour l’associer.
Pour une politique de service externe : USE CONNECTION sur la connexion HTTP Unity Catalog. Consultez Avant de commencer.

remarque

Si un libellé diffère de ces étapes, suivez les libellés présents dans le produit. Une politique s’applique à tous les utilisateurs du compte sur le service ; par conséquent, laissez Appliqué à défini sur Tous les utilisateurs du compte .

Associer une politique intégrée

Databricks fournit des stratégies de service intégrées sous l'espace de noms system.ai, telles que system.ai.block_unsafe_content pour bloquer les contenus dangereux ou nuisibles. Elles couvrent les risques courants sans nécessiter de code. Pour obtenir la liste complète des stratégies intégrées et une remarque sur la façon dont elles apparaissent dans Unity Catalog, consultez la page Stratégies de service intégrées.

Les étapes suivantes permettent d'associer le mécanisme de contrôle Unsafe Content à un service :

Dans la barre latérale du workspace, cliquez sur AI Gateway .
Sélectionnez le service à gouverner : un service de modèle sur la tab Models , un service de fournisseur de modèles sur la tab Providers , ou un service MCP sur la tab MCPs .
Ouvrez l'onglet Politiques , puis cliquez sur Nouvelle politique .
Saisissez un nom pour la politique, tel que block_unsafe_content.
Dans Guardrail type , sélectionnez un garde-fou intégré, tel que Unsafe Content ou Jailbreak .
Définissez le rang pour contrôler l'ordre d'évaluation. Le rang le plus bas s'exécute en premier sur la requête et en dernier sur la réponse.
Sous Phase , sélectionnez l'emplacement d'exécution de la règle : Garde-fous d'entrée (ON CALL, avant l'appel du service), Garde-fous de sortie (ON RESULT, après sa réponse), ou les deux. Certains garde-fous intégrés ne fonctionnent que dans une seule phase, telle que la détection de « jailbreak » sur l'entrée et la détection d'hallucination sur la sortie.
(Facultatif) Dans un service de modèle ou un service de fournisseur de modèles, définissez la fenêtre de conversation : le nombre de tours de conversation récents que le juge évalue pour la requête. La valeur est définie par default sur 10 tours. Définissez-le sur 1 pour évaluer uniquement le dernier message ou sélectionnez Évaluer l’intégralité de la conversation .
(Optionnel) Développez Advanced options . Le service de modèle d’évaluateur qui exécute la vérification (le juge LLM) est préselectionné. Pour en utiliser un autre, sélectionnez-le ici. Vous avez besoin de EXECUTE sur le service de modèle que vous choisissez, ainsi que de USE CATALOG et de USE SCHEMA sur son catalogue et son schéma. Pour enregistrer les verdicts sans blocage, définissez Mode sur Log .
Cliquez sur Créer une politique .

La politique apparaît sur le tab Policies du service. Prévoyez un court délai pour sa propagation avant de procéder à un test.

Les garde-fous intégrés ne nécessitent aucune configuration spécifique à une politique. Vous configurez uniquement les champs standard Phase , Rank , Evaluator model service et Mode . Le garde-fou déterministe de détection des données sensibles constitue l’exception : il prend également en compte les étiquettes de classification et une action. Consultez Detect sensitive data with a service policy.

Créer une politique LLM-as-a-judge

Une politique personnalisée d'évaluation par LLM (LLM-as-a-judge) utilise un modèle d'évaluation pour classer une requête ou une réponse par rapport à des critères que vous décrivez en langage naturel. Utilisez-le pour des vérifications sémantiques qu'une règle déterministe ne peut pas exprimer, par exemple si un message est pertinent ou si une réponse reste professionnelle. Vous rédigez les critères sous forme de prompt, et non de code.

Les étapes suivantes permettent d'associer une politique qui permet de maintenir un assistant de support sur le sujet :

Dans la barre latérale du workspace, cliquez sur AI Gateway .
Sélectionnez le service à gouverner : un service de modèle sur la tab Models , un service de fournisseur de modèles sur la tab Providers , ou un service MCP sur la tab MCPs .
Ouvrez l'onglet Politiques , puis cliquez sur Nouvelle politique .
Saisissez un nom pour la politique, tel que keep_on_topic.
Dans Type de garde-fou , sélectionnez Personnalisé .
Définissez le rang pour contrôler l'ordre d'évaluation. Le rang le plus bas s'exécute en premier sur la requête et en dernier sur la réponse.
Sous Implementation , sélectionnez LLM-as-a-judge .
Sous Phase , sélectionnez l’endroit où la politique s’exécute : Garde-fous d’entrée (ON CALL, avant l’appel du service), Garde-fous de sortie (ON RESULT, après sa réponse), ou les deux. Une vérification de sujet comme celle-ci s’exécute sur l’entrée.
Sélectionnez un service de modèle d’évaluation . Vous avez besoin de EXECUTE sur le service de modèle que vous choisissez, ainsi que de USE CATALOG et de USE SCHEMA sur son catalogue et son schéma.
Dans Prompt , décrivez ce que l’évaluateur doit signaler et ce qu’il doit ignorer. Par exemple :

Vous examinez les messages envoyés à un assistant de support client qui ne peut aider qu’en ce qui concerne les produits, les commandes, la facturation et le support de compte de l’entreprise. Signalez le message s’il demande quelque chose qui sort de ce cadre, comme une aide générale à la codification, la rédaction d’essais, des anecdotes sans rapport, ou l’utilisation de l’assistant comme un robot conversationnel polyvalent. Ne signalez pas une véritable question sur un produit ou le support.

N’écrivez pas ALLOW ou DENY dans l’invite, et ne spécifiez pas de format de sortie. Databricks ajoute un contrat de sortie structurée à votre invite, de sorte que l’évaluateur renvoie un verdict au format JSON. Lorsque l’évaluateur signale le contenu, Databricks bloque l’interaction.
(Facultatif) Dans un service de modèle ou de fournisseur de modèles, définissez la fenêtre de conversation : le nombre de tours de conversation récents que le juge évalue dans la requête. Par default, elle est définie sur 10 tours. Définissez-le sur 1 pour évaluer uniquement le dernier message ou sélectionnez Évaluer l’intégralité de la conversation . La fenêtre s’applique uniquement à l’évaluation des entrées.
(Facultatif) Développez Advanced options et définissez Mode sur Log pour enregistrer les verdicts sans blocage pendant que vous ajustez le message de guidage.
Cliquez sur Créer une politique .

La politique apparaît sur le tab Policies du service. Prévoyez un court délai pour sa propagation avant de procéder à un test.

L’évaluateur est un modèle, ses verdicts ne sont donc pas déterministes. Databricks recommande de commencer en mode Log et d’examiner les verdicts potentiels dans la table des traces unifiée. Consultez Non-déterminisme et tests de simulation. Pour en savoir plus sur les invites, les bonnes pratiques pour les rédiger et des exemples multi-tours, consultez les exemples de politiques LLM-as-a-judge.

Create a SQL policy

Une politique SQL personnalisée est une fonction SQL qui renvoie une décision. Utilisez-le lorsque la règle doit être déterministe, lorsqu’elle dépend du nom ou des arguments d’un outil ou de la personne qui effectue l’appel, ou lorsqu’elle doit suspendre un appel en attendant une approbation humaine (ASK).

Étape 1 : Rédigez la fonction de stratégie

Une fonction de politique de service est une UDF SQL enregistrée dans Unity Catalog. Il prend un unique paramètre VARIANT, event (les données d'interaction et le contexte), et renvoie un résultat VARIANT :

SQL
CREATE OR REPLACE FUNCTION <catalog>.<schema>.<function_name>(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN <expression>;

La fonction s’exécute aux deux points d’évaluation ; effectuez un branch sur event:type::string ('request' pour la phase d’entrée, 'response' pour la phase de sortie) pour agir sur une seule phase. Pour obtenir la liste complète des champs event, la valeur de retour et le sous-ensemble SQL pris en charge, consultez la référence des fonctions de politique de service.

La fonction renvoie une décision : un VARIANT avec un champ result valant ALLOW, DENY ou ASK et un reason facultatif. Construisez le résultat avec named_struct et enveloppez-le dans to_variant_object afin que la fonction renvoie un VARIANT, tout en conservant result et reason en tant que champs de premier niveau.

La valeur result détermine ce qui se passe (elle est insensible à la casse) :

ALLOW: l’interaction se déroule.
DENY: Databricks bloque l’interaction. Au lieu d’une erreur, l’appelant reçoit une réponse réussie (HTTP 200) dont le tour de l’assistant signale le bloc, avec le reason dans un objet databricks_service_policy de niveau supérieur.
ASK: sur un service MCP, la requête s'interrompt pour demander l'approbation de l'utilisateur avant l'exécution de l'outil. Si une politique SQL ou Python personnalisée renvoie ASK pour un service de modèle ou un service de fournisseur de modèle, Databricks bloque la requête ou la réponse, car ces services ne peuvent pas demander l'approbation de l'utilisateur.

Exemple : refuser un envoi GitHub lorsqu’un agent agit au nom d’un utilisateur

Pour supprimer un outil pour l’ensemble des appelants, utilisez la sélection d’outils plutôt qu’une politique de service. Une politique de service est utile lorsque la décision dépend de l’appelant. Cette politique permet aux utilisateurs d’appeler directement l’outil push_files, mais l’interdit lorsqu’un agent ou une application l’appelle au nom d’un utilisateur (on-behalf-of, ou OBO), tel que rapporté par event:context.actor.context.is_on_behalf_of:

SQL
CREATE OR REPLACE FUNCTION main.governance.block_agent_github_push(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND event:context.tool.name::string = 'push_files'
      AND event:context.actor.context.is_on_behalf_of::boolean = true
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Agents cannot push to GitHub on behalf of a user. Push the change yourself.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Pour autoriser des agents spécifiques au lieu de tous les bloquer, vérifiez l’ID client OAuth de l’agent. Consultez Restreindre un outil sensible aux agents approuvés. Pour obtenir la liste complète des champs d’acteur, consultez Service policy function reference.

Exemple : exiger une approbation humaine avant l'exécution d'un outil destructeur.

Cette politique met en pause tout appel à l'outil delete_repository pour approbation humaine et autorise toutes les autres interactions.

SQL
CREATE OR REPLACE FUNCTION main.governance.ask_before_repo_delete(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:context.tool.name::string = 'delete_repository'
    THEN to_variant_object(named_struct('result', 'ASK', 'reason', 'Deleting a repository requires human approval.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Lorsque cette politique renvoie DEMANDER, Databricks met en pause l'appel pour approbation humaine avant son exécution.

Pour les agents externes qui appellent les services MCP, Databricks délivre la décision d'approbation en utilisant l'élicitation en mode URL MCP: l'utilisateur ouvre l'URL fournie pour approuver ou refuser l'appel. L'agent externe doit relancer l'appel après approbation. Pour utiliser ASK avec un agent externe, le client MCP de l’agent doit prendre en charge la version 2025-11-25 du protocole MCP ou une version ultérieure.

Pour les services MCP, l'approbation d'un appel d'outil met en cache l'approbation pendant une heure, afin qu'un appel identique ne soit pas de nouveau sollicité dans ce délai.

ASK l'approbation n'est disponible que pour les services MCP pendant la phase d'entrée. Si une politique SQL ou Python personnalisée renvoie ASK pour un service de modèle ou un service de fournisseur de modèle, Databricks bloque la demande ou la réponse, car ces services ne peuvent pas demander l'approbation de l'utilisateur.

Pour en savoir plus sur les politiques personnalisées, y compris les listes d'autorisation d'outils, le blocage de mots clés et de thèmes, les limites de longueur de requête et les contrôles de réponse, consultez Service policy examples.

Étape 2 : associer la fonction à un service

Dans la barre latérale du workspace, cliquez sur AI Gateway .
Sélectionnez le service à gouverner : un service de modèle sur la tab Models , un service de fournisseur de modèles sur la tab Providers , ou un service MCP sur la tab MCPs .
Ouvrez l'onglet Politiques , puis cliquez sur Nouvelle politique .
Saisissez un **Nom** pour la politique.
Dans Type de garde-fou , sélectionnez Personnalisé .
Définissez le rang pour contrôler l'ordre d'évaluation. Le rang le plus bas s'exécute en premier sur la requête et en dernier sur la réponse.
Sous Implementation , sélectionnez Custom function , puis cliquez sur Select function et sélectionnez la fonction SQL que vous avez écrite à l’étape 1.
Cliquez sur Créer une politique .

Une fonction SQL personnalisée ne comporte aucun paramètre Phase : elle s'exécute lors des deux phases. Vous devez donc créer une Branch sur event:type dans le corps de la fonction pour cibler son comportement (voir l'étape 1). La politique apparaît sous le tab Politiques du service. Veuillez patienter un moment pour laisser le temps à la propagation avant d'effectuer un test.

Associer une politique de service externe

Une politique de service externe envoie le contenu évalué à un fournisseur de garde-fous tiers et applique le verdict ALLOW ou DENY du fournisseur. Pour en utiliser un, ouvrez le tab Policies du service et cliquez sur New policy , puis choisissez External dans Guardrail type et sélectionnez ou créez la connexion HTTP Unity Catalog vers l'Endpoint de votre fournisseur. Définissez les champs Phase , Rank , Policy configuration (facultatif) et Mode comme pour n'importe quelle politique.

Vous avez besoin de MANAGE sur le service cible et de USE CONNECTION sur la connexion. Vous n’avez pas besoin d’une fonction de politique. Pour la configuration complète, y compris les champs de connexion, le contenu envoyé au fournisseur et le comportement d'arrêt de sécurité en cas de défaillance (fail-closed), consultez la section Appliquer une règle de garde-fou de partenaire avec une politique de service externe.

Vérifier la politique

Après avoir associé une stratégie, vérifiez qu'elle est active et qu'elle produit les résultats attendus.

remarque

Après avoir joint ou modifié une politique, patientez un court instant pour que la modification prenne effet avant d’effectuer des tests. Les modifications de politique prennent généralement une minute ou deux à se propager.

Confirmer le rattachement

Dans Unity Gateway, ouvrez le service cible et affichez les politiques qui lui sont associées. La politique que vous avez créée apparaît dans la liste.

Observez les résultats de la politique

Vous pouvez confirmer qu'une politique prend effet :

De l'appelant : lorsque la politique renvoie DENY, l'appelant reçoit une réponse réussie (HTTP 200) plutôt qu'une erreur. Le tour de l'assistant indique que le contenu a été bloqué, et un objet databricks_service_policy de haut niveau contient le reason que vous avez spécifié. ASK met l'appel en pause pour une approbation humaine.
Dans la table des traces unifiée : la table des traces unifiée enregistre chaque requête effectuée sur l’ensemble de vos services Unity Gateway, avec un événement policy_evaluated pour chaque politique et phase exécutée, incluant l’action effectuée. Consultez la page Événements d’évaluation de politique.
Dans les tables système : l'activité des modèles et du protocole MCP est enregistrée dans les tables d'utilisation, et, pour un service doté d'une table d'inférence, les charges utiles complètes des requêtes et des réponses sont consignées dans sa table d'inférence.

Déboguer et auditer une décision de politique

Lorsqu’une politique bloque une interaction, le bloc reason dans l’objet databricks_service_policy nomme la politique et fournit une brève explication. Voir Observer les résultats de la politique.

Pour savoir quelles politiques ont été exécutées sur une requête et quelle a été la décision de chacune, start par consulter le tableau de traces unifié. Un administrateur de métastore le configure une seule fois pour tous les services Unity Gateway, et la portée (span) de chaque requête transporte un événement policy_evaluated pour chaque politique et phase exécutée, incluant le nom, le type et l'action de la politique. For a policy in Log mode, the event also records the would-be verdict in policy.dry_run_action and policy.dry_run_reason. Consultez les événements d’évaluation de politique.

L’enregistrement de trace consigne l’action de chaque politique LLM-as-judge, mais pas le raisonnement de l’évaluateur. Pour consulter le raisonnement complet derrière une décision LLM-as-judge intégrée ou personnalisée, y compris la confiance de l’évaluateur et le contenu exact évalué, examinez la table d’inférence du service de modèle de l’évaluateur.

Une politique LLM-as-a-judge exécute son prompt sur un service de modèle d’évaluateur distinct (le juge). Le verdict du juge n’est pas enregistré dans la table d’inférence du service protégé, qui ne Logs que la propre requête et réponse du service protégé. L’entrée et le verdict du juge ne sont capturés que lorsqu’une table d’inférence est activée sur le service de modèle évaluateur .

Capturer les verdicts de l’évaluateur

Activez une table d’inférence sur le service de modèle qui exécute la vérification. Vous avez deux options :

Activer une table d’inférence directement sur l’évaluateur déjà utilisé par la barrière de sécurité. L’évaluateur « default » est un service de modèle system.ai, et vous pouvez y activer une table d’inférence.
Sous Options avancées , lorsque vous attachez la politique, pointez le garde-fou vers un service de modèle d’évaluation que vous possédez (il ne doit pas nécessairement s’agir d’un modèle system.ai), puis activez une table d’inférence sur ce service.

Pour activer une table d’inférence, consultez Logs les requêtes et les réponses dans des tables d’inférence. Activez-la avant les interactions que vous souhaitez auditer : seules les évaluations exécutées après l’activation des Logs sont capturées, et les lignes peuvent mettre quelques minutes à apparaître.

Lire un verdict

Chaque évaluation écrit une ligne par politique et par phase dans la table d’inférence de l’évaluateur :

request est le prompt de juge assemblé : les critères de la politique, le contrat de sortie JSON et le contenu en cours d’évaluation enveloppé dans des marqueurs <ContentToEvaluate>. Pour une politique d’entrée multi-tours (fenêtre de conversation), le contenu évalué correspond aux tours récents ainsi qu’à la dernière entrée ; sinon, il s’agit du message unique.
response est la complétion brute de l’évaluateur. Le verdict est le contenu du message de l’assistant : un objet JSON avec flagged, confidence et, lorsque flagged est true, reason.
destination_name identifie l’évaluateur, et request_id lie l’évaluation à l’interaction qui l’a déclenchée.

Pour trouver les évaluations où le juge a signalé du contenu, filtrez la table d’inférence de l’évaluateur sur le verdict :

SQL
SELECT
  event_time,
  request_id,
  get_json_object(response, '$.choices[0].message.content') AS verdict,
  request
FROM <catalog>.<schema>.<evaluator_inference_table>
WHERE get_json_object(response, '$.choices[0].message.content') ILIKE '%"flagged":true%'
ORDER BY event_time DESC;

La colonne verdict indique la décision de l’évaluateur, telle que {"flagged":true,"confidence":0.87,"reason":"..."}. Un élément reason apparaît uniquement lorsque flagged est true. Un verdict signalé correspond à la décision du juge, et non à la preuve que l’interaction a été bloquée. En mode Log , un éventuel DENY est enregistré ici mais n’est pas appliqué, et la table n’enregistre pas le mode. Veuillez donc confirmer un blocage effectif à partir de la réponse databricks_service_policy de l’appelant (voir Observer les résultats de la politique). Pour retracer une interaction spécifique à la place, filtrez par son request_id.

remarque

Auditez les blocages à partir de la table d’inférence de l’évaluateur, et non de celle du service protégé. Lorsqu’une politique de phase d’entrée refuse une requête, Databricks n’invoque pas le service sous-jacent ; par conséquent, une interaction bloquée peut ne pas produire de ligne dans la table d’inférence du service protégé. L’extraction des ID de requête à partir de la table protégée omet donc les interactions bloquées ; filtrez plutôt la table de l’évaluateur sur le verdict.

Restreindre à une interaction dans une grande table

La table d’inférence de l’évaluateur ne possède pas de colonne de nom de politique, et le id dans le corps de la réponse (chatcmpl-...) n’est pas le request_id. Restreignez la recherche à l’interaction que vous êtes en train de debugging à l’aide de ces filtres, et limitez l’analyse par période :

request_id (le plus précis) : chaque évaluation pour une interaction le partage. Capturez-le à partir de l’en-tête de réponse databricks-request-id de l’appel, puis filtrez WHERE request_id = '<id>'. Cela fonctionne pour un bloc. Confirmez que la valeur de l’en-tête correspond à la colonne, car le champ id du corps de la réponse est une valeur différente.
Contenu de la demande : le request du juge contient le contenu évalué ; ainsi, une chaîne distinctive dans votre prompt permet de pin l’interaction, par exemple request ILIKE '%<your marker>%'.
Temps : event_time >= current_timestamp() - INTERVAL 30 MINUTES limite l’analyse.

Pour savoir quelle politique a produit une ligne, lisez son request. Le message système correspond aux critères de cette politique, ce qui vous permet de filtrer et d’identifier la politique. Par exemple request ILIKE '%<distinctive phrase from the policy prompt>%'. Le reason dans le verdict reformule généralement le Trigger.

SQL
SELECT event_time, request_id, invocation_id,
       get_json_object(response, '$.choices[0].message.content') AS verdict,
       request
FROM <catalog>.<schema>.<evaluator_inference_table>
WHERE event_time >= current_timestamp() - INTERVAL 30 MINUTES
  AND request ILIKE '%<your marker or prompt text>%'
  AND get_json_object(response, '$.choices[0].message.content') ILIKE '%"flagged":true%'
ORDER BY event_time DESC;

Non-déterminisme et tests de simulation

L’évaluateur est un modèle, ses verdicts sont donc non déterministes : la même entrée peut renvoyer des verdicts différents selon les exécutions, et la variation est plus importante entre différents modèles d’évaluateur ou lorsque le routage des requêtes couvre plusieurs versions de modèle. Le reason est un texte libre court, et non des données structurées par entité, et il peut citer le contenu signalé. Pour une vérification répétable et déterministe, utilisez la politique intégrée Sensitive Data Detection ou une politique SQL personnalisée au lieu d’un juge LLM.

Databricks recommande d'associer d'abord une politique LLM-as-a-judge en mode Log , ce qui enregistre le verdict sans le bloquer. Consultez les verdicts potentiels dans la table des traces unifiée et activez une table d'inférence sur l'évaluateur si vous avez également besoin de son niveau de confiance et du contenu évalué. Inspectez les verdicts sur le trafic réel, affinez le prompt et le classement, puis basculez la politique sur Enforce . La détection des données sensibles s'exécute uniquement en mode d'application (enforce).

Droits d’accès

Les étapes ci-dessus nécessitent les privilèges suivants :

Étape	Accès requis
Attachez le garde-fous	`MANAGE` sur le service cible (protégé) et `EXECUTE` sur la fonction de politique que vous joignez. Voir Étape 2.
Sélectionnez un évaluateur non-default	`EXECUTE` on the evaluator model service you choose, plus `USE CATALOG` and `USE SCHEMA` on its catalog and schema. See Grant access to a model service.
Activer un tableau d’inférence sur l’évaluateur	Autorisation de gérer le service de modèle d’évaluation (par exemple, si vous l’avez créé), ainsi que `USE CATALOG`, `USE SCHEMA` et `CREATE TABLE` sur le catalogue et le schéma où la table est stockée. Consultez les prérequis de la table d’inférence.
Lire le tableau d’inférence de l’évaluateur	`SELECT` sur la table, plus `USE CATALOG` et `USE SCHEMA` sur son catalogue et son schéma. Le créateur du service de modèle est propriétaire de la table et accorde l’accès à d’autres personnes.

Étape	Accès requis
Attachez le garde-fous	`MANAGE` sur le service cible (protégé) et `EXECUTE` sur la fonction de politique que vous joignez. Voir Étape 2.
Sélectionnez un évaluateur non-default	`EXECUTE` on the evaluator model service you choose, plus `USE CATALOG` and `USE SCHEMA` on its catalog and schema. See Grant access to a model service.
Activer un tableau d’inférence sur l’évaluateur	Autorisation de gérer le service de modèle d’évaluation (par exemple, si vous l’avez créé), ainsi que `USE CATALOG`, `USE SCHEMA` et `CREATE TABLE` sur le catalogue et le schéma où la table est stockée. Consultez les prérequis de la table d’inférence.
Lire le tableau d’inférence de l’évaluateur	`SELECT` sur la table, plus `USE CATALOG` et `USE SCHEMA` sur son catalogue et son schéma. Le créateur du service de modèle est propriétaire de la table et accorde l’accès à d’autres personnes.

Limitations

Les limitations suivantes s’appliquent :

Transformation : les politiques de service renvoient une décision (ALLOW, DENY ou ASK) et ne modifient pas le contenu de la demande ou de la réponse.
Langage de stratégie : Les fonctions de stratégie personnalisées ne prennent en charge que LANGUAGE SQL.
**Portée de l'attachement** : l'attachement de politique est limité à l'interface utilisateur et à un service individuel, et la politique s'applique à tous les utilisateurs du compte. L'attachement de politiques au niveau du catalogue ou du schéma, les conditions de contrôle d'accès basé sur les attributs (ABAC) et les principaux personnalisés ne sont pas disponibles.

Choisissez un type de politique​

Prérequis​

Associer une politique intégrée​

Créer une politique LLM-as-a-judge​

Create a SQL policy​

Étape 1 : Rédigez la fonction de stratégie​

Étape 2 : associer la fonction à un service​

Associer une politique de service externe​

Vérifier la politique​

Confirmer le rattachement​

Observez les résultats de la politique​

Déboguer et auditer une décision de politique​

Capturer les verdicts de l’évaluateur​

Lire un verdict​

Restreindre à une interaction dans une grande table​

Non-déterminisme et tests de simulation​

Droits d’accès​

Limitations​

Choisissez un type de politique

Prérequis

Associer une politique intégrée

Créer une politique LLM-as-a-judge

Create a SQL policy

Étape 1 : Rédigez la fonction de stratégie

Étape 2 : associer la fonction à un service

Associer une politique de service externe

Vérifier la politique

Confirmer le rattachement

Observez les résultats de la politique

Déboguer et auditer une décision de politique

Capturer les verdicts de l’évaluateur

Lire un verdict

Restreindre à une interaction dans une grande table

Non-déterminisme et tests de simulation

Droits d’accès

Limitations