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 un type de politique de contrôle d'accès basé sur les attributs (ABAC) ciblé sur les services d'IA. Les politiques ABAC se divisent en deux groupes : les politiques de contrôle d'accès (telles que les autorisations) décident si un principal peut atteindre un objet, tandis que les politiques de contenu régissent ce qui se passe après cela. Les politiques de service sont des politiques de contenu pour les services d'IA, le même rôle que les politiques de filtrage de lignes et de masquage de colonnes jouent pour les tables. Comme celles-ci, une politique de service 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 l'invocation du service (ON CALL) et après la réponse du service (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. L'appelant reçoit une erreur structurée avec une raison facultative.
- 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 :
- EN APPEL : *avant* que Databricks n’invoque le service, contre 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 qui contient des informations personnelles identifiables (PII) avant qu'elle n'atteigne un modèle.
- SUR LE RÉSULTAT : après que le service réponde, 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 qui contient du contenu « halluciné » ou des données sensibles.
Une fonction de politique personnalisée s'exécute aux deux points. Il inspecte la phase actuelle (event:type) et décide comment agir, ainsi une politique unique peut régir la requête, la réponse, ou les deux. Pour agir sur une seule phase, utilisez la Branch event:type dans le corps de la fonction. Les politiques intégrées sont plutôt définies avec une option phases, et certaines s'exécutent dans une seule phase (par exemple, la détection de jailbreak s'exécute uniquement ON CALL et la détection d'hallucinations uniquement ON RESULT).
Ordre d'évaluation
Vous pouvez associer plusieurs politiques de service à un service. Chaque pièce jointe a un rang (priorité), et la chaîne s'arrête au premier DENY. Databricks évalue les stratégies par ordre de rang croissant à **ON CALL** (le rang le plus bas en premier) et dans l'ordre inverse à **ON RESULT**. Utilisez le rang pour contrôler les vérifications qui s'exécutent en premier.
Le diagramme suivant montre où se situent les deux phases autour d'un service et ce que chaque décision fait :
Politiques de service intégrées
Databricks fournit des politiques de service intégrées dans le catalogue system.ai. Ces derniers 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 des IPI et du contenu dangereux) que vous attachez de la même manière qu'une politique personnalisée :
system.ai.block_pii: refuse les interactions qui contiennent des informations personnelles identifiables.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é.
Pour utiliser une politique intégrée, attachez-la à un service. Vous devez disposer du privilège EXECUTE sur la fonction de politique et de MANAGE sur le service cible.
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 une requête (ON CALL), le dernier message utilisateur sur un service de modèle ou l'appel d'outil et ses arguments sur un service MCP ; pour une réponse (ON RESULT), 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é, les tours précédents de la conversation, ou le contenu image et audio. Étant donné que chaque évaluation est limitée à un seul message, une politique de service intégré ne peut pas détecter les modèles qui s’étendent sur plusieurs messages, tels qu’une escalade progressive au cours d’une conversation.
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 par default. Si la politique est attachée à un service MCP et configurée pour demander, un résultat signalé met plutôt la demande en pause pour approbation humaine. Étant donné que Databricks applique le contrat pour vous, les politiques de service intégré ne nécessitent aucune configuration au-delà de la phase et du classement.
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) ; elles ne transforment pas le contenu de la requête ou de la réponse pendant la version bêta.
- 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 de message unique : une politique de service intégrée évalue un message à la fois, elle ne peut donc pas détecter les modèles qui s'étendent sur plusieurs messages dans une conversation. Voir Comment fonctionnent les politiques 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.