Decisions API: preguntas acotadas

1. Qué cambia cuando el modelo debe decidir

Una guía para separar clasificación y elección de la generación abierta, con un método claro para evaluar límites, coste y supervisión humana.

OpenAI anunció el 22 de octubre de 2026 la disponibilidad general de Decisions API, basada en GPT‑6 Luna, para preguntas acotadas con texto, imágenes o JSON.

Acotada describe una frontera de producto. En vez de pedir un texto que quizá sirva para muchas cosas, la aplicación pregunta algo pequeño y determina de antemano qué respuestas puede aceptar. Un asistente puede explicar por qué una solicitud parece urgente; un componente de decisión puede elegir si requiere revisión ahora o puede esperar. El primer caso produce lenguaje para una persona. El segundo alimenta una regla que la aplicación todavía debe controlar.

La primera decisión es operativa: qué resultado se quiere y qué no podrá hacer por sí solo. Un clasificador puede sugerir una cola, pero no bloquear una cuenta ni aprobar un pago. Su utilidad depende de un flujo verificable, con responsables y una salida para los casos dudosos.

2. Un modelo mental: contrato antes que llamada

Piensa en la decisión como un contrato de cuatro piezas: una entrada, una pregunta, un conjunto de salidas aceptables y una política posterior. La entrada debe contener solo las señales necesarias. La pregunta describe una tarea específica y limita qué debe resolver. Las salidas reducen la ambigüedad. La política define qué ocurre después, quién puede revisar y cómo se corrige un error.

Una opción sirve cuando cada caso entra en una categoría. Una probabilidad puede ordenar casos, pero no implica calibración sin medirla. Una puntuación ayuda solo si cada nivel tiene ejemplos que el equipo interpreta igual. Si la diferencia entre niveles no es verificable, el contrato no está listo.

Incluye casos límite: temas mezclados, imagen ilegible, datos contradictorios y entradas fuera de las opciones. Define una reacción segura para cada uno; otra o revisión humana pueden ser salidas deliberadas. Así evitas forzar una etiqueta cuando el contrato no contempla el caso.

3. Qué entra y qué debe hacer tu aplicación

La guía describe tres respuestas: predicate estima probabilidad, choice elige y score puntúa.

Para entender las salidas, imagina tres preguntas distintas sobre la misma solicitud: si parece urgente, a qué equipo corresponde y qué nivel de una rúbrica describe mejor su impacto. En una prueba ficticia, una probabilidad de 0,8 no significa que este caso esté comprobado ni que el sistema acierte siempre ocho de cada diez veces. Para sostener esa interpretación tendrías que contrastar muchos casos comparables con una referencia revisada. La etiqueta elegida y la calidad de esa elección también deben evaluarse por separado.

Una ruta no define por sí sola una integración robusta. Antes de llamar, normaliza los datos, elimina campos que no aportan y conserva un identificador de caso que permita seguir el resultado. Después valida que la respuesta corresponde a una salida permitida. Si falta el valor, es inválido o la solicitud falla, establece una alternativa segura: mantener el caso pendiente, pedir revisión o mostrar un error recuperable. No sustituyas un fallo por la primera opción de una lista.

Imagina que la pregunta es ¿qué equipo debería revisar primero este mensaje? y las opciones son acceso, facturación y seguridad. La aplicación puede crear una tarea preliminar en la cola sugerida, pero una persona conserva el control de prioridad y cierre. Si el resultado recomienda seguridad, se puede enviar a una revisión más urgente; la regla que permite ese cambio vive en el producto, no en la clasificación. Así, los permisos no quedan ocultos en un prompt.

La aplicación debe decidir además qué registrar. Para depurar quizá basten la versión del contrato, la etiqueta, el tiempo de respuesta y si alguien la corrigió. Guardar el texto completo de cada solicitud puede ser innecesario y elevar el riesgo de privacidad. Define retención, acceso y propósito antes de ampliar el volumen. Una salida estructurada es más fácil de auditar solo si el sistema conserva el contexto mínimo que explica el resultado.

