Databricks ai_decide: quando a Decision Layer vai até os dados

E se, em vez de levar os dados até uma API de IA, levarmos a capacidade de decisão até os dados? Essa pergunta explica o interesse arquitetural de ai_decide. Para equipes que já operam dados no Databricks, a integração pode importar tanto quanto a velocidade da inferência.

AI Function, não o nome de um modelo

Segundo a Databricks, ai_decide é uma função de IA alimentada por um modelo de decisão. Ela oferece probabilidade, escolha entre critérios nomeados ou pontuação em escala. O acesso pode ocorrer em SQL para processamento em lote ou em REST para aplicações e agentes. O lançamento de 30 de setembro informa disponibilidade em Beta. [1]

Portanto, não a apresentamos como “o novo Decision Model da Databricks”. O artefato usado pelo desenvolvedor é uma função integrada à plataforma. O modelo que fornece a capacidade pode mudar, como a documentação avisa. [2]

Onde os dados governados já estão

Um lakehouse reúne trabalho com dados e controles da plataforma. “Dados governados” significa que existem regras de acesso, gestão e rastreabilidade. Não significa que todo uso desses dados esteja automaticamente aprovado.

Arquiteturalmente, uma função acessível em consultas pode reduzir a necessidade de montar um pipeline separado para exportar registros, chamar um serviço externo e reimportar classificações. Essa é uma possibilidade de desenho. Ainda é necessário verificar o caminho real de processamento, regiões, logs e requisitos da organização.

A documentação afirma que os dados de documentos são processados dentro do perímetro de segurança do Databricks e que os parâmetros da função não são armazenados, embora metadados da execução sejam mantidos. [2] Isso descreve o tratamento informado para a função; não prova conformidade para todo fluxo corporativo.

SQL: decisão como parte da consulta

A sintaxe documentada é ai_decide(state, questions [, options]). O estado pode variar por linha; a definição das perguntas é constante na consulta. A saída é VARIANT, com resposta, metadados e possível erro. [2]

Um exemplo simples de triagem:

SELECT
  ticket_id,
  ai_decide(
    message,
    '{"team": {
      "type": "choice",
      "instructions": "Which team should review this ticket?",
      "criteria": {
        "billing": "Payment and invoice issues",
        "technical": "Technical errors",
        "other": "Anything else or insufficient information"
      }
    }}'
  ) AS decision
FROM support_tickets;

support_tickets, ticket_id e message são nomes ilustrativos. Execute somente em ambiente autorizado e verifique erros da função antes de consumir a resposta. O SQL classifica; não concede permissão para agir sobre a conta do cliente.

Batch e real-time têm necessidades diferentes

Uma classificação incorreta em grande volume pode distorcer métricas agregadas. Uma decisão atrasada pode ser inútil em uma aplicação interativa. Defina critérios separados, mesmo que o mesmo produto atenda aos dois caminhos.

REST: a capacidade fora da consulta

A referência oficial documenta acesso HTTP à capacidade de decisões estruturadas. [3] Isso permite que uma aplicação solicite a decisão no momento da interação. SQL e REST são portas de entrada para a capacidade, não demonstrações de dois modelos diferentes.

O cliente precisa tratar autenticação, permissões e erros. Uma resposta transportada com sucesso não significa que o julgamento passou nos critérios da aplicação. Registre o estado usado, a versão identificável, os sinais retornados e a regra que liberou ou bloqueou o caminho.

Documentos, routing e avaliação

O anúncio apresenta processamento de documentos, roteamento de modelos e avaliação de agentes entre os usos da função. [1] Em um workflow de documentos, a etapa anterior pode extrair conteúdo e a decisão posterior escolher categoria ou necessidade de revisão. Extração e decisão têm falhas diferentes e precisam de evidência própria.

Para routing, a classificação pode sugerir que a solicitação exige raciocínio complexo. Uma política da aplicação escolhe um modelo disponível dentro do orçamento. Para avaliação, uma rubrica delimita o julgamento; a função não se torna um auditor independente por ser chamada de “judge”.

Governança não termina na fronteira da plataforma

Minimize os campos enviados ao estado e preserve a finalidade do uso. Uma pessoa autorizada a consultar uma tabela não necessariamente está autorizada a transformar todos os registros em um novo produto. Reveja permissões e rastreabilidade do resultado derivado.

As regras de execução precisam incluir revisão humana onde o risco exige. Confiança alta não substitui evidências, consentimento ou política de acesso. Mudanças no modelo subjacente podem exigir nova avaliação, mesmo se a consulta SQL permanecer idêntica.

Disponibilidade, desempenho e custo

A documentação registra restrições de região e runtime, além de indisponibilidade no SQL Classic. [2] Consulte a matriz atual para seu workspace antes de planejar rollout. O status Beta deve ser considerado nos testes e no plano de contingência.

O fabricante descreve decisões em frações de segundo, mas não incluímos essa expressão como SLA ou benchmark independente. [1] Também não publicamos uma tarifa específica sem confirmação. O custo do fluxo pode incluir capacidade de computação, serviço, processamento dos dados e operação.

Essa abordagem tende a merecer avaliação quando os dados e controles já estão na plataforma. Em uma aplicação sem esse contexto, a dependência adicional pode superar o benefício. A decisão correta considera a arquitetura existente, e não apenas a lista de recursos.

Veja como OpenAI entrega a camada por uma API, como Strands permite uma decisão local e como o hub conecta os cinco ecossistemas.

Fontes verificadas em 2 de outubro de 2026

1. Databricks: lançamento de ai_decide
2. Documentação SQL: sintaxe, segurança, resultados e restrições
3. Referência REST: decisões estruturadas