Decisions API de OpenAI: decisiones rápidas sin convertir la confianza en certeza

OpenAI ha lanzado el 22 de octubre de 2026 la versión general de Decisions API, un servicio pensado para resolver una clase muy concreta de problemas: tomar decisiones acotadas y estructuradas dentro de una aplicación. No redacta un informe ni mantiene una conversación abierta. Recibe texto, imágenes o datos JSON y devuelve una probabilidad, una opción de una lista o una puntuación. La promesa es hacerlo con menos latencia y coste que una llamada convencional a un modelo generativo.

La idea parece sencilla, pero cambia una pieza importante de la arquitectura de los agentes. Muchas aplicaciones no necesitan “pensar” durante varios segundos para cada paso. Necesitan decidir si una solicitud pertenece a facturación o soporte, si una fotografía muestra un daño, si una respuesta requiere revisión o qué acción debe ejecutarse a continuación. Decisions API intenta ocupar ese espacio intermedio entre una regla rígida y una generación libre.

Qué ha anunciado OpenAI exactamente

La presentación oficial de Decisions API afirma que el servicio ya está disponible de forma general y utiliza GPT‑6 Luna. Según OpenAI, puede trabajar con texto, imágenes y entradas estructuradas hasta diez veces más rápido que GPT‑6 Luna a través de Responses API. Desde la beta pública se han añadido caché de instrucciones repetidas, integración con GPT‑Live, residencia de inferencia en Estados Unidos y Europa, soporte de JSON nativo e imágenes asociadas a cada pregunta.

También aumenta el número máximo de preguntas por solicitud de 200 a 400. Eso permite reutilizar un mismo contexto —por ejemplo, la ficha completa de un cliente o un documento— para resolver varias clasificaciones sin repetir todo el intercambio. La ventaja práctica no consiste solo en “hacer más llamadas”, sino en separar el contexto común de las preguntas concretas y reducir trabajo redundante.

La documentación técnica describe tres tipos de respuesta:

No es una respuesta más corta de un chatbot

La diferencia fundamental está en el contrato de salida. En un chat abierto, el modelo puede explicar, matizar o proponer alternativas. En una decisión acotada, el desarrollador define previamente qué pregunta se formula y qué respuestas son válidas. El sistema devuelve un dato que otra parte del programa puede usar. Esa rigidez facilita la integración, pero también traslada mucha responsabilidad al diseño de la pregunta.

Una mala taxonomía produce una decisión aparentemente ordenada y, sin embargo, inútil. Si un formulario de soporte solo permite “ventas”, “facturación” o “error técnico”, una petición relacionada con privacidad será forzada hacia una categoría incorrecta. El modelo no puede inventar una cuarta salida si el esquema no la admite. Por eso conviene incluir opciones como “no determinado”, “necesita contexto” o “revisión humana” cuando el dominio no sea completamente cerrado.

También importa distinguir clasificación de autorización. Determinar que una solicitud parece legítima no equivale a conceder acceso; puntuar un comando como poco arriesgado no garantiza que sea seguro; detectar un posible daño en una imagen no demuestra su causa ni su fecha. Decisions API puede informar un control, pero no debería sustituir los controles deterministas, los permisos ni las comprobaciones externas.

Dónde puede aportar valor

1. Enrutamiento de atención y operaciones

Una empresa puede clasificar mensajes por tema, prioridad o idioma y enviarlos al equipo adecuado. El beneficio aparece cuando hay volumen y las categorías son estables. En una conversación en tiempo real, unos cientos de milisegundos pueden separar una interacción fluida de una pausa perceptible.

Este patrón también sirve para decidir si un agente debe contestar, pedir un dato o escalar a una persona. Quien trabaje con automatización puede complementar este enfoque con una guía sobre cómo evaluar agentes mediante trazas y conjuntos de prueba. La velocidad solo es útil si se puede reconstruir por qué se tomó cada ruta y cuántas veces falla.

2. Clasificación de documentos e imágenes

La entrada multimodal permite preguntar por atributos visibles o por el tipo de documento. Un sistema podría separar facturas, contratos y justificantes; otro podría priorizar fotografías que parecen mostrar un daño. En ambos casos, la decisión debe validarse con datos representativos del entorno real. Las imágenes borrosas, los documentos incompletos y las categorías poco frecuentes suelen revelar fallos que una demostración limpia no muestra.

3. Priorización de trabajo

