Quando não usar a Decisions API da OpenAI: os casos em que uma regra simples em código resolve melhor

Fala aí, beleza? A OpenAI soltou a Decisions API e, de cara, bate aquela vontade de mandar TODA decisão do sistema pra IA 😀

Só que nem toda decisão precisa de um modelo

A API foi apresentada no DevDay de 29 de setembro de 2026 e está em beta pública, aberta a todos os desenvolvedores, desde 6 de outubro de 2026

Ela é rápida, é barata e devolve resposta tipada… e é justamente por isso que fica tentador usar pra tudo

Neste post a ideia é separar duas coisas: decisão de julgamento (onde a API faz sentido) e regra determinística (que deve continuar no bom e velho if)

É a mesma lógica de quando não usar o Claude Code: ferramenta boa no lugar errado só te deixa mais lento

Um aviso antes: o veredito aqui é análise editorial nossa, não uma orientação oficial da OpenAI, beleza?

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que a Decisions API faz (e o que ela não faz)

Antes de falar dos limites, vale entender o que a ferramenta entrega de fato

Ela é um produto da OpenAI e roda em cima de uma versão especializada do GPT-6 Luna

O endpoint é o POST /v1/decisions

E aqui vem o ponto principal: ela não gera texto livre

Você envia um contexto (texto ou imagem) e perguntas com respostas delimitadas que você mesmo definiu antes, e o modelo devolve respostas tipadas

Imagens precisam ir inline como data URL em base64

Quais são os tipos de pergunta da Decisions API?

São três, e cada um devolve um formato diferente:

• predicate: checa uma condição e devolve uma probabilidade de 0 a 1 de ela ser verdadeira
• choice: escolhe uma das opções que você forneceu (categorias sem ordem, tipo departamentos) e devolve a opção junto com um score de confiança
• score: avalia a entrada contra níveis ordenados (tipo severidade) e devolve a média dos índices dos níveis ponderada pela probabilidade, que pode cair entre dois níveis

A resposta vem num array answers, e cada pergunta precisa ter um name único, que a API repete na resposta pra você saber qual resposta é de qual pergunta

A resposta dessa API é determinística?

Não, e isso é o que mais importa pra este post

Toda saída é probabilística: probabilidade, score de confiança ou média ponderada

Ou seja, a API te diz o quão provável é algo ser verdade, não se é verdade

Pra muita coisa isso é ótimo… e pra outras é exatamente o problema 🙂

Sinais de que seu problema é determinístico e deve ficar em código

Se liga nessa lista

Se a sua decisão encaixa em algum desses sinais, a chance de você precisar de um modelo é bem baixa

Campo obrigatório preenchido ou vazio

Exemplo: o formulário só pode seguir se o campo email tiver valor

Isso é true ou false, sem meio-termo

Uma probabilidade de 0,97 de "o campo está preenchido" é pior que a resposta exata que uma linha de código te dá de graça

Valor numérico acima ou abaixo de X

Exemplo: pedido acima de um certo valor vai pra aprovação manual

Comparar dois números é a coisa mais determinística que existe na programação

Perguntar isso pra um modelo e receber "provavelmente sim" é tipo pedir pro colega conferir se 2 é maior que 1 haha

Formato ou extensão de arquivo

Exemplo: só aceitar upload em .pdf ou .png

A extensão está no nome do arquivo e o tipo dá pra checar no próprio código

Não tem interpretação nenhuma aqui, então não tem por que pagar por uma resposta com score de confiança

Data dentro de um intervalo

Exemplo: cupom válido só entre duas datas

Comparação de data dá sempre o mesmo resultado pra mesma entrada

E se o resultado mudar entre duas chamadas iguais, você vai passar uma tarde inteira caçando bug que não é bug

Valor pertence a uma lista fechada conhecida

Exemplo: o estado informado precisa ser uma das siglas válidas

Se a lista é fechada e você conhece todos os itens, um includes ou um in resolve

O tipo choice da API faz sentido quando a entrada é bagunçada e precisa ser interpretada, não quando ela já chega exatamente igual a um item da lista

Regra de negócio que precisa ser auditável

Exemplo: política de reembolso, cálculo de elegibilidade, bloqueio por compliance

Aqui o problema não é nem custo, é explicar a decisão

Com código, você aponta a linha que tomou a decisão e ela vai dar sempre o mesmo resultado

Com uma resposta probabilística, você tem uma confiança, não uma regra que dá pra auditar linha por linha

Como fica isso em código?

