MnzAI Labs Special Report / Decision Models
Decision Models: a nova camada de decisão da IA
Um guia interativo para entender modelos de decisão, APIs e funções de plataforma, agentes híbridos, confiança, segurança e AI FinOps.
Ilustração conceitual criada com IA para este especial.
Uma mensagem chega. O sistema precisa escolher uma fila, identificar urgência e decidir se pode continuar sozinho. Essa tarefa pede três julgamentos delimitados. Não necessariamente uma conversa, um plano longo ou um texto explicando cada passo.
É nesse espaço que os Decision Models começam a ganhar relevância: transformar contexto em decisões finitas, estruturadas e diretamente consumíveis por software. A capacidade pode aparecer em um modelo especializado, em uma API ou em uma função de plataforma. A Decision Layer é a responsabilidade arquitetural que reúne essas decisões, independentemente do produto escolhido.
A pergunta útil não é “qual modelo ganhou?”. É “qual responsabilidade deve ficar em qual parte da arquitetura?”.
O que é um Decision Model?
Pense em uma recepcionista com uma lista de departamentos. Ela interpreta um pedido e escolhe para onde encaminhá-lo. Não precisa escrever uma dissertação para cada visitante. Mas precisa reconhecer quando o pedido não cabe na lista ou quando faltam informações.
Um modelo de decisão recebe o contexto e critérios definidos pelo desenvolvedor, avalia possibilidades delimitadas e devolve uma escolha, uma pontuação ou probabilidades. As opções podem mudar entre requisições, conforme o contrato de cada implementação. É diferente de um classificador tradicional treinado apenas para um conjunto fixo de rótulos.
A interface importa tanto quanto a capacidade: a aplicação consegue consumir a decisão sem transformar uma resposta aberta em regras de negócio. Isso não torna a escolha automaticamente correta. O modelo pode interpretar mal o contexto e escolher uma opção perfeitamente válida, porém inadequada.
Por que essa camada está aparecendo agora?
Classificação e roteamento já existiam muito antes desta categoria. O que muda é a combinação de interpretação de contexto, opções fornecidas na requisição e interfaces voltadas a decisões recorrentes. O crescimento de agentes aumenta a quantidade de bifurcações: cada tarefa pode exigir várias escolhas antes de chegar à resposta final.
Esse trabalho fica escondido quando tudo é tratado como “uma chamada de IA”. Selecionar ferramenta, avaliar evidência e pedir aprovação são operações diferentes de escrever um relatório. Separá-las permite medir qualidade, latência e custo com mais precisão.
Decidir e gerar: uma diferença de responsabilidade
| Trabalho | Forma de saída útil | Caminho que vale avaliar |
|---|---|---|
| Qual fila atende este pedido? | Uma opção de um catálogo | Decision Model ou regra, conforme a ambiguidade |
| Esta resposta cumpre os critérios? | Pontuação ou classificação | Decision Layer com avaliação validada |
| Como redesenhar a arquitetura de um produto? | Análise, hipóteses e plano aberto | Generative / reasoning model |
| O usuário tem permissão para estornar? | Resultado de uma política de acesso | Código e controle de autorização |
| Qual é o valor exato da fatura? | Cálculo verificável | Banco de dados e código |
Modelos generativos também oferecem saídas estruturadas e podem classificar. Portanto, obter JSON não prova que exista uma arquitetura de decisão especializada. A diferença investigada neste especial está no objetivo de treinamento, no mecanismo de saída e no contrato operacional, quando esses detalhes são públicos.
Dentro do modelo / representação conceitual
Produzir texto e escolher opções são trabalhos diferentes
Um mapa para evitar comparações erradas
System One Models é a nomenclatura usada pela TypeSafe para a classe introduzida com Jev. Também aparece em materiais do ecossistema. A inspiração no System 1 de Daniel Kahneman funciona como analogia para decisões rápidas. Não é uma taxonomia universal consolidada, nem transforma GPT, Claude ou Gemini formalmente em “System Two Models”. [1]
Mapa interativo da arquitetura
Duas responsabilidades, vários artefatos
Um modelo com saída especializada
Jev, Clef e Strands pontuam opções conhecidas. A arquitetura e a implantação variam: serviço hospedado, pesos abertos ou execução local.
| Ecossistema | Artefato que estamos examinando | O que aprofundar |
|---|---|---|
| Jev / TypeSafe | Modelo especializado, servido por API | Tipos, confiança e limites de automação |
| Clef / Cloudflare | Modelos abertos de decisão | Multimodalidade e implantação |
| Strands Decider 2B | Modelo pequeno e aberto | Execução local e decisões de agentes |
| OpenAI Decisions API | API com capacidade de decisão | Abstração, integração e limites do contrato |
| Databricks ai_decide | AI Function alimentada por modelo de decisão | SQL, REST e dados governados |
Os três primeiros expõem modelos explicitamente voltados a decisões. Os dois últimos expõem a capacidade por interfaces de serviço ou plataforma. Compartilhar uma camada funcional não estabelece equivalência de arquitetura interna. [2–5]
Arquitetura híbrida: Decision Models + frontier models
Uma aplicação recebe o objetivo, reúne contexto e identifica uma decisão fechada. A Decision Layer avalia as opções. Se o sinal de confiança passa pelo critério e a ação está permitida, o código segue. Caso contrário, o sistema reúne mais contexto, encaminha a um modelo de raciocínio ou solicita revisão humana.
O frontier model continua apropriado para pesquisa, geração, planejamento, programação, criatividade e análise complexa. Quando as respostas possíveis não são conhecidas antecipadamente, é preciso construir possibilidades antes de escolhê-las. A camada de decisão pode atuar depois, avaliando propostas contra critérios claros.
Esse caminho exige uma opção de abstenção. Uma lista incompleta força o sistema a escolher “a menos errada”. Incluir “outro”, “informação insuficiente” ou uma rota de escalonamento é parte do desenho do produto.
Exemplo: atendimento com confiança ajustável
No exemplo, Billing, Technical e Other formam uma classificação com opções mutuamente exclusivas. Urgent é outra pergunta. A urgência pode ser alta independentemente do departamento. Mude o limiar e observe o caminho; depois tente uma mensagem ambígua.
Exemplo 01 / Atendimento
A confiança muda o caminho
“Minha cobrança veio duplicada e preciso resolver isso hoje.”
94% > 90%
Fila de cobrança. O sistema encaminha o ticket; não autoriza um estorno.
Investigar contexto, pedir esclarecimento e revisar antes de agir.
Encaminhar o pedido de cobrança é uma ação. Autorizar um estorno é outra, com risco e permissões diferentes. A confiança da classificação não concede direitos sobre a conta do cliente.
Exemplo: um agente e suas pequenas bifurcações
Model routing significa escolher qual modelo deve receber uma tarefa. Tool selection significa escolher uma ferramenta disponível. Guardrails são verificações que ajudam a manter o fluxo dentro de critérios e limites. Cada uma dessas decisões precisa de um teste próprio, em vez de herdar a reputação do modelo usado.
Exemplo 02 / Agente híbrido
Pequenas decisões, controles explícitos
Atendimento financeiro
O objetivo e o contexto ajudam a selecionar um agente em um catálogo finito.
Nem toda bifurcação precisa de IA. Se uma regra resolve o caso de forma exata e estável, use a regra. A camada de decisão ganha valor quando a interpretação é necessária e o espaço de respostas continua controlável.
AI FinOps: medir o fluxo completo
O custo cresce com requisições × tokens × chamadas intermediárias. A latência acumula nos trechos sequenciais e também depende de rede, filas e preparação do contexto. A Decision Layer pode reduzir geração intermediária e agrupar perguntas. Pode também adicionar uma chamada desnecessária ou encaminhar muitos casos ao caminho mais caro.
AI FinOps / cálculo transparente
Quanto custa só a entrada?
requisições × tokens de entrada ÷ 1.000.000 × US$ 0,042
A tarifa do cálculo foi confirmada na documentação de Jev 1.13. [6] Ela não permite concluir quanto sua organização economizará. Meça também escalonamentos, retrabalho, infraestrutura local, observabilidade e custo do erro. O indicador útil é custo por decisão correta dentro do prazo, acompanhado de qualidade e cobertura da automação.
Confiança, calibração e segurança
Calibração é a relação entre probabilidades e acertos observados em muitos casos semelhantes. Um conjunto de previsões perto de 90% deveria acertar aproximadamente nessa frequência, sob as condições avaliadas. Isso não é garantia para cada pedido, nem para um domínio novo.
Também é necessário distinguir probabilidade da opção e um campo de confiança calculado pelo fornecedor. Critérios, número de opções e versão do modelo alteram a interpretação. Um limiar escolhido para encaminhar tickets não deve ser reutilizado automaticamente para decisões financeiras.
Antes de executar, o código precisa validar identidade, permissões, argumentos e limites. Dados recebidos de fora podem conter instruções maliciosas. Saída tipada reduz erros de formato; não elimina manipulação, exposição de dados ou escolhas erradas. Revise o conteúdo enviado e as políticas de retenção do serviço.
Quando vale experimentar?
- Há muitas decisões repetitivas e respostas delimitáveis.
- O custo de interpretar cada caso já é relevante no fluxo.
- Existem exemplos rotulados para avaliar qualidade no domínio real.
- A equipe consegue medir falsos positivos, latência e escalonamento.
- Há uma rota segura para dúvidas e falhas.
Comece em modo de observação: o modelo recomenda e o fluxo atual continua decidindo. Compare erros por tipo de solicitação, idioma e risco. Depois libere apenas ações reversíveis com critérios explícitos. Amplie o escopo quando as evidências justificarem.
Uma categoria promissora, ainda inicial
Os produtos deste especial chegaram em setembro e outubro de 2026. A evidência independente ainda é limitada e pode depender de versões que mudam rapidamente. Não há um ranking que represente todo trabalho possível. Um excelente resultado em classificação não demonstra capacidade para qualquer decisão empresarial.
O desenho híbrido é o aprendizado que permanece: delimitar o que pode ser decidido, abrir espaço para o que precisa ser investigado e manter o controle de execução no software. O ganho não vem apenas de trocar um modelo. Vem de entender a responsabilidade de cada chamada.
Fontes e critérios editoriais
Verificação realizada em 2 de outubro de 2026. Demonstrações interativas são simulações locais. Valores de fabricantes e avaliações independentes são identificados nos capítulos. Ausência de preço ou documentação pública verificada é tratada como lacuna, sem estimativas inventadas.