Una puntuación puede ordenar incidencias, revisiones o solicitudes. Es útil cuando el objetivo es decidir qué mirar primero, no dictar una verdad definitiva. El equipo puede reservar la revisión inmediata para los casos de mayor riesgo y muestrear parte de los casos de baja puntuación para detectar deriva.

4. Flujos creativos con controles claros

En producción de contenido, una decisión acotada puede comprobar si un guion cumple requisitos formales, si una pieza necesita una revisión adicional o qué variante encaja con un canal. No sustituye la edición humana, pero sí puede ordenar el trabajo. Dos ejemplos de procesos creativos que ayudan a entender dónde colocar esos controles son la creación de Reels, Shorts y anuncios asistidos por IA y el diseño de personajes virtuales coherentes para contenido. En ambos casos, la decisión automática debería verificar criterios definidos, no aprobar la publicación por sí sola.

Cómo interpretar las cifras de velocidad y coste

OpenAI habla de hasta diez veces más velocidad frente a GPT‑6 Luna mediante Responses API. Además, publica resultados comunicados por clientes: Box observó una selección de ruta aproximadamente cinco veces más rápida en una evaluación de 30 certificados; Datadog informa de una latencia p95 cuarenta veces menor frente a modelos de frontera que comparó; Sierra declara menos de 280 milisegundos p95 en parte de su orquestación; y Speak afirma haber reducido el tiempo hasta la siguiente acción de 1,4 a 0,13 segundos.

Son datos útiles, pero no constituyen una garantía universal. Proceden de casos, configuraciones y comparaciones distintas. “Hasta diez veces” tampoco significa que cada solicitud vaya a mejorar en esa proporción. La latencia real dependerá del tamaño del contexto, la región, la carga, el número de preguntas, la red y el diseño del flujo. Una prueba propia debe medir al menos mediana, percentil 95, errores, reintentos y coste por decisión correcta.

La documentación fija para gpt-6-luna un precio de 0,10 dólares por millón de tokens de entrada no almacenados en caché en este endpoint. Las lecturas de caché tienen descuento, las escrituras de caché se cobran y no se facturan tokens de salida. Pueden aplicarse recargos por procesamiento regional y multiplicadores para contextos largos. La cifra atractiva de entrada, por tanto, no basta para calcular el coste final de un sistema con reintentos, evaluaciones y revisión humana.

Una arquitectura segura para decisiones automáticas

Definir una política antes del prompt

Primero debe escribirse la regla de negocio en lenguaje claro: qué significa cada categoría, qué evidencia la respalda y qué casos deben quedar fuera. Después se traduce esa política a la pregunta y a las respuestas permitidas. Si el equipo no puede acordar la regla sin IA, el modelo no resolverá la ambigüedad de forma estable.

Separar confianza de permiso

Una probabilidad puede activar una revisión, pero no debería conceder por sí sola un permiso irreversible. Para acciones sensibles conviene exigir controles deterministas: autenticación, límites, listas autorizadas, validación de parámetros y confirmación explícita. Si la decisión afecta a dinero, salud, empleo, crédito, seguridad o derechos, la revisión humana y el asesoramiento especializado son especialmente importantes.

Crear una zona de abstención

No todo debe terminar en sí o no. Un diseño robusto establece una franja intermedia. Por ejemplo: por encima de un umbral se acepta, por debajo de otro se rechaza y entre ambos se revisa. Los umbrales no deben elegirse por intuición, sino a partir de falsos positivos, falsos negativos y coste de cada error.

Evaluar con datos reales y conservar trazas

El conjunto de prueba debe incluir casos normales, ambiguos, adversariales y raros. Además de precisión global, conviene medir cada clase por separado, calibración de probabilidades, tasa de abstención y estabilidad ante cambios pequeños. Las trazas deben registrar versión de la política, pregunta, respuestas permitidas, modelo, salida, acción posterior y corrección humana, sin almacenar más datos personales de los necesarios.

Preparar una alternativa cuando el servicio falla

Una API rápida sigue siendo un servicio externo. El sistema necesita tiempos máximos, reintentos limitados, idempotencia y una ruta segura si no hay respuesta. A veces la mejor alternativa es una regla sencilla; otras, una cola para revisión. Nunca debería repetirse de forma ciega una acción con efectos secundarios. El problema se parece al de las pasarelas de modelos: hay que saber quién aplica políticas, cómo se registra el uso y qué ocurre si cambia el proveedor. En este contexto resulta útil el análisis sobre los nuevos requisitos para routers y pasarelas de IA.

