Pular para o conteúdo principal

Exemplos de políticas de serviço

info

Beta

Este recurso está em Beta. Administradores da conta podem controlar o acesso a este recurso na página **Prévias** do console da conta. Consulte Gerenciar prévias do Databricks.

Estes exemplos de políticas de serviço personalizadas cobrem cenários comuns de governança para modelos de AI e serviços MCP. Eles se enquadram em dois tipos de política personalizada:

  • Políticas SQL determinísticas : uma função SQL que toma uma decisão exata baseada em regras (um nome de ferramenta, um valor de argumento, uma palavra-chave, um comprimento). Utilize-as quando a regra for precisa e repetível.
  • Políticas de LLM como juiz : um classificador de linguagem natural que um modelo avaliador aplica à solicitação ou resposta. Use-os quando a verificação for semântica (intenção, tópico, tom) e nenhuma regra exata a capture.

Para o procedimento de ponta a ponta para criar e anexar uma política, consulte Criar e anexar uma política de serviço. Para os campos event, o valor de retorno e o subconjunto SQL compatível, consulte Referência de função de política de serviço. Para as guardrails integradas que cobrem PII, conteúdo inseguro, jailbreak e alucinação sem código personalizado, consulte Políticas de serviço integradas.

Exemplos de política SQL determinística

Cada exemplo é uma função definida pelo usuário (UDF) SQL que você registra no Unity Catalog e anexa a um serviço. A política é executada em ambos os pontos de avaliação, portanto, cada função ramifica em Branch em event:type::string ('request' para a fase de entrada, ON CALL; 'response' para a fase de saída, ON RESULT) e retorna um ALLOW explícito para cada caminho que não bloqueia.

nota

As políticas de serviço são fail-closed : um campo ausente, uma função não compatível ou qualquer erro de avaliação resulta em DENY. Sempre converta um caminho VARIANT antes de compará-lo a um literal (por exemplo, event:type::string = 'request') e termine cada função com uma branch ALLOW explícita. O corpo da política oferece suporte apenas a um subconjunto restrito de SQL. Consulte SQL compatível.

Bloquear solicitações que contenham palavras-chave específicas

Esta política bloqueia solicitações para um Serviço de modelo ou Serviço de provedor de modelos cuja mensagem contenha qualquer termo em uma lista de bloqueio, como um codinome de projeto interno. Ele converte a mensagem para minúsculas com LOWER para que a correspondência não diferencie maiúsculas de minúsculas.

SQL
CREATE OR REPLACE FUNCTION main.governance.block_codenames(
event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
CASE
WHEN event:type::string = 'request'
AND (
CONTAINS(LOWER(event:context.message::string), 'projectfalcon')
OR CONTAINS(LOWER(event:context.message::string), 'bluewidget')
OR CONTAINS(LOWER(event:context.message::string), 'codename-atlas')
)
THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Your request references a restricted internal or competitor codename.'))
ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
END;

Bloquear solicitações sobre tópicos restritos

Esta política bloqueia solicitações a um Model serviço ou Model Provider serviço que mencionem tópicos nos quais o assistente não deve se envolver, correspondidos por palavra-chave. Esta é a forma determinística de um bloco de tópico. Quando o tópico é sutil e uma lista de palavras-chave é muito imprecisa, use uma política de LLM-como-juiz em vez disso.

SQL
CREATE OR REPLACE FUNCTION main.governance.deny_restricted_topics(
event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
CASE
WHEN event:type::string = 'request'
AND (
CONTAINS(LOWER(event:context.message::string), 'lawsuit')
OR CONTAINS(LOWER(event:context.message::string), 'legal advice')
OR CONTAINS(LOWER(event:context.message::string), 'investment advice')
)
THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'This assistant does not handle legal or investment topics.'))
ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
END;
nota

O subconjunto SQL da política corresponde a substrings com CONTAINS, LIKE, STARTSWITH e ENDSWITH; expressões regulares (regexp_*) não são suportadas. A correspondência de substring não pode validar um formato que dependa de estrutura ou de uma soma de verificação, como um ID nacional ou um número de account. Para essas verificações, use um guardrail integrado onde um se aplique. Consulte SQL suportado.

Limitar o comprimento do prompt

Esta política nega solicitações a um Model serviço ou Model Provider serviço cuja mensagem excede um limite de caracteres. Prompts muito longos são frequentemente despejos colados ou tentativas de prompt-stuffing, e eles aumentam a latência e o custo.

