Preflight do Genie autônomo da Databricks: aprovações, orçamentos e guardrails antes de rodar

Na prática, isso significa três coisas: comece com jobs que apenas leem e reportam, coloque uma aprovação humana antes de qualquer coisa que altere um sistema ou contate uma pessoa e não trate um orçamento do Genie como teto para a sua conta total.

O que muda com o Genie autônomo

Os jobs do Genie não esperam mais que alguém peça. O blog de anúncio da Databricks diz que, depois que um job do Genie está em execução, ele pode rodar em um agendamento ou responder a gatilhos, como a queda de uma métrica ou mais de 10 clientes pedindo o mesmo recurso.

Esses gatilhos podem se basear em um conjunto muito maior de dados. A Databricks diz que o Genie Search se expande para mais de 100 fontes de dados corporativas, incluindo o lakehouse e aplicativos de negócios como Google Drive, Jira e Confluence.

O alcance maior vem acompanhado de um modelo de cobrança diferente. No comunicado à imprensa, a Databricks diz que os clientes pagam pelo que usam, e não por assento, e que os administradores podem definir limites de gastos por equipe ou por usuário por meio do Unity AI Gateway. O Genie One é gratuito para usuários até 31 de janeiro de 2027, e a Databricks diz que controles de custo mais detalhados estarão disponíveis antes disso.

Para mostrar o modelo funcionando em escala, a Databricks cita dois clientes. Ela relata que a General Motors implantou mais de 1,000 agentes do Genie em vendas, engenharia, cadeia de suprimentos e operações de RH. A HelloFresh é citada dizendo que o Genie reduziu em 75% o tempo necessário para identificar anúncios vencedores na Meta. A Databricks publicou as duas declarações, nenhuma delas é uma medição independente e nenhuma informa quais controles estavam em vigor; portanto, elas falam sobre demanda, mas dizem pouco sobre como o Genie vai se comportar no seu ambiente.

Por que agentes sempre ativos exigem um modelo de risco diferente

No chat, uma pessoa lê cada resposta antes de agir com base nela, e a sessão tem um fim claro. Um job acionado por gatilho pode rodar no meio da noite ou sempre que uma métrica ultrapassar um limite, sem ninguém acompanhando, e continua até que algo o interrompa. Por isso, as permissões dele são decididas na fase de design.

Essa decisão de design fica mais difícil à medida que os conectores se multiplicam. Dependendo das ferramentas, um job que consegue ler o Jira e o Confluence também pode conseguir editá-los; então, para cada job, documente o que ele pode alterar, além do que ele pode ver.

O volume agrava o problema. A documentação de configuração da Databricks diz que cada Genie Agent suporta até 200,000 conversas, e cada conversa pode incluir até 10,000 mensagens. Um gatilho mal configurado poderia disparar muitas vezes dentro desses limites antes que alguém percebesse.

Organizamos isso com o que chamamos de escada de autonomia Ler-Reportar-Agir (Read-Report-Act). Cada ferramenta que um job pode chamar recebe um degrau, e cada job sobe um degrau por vez.

A autonomia é conquistada por degrau, não concedida por agente.

Aprovações e allowlists de ferramentas

Comece com leitura e relatórios

Comece todo job autônomo nos dois degraus inferiores e faça com que qualquer coisa que grave em um sistema, envie uma mensagem ou abra um ticket aguarde um humano. Isso é cauteloso de propósito, porque você pode afrouxar uma política depois, mas não consegue desfazer facilmente algo que já chegou a um cliente.

Escreva service policies como allowlists

As service policies do Unity AI Gateway decidem quais chamadas de ferramentas MCP são permitidas. A sintaxe e as opções de aprovação podem mudar, então trabalhe a partir dos exemplos de service policies e da documentação Govern an MCP da Databricks, em vez de presumir que um recurso existe. Se você precisar de uma etapa de aprovação para ferramentas do degrau Agir que a documentação não descreve, pergunte à Databricks ou encaminhe essas ações por um fluxo de trabalho existente que já exija aprovação.

Cada política deve nomear as ferramentas que um job pode chamar.

Espere que as políticas falhem fechadas

As service policies falham fechadas (fail closed): uma comparação em um campo ausente, uma função não suportada ou qualquer erro de avaliação resulta em DENY. Esse é o padrão de segurança correto, mas tem um custo operacional, porque um erro de digitação ou uma regra que verifica um campo que algumas chamadas não têm vai bloquear silenciosamente trabalho legítimo.