4. Disponibilidad, límites por solicitud y voz

OpenAI anuncia hasta 400 preguntas por solicitud e integración con GPT‑Live.

Ese número describe un límite anunciado por solicitud, no el rendimiento garantizado de cualquier cuenta. Un máximo alto tampoco convierte un lote grande en una buena decisión de ingeniería: un error puede afectar muchos casos y una revisión se vuelve más difícil. Empieza con lotes pequeños, mide respuestas inválidas y tiempo total, y aumenta el tamaño solo cuando el resultado siga siendo trazable.

La integración con voz sugiere decisiones durante una conversación, como escoger cuál alternativa presentar después. Aquí importan interrupciones, confirmación y comprensión del usuario. Una voz fluida no convierte una clasificación en asesoría autorizada. Si el siguiente paso reserva, modifica o deriva algo importante, permite que la persona vea la propuesta y confirme antes de que el sistema actúe.

Disponibilidad general es el hito comunicado por OpenAI, no una garantía de acceso para toda cuenta, país o contrato. Antes de diseñar producción, verifica las condiciones de tu cuenta y las funciones que realmente necesitas. Un titular de lanzamiento no resuelve una habilitación regional o comercial que el equipo aún no ha comprobado.

5. Coste: mirar la petición completa

OpenAI publica US$0,10 por millón de tokens de entrada no cacheada, sin cargo de salida. Caché, región y contexto largo tienen condiciones propias.

La tarifa de entrada no equivale al costo de una decisión terminada. Calcula el volumen real: solicitudes diarias, tokens medios y máximos, contexto reutilizado, reintentos y proporción de casos que necesita revisión humana. La operación también consume tiempo del equipo. Una tarifa por millón da una base para estimar, no el precio final de un flujo con caché, contexto largo y reglas de región.

Un ejemplo hipotético permite hacer la cuenta: 2.000 solicitudes al día con 150 tokens de entrada cada una suman 300.000 tokens diarios. Es el 30 % de un millón; multiplica esa fracción por la tarifa aplicable a ese tipo de entrada. Después incorpora las repeticiones y la revisión humana por separado. Los números del ejemplo son inventados para explicar el cálculo; no describen consumo, ahorro ni resultados de un cliente.

Arma tres escenarios: uso esperado, un pico de demanda y una solicitud con contexto más extenso. Para cada uno anota el volumen, la tasa de error, las derivaciones y el esfuerzo humano. Si el ahorro solo aparece cuando todas las respuestas se aceptan sin revisión o todos los casos son breves, la hipótesis económica todavía no está probada. Guarda los supuestos junto a la evaluación para que finanzas pueda cambiar los valores.

Compara la misma tarea con lo que hoy hace el equipo. Para un volumen bajo, una revisión manual puede ser más sencilla; para categorías estables, una regla determinista puede bastar; para una explicación amplia, la generación abierta puede encajar mejor. La decisión correcta compara el costo del flujo completo con una calidad acordada, no dos tarifas aisladas.

Los precios pueden cambiar. Antes de un lanzamiento, vuelve a comprobar la tabla de la cuenta y región efectivas, mide un piloto limitado y define una alerta presupuestaria. Si se habilita caché, separa lecturas y escrituras en la estimación y asegúrate de que el contexto reutilizado siga vigente. Un descuento deja de ser una ventaja si la información cacheada ya no representa el caso.

6. Región, datos y elegibilidad

OpenAI admite procesamiento regional en Estados Unidos y Europa (EEE y Suiza); la retención cero requiere elegibilidad.

Residencia y procesamiento responden preguntas distintas: dónde puede mantenerse un dato y dónde se procesa. Ninguna frase acredita por sí sola cumplimiento o habilitación. Comprueba cuenta, acuerdos y modalidad con privacidad y seguridad; si falta confirmación, déjala como requisito pendiente.

