¿Qué es Decisions API? La capa de decisiones rápida de OpenAI

Si buscas what is decisions api, la respuesta breve es esta: OpenAI Decisions API es una interfaz en preview limitado para tomar juicios pequeños y acotados dentro del software. En lugar de pedir a un modelo general que escriba un párrafo y después analizarlo, el desarrollador define una pregunta, envía el contexto y deja que el sistema elija entre un conjunto finito de respuestas.

Por eso resulta interesante para clasificación, routing de solicitudes, puertas de herramientas y selección del siguiente paso en un bucle de agente de IA. No sustituye a un modelo general de chat o razonamiento. Es una capa más estrecha situada entre el estado de la aplicación y el código determinista.

OpenAI presentó Decisions API en DevDay 2026. La cobertura del lanzamiento la describe como una versión especializada de GPT-6 Luna, con contexto de texto o imagen, respuestas predefinidas y disponibilidad inicial en preview limitado. También se mencionan unos 150 milisegundos de respuesta y una velocidad aproximadamente diez veces superior a una llamada normal de GPT-6 Luna. Son datos publicados durante el lanzamiento, no una garantía de nivel de servicio.

Esta guía explica el concepto sin tratar la cobertura de terceros como una referencia estable de la API. El contrato de preview, los precios, los límites y las reglas de acceso pueden cambiar. Antes de conectarlo a un flujo crítico, verifica la documentación y el panel actuales de OpenAI, y utiliza estas ideas de arquitectura y evaluación como punto de partida.

Tabla de contenidos

• Decisions API en una frase
• ¿En qué se diferencia una API de decisiones de una Chat API?
• ¿Cómo funciona el bucle de decisión?
• ¿Para qué se puede usar Decisions API?
• ¿Cómo sería una integración?
• OpenAI Decisions API frente a Jev
• ¿Dónde encaja en un agente de IA?
• Latencia, coste y confianza
• ¿Qué hay que verificar antes de producción?
• Preguntas frecuentes

Decisions API en una frase

Decisions API es una interfaz de modelos orientada a decisiones: recibe el contexto de una aplicación y una pregunta acotada, y devuelve una selección estructurada que el software puede utilizar.

La palabra clave es acotada. “Escribe una respuesta útil para este cliente” es una tarea de generación abierta. “¿Qué cola aprobada debe recibir este ticket?” tiene un espacio finito de respuestas. “¿Esta llamada concreta a una herramienta necesita confirmación humana?” también es una pregunta acotada si la aplicación define qué significa “necesita confirmación”.

Una abstracción útil es:

decision = f(state, question, allowed_answers)

La salida no pretende ser un ensayo terminado. Es una señal para el programa que la rodea. El programa sigue teniendo que validar la respuesta, comprobar permisos, aplicar reglas de negocio, registrar el resultado y decidir si una acción está permitida.

La cobertura pública del lanzamiento presenta la preview como una solución para clasificación, routing y selección rápida del siguiente paso de un agente. Según esas descripciones, admite contexto de texto o imagen y una lista limitada de respuestas definidas por el desarrollador. El esquema exacto de request y response debe considerarse provisional hasta que OpenAI actualice su referencia oficial.

¿En qué se diferencia una API de decisiones de una Chat API?

La mayoría de las integraciones de modelos tienen forma de chat: entran mensajes y sale texto libre. Esa flexibilidad es valiosa cuando el producto necesita explicaciones, borradores, síntesis o razonamiento abierto. Es menos cómoda cuando el modelo está dentro de un bucle de control que se ejecuta miles de veces al día.

Imagina que un sistema de soporte recibe este ticket:

Al cliente se le cobró dos veces y los pagos llevan tres días fallando.

Un modelo general puede producir un párrafo útil que mencione facturación, pagos y urgencia. Después, la aplicación tiene que extraer una ruta, validar la etiqueta, manejar texto adicional y decidir qué hacer si el formato se desvía. Una pregunta acotada parte del contrato de software:

Pregunta: ¿Qué cola aprobada es responsable de este ticket?
Respuestas: billing, technical, account, none_of_the_above
Contexto: <estado del ticket>

La diferencia no es solamente “JSON frente a texto”. Una función de salida estructurada puede pedir a un modelo generativo que formatee varios campos como JSON. Una API de decisiones está diseñada alrededor de la elección semántica: el espacio de respuestas se define antes de inferir y el resultado se consume como una señal de decisión.

Los dos caminos pueden resumirse así:

modelo de chat:       prompt -> prose -> parser -> validation -> retry -> action
modelo de decisiones: state + bounded question -> decision -> policy -> action

