OpenAI Decisions API: o que decisões tipadas mudam no software
A nova Decisions API da OpenAI retorna probabilidades, escolhas e pontuações para roteamento e triagem. Veja o que desenvolvedores e compradores devem avaliar.

Resumo do Artigo
This article covers OpenAI Decisions API: o que decisões tipadas mudam no software. A nova Decisions API da OpenAI retorna probabilidades, escolhas e pontuações para roteamento e triagem. Veja o que desenvolvedores e compradores devem avaliar.
Pontos-Chave
- Published: October 8, 2026
- Category: Artificial Intelligence
- Tags: OpenAI, Decisions API, AI software, developer tools, workflow automation
- Views: 118
- Reading time: ~12 min read
"A nova Decisions API da OpenAI retorna probabilidades, escolhas e pontuações para roteamento e triagem. Veja o que desenvolvedores e compradores devem avaliar."

Resumo: o software de IA está ganhando um endpoint de decisão
A OpenAI anunciou a Decisions API em beta em 6 de outubro de 2026. Ela é mais limitada que uma API geral de geração: avalia texto, imagens ou os dois e devolve respostas tipadas que o software pode usar. O guia oficial descreve três formatos: uma probabilidade de predicado, uma escolha dentro de um conjunto fixo ou uma pontuação baseada em níveis ordenados. A OpenAI afirma que essas tarefas podem ser até dez vezes mais rápidas que o uso da Responses API.
Isso não torna o endpoint um substituto universal para geração. Ele pode ser mais adequado para roteamento, triagem, moderação, priorização e inspeção de imagens quando o aplicativo precisa de um resultado limitado, não de um parágrafo. Leia o guia oficial da Decisions API e compare ferramentas relacionadas no diretório de software da BTTC.
O que foi lançado
O novo endpoint é POST /v1/decisions. A requisição tem um modelo, uma entrada compartilhada e uma ou mais perguntas nomeadas. O guia público lista gpt-6-luna como o único modelo disponível no momento. Cada pergunta explica o que deve ser avaliado e, quando necessário, define escolhas permitidas ou níveis de pontuação. A resposta traz um array de respostas identificadas pelo nome da pergunta.
A separação entre evidência e formato de saída é o ponto principal. Uma reclamação pode ser encaminhada para cobrança, suporte técnico, entrega ou outra fila. Uma foto pode ser avaliada quanto a danos visíveis. Um documento pode receber uma nota de severidade. Esses casos não precisam necessariamente de texto aberto; precisam de um resultado que uma fila, regra, painel ou fluxo possa consumir.
Use predicate para verificar uma condição, choice para categorias sem ordem natural e score para níveis ordenados. Perguntas independentes podem compartilhar uma requisição. Se uma resposta determina a próxima pergunta, faça outra requisição para manter a dependência explícita.
Por que isso afeta a arquitetura
Muitos produtos ainda tratam toda chamada de IA como chat. Isso é prático no protótipo, mas aumenta o trabalho em produção: interpretar texto, lidar com campos ausentes, definir fallback e testar se uma resposta pode iniciar uma ação.
Um resultado tipado deixa a fronteira mais clara. Uma probabilidade pode ser comparada com um limite, uma escolha pode indicar uma fila e uma pontuação pode abrir uma faixa de revisão humana. A incerteza não desaparece; ela vira um valor que a aplicação consegue medir e governar.
Se o usuário precisa de explicação, objeto JSON personalizado, chamada de ferramenta ou texto longo, Responses com Structured Outputs ou function calling pode ser melhor. Se o app precisa apenas de classificação ou ranking limitado, um endpoint dedicado pode reduzir latência e simplificar o código.
Quatro verificações antes da produção
1. Escreva perguntas observáveis
“É um bom cliente e devemos priorizar o caso?” mistura julgamentos. Separe em “a mensagem descreve um problema de cobrança?” e “ela contém um prazo?” Perguntas distintas são mais fáceis de testar. Para imagens, descreva critérios visíveis em vez de pedir uma opinião geral.
2. Defina limites com exemplos rotulados
Uma probabilidade não é uma regra de negócio pronta. Use exemplos representativos, meça falsos positivos e falsos negativos e escolha o limite conforme o custo de cada erro. Recalibre quando mudarem tráfego, idioma, produtos ou padrões de abuso.
3. Preserve evidências e revisão
O resultado deve ser rastreável à entrada, à pergunta, à versão do modelo, ao limite e a qualquer substituição humana. A documentação de controles de dados da OpenAI explica retenção e processamento regional para /v1/decisions, incluindo Zero Data Retention para clientes elegíveis. Confirme os termos aplicáveis antes de enviar dados sensíveis.
4. Prepare falhas e fallback
Limites de taxa, timeout, entrada inválida e casos ambíguos são normais. Defina o que acontece quando a API falha, a confiança é baixa ou a nota cai entre dois níveis. Uma revisão humana ou uma fila sem ação irreversível costuma ser um padrão mais seguro.
Mais rápido não significa automaticamente mais barato
O guia informa preço de entrada de US$ 0,10 por 1 milhão de tokens para gpt-6-luna, mas podem existir adicionais regionais e multiplicadores de contexto longo. Compare também tentativas, monitoramento, rotulagem, revisão, armazenamento, integração e o custo de roteamento errado. Um modelo rápido que encaminha casos à equipe errada pode custar mais que um fluxo mais lento com uma boa barreira de revisão.
Ao escolher ferramentas ao redor da API, procure logs, replay, controles de limite, exportação, permissões e disponibilidade clara do modelo. Uma demonstração bonita não basta se o produto não mostra evidências, não recupera falhas parciais ou não permite trocar de fornecedor.
Perguntas frequentes
A documentação oficial é a fonte principal para o comportamento do beta e os modelos suportados.
Conclusão
A Decisions API mostra uma divisão útil: geração para trabalho rico em linguagem e decisões tipadas para lógica limitada de aplicativos. Ela pode simplificar roteamento e triagem, mas exige perguntas mensuráveis, limites calibrados, rastreabilidade, revisão de privacidade e fallback seguro.

