La Decisions API de OpenAI: preguntar en vez de generar

El 22 de octubre de 2026 OpenAI abrió al público general su Decisions API. Llevaba en beta desde el 6 de octubre y se presentó en el DevDay del 29 de septiembre. No es un modelo nuevo: es otra forma de llamar al modelo.

Qué hace distinto

En vez de pedirle texto, le defines preguntas con respuestas cerradas y recibes una de tres cosas:

predicate: probabilidad entre 0 y 1 de que una condición sea cierta.
choice: una opción de tu lista, con sus probabilidades y un nivel de confianza.
score: nota sobre una rúbrica ordenada, devuelta como media ponderada por probabilidad.

Corre sobre gpt-6-luna en un endpoint propio, acepta texto, imágenes y JSON estructurado, y admite hasta 400 preguntas por petición. Precio: 0,10 $ por millón de tokens de entrada, 0,01 $ si van cacheados, y nada por la salida. No hay salida que cobrar: solo el veredicto.

Por qué importa

Quien haya montado un clasificador con un LLM ha acabado igual: prompt largo pidiendo JSON, temperatura 0, un try/except por si el modelo se pone creativo y una factura que crece con cada ticket. Funciona, pero estás pagando generación de texto para obtener un booleano.

Aquí el modelo no escribe. Devuelve la decisión y su confianza. Eso cambia tres cosas en tu arquitectura:

Desaparece el parser. No hay prosa que rescatar con una regex.
La confianza es un número que puedes usar. Umbral alto, automático; umbral bajo, respuesta fija o cola humana; en medio, revisión. Eso es lo que hace defendible un flujo automático delante de un cliente.
El coste por decisión cae. Sin tokens de salida y con el contexto cacheado a una décima parte, clasificar lotes deja de comerse el presupuesto.

Dónde lo metería

Triage de tickets: dos preguntas bien definidas (¿es facturación o bug?, ¿urgencia?) y enrutado directo al equipo que toca.
Guardarraíles de agentes: antes de ejecutar un comando o una escritura en base de datos que ha generado el modelo, una pregunta de riesgo. Datadog lo usa justo para eso con los comandos de su agente.
Extracción de documentos: albaranes, pólizas, facturas de proveedor. Una batería de predicates en una sola llamada y te ahorras el parseo del PDF a texto y vuelta.
Enrutado dentro de un agente: qué herramienta toca ahora. Sierra lo aplica para elegir el siguiente paso en conversaciones en vivo.
Backoffice propio: categorizar descripciones de movimientos, puntuar leads, decidir si un email entra en cola prioritaria.

Los peros

Los números del anuncio son del proveedor: hasta 10 veces más rápido que la misma pregunta por la Responses API, 280 ms de p95 en el caso de Sierra, 40 veces mejor p95 en Datadog. Son cargas concretas de clientes, no una garantía para la tuya. Mídelo con tus datos antes de rediseñar nada.

El schema exacto de la petición está en la referencia de la API, no en los blogs. Léelo antes de escribir el cliente: los ejemplos que circulan son ilustrativos y los nombres de campo cambian entre borradores.

Y esto no sustituye al chat. Si necesitas redactar, resumir o razonar en abierto, sigue siendo Responses o Completions. La propia OpenAI lo enmarca como preguntas con respuesta acotada; forzarlo para lo demás sale peor y más caro.

El último riesgo es de diseño, no de API: tu lógica de negocio acaba expresada como umbrales sobre las probabilidades de un proveedor. Calibra esos umbrales con 100 o 200 casos etiquetados por ti, y guarda en base de datos la decisión, la confianza y la versión del modelo. Cuando el modelo cambie, querrás poder comparar.

La Decisions API abre una categoría: TypeSafe lleva desde el 15 de septiembre de 2026 vendiendo lo mismo con modelos propios. Que haya competencia ya es un aviso. Si mañana quieres cambiar de proveedor, la decisión de qué endpoint usa tu clasificador no debería estar repartida en cuarenta sitios del código. Aíslala detrás de una función propia y que el resto del sistema no sepa quién responde.