El segundo camino es más corto, pero no elimina el riesgo. Una respuesta válida puede ser incorrecta y un número de confianza puede no estar calibrado. El modelo no debe recibir permisos solo porque haya elegido “seguro”. La ventaja es que el límite queda más claro: el modelo juzga y el código conserva la autoridad determinista.

Regla práctica de diseño

Usa una API de decisiones cuando la aplicación pueda escribir el espacio de respuestas antes de la llamada. Usa un modelo general cuando haya que generar lenguaje, explorar posibilidades o crear un plan que no pueda reducirse a pocos resultados aprobados.

¿Cómo funciona el bucle de decisión?

Una integración fiable puede diseñarse en cuatro pasos.

1. Captura solo el estado necesario para una decisión

El estado es la evidencia disponible para decidir. Puede ser un ticket, un correo, una llamada a una herramienta propuesta, una captura de pantalla, un objeto compacto reunido desde varios servicios o una lista breve de hechos recuperados.

Mantenlo enfocado. Si para enrutar solo hacen falta el título del ticket, el cuerpo, el nivel de cuenta y los últimos eventos, enviar todo el historial de conversación añade ruido, latencia, exposición de privacidad y coste. Pregunta qué necesitaría ver una persona revisora para responder a esta única cuestión.

2. Escribe una pregunta acotada

La pregunta debe describir un solo juicio. “Clasifica, prioriza, reembolsa y notifica al cliente” esconde varias políticas. Sepáralo en preguntas o pasos de aplicación:

• ¿Qué equipo aprobado debe hacerse cargo?
• ¿Cuál es el impacto operativo en una escala definida?
• ¿La siguiente acción necesita aprobación humana?

Cada pregunta debe tener un espacio de respuestas que una persona pueda revisar. Incluye una salida explícita como none_of_the_above cuando la realidad pueda quedar fuera de las categorías.

3. Define las respuestas permitidas

La aplicación debe ser dueña de las opciones. Para routing pueden ser billing, technical, account y manual_review; para una puerta de herramientas, allow, confirm y block. Para una puntuación de prioridad, utiliza un criterio con definiciones operativas y no solo “bajo” y “alto”.

El diseño de la pregunta forma parte de la política del producto. Cambiar las opciones cambia el significado de los resultados históricos, así que versiona la pregunta, el criterio y la política junto con el identificador del modelo.

4. Aplica la política antes de que actúe el código

La decisión devuelta es una señal. La aplicación debe comprobar permisos, alcance de recursos, validez de los datos y reglas de efectos secundarios. El modelo puede recomendar refund_review; un reembolso real solo debe aprobarlo un servicio autorizado o una persona.

La fórmula segura es:

ruta ejecutable = juicio del modelo ∩ política determinista

La intersección es lo importante. El modelo de decisiones resuelve un juicio semántico ambiguo; el código conserva la autoridad.

¿Para qué se puede usar Decisions API?

Los mejores casos son decisiones estrechas y repetidas en las que el sistema ya sabe qué acción viene después.

Clasificación y routing

Enruta tickets, leads, documentos, incidentes o eventos de moderación a una cola aprobada. La ruta puede depender de intención, área de producto, gravedad, nivel de cliente o varios datos del estado. Una ruta de fallback evita forzar los casos desconocidos dentro de categorías engañosas.

Elegir el siguiente paso de un agente

Un agente puede usar un modelo más potente para entender el objetivo y planificar, y después una capa rápida de decisiones para escoger entre acciones permitidas: buscar, abrir, rellenar, verificar, reintentar, pedir ayuda o terminar. La aplicación anfitriona sigue verificando que la acción exista y que sus argumentos sean seguros.

Puertas para llamadas a herramientas y transacciones

Antes de enviar un correo, cambiar una cuenta, borrar datos, hacer un pago o publicar contenido, pregunta algo concreto sobre la acción propuesta. Combina la respuesta con listas de permitidos, permisos, requisitos de confirmación y auditoría. El modelo ayuda a interpretar la intención, pero no debe ser la única capa de autorización.

Routing de modelos y control de costes

No todas las solicitudes necesitan un modelo frontier. Una capa de decisiones puede enviar lo sencillo a un clasificador rápido, lo complejo a un modelo potente, lo incierto a recuperación y lo sensible a una persona. Enruta capacidades con entradas, latencia, coste y fallback conocidos, no nombres de modelos arbitrarios escondidos en un prompt.

Triage y priorización

Los sistemas de colas suelen necesitar una señal de prioridad coherente, no un resumen escrito. Una puntuación es útil cuando el criterio explica el significado operativo de cada nivel. “Servicio bloqueado” y “impacto menor” son más comprobables que “urgente” y “no urgente” sin definición.