Un piloto prudente usa casos controlados y representativos antes de tocar operaciones reales. Casos con pagos, identidad, salud, seguridad o acceso requieren reglas de escalamiento que no descansen en una puntuación. Un anuncio general no confirma todas las condiciones de una cuenta concreta. Antes de operar desde Chile, comprueba que la modalidad elegida admite tu cuenta y tus datos. Confirma país, cuenta y modalidad antes de comprometer fechas.

7. Rendimiento: medir el recorrido, no el titular

OpenAI afirma hasta 10× más rapidez frente a GPT‑6 Luna por Responses API.

La comparación del proveedor sirve para plantear una prueba, no para predecir el resultado de toda carga. El tiempo depende de la pregunta, el contexto, el tamaño del lote, la región y el resto de la aplicación. Una respuesta más rápida con más errores puede empeorar el servicio. Compara la misma tarea, los mismos ejemplos y condiciones equivalentes con la alternativa actual.

Mide mediana y percentiles altos; un promedio rápido puede esconder solicitudes lentas en sesiones de voz. Registra aciertos, errores, abstenciones, resultados inválidos y derivaciones. Si se devuelve una probabilidad, evalúa si ordena los casos de forma útil; no asumas calibración porque aparezca un número. Define por adelantado qué error es aceptable y cuál debe detener el piloto.

Incluye grupos distintos: idioma, tipo de entrada y categoría. Una media global puede esconder que las imágenes generan más errores o que una opción concreta se asigna mal. Si cambian pregunta, opciones o muestra, vuelve a evaluar. Una revisión independiente de un conjunto etiquetado ayuda a separar una mejora real de una impresión favorable.

8. Caso hipotético: priorizar solicitudes de soporte

Supongamos que una empresa recibe mensajes sobre acceso, facturación y seguridad. El objetivo hipotético no es responder al cliente ni cerrar un caso: es sugerir cuál equipo debería leerlo primero. El producto limita los datos enviados a la descripción necesaria, incluye una opción otra o insuficiente y deriva los mensajes contradictorios a una persona. Este ejemplo es una aplicación editorial; no es un cliente ni un caso de uso declarado por OpenAI.

El equipo prepara cien solicitudes ya revisadas por personas y acuerda una etiqueta de referencia para cada una. Luego reserva una muestra distinta para evaluación, sin ajustar las reglas mirando sus respuestas. Para cada opción cuenta aciertos, errores que cambian la prioridad y casos que terminan en otra. Si una alerta de seguridad se clasifica como facturación, el costo de ese error puede superar varios minutos ahorrados; por eso el porcentaje global de aciertos no basta.

La política de prueba puede ser sencilla: una sugerencia clara crea una tarea preliminar, un caso ambiguo queda pendiente y la categoría sensible siempre pasa por revisión. Los umbrales se eligen comparando falsos positivos, falsos negativos y carga del equipo. No se adoptan porque un número parezca convincente. Si una puntuación no distingue los grupos que importan, una opción directa con ruta de abstención puede ser más fácil de explicar.

9. Cómo decidir si vale la pena probarla

Empieza con una pregunta frecuente, acotada y reversible. Escribe las salidas, el costo de cada error y quién aprueba la acción. Compara casos límite con el flujo actual; registra tiempo, costo completo y correcciones humanas. Mantén revisión hasta superar criterios definidos antes del piloto.

Aplaza la prueba si las opciones no están claras, el daño de un error no puede contenerse o el presupuesto depende de una región no confirmada. Mejora el contrato, reduce datos o crea una revisión antes de llamar al modelo.

Para evaluar agentes, revisa la evaluación de agentes con SPIRECLIMB. Para resguardar revisiones, consulta cómo preservar la evidencia en una revisión de agentes. Su relación temática no demuestra calidad de esta API.

Fuentes: anuncio OpenAI y guía API.