Privacidad y residencia de datos en Europa

OpenAI indica que /v1/decisions está disponible en las regiones compatibles y admite procesamiento regional en Estados Unidos y Europa —Espacio Económico Europeo y Suiza—. La guía oficial de controles de datos advierte, además, de que la caché está sujeta a sus propias reglas de retención.

Residencia regional no significa automáticamente cumplimiento normativo. Una organización en España debe identificar la base jurídica, limitar la finalidad, reducir los datos enviados, fijar plazos, revisar encargados y transferencias, atender derechos y documentar decisiones cuando corresponda. También debe comprobar si el contexto repetido que se beneficia de la caché contiene datos personales o secretos que podrían evitarse.

La minimización mejora tanto la privacidad como el rendimiento. En lugar de enviar un expediente completo, puede bastar con los campos necesarios para la pregunta. Si una imagen contiene rostros, documentos o ubicaciones, conviene analizar si pueden recortarse, ocultarse o procesarse de otra forma antes de enviarla.

Plan de adopción en siete pasos

1. Elegir una decisión de bajo riesgo. Empezar por clasificación o priorización, no por una acción irreversible.
2. Definir categorías y abstención. Escribir ejemplos positivos, negativos y ambiguos para cada salida.
3. Construir un conjunto de evaluación. Separar datos de desarrollo y prueba para evitar ajustar el sistema a los mismos ejemplos.
4. Medir la referencia. Comparar con reglas actuales, revisión humana y, si procede, Responses API.
5. Fijar umbrales por coste de error. No usar el mismo nivel de confianza para todas las acciones.
6. Desplegar con registro y muestreo. Revisar una parte de las decisiones aunque parezcan seguras.
7. Vigilar la deriva. Repetir las evaluaciones cuando cambien el modelo, la política, los usuarios o los datos.

Qué no puede concluirse todavía

La disponibilidad general demuestra que OpenAI considera estable el producto, pero no prueba que supere a todos los clasificadores en todos los dominios. Tampoco sabemos, a partir del anuncio, cómo se comportará cada combinación de idioma, sector, calidad de imagen y distribución de datos. Los testimonios de clientes muestran posibilidades, no resultados reproducibles para cualquier empresa.

Hecho verificado: el endpoint admite respuestas tipadas, GPT‑6 Luna, hasta 400 preguntas y procesamiento regional europeo. Inferencia razonable: puede reducir latencia y coste en flujos que hoy usan generación abierta para decisiones pequeñas. Hipótesis que requiere prueba: que mantendrá la calidad de un sistema concreto bajo carga, con datos españoles y casos difíciles. Predicción: veremos más arquitecturas híbridas, con modelos rápidos para enrutar y modelos más potentes o personas para resolver excepciones.

Preguntas frecuentes

¿Decisions API sustituye a Responses API?

No. Está optimizada para respuestas cerradas: probabilidad, elección o puntuación. Responses API sigue siendo adecuada cuando se necesita generar, razonar de forma abierta, usar herramientas o producir una explicación completa.

¿Una probabilidad alta garantiza que la decisión sea correcta?

No. Es una estimación del modelo y puede estar mal calibrada. Debe validarse con ejemplos representativos y traducirse a acciones mediante umbrales acordes al riesgo.

¿Puede decidir sobre imágenes?

Sí, la documentación admite imágenes como entrada y dentro de las instrucciones de cada pregunta. Eso no convierte una clasificación visual en una prueba pericial ni certifica el origen de la imagen.

¿Es suficiente elegir procesamiento europeo?

No. Ayuda a controlar dónde se procesa la información, pero el cumplimiento exige revisar finalidad, minimización, contratos, conservación, acceso y derechos, entre otros elementos.

Conclusión

Decisions API formaliza una tendencia útil: no todas las tareas de IA necesitan una respuesta libre. Para clasificar, puntuar o enrutar, una salida acotada puede ser más rápida, barata y fácil de integrar. Su mayor riesgo es precisamente su aspecto ordenado: una cifra o una etiqueta pueden parecer objetivas aunque procedan de una estimación.

La adopción responsable consiste en convertir esa estimación en una parte de un sistema verificable. Política clara, opciones de abstención, umbrales, evaluaciones, trazas, controles deterministas y revisión humana cuando el impacto lo exige. Si esas capas existen, la velocidad ayuda. Si faltan, solo permite equivocarse más deprisa.