Decisiones visuales

La cobertura del lanzamiento describe el contexto de imagen como una capacidad de la preview. Podría servir para identificar un estado conocido de una interfaz en una captura o dirigir un informe visual al flujo adecuado. Verifica formatos, límites de tamaño, privacidad y precisión con datos etiquetados antes de asumir que está listo para producción.

¿Cómo sería una integración?

Como el contrato de preview puede cambiar, no copies un payload no oficial directamente a producción. Coloca el proveedor detrás de un adaptador pequeño. Lo siguiente es pseudocódigo conceptual:

{
  "context": {
    "ticket": "The customer was charged twice.",
    "account_tier": "business",
    "recent_events": ["payment_succeeded", "payment_succeeded"]
  },
  "question": {
    "name": "route",
    "prompt": "Which approved workflow owns this case?",
    "answers": ["refund_review", "technical_support", "account_security"]
  }
}

El adaptador debe validar la respuesta como unknown, rechazar opciones fuera de la lista permitida y separar incertidumbre de fallo de transporte. Un timeout no equivale a un “no” seguro.

const decision = await decisionsApi.evaluate(request);

if (!allowedRoutes.includes(decision.choice)) {
  return sendToManualReview('Unknown route');
}

if (decision.score < ROUTE_THRESHOLD || !policyAllows(decision.choice)) {
  return sendToManualReview('Uncertain or disallowed route');
}

return dispatch(decision.choice, { auditId, source: 'decisions-api' });

Los nombres de campo son ilustrativos. No asumas que score o confidence es una probabilidad calibrada. Registra el resultado bruto, la versión de la pregunta, la versión de la política, el identificador del modelo, la acción final y el resultado humano posterior para medir si el umbral funciona.

OpenAI Decisions API frente a Jev

La preview de OpenAI y Jev pertenecen a una categoría parecida: decisiones rápidas y estructuradas dentro del software. No son el mismo servicio y la información disponible describe contratos diferentes.

Dimensión	OpenAI Decisions API	Jev AI
Estado descrito por la cobertura actual	Preview limitado en DevDay 2026	Playground y flujo de API públicos
Motor descrito	Versión especializada de GPT-6 Luna	Modelo de decisiones Jev
Entrada descrita públicamente	Contexto de texto o imagen	Texto, objetos JSON y arrays de texto en el sitio público
Idea de salida	Selección entre respuestas del desarrollador, con score mencionado en la cobertura	Resultados tipados Choice, Score y Noul con probabilidades y confidence
Trabajos habituales	Clasificación, routing y siguiente paso de agente	Clasificación, routing, scoring, controles de seguridad y revisión humana
Madurez del contrato	Verificar endpoint, límites, precio y acceso en la preview	Documentación pública y Playground interactivo

La pregunta útil no es “¿qué marca es mejor?”, sino “¿qué contrato puede evaluar y operar mi equipo?”. OpenAI puede resultar atractivo si importan la consolidación de cuentas, el contexto de imagen o el acceso a la preview. Un flujo público de decisiones tipadas puede ser más práctico si se necesita experimentar de inmediato. En ambos casos, define un espacio de respuestas pequeño, reúne ejemplos etiquetados y deja la autoridad final en el código de la aplicación.

¿Dónde encaja en un agente de IA?

Un agente de producción suele tener varias capas separadas:

1. Orquestador: mantiene la tarea, el contexto, los reintentos y el estado del bucle.
2. Modelo generativo: interpreta la intención, planifica, escribe lenguaje o resume evidencias.
3. Capa de decisiones: responde preguntas estrechas sobre ruta, riesgo, prioridad o finalización.
4. Políticas y permisos: imponen lo que el usuario, el agente y la herramienta pueden hacer.
5. Acción y auditoría: ejecutan las llamadas aprobadas y registran lo ocurrido.

Decisions API pertenece a la tercera capa. No debe convertirse silenciosamente en la cuarta. El modelo puede decir que una llamada parece de bajo riesgo, pero no puede conceder un permiso que el motor de políticas no haya concedido.

Para el primer experimento, elige una decisión reversible y de bajo riesgo:

ejemplos históricos
        ↓
pregunta + respuestas permitidas
        ↓
evaluación offline
        ↓
tráfico en shadow mode
        ↓
automatización aprobada por personas
        ↓
ruta de producción monitorizada

El modo shadow es especialmente importante para dinero, acceso, borrado, seguridad y reputación. Compara la decisión del modelo con una etiqueta humana o una regla fiable antes de permitirle cambiar el mundo real.

