Decisions API: decidir, enrutar y escalar tareas con IA

1. Qué es Decisions API y por qué conviene separar decidir de generar

Muchas aplicaciones de IA mezclan dos trabajos diferentes. El primero es generar: redactar un correo, resumir un documento, explicar una incidencia o preparar un plan. El segundo es decidir: elegir una categoría, determinar la ruta de una solicitud, puntuar un riesgo o decidir si debe intervenir una persona.

Decisions API está pensada para el segundo trabajo. OpenAI declaró su disponibilidad general el 22 de octubre de 2026, después de una beta pública iniciada el 6 de octubre. Se utiliza mediante POST /v1/decisions y actualmente es compatible con gpt-6-luna. Acepta texto, imágenes y JSON, y devuelve decisiones estructuradas.

La diferencia práctica es importante. Si una pyme recibe cientos de correos de clientes, puede usar un modelo generativo para comprender el contenido y redactar una respuesta. Pero puede reservar Decisions API para contestar una pregunta más acotada: ¿es una devolución, una incidencia técnica, una consulta comercial o un caso que requiere revisión?

Según OpenAI, Decisions API puede tomar decisiones hasta 10 veces más rápido que GPT-6 Luna mediante Responses API. Es una afirmación del proveedor, no una garantía para cualquier empresa: el resultado dependerá del contexto, la longitud de las entradas, los reintentos, la infraestructura y la complejidad de cada proceso.

2. Qué devuelve: predicate, choice y score

La API ofrece tres tipos principales de salida. Elegir bien entre ellos ayuda a diseñar procesos más sencillos y auditables.

Predicate: ¿se cumple una condición?

Predicate devuelve la probabilidad de que una condición sea cierta. Puede servir para preguntar si un mensaje contiene una solicitud de cancelación, si una factura parece incluir un riesgo concreto o si una conversación necesita atención prioritaria.

No debe confundirse automáticamente esa probabilidad con una probabilidad perfectamente calibrada. La empresa debe comprobar con ejemplos propios si un 0,8 representa realmente un nivel de acierto cercano al 80% en su dominio.

Choice: ¿qué opción cerrada corresponde?

Choice selecciona una opción de una lista definida previamente. Es adecuado para clasificar tickets, enrutar documentos a un equipo, escoger el tipo de revisión o determinar el siguiente paso de un agente.

La lista debe incluir una salida como review, unknown u other. Sin una vía explícita para la ambigüedad, el sistema puede verse obligado a elegir una categoría incorrecta.

Score: ¿qué puntuación merece?

Score puntúa una entrada en una escala ordenada. Puede utilizarse para priorizar solicitudes, ordenar oportunidades comerciales o graduar el riesgo de una operación. La escala debe tener un significado claro: niveles de prioridad definidos por el negocio, no números que nadie sabe interpretar.

Procesos adecuados para una pyme

La API encaja mejor cuando las decisiones son repetitivas, tienen opciones limitadas y se producen con suficiente volumen como para que la velocidad o el coste importen:

• Clasificar correos, tickets, formularios o documentos.
• Enrutar una solicitud al equipo adecuado.
• Priorizar incidencias según urgencia o impacto.
• Detectar señales de riesgo que activen una revisión.
• Seleccionar la siguiente acción de un agente conversacional.

No es la herramienta adecuada para sustituir un modelo generativo en la planificación compleja, el razonamiento de horizonte largo o la redacción de explicaciones.

3. Arquitectura práctica: comprender, decidir, ejecutar y verificar

Una implementación fiable separa las responsabilidades en varias etapas:

Esta separación evita un error habitual: permitir que una respuesta del modelo active directamente una operación irreversible. La documentación de OpenAI diferencia la selección de una opción de la ejecución de la acción. Los permisos, las validaciones, los límites y la aprobación deben permanecer en la aplicación.

Por ejemplo, una API puede decidir que una solicitud parece un reembolso y asignarla a la ruta correspondiente. No debería aprobar por sí sola el pago. La aplicación debe comprobar el importe, la identidad del cliente, la política aplicable y si es necesaria una autorización humana.

Si cambia una política de negocio, se puede modificar una regla determinista sin depender exclusivamente del comportamiento del modelo. Además, la empresa puede conservar un registro de la entrada, la decisión, la probabilidad o puntuación, la versión de las instrucciones y el resultado final.

4. Cómo diseñar escalados según el coste del error

Un sistema de producción no debería dividir las decisiones únicamente entre “correctas” e “incorrectas”. Conviene establecer tres zonas:

• Alta confianza: la aplicación automatiza la ruta cuando la decisión supera el umbral definido y las reglas de negocio se cumplen.
• Incertidumbre: el sistema no ejecuta todavía; solicita más información, usa una alternativa o deriva el caso.
• Revisión humana: una persona valida la decisión cuando el coste del error es alto o la categoría es sensible.

El umbral debe depender del coste de equivocarse. Para clasificar internamente correos de bajo impacto, puede ser razonable aceptar un umbral moderado. Para pagos, reembolsos, cuentas de clientes o comandos de producción, debe ser mucho más exigente y combinarse con controles deterministas.

También hay que distinguir entre falsos positivos y falsos negativos. Un falso positivo puede enviar un caso normal a revisión y aumentar el trabajo humano. Un falso negativo puede dejar pasar un riesgo o asignar una incidencia crítica a un equipo inadecuado.

5. Cómo medir coste, latencia y precisión antes de producción

Antes de conectar la API con un proceso real, la pyme debería preparar un conjunto de ejemplos representativos, etiquetados por una persona o equipo. No basta con probar casos fáciles: hay que incluir mensajes breves, incompletos, ambiguos, duplicados y casos que se parezcan entre sí.

