Herramientas · · 9 min de lectura
OpenAI Decisions API en beta: la decisión como primitiva y el fin de la prosa innecesaria en producción
OpenAI abre la beta pública de Decisions API: probabilidades, etiquetas y puntuaciones en lugar de texto, con ~10x menos latencia que Responses API. Analizamos qué cambia realmente para los equipos que despliegan agentes IA en producción.
OpenAI ha abierto la beta pública de Decisions API, un endpoint que no escribe prosa: devuelve probabilidades, etiquetas, opciones y puntuaciones, y según la fuente original corre unas 10 veces más rápido que Responses API. Para cualquiera que haya peleado con latencias de 3-5 segundos en pipelines de agentes IA en producción, esto no es un feature: es un cambio de unidad de medida.
TL;DR: OpenAI abre la beta de Decisions API, un endpoint que sustituye la generación narrativa por probabilidades, opciones y scores, con ~10x menos latencia que Responses API y tres tipos de pregunta (clasificación, inspección visual y priorización). La tesis: la decisión como primitiva abarata el coste por inferencia en cualquier arquitectura de agentes, pero solo si tu equipo sabe qué llamadas sustituir y cuáles no. El verdadero reto no es técnico, es de diseño de producto.
La latencia deja de ser un detalle de ingeniería y pasa a ser P&L
Durante los últimos 18 meses, la conversación sobre LLMs en empresas ha girado alrededor de dos números: coste por millón de tokens y calidad del output. La latencia se ha tratado como un compromiso aceptable. Eso se acabó. Cuando una API devuelve una distribución de probabilidad sobre etiquetas discretas en lugar de 200 tokens de explicación, el coste por decisión cae en órdenes de magnitud distintos.
Pensemos en un caso concreto que aparece en la propia nota: clasificar consultas de clientes. Hoy, un equipo típico lanza un prompt tipo "clasifica este ticket en una de estas cinco categorías y explica brevemente por qué". El modelo genera entre 80 y 200 tokens, incluye la etiqueta deseada y una justificación que nadie consume. En Decisions API, la respuesta es {categoria: "facturacion", score: 0.87} y punto. Menos tokens, menos cómputo, menos latencia.
La aritmética es brutal en cualquier volumen B2B. Un call center con 40.000 tickets diarios que deduzca 150 tokens de salida por ticket está quemando 6 millones de tokens diarios en texto que nadie lee. Ese patrón, replicado en un pipeline de agentes autónomos que ejecutan 20 micro-decisiones por tarea, es la razón por la que muchos pilotos nunca pasan a producción. No es el precio del token: es la acumulación de latencia en serie.
Tres primitivas, tres verticales que se comen el mercado por debajo
La nota menciona tres tipos de pregunta que Decisions API maneja: clasificación de texto, detección de daños en fotos de producto y evaluación de prioridad de tareas. Traducido a negocio:
- Clasificación de texto: triaje de tickets, enrutado de leads, etiquetado de documentos legales, moderación. Es la capa básica de cualquier automatización con IA y hasta ahora se hacía con modelos generativos sobredimensionados.
- Detección visual: control de calidad en e-commerce, seguros (peritaje automático), logística (paquetes dañados), retail (lineal y stock). Aquí es donde la latencia importa doble, porque suele ir acoplada a un flujo físico.
- Priorización: scoring de urgencia, ranking de colas, triaje clínico, escalado en soporte. Es la primitiva que más valor tiene y la que más se ha venido improvisando con prompts largos y cadenas de razonamiento innecesarias.
El ecosistema de agencias de agentes autónomos en España lleva más de un año construyendo estas capas a golpe de prompting. Decisions API formaliza el patrón y, sobre todo, lo estandariza.
Lo que OpenAI no dice del anuncio (y deberías preguntar)
El número del "10x más rápido" merece escepticismo quirúrgico. La comparación es contra Responses API, no contra un endpoint especializado de clasificación tipo encoder pequeño. Un DistilBERT afinado seguirá siendo 50x más barato y 20x más rápido para clasificar tickets en cinco categorías predecibles. Lo que aporta Decisions API es generalización sin entrenamiento: no tienes que montar un dataset, no tienes que mantener un modelo, y funciona en dominios donde no tienes datos etiquetados.
A diferencia de lo que suele sugerir el marketing de las plataformas, el verdadero competidor de Decisions API no es un transformer más grande, es tu pipeline de reglas y un clasificador clásico. Si tu caso de uso es estable, cerrado y con volumen, fine-tuning de un encoder seguirá ganando en coste. Si tu caso de uso es cambiante, multimodal o con vocabulario emergente, Decisions API gana sin discusión.
Otro punto que la nota deja fuera: no se especifica precio, ni SLA, ni límites de rate. Es beta pública, y eso significa que cualquier CTO serio debería asumir que el endpoint cambiará de contrato al menos dos veces antes de GA. Diseña el acoplamiento en consecuencia: envuelve la llamada detrás de una interfaz propia.
Dónde esto descoloca a las agencias IA en Madrid y Barcelona
Para las empresas que buscan agencias IA en Madrid, el cambio no es tecnológico, es de propuesta comercial. Hasta ahora, muchas agencias vendían "un asistente conversacional" porque era el único envoltorio digerible por el cliente. Con Decisions API aparece una categoría de proyecto mucho más honesta: sustituir reglas y clasificadores internos por una capa de decisión probabilística sin mantener infraestructura.
El ecosistema de agencias IA en Barcelona ya está moviendo proyectos de scouting visual en retail y logística donde la latencia era el cuello de botella. La diferencia es que ahora se puede vender como decisión (¿hay daño? ¿cuánta prioridad?) y no como "visión por computador con IA generativa", que siempre suena a sobrecoste.
Para los equipos que necesiten rediseñar arquitectura, consultoría IA especializada en agentes es probablemente el punto de entrada más razonable, más que contratar directamente desarrollo.
Decisions API vs Responses API vs fine-tuning: cuándo usar cada cosa
| Criterio | Decisions API | Responses API | Encoder afinado (tipo DistilBERT/E5) |
|---|---|---|---|
| Latencia relativa | ~1x (referencia: 10x más rápido que Responses) | ~10x | ~20-50x más rápido |
| Coste por decisión | Bajo | Alto (genera tokens) | Muy bajo |
| Necesita dataset etiquetado | No | No | Sí (miles de ejemplos) |
| Multimodal (texto+imagen) | Sí | Sí | Solo si entrenas multimodal |
| Flexibilidad de esquema de salida | Probabilidades + opciones + scores | Texto libre / JSON | Fijo tras entrenamiento |
| Mantenimiento | Ninguno | Prompts a mantener | Reentrenamiento periódico |
| Encaje ideal | Casos cambiantes, multimodal, sin datos | Generación, razonamiento abierto | Alto volumen, etiquetas estables |
La conclusión operativa de esa tabla es incómoda para muchos equipos de datos: si llevas dos años manteniendo un clasificador propio con mal rendimiento y sin pipeline de reentrenamiento, Decisions API te da un atajo. Si tienes un clasificador afinado, medido y monitorizado, no lo toques.
El error que van a cometer el 80% de los equipos
El patrón fallido ya se ve venir: usar Decisions API como sustituto directo de cada llamada generativa, incluidas las que requieren explicación humana auditable. Cuando un sistema toma una decisión con impacto sobre un cliente (denegar un crédito, marcar un siniestro como fraudulento, priorizar una urgencia sanitaria), la probabilidad sola no basta. Necesitas trazabilidad, necesitas motivo, y necesitas que un humano pueda revisarlo en caso de reclamación.
Eso significa mantener un pipeline híbrido: Decisions API para el enrutado rápido y el scoring, y un modelo generativo invocado solo en los casos de baja confianza o alto impacto. Ese patrón —"router barato + generador caro solo cuando hace falta"— es lo que llevamos meses recomendando a cualquier cliente con volumen real, y Decisions API por fin lo hace trivial de implementar.
En el contexto europeo, y con el AI Act entrando en fase de aplicación, delegar la decisión final a un endpoint opaco sin capacidad de recibir explicaciones post-hoc es un riesgo regulatorio evitable. Un CTO que despliegue esto en un dominio de alto riesgo sin diseño de auditoría se expone a sanciones que superan con creces cualquier ahorro en tokens.
Qué mirar a partir de ahora
Tres indicadores van a separar a los equipos que aprovechan esta API de los que la mencionan en una slide:
- Ratio decisions/token de salida en su pipeline de agentes. Si no ha bajado en un trimestre, no la están usando bien.
- Coste por decisión auditada, no coste por token. Es la métrica que se lleva a comité de dirección.
- Porcentaje de decisiones con score de confianza por debajo del umbral que activan revisión humana. Si es cero, el sistema no está aprendiendo nada del mundo real.
El movimiento estratégico de OpenAI con Decisions API es claro: bajar por la pila desde la generación hacia la decisión, donde el volumen es infinitamente mayor. Si funciona, en 12 meses el endpoint generativo se convertirá en la parte cara y minoritaria de cualquier arquitectura de agentes IA. Y eso redefinirá qué significa "proveedor de IA" para una empresa: no el que mejor escribe, sino el que mejor decide, mide y factura por decisión.
Preguntas frecuentes sobre OpenAI Decisions API
¿Qué es Decisions API de OpenAI exactamente?
Es un endpoint en beta pública que evalúa texto e imágenes y devuelve probabilidades, opciones y puntuaciones en lugar de respuestas narrativas. Está pensado para tareas de decisión (clasificación, detección, priorización) y corre aproximadamente 10 veces más rápido que Responses API según la propia firma.
¿Cuánto cuesta Decisions API?
La nota original no detalla precio ni límites de rate durante la beta. Dado el patrón habitual de OpenAI con endpoints en beta, es razonable asumir cambios de contrato antes de GA; conviene envolverlo tras una interfaz propia para no quedar acoplados.
¿Decisions API o un clasificador propio afinado?
Depende del escenario. Si tu caso de uso es cerrado, de alto volumen y con etiquetas estables, un encoder afinado sigue siendo más barato y rápido. Decisions API gana cuando el dominio cambia, no tienes dataset etiquetado o necesitas cubrir texto e imagen con un solo endpoint.
¿Puedo usar Decisions API en producción con un cliente real?
Sí, pero con arquitectura híbrida: Decisions API para el scoring rápido y un modelo generativo invocado solo en casos de baja confianza o alto impacto. En dominios regulados por el AI Act, la ausencia de explicabilidad post-hoc es el principal riesgo a mitigar.
¿Qué casos de uso priorizan las agencias que ya lo están probando?
Triaje de tickets, enrutado de leads, inspección visual de producto en retail y logística, y priorización de colas de soporte o siniestros. Son dominios donde la latencia afecta a un flujo físico o a un SLA medible, no solo a la experiencia percibida.
Temas relacionados en agentes.ai
Si quieres aplicar lo que lees en tu empresa, estos son puntos de partida útiles dentro de agentes.ai:
- Directorio de agencias de agentes de voz
- Agencias de IA en Madrid y en Sevilla
- Explora el directorio completo de agencias de IA
- Sigue las últimas noticias de IA en tiempo real