Latencia, coste y confianza

Latencia

Los informes del lanzamiento citan unos 150 milisegundos y una velocidad aproximadamente diez veces superior a una llamada normal de GPT-6 Luna. Es una dirección interesante para bucles de agentes de alta frecuencia, pero la aplicación debe medir por sí misma p50, p95 y p99. La red, el tamaño del contexto, la concurrencia, los reintentos y las colas pueden dominar el tiempo del modelo.

Coste

Un endpoint de decisiones puede reducir el coste al evitar explicaciones largas y sacar las solicitudes sencillas de modelos caros. Incluye en la economía unitaria el contexto, los reintentos, la observabilidad, las llamadas posteriores y la revisión humana. Verifica los precios de preview en la cuenta actual de OpenAI.

Confianza y calibración

Un score es evidencia, no permiso. Un resultado de 0.92 todavía puede ser erróneo para un idioma, segmento de clientes o entrada adversarial concretos. Mide como mínimo:

• coincidencia con etiquetas revisadas;
• falsos positivos y falsos negativos para cada acción costosa;
• cobertura de automatización en cada umbral;
• calibración por clase, idioma, tipo de entrada y segmento;
• volumen de revisión humana y tiempo de resolución;
• drift después de cambios de modelo, pregunta, política o producto.

Si la mejor opción y la segunda están muy cerca, la etiqueta superior puede ser frágil. Conserva una ruta de abstención o revisión. Para acciones de alto impacto, utiliza dos llaves: el modelo recomienda una ruta y la política determinista o una persona la autoriza.

¿Qué hay que verificar antes de producción?

Las fuentes públicas describen Decisions API como una preview limitada. Antes de integrarla profundamente, verifica:

1. el endpoint oficial, el alcance de autenticación y el esquema actual de la solicitud;
2. si la entrada de imágenes está habilitada para tu cuenta y caso de uso;
3. cómo se define el conjunto de respuestas y si admite varias preguntas;
4. qué significa el score devuelto y si está calibrado o solo informado por el modelo;
5. límites, latencia esperada, rate limits, reintentos y códigos de error;
6. retención de datos, controles de privacidad y disponibilidad regional;
7. unidad de facturación, incluidas llamadas fallidas, repetidas o agrupadas;
8. fijación de versión del modelo y proceso para cambios de preview.

Mantén la integración detrás de un adaptador estrecho. Versiona preguntas y políticas, elimina estados sensibles de los logs y trata el contenido del usuario como datos, no como política. Si el proveedor no está disponible, envía el caso a una cola segura o a una persona en lugar de adivinar.

Preguntas frecuentes

¿Decisions API sustituye a ChatGPT o a una Responses API general?

No. Es mejor verla como una capa especializada de decisiones. La generación, la planificación, la orquestación de herramientas, las explicaciones y el texto para usuarios corresponden a un modelo general. Un endpoint de decisiones sirve para un juicio estrecho entre resultados aprobados.

¿Devuelve texto Decisions API?

La descripción pública destaca la selección entre respuestas definidas por el desarrollador, no la generación de párrafos libres. Aunque el transporte use JSON, la aplicación necesita principalmente el valor de la decisión y sus metadatos.

¿Puede elegir el siguiente paso de un agente?

Es uno de los casos de uso públicos más claros. Limita el conjunto de acciones y valida herramienta, argumentos, permisos, alcance del recurso y requisito de confirmación antes de ejecutar.

¿Confidence es lo mismo que precisión?

No. Puede ayudar a ordenar o enrutar casos, pero debe evaluarse contra resultados reales. Para decisiones costosas, añade umbrales, abstención, revisión humana, reglas deterministas y monitorización.

¿Deberían usarla los desarrolladores ahora?

Si tu cuenta tiene acceso y el flujo tolera cambios de preview, empieza con un experimento controlado. Haz primero evaluación offline o en shadow mode, no automatización irreversible. Comprende el patrón de decisiones tipadas antes de diseñar el adaptador.

¿Cuál es la conclusión principal?

Decisions API representa el paso de “pide al modelo que escriba algo” a “pide al modelo un juicio pequeño y tipado”. Puede hacer más rápidos y fáciles de integrar la clasificación, el routing y los bucles de agentes. La fiabilidad sigue exigiendo un espacio de respuestas claro, evaluación con datos representativos, código como autoridad y confianza como evidencia, no como permiso.

Fuentes

• Anuncio oficial de OpenAI DevDay 2026
• The Decoder: OpenAI expands Codex and its API at DevDay.
• Pasquale Pillitteri: OpenAI launches Decisions API to take on Jev.