règles de service pour les objets sécurisables d’IA
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.
Les politiques de service vous permettent de régir le contenu des interactions avec les services d'IA enregistrés dans Unity Catalog — y compris les serveurs MCP externes et les modèles de tout fournisseur, pas seulement ceux hébergés par Databricks. Les octrois Unity Catalog déterminent *si* un principal peut appeler un service. Les politiques de service régissent la façon dont cette interaction se déroule, en fonction du contenu de la demande et de la réponse, et de la personne qui effectue l'appel.
Les politiques de service sont les mécanismes que vous utilisez pour mettre en œuvre des garde-fous pour les services d'IA. Si vous cherchez à ajouter des garde-fous, tels que le blocage des PII, l'injection de prompt ou le contenu dangereux, les politiques de service sont le mécanisme : Databricks dispose de garde-fous intégrés pour les risques courants, et vous pouvez écrire des politiques personnalisées pour les règles spécifiques à votre organisation.
Cela importe le plus lorsque les agents agissent au nom des utilisateurs. Un agent hérite de tout ce à quoi l'utilisateur peut accéder, et les services atteignent souvent des systèmes externes. Les stratégies de service vous permettent de définir des garde-fous pour cette activité. Par exemple, vous pouvez exiger le consentement de l'utilisateur avant qu'un agent ne pousse du code vers un repository Git, refuser une réponse de modèle qui contient des informations personnellement identifiables (PII), ou bloquer du contenu dangereux.
Les politiques de service sont l'un des trois types de politiques de contrôle d'accès basées sur les attributs (ABAC) dans Unity Catalog :
- Les politiques ABAC GRANT accordent des privilèges Unity Catalog sur des éléments sécurisables dont les tags gouvernés correspondent à une condition. Ils déterminent si un principal peut accéder à un objet.
- Row filter and column mask policies contrôlent les lignes et les colonnes qu’un principal peut voir dans une table.
- Les politiques de service régissent le contenu de chaque demande et réponse adressée à un service d'IA, afin de l'autoriser, de la refuser ou de la mettre en attente pour approbation.
Les politiques ABAC GRANT sont des politiques de contrôle d'accès ; les politiques de filtrage de lignes et de masquage de colonnes ainsi que les politiques de service sont des politiques de contenu , qui régissent ce qui se passe une fois qu'un principal a accès. Tout comme un filtre de ligne ou un masque de colonne, une politique de service fait référence à une fonction Unity Catalog qui contient la logique de gouvernance et l'attache à un élément sécurisable.
Comment les politiques de service complètent les octrois de Unity Catalog
Les privilèges et les politiques de service d'Unity Catalog répondent à différentes questions de gouvernance et opèrent à différents points d'application.
Privilèges Unity Catalog | Politiques de service | |
|---|---|---|
Question répondue | Ce principal peut-il appeler ce service ? | Comment cette interaction doit-elle procéder ? |
Entrées | Identité du principal et privilèges accordés | Contenu de la demande, contenu de la réponse, annotations d'outils et contexte de l'acteur |
Point d'application | Avant que la requête n'atteigne le service | Avant que le service ne soit invoqué (phase d'entrée, ON CALL) et après que le service a répondu (phase de sortie, ON RESULT) |
Granularité | Par principal, par sécurisable | Par requête, en fonction du contenu et du contexte |
Les stratégies de service ne remplacent pas les autorisations Unity Catalog. Un principal doit d'abord disposer des privilèges Unity Catalog appropriés pour appeler un service. Les stratégies de service évaluent ensuite le contenu de chaque interaction pour appliquer des règles de gouvernance supplémentaires.
Décisions politiques
Une politique de service évalue le contenu d'une requête ou d'une réponse et renvoie l'un des trois résultats suivants :
- **AUTORISER** : l'interaction se poursuit.
- DENY : la politique bloque l'interaction. Au lieu d'un statut d'erreur, Databricks renvoie une réponse de succès (HTTP 200). Le tour de l'assistant contient un court message nommant la politique de service qui a bloqué, et un objet
databricks_service_policyde haut niveau contient les détails structurés, y compris le blocreason. Le renvoi du bloc en tant que tour normal empêche les clients conversationnels qui renvoient l'historique complet, tels que les agents de codage, de re-trigger le même bloc à chaque tour ultérieur. - ASK : la politique suspend l'interaction pour approbation humaine avant qu'elle ne se poursuive. Cette étape d'approbation permet des workflows avec intervention humaine pour les opérations sensibles. Par exemple, un administrateur peut approuver un appel d'outil MCP destructeur avant son exécution. Pour les agents externes appelant un service MCP, cette invite d'approbation est livrée par l'intermédiaire de la sollicitation d'URL MCP. Consultez Rédiger une politique de décision.
Une politique est une fonction SQL définie par l'utilisateur (UDF) qui reçoit l'événement d'interaction (qui inclut l'acteur et le contenu de la requête ou de la réponse) et renvoie un résultat de décision.
Points d'évaluation
Databricks évalue une politique de service à deux moments dans chaque interaction :
- Entrée (ON CALL) : avant que Databricks n'appelle le service, par rapport à la requête. Utilisez cette phase pour inspecter les requêtes avant qu'elles n'atteignent le service sous-jacent. Par exemple, bloquez une requête qui appelle un outil MCP destructeur, ou refusez une invite contenant des PII avant qu'elle n'atteigne un modèle.
- Sortie (ON RESULT) : après la réponse du service, par rapport à la réponse. Utilisez cette phase pour inspecter les réponses avant qu'elles ne soient renvoyées à l'appelant. Par exemple, bloquez une réponse contenant du contenu hallucinatoire ou des données sensibles.
Une fonction de politique personnalisée s'exécute aux deux points. Elle inspecte la phase actuelle (event:type) et décide de la marche à suivre, de sorte qu'une seule politique peut régir la demande, la réponse, ou les deux. Pour agir sur une seule phase, effectuez un Branch sur event:type dans le corps de la fonction. Les politiques intégrées sont limitées par une option phases, et certaines ne s'exécutent que dans une seule phase (par exemple, la détection de jailbreak ne s'exécute que sur la phase d'entrée et la détection d'hallucination uniquement sur la phase de sortie).
Ordre d'évaluation
Vous pouvez attacher plus d'une politique de service à un service. Chaque pièce jointe possède un rang (priorité), et la chaîne s'arrête au premier DENY. Databricks évalue les politiques par ordre de rang croissant lors de la phase d' entrée (ON CALL, rang le plus bas en premier) et dans l'ordre inverse lors de la phase de sortie (ON RESULT). Utilisez le rang pour contrôler quelles vérifications s'exécutent en premier.
Évaluation au sein d'un rang
Databricks évalue les politiques au même rang en deux étapes :
- Les politiques bloquantes LLM-as-a-judge s'exécutent en parallèle. Ces politiques sont intégrées et bloquent les contenus (
DENY), tels que la détection de contenu dangereux. Comme il s'agit des vérifications basées sur le modèle, les exécuter simultanément signifie que leur latence ajoutée est approximativement celle de l'évaluation unique la plus lente, et non leur somme. - Les politiques restantes s'exécutent ensuite séquentiellement , mais seulement si chaque politique parallèle de la première étape a autorisé l'interaction. Cette étape couvre les politiques SQL personnalisées et les politiques qui nécessitent une approbation (
ASK), évaluées dans l'ordre où vous les avez jointes.
L'évaluation est court-circuitée au premier DENY de l'une ou l'autre des étapes, de sorte que les politiques ultérieures à ce rang et à tous les rangs supérieurs ne s'exécutent pas. Comme Databricks parallélise les vérifications lentes effectuées par les modèles, l'ajout de plusieurs garde-fous bloquants sur un service ne multiplie pas leur latence.
Le diagramme suivant montre où se situent les deux phases autour d'un service et ce que chaque décision fait :
Pour voir les politiques associées à un service spécifique et leur ordre d'exécution, ouvrez le Policies tab du service et cliquez sur See execution flow .
Politiques de service intégrées
Databricks fournit des politiques de service intégrées sous l'espace de nom system.ai. Celles-ci couvrent les scénarios de gouvernance courants sans SQL personnalisé. Les garde-fous IA de Databricks sont des politiques de service intégrées : des politiques préconfigurées et gérées par Databricks (telles que la détection de contenu non sécurisé et de jailbreak) que vous attachez de la même manière qu’une politique personnalisée :
system.ai.block_unsafe_content: refuse les interactions qui contiennent du contenu dangereux ou nuisible.system.ai.block_jailbreak: refuse les requêtes qui tentent de contourner les instructions de sécurité du modèle.system.ai.block_hallucination: refuse les réponses qui contiennent un contenu halluciné.system.ai.detect_sensitive_data: détecte les données sensibles structurées (telles que les numéros de carte de crédit et les numéros de sécurité sociale) et bloque l'interaction ou masque les valeurs correspondantes. Contrairement aux autres, il est déterministe (basé sur des modèles, sans modèle d'évaluation) et peut masquer plutôt que simplement bloquer. Voir Détectez les données sensibles avec une politique de service.
Pour utiliser une stratégie intégrée, attachez-la à un service. Vous devez disposer de MANAGE sur le service cible.
Pendant la version bêta, les politiques intégrées sont gérées par Databricks et n'apparaissent pas en tant que fonctions que vous pouvez parcourir dans le schéma system.ai de l'explorateur de catalogues. Vous les sélectionnez et les attachez par nom via l'interface utilisateur Unity AI Gateway, comme décrit dans Créer et attacher une politique de service.
Fonctionnement des stratégies de service intégrées
Les politiques de service intégrées sont des vérifications LLM-as-a-judge : chacune exécute un prompt organisé par Databricks contre un modèle d'évaluateur pour décider si le contenu enfreint la politique.
Le service de modèle d'évaluation
Chaque stratégie de service intégrée exécute son invite sur un **service de modèle d'évaluateur**, le modèle qui juge le contenu. Databricks présélectionne un évaluateur default, donc aucune configuration n'est requise. Pour utiliser un modèle différent, développez **Options avancées** lorsque vous joignez la stratégie et en sélectionnez un ; vous avez les CAN QUERY sur le modèle que vous choisissez. L'évaluateur est distinct du service que vous protégez, ainsi une stratégie peut juger une requête adressée à un service de modèle en utilisant un modèle différent comme évaluateur.
Databricks gère le prompt de la politique, qui est en lecture seule. Vous pouvez le consulter sous Prompt lorsque vous associez la politique pour voir les critères exacts que l'évaluateur applique.
Ce que l’évaluateur reçoit
Lorsqu’une politique de service intégré s’exécute, Databricks envoie à l’évaluateur une demande en deux parties :
- Un **message système** qui contient l'invite de stratégie et un contrat de sortie (décrit dans la section suivante).
- Un message utilisateur qui contient le contenu en cours d'évaluation : pour l'entrée, le dernier message utilisateur sur un service de modèle ou l'appel d'outil et ses arguments sur un service MCP ; pour la sortie, la réponse du modèle.
L'évaluateur ne voit que cet élément extrait unique. Il ne voit pas l'invite système du service protégé ni le contenu image et audio. By default, chaque évaluation est limitée à un seul message ; ainsi, une politique de service intégrée ne peut pas détecter les modèles s'étendant sur plusieurs messages, comme une escalade progressive au cours d'une conversation.
Pour l'évaluation des entrées sur les services de modèle et de fournisseur de modèle, vous pouvez augmenter cette fenêtre. Lorsque vous associez la politique, définissez le nombre de tours de conversation récents que l'évaluateur reçoit ; il voit ainsi cette fenêtre de tours au lieu du dernier message uniquement. Ceci s'applique uniquement à l'entrée et n'est pas disponible sur les services MCP.
Contrat de sortie
Databricks ajoute automatiquement un contrat de sortie JSON à l'invite de politique, de sorte que l'évaluateur renvoie une décision structurée au lieu d'un texte libre. L'évaluateur renvoie :
flagged(booléen) :truesi le contenu enfreint les critères de la politique.confidence(flottant,0.0à1.0, facultatif) : la confiance de l'évaluateur dans la décision.reason(chaîne) : brève explication des raisons pour lesquelles le contenu a été signalé. Retourné lorsqueflaggedesttrue.
Lorsque l'évaluateur renvoie flagged: true, Databricks bloque l'interaction default. Sur un service MCP, une politique configurée pour demander suspend la requête pour obtenir une approbation humaine avant l'exécution de l'outil. Puisque Databricks applique le contrat pour vous, les politiques de service intégrées ne nécessitent aucune configuration au-delà de la phase et du rang.
Coût de l'évaluation
Databricks ne facture pas de frais distincts pour les politiques de service intégré. Chaque évaluation est facturée comme tout autre appel au service de modèle d'évaluateur, de sorte que le coût dépend de la manière dont ce modèle est servi. Les jetons facturés pour chaque évaluation couvrent l'invite de la politique, le contrat de sortie, le message extrait et la réponse de l'évaluateur. Pour limiter les frais généraux, maintenez un petit nombre de politiques par phase et préférez un modèle d'évaluateur à faible latence.
Services pris en charge
Pendant la version bêta, vous pouvez attacher des politiques de service aux objets sécurisables de service Unity Catalog suivants :
- Services MCP: serveurs MCP gérés, externes et personnalisés.
- Services de modèle: endpoints LLM hébergés et externes.
- **Services de fournisseur de modèles** : fournisseurs de modèles externes gouvernés.
Comportement de basculement en mode sécurisé
L’évaluation de la politique de service utilise la sémantique de défaillance fermée. Lorsque vous attachez une stratégie via la Unity AI Gateway, Databricks la valide au moment de l'attachement, et toute erreur pendant l'évaluation entraîne DENY. Les erreurs incluent les erreurs de l'utilisateur dans la fonction de stratégie, les erreurs système, les champs manquants dans le contexte de la requête et les expirations de délai.
Une politique mal configurée ou défectueuse bloque l'interaction au lieu de la permettre.
Limitations
Les limitations suivantes s'appliquent pendant la bêta :
- Transformation : les politiques de service renvoient une décision (ALLOW, DENY ou ASK) et ne transforment pas le contenu de la requête ou de la réponse pendant la version bêta. La seule exception est la politique intégrée
system.ai.detect_sensitive_data, qui peut masquer les valeurs correspondantes sur les services de modèle. - Services pris en charge : Les politiques de service s'appliquent aux services MCP, aux services de modèle et aux services de fournisseur de modèle. Les Services aux agents ne sont pas pris en charge.
- Évaluation d'un message unique : par default, une stratégie de service intégrée évalue un message à la fois. Pour l'évaluation des entrées sur les services de modèle et de fournisseur de modèle, vous pouvez augmenter la fenêtre à un certain nombre de tours de conversation récents. L'évaluation de la sortie et les services MCP restent limités à un message unique. Consultez Comment fonctionnent les stratégies de service intégrées.
- Évaluation imbriquée : Si le service de modèle d'évaluateur que vous sélectionnez pour une politique de service intégré possède ses propres politiques attachées, Databricks les ignore lors de l'exécution de l'évaluation. Cela empêche la récursion.