OpenAI abre Decisions API: hasta 400 preguntas por solicitud y cobro solo por tokens de entrada

OpenAI anunció el 22 de octubre de 2026 la disponibilidad general de Decisions API, basada en GPT-6 Luna. El límite llega a 400 preguntas por solicitud. Según la documentación oficial, el precio base es US$0,10 por millón de tokens de entrada, sin cargos por tokens de salida. Pueden aplicar recargos por procesamiento regional y contexto largo.

La novedad merece atención en operaciones comerciales por una razón concreta: permite evaluar por separado las pequeñas decisiones que forman un flujo. Clasificar una solicitud, elegir una cola o marcar un caso para revisión son problemas distintos de redactar una respuesta completa. Esa separación puede ayudar a identificar qué parte de una automatización agrega valor y cuál introduce errores.

¿Qué tipo de decisiones permite y dónde está el límite?

La guía oficial de Decisions describe tres salidas: probabilidad de una condición, elección entre opciones y puntuación según una rúbrica. No se trata de una integración nativa anunciada para HubSpot. La conexión con un CRM y las acciones posteriores requieren una implementación propia.

Como aplicación propuesta para un equipo B2B, una consulta entrante podría clasificarse entre venta nueva, servicio o contacto administrativo. La empresa tendría que definir esas categorías con ejemplos de su operación. También debería conservar una salida para los casos ambiguos: forzar cada mensaje a una categoría puede crear una apariencia de orden mientras envía trabajo al equipo equivocado.

Antes de escribir resultados en producción, conviene comparar la clasificación propuesta con la que habría hecho una persona responsable del proceso. El criterio de éxito debe incluir los errores de asignación y sus consecuencias. Acertar en mensajes fáciles no compensa derivar a la cola incorrecta una solicitud de un cliente que ya tiene una oportunidad abierta.

¿Cómo evaluar el costo sin confundir precio con retorno?

OpenAI presenta el producto como hasta diez veces más rápido que GPT-6 Luna mediante Responses API. Es una comparación del proveedor, no una garantía del tiempo total de un proceso comercial. Un flujo también puede esperar al CRM, a una integración o a la revisión humana. Reducir la latencia de una pieza no asegura el mismo cambio en el conjunto.

Para presupuestar, recomendamos registrar el consumo por caso resuelto y sumar las llamadas repetidas, el mantenimiento y la revisión de excepciones. El gasto de inferencia debe relacionarse con una unidad de trabajo reconocible: una solicitud asignada correctamente, por ejemplo. Medir solo llamadas baratas puede premiar una automatización que necesita demasiadas correcciones.

Una prueba útil compara el flujo actual con una alternativa sobre los mismos casos. Debe observar tiempo hasta la asignación correcta, cantidad de reasignaciones y costo operativo completo. Si el equipo invierte más tiempo corrigiendo etiquetas que el que antes dedicaba a clasificarlas, el ahorro técnico todavía no se convierte en una mejora del negocio.

¿Qué deberían probar las empresas en Chile y Latinoamérica?

La recomendación para una empresa en Chile o Latinoamérica es empezar por una cola interna y reversible. Un piloto puede sugerir el destino de una solicitud sin enviar mensajes al cliente ni modificar el valor de un negocio. Así el responsable comercial puede revisar ejemplos reales, explicar desacuerdos y ajustar los criterios antes de ampliar el alcance.

El conjunto de evaluación debería incluir mensajes breves, abreviaturas locales, conversaciones que mezclan venta y soporte y contactos que ya existen en el CRM. Conviene acordar quién corrige la etiqueta y cómo se registra esa corrección. Esa evidencia permite decidir qué automatizar y qué mantener bajo revisión, sin confundir una demostración ordenada con el trabajo cotidiano.

Análisis de Revenue Hub

Nuestra lectura es que el valor para RevOps está en hacer explícitas las decisiones que hoy quedan escondidas dentro de un flujo. Antes de elegir tecnología, recomendamos definir los datos, las relaciones y los responsables del CRM. Una clasificación solo ayuda si el siguiente equipo sabe qué debe hacer con ella. Si marketing y ventas entienden de forma distinta qué es una solicitud comercial válida, acelerar la asignación puede acelerar también el desacuerdo.

La decisión de escalar debería tener un dueño y una condición de salida. Proponemos revisar con ventas, marketing y servicio una muestra de asignaciones, registrar errores y acordar qué resultado justificaría continuar. La guía para coordinar procesos y equipos mediante Revenue Operations aporta ese marco de trabajo. El indicador relevante es cuánto tarda una solicitud en llegar a una persona capaz de resolverla, con el contexto necesario para actuar.

Para un líder comercial B2B, la compra de capacidad de IA debería venir después de esa definición. Recomendamos aprobar primero un piloto acotado, con responsable de mantenimiento y posibilidad de volver al proceso anterior. Un precio bajo por token puede hacer viable experimentar; la autorización para operar sobre clientes debe depender de la evidencia del piloto y de quién responde cuando la clasificación falla.