O gateway de IA da Databricks agora lê o motivo de cada requisição. Quem responde é quem chama

A governança de IA nas empresas vive pedindo contexto: não só quem está chamando um modelo ou uma ferramenta, mas para qual projeto, em qual ambiente, com qual finalidade. Em 9 de outubro, a Databricks deu ao seu gateway uma forma de ler esse contexto. O problema está em quem fornece a informação.

A nota de release, em beta, é curta: “As políticas de serviço customizadas no Unity Gateway agora podem checar request tags fornecidas por quem chama, por exemplo exigindo uma tag antes que uma requisição de modelo ou uma chamada de ferramenta MCP prossiga.” Quem chama envia as tags como um objeto JSON num header da requisição, e uma política pode devolver ALLOW ou DENY com base nos valores, avaliada a cada requisição.

A própria documentação da Databricks deixa o limite claro: “As tags são fornecidas por quem chama e são separadas das service tags e do contexto do ator autenticado.” E: “Uma tag sozinha não estabelece identidade nem permissão para usar um projeto.”

Três tipos de entrada que uma política de gateway pode ler

Estabelecido pela plataforma

• Ator autenticado
• Service tags

Pode sustentar autorização

Declarado por quem chama

• Request tags: projeto, finalidade, ambiente

Contexto útil; sozinho, não prova nada

Julgado por um modelo

• Políticas LLM-as-a-judge, agora com OpenJev

As request tags não chegam ao juiz

Úteis para atribuição, fracas para autorização

As request tags são realmente úteis. Uma tag com o projeto permite que o financeiro atribua o gasto com modelos ao orçamento certo. Uma tag com o ambiente permite que uma política afaste o tráfego de teste dos endpoints de produção. “Exigir uma tag antes da chamada” é boa higiene, porque obriga quem chama a declarar uma finalidade que depois aparece no registro.

O que uma tag não consegue fazer sozinha é autorizar. Se a política diz “permita chamadas com a tag do projeto p-1042”, qualquer um capaz de enviar o header pode alegar p-1042. Um DENY baseado em tag barra quem esqueceu de enviá-la por descuido, não quem age de má-fé. A documentação diz que verificações de identidade ou de permissão de projeto precisam de dados confiáveis de identidade e autorização.

O padrão útil é amarrar as duas coisas: a política confere se o projeto da tag é um ao qual o ator autenticado realmente pertence, usando dados em que a plataforma confia. Aí a tag acrescenta contexto a uma identidade, em vez de substituí-la. É a mesma separação que encontramos nos agentes da Databricks que carregam a identidade do usuário e nas três identidades de todo agente de IA: uma alegação sobre finalidade não é uma credencial.

A lacuna na aprovação

Um detalhe da documentação merece a atenção de quem desenha aprovações humanas. Políticas que devolvem ASK, pausando para uma pessoa aprovar, não distinguem tags. A documentação alerta que uma aprovação pode ser reaproveitada numa chamada equivalente com tags diferentes, e que as telas de aprovação não mostram as tags.

Na prática: se um revisor aprova uma chamada de ferramenta marcada como “teste”, a mesma aprovação pode cobrir uma chamada equivalente marcada como “produção”. Não use tags para delimitar o que uma pessoa aprovou. Delimite as aprovações pela própria chamada e deixe as tags para atribuição.

As tags também chegam às duas fases de uma política, a chamada e o resultado, e sobrevivem a novas tentativas e ao fallback de modelo, então a requisição mantém o contexto declarado do início ao fim. Elas não são enviadas a provedores externos de política nem incluídas nos prompts de LLM-as-a-judge, e o tamanho das tags decodificadas é limitado a 10 KiB por padrão.

Um juiz mais rápido

O mesmo release trouxe um segundo beta. O OpenJev, um modelo Qwen3.5 4B, agora pode ser escolhido como avaliador de políticas customizadas de LLM-as-a-judge. Como ele “classifica o conteúdo sem gerar tokens de saída”, a Databricks diz que ele “normalmente responde mais rápido que um avaliador de chat”.

Isso importa porque a governança inline tem um orçamento de latência. Um juiz que confere cada resposta de modelo ou resultado de ferramenta soma seu atraso a cada chamada, e um juiz lento acaba sendo desligado. Um avaliador do tipo classificador é a ideia dos modelos de decisão aplicada à aplicação de políticas. Ele ainda custa inferência, e os veredictos dele precisam do mesmo teste de calibração que qualquer juiz.

Os dois recursos estão em beta, e a combinação diz muito. A Databricks está dando ao seu gateway mais contexto e julgamento mais rápido, os ingredientes de um gateway que aplica política em vez de só repassar tráfego. O trabalho de desenho que sobra para os clientes é decidir quais dessas entradas merecem confiança para decidir alguma coisa.