Nada de mágica: é if mesmo

O pseudocódigo abaixo é genérico, sem SDK e sem parâmetro de nenhuma API:

função validarPedido(pedido):
    se pedido.email estiver vazio:
        retornar "bloqueado: email obrigatório"

    se pedido.valor > LIMITE_APROVACAO:
        retornar "aprovação manual"

    se extensão(pedido.anexo) não estiver em ["pdf", "png"]:
        retornar "bloqueado: formato inválido"

    se pedido.data fora de [DATA_INICIO, DATA_FIM]:
        retornar "bloqueado: fora do período"

    retornar "aprovado"

Cada linha dessa dá sempre o mesmo resultado, roda local e não custa nada por chamada

Não precisa de PC da Nasa nem de beta pública pra isso 😛

Regra em código x Decisions API: comparação direta

Colocando lado a lado fica mais fácil enxergar onde cada um ganha:

Repara que a API é rápida pra uma chamada de modelo: os cerca de 150 ms divulgados se comparam a cerca de 1,6 s de uma chamada padrão ao Luna

Mas comparar com outra chamada de modelo é uma coisa, comparar com um if local é outra bem diferente

E se a decisão nem precisa de resposta na hora, vale pensar também em processamento em lote em vez de chamada síncrona

Quando a Decisions API vale a pena

Agora o contraponto honesto, porque a ferramenta é muiiito útil no lugar certo

Os casos divulgados no lançamento foram três:

• Classificar conteúdo: por exemplo, decidir se um comentário é spam, reclamação ou elogio
• Rotear requisições: mandar um ticket de suporte pro departamento certo a partir do que o cliente escreveu
• Escolher a próxima ação de um agente: em uma única chamada, em vez de pedir texto livre e ficar parseando

Qual é o critério pra usar a API?

A pergunta-chave é: dá pra escrever a regra?

Se a entrada é texto livre ou imagem e a decisão depende de interpretação, escrever um if vira uma pilha de exceções que nunca termina

Aí sim um modelo que devolve uma resposta tipada, dentro das opções que você definiu, faz MUITO sentido

E como a resposta já vem tipada, você não precisa caçar a decisão no meio de um texto gerado

E o padrão híbrido?

Na maioria dos sistemas reais a resposta não é "código OU IA", é os dois em sequência

Primeiro você filtra com regras em código tudo que é determinístico

Só o que sobrou ambíguo vai pra API

função triarTicket(ticket):
    se ticket.texto estiver vazio:
        retornar "descartar"

    se ticket.cliente estiver em LISTA_PRIORITARIA:
        retornar "fila prioritária"

    // só chega aqui o que depende de interpretação do texto
    retornar decidirComModelo(ticket.texto)

O decidirComModelo aí é só um nome ilustrativo pra chamada ao POST /v1/decisions, não é função de SDK nenhum

Assim você paga e espera pela IA só onde ela agrega, e o resto continua exato, local e auditável

Veredito: regra simples primeiro, IA só no que é ambíguo

A API é barata e rápida pra uma chamada de modelo, isso é fato

Porém, ela continua sendo probabilística, externa e em beta

Então o veredito é simples: se dá pra escrever o if, escreva o if

Nada de colocar modelo pra conferir se um campo está vazio, isso é o código zoado do modo 100% vibe coder haha

Checklist antes de chamar o endpoint:

1. A decisão depende de interpretar texto livre ou imagem? Se não, fica em código
2. Dá pra escrever a regra em poucas linhas sem virar uma lista infinita de exceções? Se dá, fica em código
3. A regra precisa dar sempre o mesmo resultado e ser auditável? Se sim, fica em código
4. Uma resposta com probabilidade ou score de confiança é aceitável pro seu caso? Se não, fica em código
5. Seu sistema aguenta depender de um serviço externo que ainda está em beta? Se não, pense duas vezes
6. Sobrou só a parte ambígua depois dos filtros? Aí sim, essa parte é candidata à API

Próximo passo: audite suas decisões antes de integrar

Antes de sair integrando, faz um exercício rápido

Lista todas as decisões que o seu sistema toma hoje

Marca quais são determinísticas (campo, valor, formato, data, lista fechada, regra auditável): essas ficam em código

Marca quais dependem de interpretação de texto ou imagem: essas são as candidatas à API

E lembra que a API está em beta pública e o GA ainda não tem data definida

Ou seja, começa pequeno, pela parte ambígua, e deixa o resto no if que já funciona 🙂

Até o próximo post!