SQL
CREATE OR REPLACE FUNCTION main.governance.deny_oversized_prompt(
event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
CASE
WHEN event:type::string = 'request'
AND LENGTH(event:context.message::string) > 8000
THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Your prompt exceeds the 8000-character limit for this service.'))
ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
END;

Exigir aprovação quando um agente atua em nome de um usuário

Esta política usa o contexto de ator em nome de (OBO) para reter uma ação de gravação para aprovação humana quando um agente, em vez de uma pessoa, chama uma ferramenta sensível em um Serviço MCP . O resultado ASK pausa a chamada até que uma pessoa a aprove.

SQL
CREATE OR REPLACE FUNCTION main.governance.ask_when_agent_writes(
event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
CASE
WHEN event:type::string = 'request'
AND event:context.actor.context.is_on_behalf_of::boolean = true
AND event:context.tool.name::string IN ('create_issue', 'push_files', 'merge_pull_request')
THEN to_variant_object(named_struct('result', 'ASK', 'reason', 'An agent is attempting a write action on your behalf. Please confirm.'))
ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
END;

Para saber como o Databricks entrega o prompt de aprovação ASK a um agente externo, consulte Write a decision policy.

Bloquear respostas que exponham URLs internas

Esta política é executada na fase de saída (ON RESULT): ela inspeciona a resposta do modelo em um Model Service ou Model Provider Service e bloqueia respostas que fazem referência a um host interno. Como ela faz branch em event:type::string = 'response', ela avalia a resposta em vez da solicitação.

SQL
CREATE OR REPLACE FUNCTION main.governance.block_internal_links_in_response(
event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
CASE
WHEN event:type::string = 'response'
AND (
CONTAINS(LOWER(event:context.message::string), 'wiki.internal.example.com')
OR CONTAINS(LOWER(event:context.message::string), 'admin.example.com')
)
THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'The response was blocked because it referenced an internal-only URL.'))
ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
END;

Bloquear uma chamada de ferramenta por seus argumentos

Esta política inspeciona os argumentos de uma ferramenta e bloqueia chamadas que visam um recurso protegido, enquanto permite todas as outras chamadas. Isso se aplica a um serviço MCP . O exemplo publicado negar um push do GitHub bloqueia uma ferramenta pelo nome; este vai um nível mais fundo e verifica um valor de argumento.

SQL
CREATE OR REPLACE FUNCTION main.governance.block_protected_repo(
event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
CASE
WHEN event:type::string = 'request'
AND event:context.tool.arguments.repo::string = 'prod-infra'
THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Actions on the prod-infra repository are not permitted through the agent.'))
ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
END;

Restringir uma ferramenta sensível a agentes aprovados

Esta política restringe uma ferramenta de gravação sensível em um serviço MCP a agentes aprovados. Uma chamada push_files feita em nome de um usuário só é permitida se o ID do cliente OAuth do agente atuante (event:context.actor.context.client_id) estiver na lista de aprovados; todo o resto é permitido. Se o ID do cliente estiver ausente ou nulo, a chamada também será negada, portanto, o portão permanece fechado em caso de falha. Chamadas não feitas em nome de um agente passam para ALLOW, deixando o acesso comum governado por concessões.

SQL
CREATE OR REPLACE FUNCTION main.governance.restrict_push_to_approved_agents(
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
AND (
event:context.actor.context.client_id IS NULL
OR event:context.actor.context.client_id::string NOT IN ('release-bot', 'ci-deployer')
)
THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'Only approved agents can call the push_files tool on this service.'))
ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
END;

Para restringir ainda mais a regra, combine a verificação do agente com um valor de argumento, como Bloquear uma chamada de ferramenta por seus argumentos, por exemplo, para permitir o push apenas para um repository específico. Este exemplo usa o mesmo contexto de ator em nome de como Exigir aprovação quando um agente age em nome de um usuário, mas retorna DENY para um agente não aprovado em vez de ASK.

Exemplos de política LLM-como-juiz

Uma política de LLM-as-a-judge usa um modelo avaliador para classificar a solicitação ou resposta em relação a critérios descritos por você em linguagem natural. Use-o para verificações semânticas que uma regra determinística não consegue expressar, como se uma mensagem está dentro do tópico ou se uma resposta permanece profissional.

Para criar um, siga o procedimento anexar uma política, mas em Tipo de guardrail selecione Personalizado e, em seguida, defina Tipo como LLM-as-a-judge . Insira seu classificador no campo Prompt e selecione um serviço de modelo de avaliador (você precisa de CAN QUERY no modelo que escolher).

Você escreve os critérios de classificação. O Databricks anexa um contrato de saída estruturada ao seu prompt, para que o avaliador retorne uma decisão JSON (um booleano flagged e uma pontuação confidence) em vez de texto livre. Não escreva ALLOW ou DENY no prompt e não especifique um formato de saída. Quando o avaliador sinaliza conteúdo, o Databricks bloqueia a interação. O Databricks também encapsula o conteúdo em avaliação e instrui o avaliador a tratá-lo como dados não confiáveis, em vez de instruções a serem seguidas.

nota

Os exemplos nesta seção estão em execução em serviços de modelo e bloqueiam conteúdo sinalizado. Para manter uma interação para aprovação humana em vez de bloqueá-la, use o resultado ASK, que se aplica a serviços MCP. Consulte Exigir aprovação quando um agente atua em nome de um usuário.

Escrever prompts de juiz eficazes

Os prompts nesta página são pontos de partida. Adapte cada um ao domínio do seu assistente e teste-o em tráfego realista dentro do escopo antes de confiar nele para bloquear.

A tabela a seguir lista as práticas recomendadas que tornam um prompt de juiz mais confiável.

Prática recomendada

Descrição

Defina os critérios de MARCAR e NÃO MARCAR.

Descreva o conteúdo a ser sinalizado e, em seguida, o conteúdo a ser ignorado. Cada exemplo aqui associa uma condição de "sinalizar se" com um limite de "não sinalizar"; um prompt que lista apenas o que sinalizar tende a sinalizar em excesso.

Forneça um critério de desempate para casos de limite.

Indique como classificar o conteúdo que se situa entre as duas listas, por exemplo, se um enquadramento educacional ou fictício isenta detalhes que, de outra forma, seriam proibidos, para que o avaliador não decida esses casos de forma inconsistente.

Descreva a intenção, não apenas palavras-chave ou técnicas.

Sinalize com base no que uma mensagem está tentando fazer, não apenas na presença de uma palavra ou técnica. Role-play ou uma string codificada não são, por si só, um jailbreak; é necessária uma tentativa de obter conteúdo não permitido.

Prefira uma integrada onde for adequado e mantenha os critérios personalizados focados.

Para um risco que uma barreira de proteção integrada já cubra, como PII, conteúdo não seguro ou jailbreak, use a integrada em vez de descrevê-la novamente em um prompt personalizado. A sobreposição de políticas ainda funciona, e algumas equipes fazem isso deliberadamente, mas isso adiciona avaliação e custo redundantes e torna mais difícil identificar qual política bloqueou uma determinada interação.

Faça a implementação primeiro no modo Log e considere o não determinismo.

Anexe a política no modo Log , que registra o veredito sem bloquear, e revise seus falsos positivos e negativos em tráfego realista no escopo antes de alterná-la para Impor . A revisão desses vereditos requer tabelas de inferência ativadas no serviço; sem elas, uma política em modo Log ainda avalia, mas não há nada que você possa inspecionar. O avaliador é um modelo, portanto, a mesma entrada pode ocasionalmente obter vereditos diferentes, e um prompt que sinaliza conteúdo limítrofe de forma agressiva produz falsos positivos em escala.

Prática recomendada

Descrição

Defina os critérios de MARCAR e NÃO MARCAR.

Descreva o conteúdo a ser sinalizado e, em seguida, o conteúdo a ser ignorado. Cada exemplo aqui associa uma condição de "sinalizar se" com um limite de "não sinalizar"; um prompt que lista apenas o que sinalizar tende a sinalizar em excesso.

Forneça um critério de desempate para casos de limite.

Indique como classificar o conteúdo que se situa entre as duas listas, por exemplo, se um enquadramento educacional ou fictício isenta detalhes que, de outra forma, seriam proibidos, para que o avaliador não decida esses casos de forma inconsistente.

Descreva a intenção, não apenas palavras-chave ou técnicas.

Sinalize com base no que uma mensagem está tentando fazer, não apenas na presença de uma palavra ou técnica. Role-play ou uma string codificada não são, por si só, um jailbreak; é necessária uma tentativa de obter conteúdo não permitido.

Prefira uma integrada onde for adequado e mantenha os critérios personalizados focados.

Para um risco que uma barreira de proteção integrada já cubra, como PII, conteúdo não seguro ou jailbreak, use a integrada em vez de descrevê-la novamente em um prompt personalizado. A sobreposição de políticas ainda funciona, e algumas equipes fazem isso deliberadamente, mas isso adiciona avaliação e custo redundantes e torna mais difícil identificar qual política bloqueou uma determinada interação.

Faça a implementação primeiro no modo Log e considere o não determinismo.

Anexe a política no modo Log , que registra o veredito sem bloquear, e revise seus falsos positivos e negativos em tráfego realista no escopo antes de alterná-la para Impor . A revisão desses vereditos requer tabelas de inferência ativadas no serviço; sem elas, uma política em modo Log ainda avalia, mas não há nada que você possa inspecionar. O avaliador é um modelo, portanto, a mesma entrada pode ocasionalmente obter vereditos diferentes, e um prompt que sinaliza conteúdo limítrofe de forma agressiva produz falsos positivos em escala.

Manter um assistente no tópico

Esta política de fase de entrada (ON CALL) é executada em um Model Serviço . Ele sinaliza solicitações que estão fora do escopo suportado pelo assistente, para que um assistente criado para um propósito não seja usado como um chatbot de propósito geral.

Prompt:

Você está revisando mensagens enviadas a um assistente de suporte ao cliente que pode ajudar apenas com produtos, pedidos, faturamento e suporte de account da empresa. Sinalize a mensagem se ela solicitar algo fora desse escopo, como ajuda geral com programação, redação de ensaios, curiosidades não relacionadas ou uso do assistente como um chatbot de uso geral. Não sinalize uma pergunta genuína sobre o produto ou suporte.

Aplicar um tom profissional

Esta política de fase de saída (ON RESULT) é executada em um Model serviço . Ele sinaliza respostas que não estão alinhadas à marca ou que não são profissionais, complementando a barreira de proteção block_unsafe_content integrada, que tem como alvo conteúdo prejudicial em vez de tom.

Prompt:

Você está revisando respostas redigidas por um assistente voltado ao público. Sinalize a resposta se ela for rude, sarcástica, desdenhosa, condescendente, usar linguagem de baixo calão ou se puder constranger a empresa caso um cliente a veja. Não sinalize uma resposta que seja profissional, respeitosa e alinhada à marca.

Bloquear conselhos regulamentados

Esta política de fase de saída (ON RESULT) é executada em um Model serviço . Ele sinaliza respostas que fornecem conselhos regulamentados individualizados, distinguindo-as de informações gerais e não consultivas, o que uma regra de palavra-chave não consegue fazer de forma confiável.

Prompt:

Você está revisando respostas redigidas por um assistente de serviços financeiros. Sinalize a resposta se ela fornecer aconselhamento individualizado sobre investimentos, impostos ou questões jurídicas, ou uma recomendação específica para uma pessoa. Não sinalize uma resposta que forneça apenas informações gerais sobre o produto, conteúdo educacional ou conteúdo não consultivo.

Este exemplo bloqueia respostas sinalizadas. Manter uma interação para aprovação humana em vez de bloqueá-la usa o resultado ASK, que se aplica a serviços MCP, conforme em Exigir aprovação quando um agente atua em nome de um usuário.

Exemplos de LLM-como-juiz de várias rodadas

Os exemplos de LLM como juiz acima avaliam a mensagem mais recente por conta própria. Alguns riscos só são visíveis em uma troca, quando a mensagem mais recente parece correta, mas a conversa recente não. Uma política de LLM como juiz de várias rodadas (multi-turn) oferece ao avaliador uma janela das mensagens mais recentes em vez de apenas a última.

Para habilitá-lo, anexe a política como uma política de LLM como juiz e defina o campo Janela de conversa para o número de mensagens recentes que o avaliador deve receber, ou selecione Avaliar a conversa inteira . A avaliação de múltiplos turnos aplica-se apenas à fase de entrada (ON CALL) em Serviços de Modelo e Serviços de provedor de modelos ; ela não está disponível na fase de saída ou em Serviços MCP. Escreva o prompt para julgar as mensagens recentes em conjunto, não apenas a última.

A Janela de conversa conta mensagens individuais de qualquer função (sistema, usuário, assistente e ferramenta), não pares de ida e volta, portanto, uma janela de 6 cobre as últimas seis mensagens, e uma janela de 1 é o mesmo que a avaliação de mensagem única. Para uma janela maior que um, o avaliador recebe as mensagens recentes junto com a última mensagem do usuário da solicitação, de modo que o turno atual seja sempre julgado juntamente com o contexto recente.

Avaliar a conversa inteira envia todas as mensagens na solicitação atual, não um histórico de sessão retido pelo servidor: o Databricks não mantém estado de conversa entre solicitações. Ele não aplica limite de tamanho, portanto, uma conversa longa pode exceder a janela de contexto do modelo avaliador e falhar na avaliação, o que nega a solicitação, pois as políticas falham de forma fechada. Uma janela maior também adiciona custo de tokens e latência. Prefira uma janela numérica delimitada grande o suficiente para capturar o padrão que você está verificando e reserve Avaliar a conversa inteira para trocas curtas.

nota

A avaliação em vários turnos é baseada em janela, não com estado. O avaliador vê apenas as mensagens presentes na solicitação atual, e o Databricks não mantém estado entre as solicitações. Dentro dessa janela, uma política pode agir em um turno anterior, mas não pode usar informação que tenha saído da solicitação ou manter uma pontuação contínua entre as solicitações. Ele não pode implementar controles com escopo de sessão, como "uma vez que este agente leia dados confidenciais, bloqueie suas outras ferramentas pelo restante da sessão."

Para riscos de jailbreak e conteúdo inseguro , use as barreiras de proteção integradas Jailbreak e Unsafe Content, que você também pode executar em mensagens recentes definindo uma Janela de conversa . Reserve um juiz personalizado de vários turnos para políticas específicas de domínio que os integrados não cobrem. Consulte as seções a seguir para obter exemplos de políticas específicas de domínio.

Detectar uma conversa que se desvia do tópico

Esta política de fase de entrada (ON CALL) é executada em um Model Service ou Serviço de provedor de modelos . É a forma de vários turnos de Manter um assistente no tópico: ele sinaliza uma conversa que saiu do escopo suportado pelo assistente ao longo de vários turnos, mesmo quando a mensagem mais recente parece aceitável por si só.

Prompt:

Você está revisando os turnos mais recentes de uma conversa com um assistente de suporte ao cliente que pode ajudar apenas com produtos, pedidos, faturamento e suporte à account da empresa. Sinalize a conversa se a troca recente tiver se movido para fora desse escopo, como para ajuda geral com codificação, redação de ensaios ou curiosidades não relacionadas, mesmo quando a mensagem mais recente por si só pareça estar dentro do escopo. Não sinalize uma conversa que permaneça dentro dos tópicos suportados.

Marcar discussão de um projeto confidencial entre turnos

Esta política de fase de entrada (ON CALL) é executada em um Serviço de Modelo ou Serviço de Provedor de Modelos . É o complemento semântico de vários turnos para o bloco de codinome de palavra-chave determinístico: ele sinaliza uma conversa que está investigando ou discutindo um projeto interno confidencial, mesmo quando a mensagem mais recente não o nomeia. Adapte a descrição do que é considerado confidencial para sua organização.

Prompt:

Você está revisando os turnos mais recentes de uma conversa com um assistente interno. Sinalize a conversa se as mensagens recentes estiverem solicitando ou discutindo detalhes de um projeto interno confidencial e não lançado, como seu roteiro, dados financeiros ou codinome, mesmo quando a última mensagem sozinha não nomear o projeto. Não sinalize perguntas gerais sobre produtos lançados publicamente ou informações públicas da empresa.

Sinalizar uma solicitação que se encaminha para conselhos regulamentados

Esta política de fase de entrada (ON CALL) é executada em um Serviço de Modelo ou Serviço de Provedor de Modelos . É o complemento de várias rodadas e fase de solicitação ao Bloquear aconselhamento regulamentado, que verifica uma única resposta: ele sinaliza uma conversa que direciona o assistente a fornecer aconselhamento regulamentado individualizado, para que o assistente possa redirecionar antes de responder.

Prompt:

Você está revisando os turnos mais recentes de uma conversa com um assistente de serviços financeiros que pode compartilhar apenas informações gerais e educacionais. Sinalize a conversa se as mensagens recentes visarem a obtenção de aconselhamento individualizado sobre investimentos, impostos ou questões jurídicas, ou uma recomendação específica para a situação do usuário, mesmo quando a última mensagem, isoladamente, pareça uma pergunta geral. Não sinalize uma conversa que permaneça em informações gerais e não consultivas.

Relacionado