Precisión y calidad de decisión

• Precisión por categoría: qué proporción de las decisiones de una categoría es correcta.
• Falsos positivos y negativos: cuántos casos se clasifican de forma incorrecta en cada dirección.
• Abstenciones: cuántas entradas terminan en review, unknown u other.
• Calibración: si las probabilidades devueltas reflejan razonablemente la frecuencia real de acierto.
• Resultados por segmento: idioma, canal, tipo de cliente, producto o complejidad del documento.

Una precisión media puede ocultar un problema grave en una categoría minoritaria pero importante. Por eso conviene analizar cada ruta por separado y revisar manualmente los errores de mayor impacto.

Latencia y disponibilidad

Hay que medir la latencia de extremo a extremo, no solo el tiempo de respuesta de la API. Registra p50, p95 y p99, e incluye extracción de datos, red, reintentos, almacenamiento y cualquier generación posterior.

La documentación indica que la API permite hasta 400 preguntas por solicitud. Agrupar decisiones puede ser útil en procesos por lotes, pero debe comprobarse si aumenta el tiempo total o complica la recuperación ante errores.

Coste total

El precio por token no representa por sí solo el coste total del proceso. El cálculo debe sumar extracción, contexto, reintentos, generación posterior, revisión humana, almacenamiento, monitorización y coste de los errores.

Una decisión barata puede dejar de serlo si provoca muchas revisiones o acciones incorrectas. La métrica útil es el coste por decisión válida y completada, no únicamente el coste por token. Consulta la página oficial de precios para contrastar las tarifas vigentes antes de hacer una estimación.

6. Qué muestran algunos casos comunicados por empresas

Los primeros casos publicados ilustran posibles beneficios, aunque no deben interpretarse como resultados garantizados para cualquier pyme. Son afirmaciones de las propias empresas o de OpenAI, no benchmarks independientes.

• Box afirma que seleccionó rutas de revisión aproximadamente cinco veces más rápido que con Responses API, con la misma precisión, en una evaluación de 30 certificados.
• Datadog afirma que obtuvo una latencia 40 veces menor en p95, con precisión comparable, al evaluar el riesgo de comandos rshell.
• Ramp afirma que redujo un 30% el coste de atribución de costes de IA y realizó la tarea cuatro veces más rápido que con GPT-6 Luna, sin pérdida de precisión.
• Sierra afirma que consiguió menos de 280 milisegundos de p95, aproximadamente tres veces más velocidad y un 90% menos de coste por llamada que su enfoque anterior.
• Speak afirma que redujo el tiempo hasta la siguiente acción de 1,4 segundos a 0,13 segundos al integrarse con GPT-Live.

El material disponible no aporta en todos los casos los conjuntos de datos completos, protocolos reproducibles o auditorías independientes necesarios para generalizar esas mejoras.

7. Limitaciones y alternativas

OpenAI diferencia Decisions API de Responses API con Structured Outputs. La primera conviene cuando las respuestas posibles están definidas de antemano. Responses API es más apropiada cuando se necesita generar un objeto estructurado flexible, producir texto o ejecutar herramientas.

La disponibilidad actual de un único modelo, gpt-6-luna, limita la posibilidad de elegir entre distintos perfiles de coste, latencia, idioma o privacidad. Para reducir dependencia, una pyme puede conservar reglas tradicionales, un clasificador local, otro proveedor o una ruta de revisión humana.

También conviene probar cómo responde el sistema ante entradas sensibles, maliciosas o fuera de distribución. La aplicación debe contemplar una salida de error o abstención y no asumir que siempre recibirá una categoría válida.

Entre las capacidades comunicadas para la API figuran la entrada JSON nativa, imágenes asociadas a preguntas, caché de contexto, hasta 400 preguntas por solicitud, URLs públicas de imágenes, evaluación de conversaciones y herramientas, informes de uso, integración con GPT-Live y Private Link. La conveniencia de cada función dependerá del caso, la arquitectura y los requisitos de privacidad de la empresa.

8. Checklist para una pyme

• ¿La decisión tiene opciones cerradas y se repite con suficiente volumen?
• ¿Está separada de la generación de texto y de la ejecución de acciones?
• ¿Existe una opción explícita para review, unknown u other?
• ¿Se han definido umbrales distintos según el coste del error?
• ¿Se registran versión, entrada, decisión, probabilidad, latencia y resultado?
• ¿Se han medido precisión por categoría, falsos positivos, falsos negativos y abstenciones?
• ¿Se conocen p50, p95 y p99 de extremo a extremo?
• ¿Se ha calculado el coste total, incluida la revisión humana?
• ¿Existe un fallback si el proveedor cambia, falla o devuelve una respuesta no utilizable?
• ¿Las reglas de permisos, límites, cumplimiento y aprobación permanecen en la aplicación?

Veredicto: automatizar con control, no por inercia

Decisions API puede ser una pieza útil para pymes que necesitan clasificar, enrutar o priorizar muchas tareas con rapidez. Su valor aparece cuando la decisión está bien delimitada, las opciones son conocidas y el proceso puede medir el impacto de cada error.

La recomendación práctica es empezar con un caso de bajo riesgo, comparar la API con reglas o con la solución generativa actual y ejecutar una prueba controlada. Automatiza solo cuando la combinación de coste total, latencia, precisión y riesgo sea mejor que las alternativas. Después, amplía gradualmente y conserva una ruta de revisión humana y un mecanismo de respaldo.

Qué hacer ahora: elige un flujo repetitivo de tu empresa, reúne ejemplos reales y crea una tabla con categorías, umbrales, coste por decisión, p95 y errores. Revisa los resultados antes de automatizar acciones irreversibles.