Fornecedores externos de guardrails se comportam da mesma forma. A documentação Govern an MCP diz que as service policies externas falham fechadas: se o endpoint do fornecedor estiver inacessível ou lento, a Databricks nega a chamada. Uma indisponibilidade do fornecedor significa jobs com falha, e não jobs passando despercebidos pelo guardrail. Configure alertas para negações e decida com antecedência se uma execução com falha deve tentar de novo mais tarde ou apenas reportar que não conseguiu concluir.

Teste uma política antes de confiar nela

Pense em um job de relatório semanal de churn no degrau Reportar. A política abaixo é um pseudocódigo ilustrativo com nomes de ferramentas hipotéticos, e não sintaxe da Databricks.

policy: churn-weekly-report
applies_to: tools/call
allow_if: tool_name in [run_readonly_sql, write_internal_summary]
otherwise: DENY

Em seguida, faça três chamadas a partir da própria identidade do job:

1. Caminho permitido. run_readonly_sql deve ser permitido.
2. Ferramenta fora do escopo. create_ticket deve retornar DENY.
3. Falha deliberada. Uma chamada sem o campo que a política verifica, como uma sem nome de ferramenta, deve retornar DENY. Se ela for permitida, a política não está fazendo o que você imagina.

Registre os resultados com o responsável pelo job e repita os três testes sempre que a política ou a lista de ferramentas mudar. Se as suas ferramentas não conseguirem enviar facilmente uma chamada malformada, pergunte à Databricks como ela sugere testar esse caso.

Pare diante de rejeições por rate limit

Os rate limits do MCP se aplicam a requisições tools/call e são medidos em consultas por minuto (QPM). Chamadas acima do limite retornam HTTP 429. Sugerimos tratar uma rejeição por rate limit em um job sem supervisão como sinal de que algo inesperado pode estar acontecendo, como um loop ou um gatilho disparando com mais frequência do que o planejado, e fazer o job parar e reportar, em vez de tentar de novo em um loop apertado que só acumula mais chamadas rejeitadas. As equipes podem achar útil definir limites de QPM por ferramenta com base no que uma execução normal precisa, mais alguma folga, para que uma rejeição continue rara o bastante para ser lida como um sinal real. Quando um job precisar ser interrompido no meio da execução, nosso runbook de kill switch para agentes de IA explica como pará-lo de forma limpa.

Limite a frequência de disparo dos gatilhos

Uma condição como 'mais de 10 clientes pediram isso' pode continuar verdadeira por horas e, se cada nova solicitação disparar o job de novo, você acaba com uma pilha de execuções quase idênticas. Os limites de QPM não ajudam aqui, já que desaceleram as chamadas dentro de uma execução sem impedir novas execuções. Defina um intervalo mínimo entre execuções e um limite diário. As fontes analisadas aqui não descrevem uma configuração nativa de debounce para gatilhos do Genie; então confirme com a Databricks e, se não houver, incorpore o limite ao próprio job.

Orçamentos: o que acompanham e o que deixam de fora

Os orçamentos do Genie cobrem apenas o uso de LLM

A documentação de orçamentos do Genie diz que os orçamentos acompanham o uso de LLM, e que a computação usada para executar consultas, como um SQL warehouse, é cobrada separadamente e não está incluída. Para um agente de dados cuja principal tarefa é executar consultas, essa lacuna pode ser grande: na sessão de teste da SELECT, descrita abaixo, a computação excluída correspondeu à conta inteira.

A documentação também orienta a não usar orçamentos para garantir um teto absoluto sobre os valores finais faturados e diz que a Databricks não se responsabiliza por custos incorridos acima dos limiares de orçamento configurados. Os limiares ajudam você a monitorar. Eles não garantem um limite.

Cada orçamento suporta no máximo quatro limiares compartilhados e 100 substituições por usuário, e uma conta pode ter no máximo 1,000 orçamentos. Se cada equipe e cada job tiver seu próprio orçamento, verifique se o seu design cabe nesses limites.

Franquias gratuitas e service principals

A Databricks começou a cobrar pelo uso do Genie Code além de uma franquia mensal gratuita em 8 de julho de 2026. Uma análise independente da SELECT relata que cada usuário identificado recebe 150 DBUs gratuitas de Genie Code em uso de LLM por mês, o equivalente a cerca de $10 a $11, dependendo do provedor de nuvem e da região. A SELECT também relata que service principals não recebem nenhuma franquia gratuita; portanto, qualquer uso do Genie vinculado a um service principal é cobrado desde a primeira requisição.

A lacuna na prática

A sessão de teste da SELECT mostra por que o gasto com LLM e o gasto com computação precisam ser acompanhados separadamente. A sessão custou $5.12 a preços de tabela: $4.34 em SQL Serverless e $0.77 em All-Purpose Serverless, com $0.00 em uso de LLM do Genie. Ainda assim, a sessão consumiu cerca de 102 DBUs de uso de LLM do Genie, divididas entre 79.7 do Genie Code e 22.7 do Genie One e Agents, tudo dentro da franquia gratuita. Um orçamento do Genie teria monitorado a parte gratuita e deixado passar a conta inteira.

Uma única sessão não prevê os seus custos, mas mostra onde está o risco. Nosso playbook de AI gateway sobre roteamento, orçamentos e controle de provedores aborda a mesma divisão do lado do gateway.

Tetos rígidos: confirme qual controle se aplica

Um post no blog da Databricks sobre o Unity AI Gateway descreve tetos rígidos de gastos que interrompem automaticamente as requisições quando os orçamentos são excedidos. A documentação de orçamentos do Genie descreve limiares que você não deve tratar como teto absoluto. As duas coisas podem estar certas para produtos ou caminhos de requisição diferentes; então pergunte à Databricks qual delas se aplica aos jobs autônomos do Genie.

Ali Ghodsi, da Databricks, disse ao TechCrunch que os custos podem ser controlados por meio do Unity AI Gateway, que permite às empresas definir limites de uso e trocar por modelos open-weight mais baratos.

O playbook de preflight

Execute as etapas em ordem. Não comece uma etapa até que a anterior tenha cumprido seu critério de saída.

Agendamentos vêm antes de gatilhos porque são previsíveis e mais fáceis de revisar. Na Etapa 5, uma aprovação só protege você se o revisor ler o que está aprovando; nosso guia sobre como aprovar e interromper execuções de agentes pelo celular aborda a aprovação pelo celular.

Questões em aberto para resolver com a Databricks

Estágio de lançamento e nuvem

As fontes analisadas aqui não deixam claro se cada recurso autônomo está em disponibilidade geral, em public preview ou em beta, e os termos de suporte variam conforme o estágio. As páginas da Databricks citadas neste artigo também são as versões para AWS, e não verificamos o comportamento no Azure nem no Google Cloud.

Identidade de execução (run-as)

As fontes também não dizem se jobs agendados e acionados por gatilho rodam como o criador, como um service principal ou como o usuário solicitante, e essa única escolha define ao mesmo tempo o acesso a dados, as trilhas de auditoria e a cobrança.

Considere o job de relatório semanal de churn mencionado antes. Se ele rodar com a identidade de quem o criou, herda tudo o que essa pessoa pode ler, o que geralmente é mais amplo do que um job do degrau Reportar precisa, e o log de auditoria associa o nome dela a execuções que ela nunca acompanhou. Transferir o job para um service principal resolve os problemas de auditoria e de ciclo de vida, mas a SELECT relata que service principals não recebem franquia gratuita; assim, o uso de LLM que caberia na franquia gratuita de um usuário nomeado passa a ser cobrado desde a primeira requisição. Nenhuma das opções é errada em todos os casos.

Contexto do benchmark

A Databricks relata que, em seu benchmark com a Turing, o Genie respondeu corretamente em 91% das execuções de tarefas, 1.6 vezes a taxa do agente de fronteira mais forte, usando menos da metade dos tokens. A cobertura da Unite.AI aponta 58% para o agente de fronteira mais forte, com o Genie consumindo em média 431,829 tokens e 100.3 segundos por execução. A Databricks alerta que o teste reflete uma implantação consolidada, com conhecimento de negócio acumulado, e que as diferenças podem ser menores em novas implantações ou quando os esquemas das tabelas por si só são suficientes.

Previsões de custo e controles em mudança

A SELECT cita uma previsão da IDC de que organizações do G1000 enfrentarão um aumento de até 30% em custos subestimados de infraestrutura de IA até 2027, causado menos por gastos excessivos do que por modelos de consumo opacos que o planejamento orçamentário tradicional nunca levou em conta. É uma previsão, e a citamos por meio da SELECT, e não do relatório original da IDC, mas ela ainda reforça a importância de acompanhar os gastos com LLM e com computação separadamente desde o primeiro dia. Os controles de custo que a Databricks prometeu podem fechar algumas das lacunas acima; então revise este checklist quando eles forem lançados.