API de decisiones de OpenAI: usos, costos y límites

Qué pedirle a la API de decisiones de OpenAI

Decisions funciona como un sistema de asignación con un conjunto de destinos definido de antemano. Tú aportas la información y la pregunta; la aplicación decide qué hacer cuando llega la respuesta.

Al 11 de octubre de 2026, la API está en beta pública, y OpenAI prevé su disponibilidad general «en las próximas semanas». Es una previsión de OpenAI, no una fecha de lanzamiento. gpt-6-luna es el único modelo compatible y el endpoint es POST /v1/decisions. OpenAI la describe como «aproximadamente 10x más rápida que la Responses API». Es una afirmación de OpenAI, no un resultado medido en tu aplicación. Guía de Decisions de OpenAI

Elige el formato de respuesta antes de escribir el prompt:

En una puntuación, los niveles empiezan en el índice 0. El resultado puede quedar entre dos niveles: resume la incertidumbre entre ellos. Utiliza una elección cuando el código necesite una sola categoría. Tipos de pregunta

Cómo realizar los tres tipos de solicitud

Estos son los tres ejemplos de solicitudes cURL de la guía, copiados con el formato unificado y con comentarios añadidos para distinguirlos. Define OPENAI_API_KEY en las variables de entorno de tu shell; el ejemplo de predicado también necesita un archivo local product.png. Cada comando realiza su propia solicitud. Los ejemplos se cotejaron con la guía pública, pero no se ejecutaron con una cuenta autenticada. Ejemplos originales de solicitudes

Las partes comunes son input, que contiene la información que se evaluará, y questions, que recoge las decisiones que se deben tomar sobre ella. El campo name de cada pregunta identifica su respuesta en el array answers que devuelve la API. Referencia de solicitudes y respuestas

# Predicate: inspect product.png for visible damage
IMAGE_BASE64="$(base64 < product.png | tr -d '\r\n')"

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "model": "gpt-6-luna",
  "input": [{
    "role": "user",
    "content": [
      {"type": "input_text", "text": "Inspect the product in this photo."},
      {"type": "input_image", "image_url": "data:image/png;base64,$IMAGE_BASE64"}
    ]
  }],
  "questions": [{
    "type": "predicate",
    "name": "visible_damage",
    "instructions": "Does the product have visible damage, such as a crack, tear, or dent? Ignore shadows and damage to the packaging."
  }]
}
JSON

# Choice: route a customer complaint
curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "I was charged twice for my order.",
    "questions": [{
      "type": "choice",
      "name": "department",
      "instructions": "Which department should handle this complaint?",
      "choices": [
        {"value": "billing", "description": "Payments, invoices, and refunds."},
        {"value": "technical", "description": "Problems using the product."},
        {"value": "shipping", "description": "Delivery and tracking."},
        {"value": "other", "description": "Requests outside these categories."}
      ]
    }]
  }'

# Score: assess issue severity
curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "Export fails in Safari but works in Chrome.",
    "questions": [{
      "type": "score",
      "name": "severity",
      "instructions": "How severe is this issue?",
      "levels": [
        {"label": "Cosmetic", "description": "Appearance only; no lost functionality."},
        {"label": "Workaround available", "description": "A task fails, but another way works."},
        {"label": "Fully blocked", "description": "A task fails with no workaround."}
      ]
    }]
  }'

El ejemplo de elección ya ofrece un punto de partida útil para una empresa: una reclamación por un cobro duplicado debe dirigirse a una de las colas definidas. El ejemplo de puntuación plantea otra cuestión: ¿qué impacto tiene un fallo si otro navegador sigue funcionando? Separa el equipo responsable de la gravedad del problema, para que una incidencia de facturación pueda ser urgente sin convertirse en un ticket técnico.

Gestiona la negativa del modelo antes de leer el valor. Los ejemplos del SDK incluidos en la guía comprueban answer.type == "refusal" antes de acceder a probability, choice o score. Una negativa es un resultado distinto: no equivale a una respuesta de baja confianza ni a la categoría other. Cómo se representa una negativa

De la elección al enrutamiento de tickets de soporte

Centra la primera versión en la asignación de colas. Un equipo de soporte podría enviar el asunto del ticket y el mensaje relevante del cliente, recibir la elección de un departamento y dejar que el código habitual de la aplicación aplique su política de enrutamiento.

Toma las definiciones de colas de la guía como punto de partida y sustitúyelas por los límites de responsabilidad reales de tu equipo. Conserva una opción other para las solicitudes que no correspondan a los departamentos indicados. Una solicitud de reembolso pertenece a facturación; eso no autoriza el reembolso.

Este pequeño adaptador ilustra la política que se aplica después de analizar una respuesta JSON correcta y seleccionar la respuesta department. thresholds debe contener los umbrales que hayas establecido con tickets etiquetados; si falta un umbral, el ticket queda pendiente de revisión.

QUEUES = {
    "billing": "billing",
    "technical": "technical",
    "shipping": "shipping",
}

def queue_for(answer, thresholds):
    if answer.get("type") == "refusal":
        return "manual_review"
    if answer.get("type") != "choice":
        return "manual_review"
    department = answer.get("choice")
    if department not in QUEUES:  # Includes the guide's "other" choice.
        return "manual_review"
    cutoff = thresholds.get(department)
    confidence = answer.get("confidence")
    if cutoff is None or confidence is None or confidence < cutoff:
        return "manual_review"
    return QUEUES[department]

En este flujo propuesto, los errores de la API, los tiempos de espera agotados y las respuestas ausentes también dejan los tickets pendientes de revisión manual. Registra la versión de la pregunta, la cola propuesta, la confianza, la cola definitiva y cualquier corrección del personal. Haz que la actualización de la cola pueda repetirse con seguridad, para que un reintento no genere asignaciones duplicadas.

Puedes incluir en una misma solicitud preguntas independientes sobre el mismo ticket. Si el sentido de una pregunta depende de una respuesta anterior, debe ir en una solicitud posterior. Recomendaciones para varias preguntas

Cómo fijar umbrales con tickets etiquetados

Elige los umbrales a partir de los errores que tu empresa puede tolerar. OpenAI no publica cifras de calibración en la guía y remite a los desarrolladores a los datos etiquetados de su propia aplicación. Un valor de confianza no garantiza que las respuestas acierten con esa frecuencia en tus tickets. Cómo interpretar las respuestas

Empieza por tickets históricos cuyo destino correcto haya verificado un responsable de soporte. Incluye solicitudes breves, problemas de varios tipos, casos sin contexto suficiente y reclamaciones que contengan instrucciones dirigidas al modelo. Separa los ejemplos que uses para ajustar preguntas y umbrales del conjunto reservado para la comparación final.

Mide las asignaciones a colas incorrectas, la proporción de tickets enviados a revisión y el tiempo que el personal dedica a corregirlas. Evalúa cada cola por separado. Confundir un problema de envíos con uno de facturación puede tener un costo operativo distinto al de pasar por alto un aviso de una cuenta comprometida.

Primero, ejecuta la nueva opción en paralelo con el clasificador existente, sin cambiar las asignaciones reales. Actívala solo cuando los resultados cumplan un criterio de aceptación por escrito. Conserva la ruta anterior para poder revertir el cambio. Estos son pasos de despliegue propuestos, no resultados de una prueba de esta API.

Seis usos que vale la pena probar, por orden de prioridad

Los mejores usos iniciales tienen categorías estables, errores observables y una persona que ya se encarga de las excepciones. Este orden responde a un criterio de implementación, no a una clasificación por precisión.

Para el etiquetado, decide si cada registro puede pertenecer a varios temas. Una elección selecciona una sola categoría; las preguntas separadas pueden encajar mejor cuando las etiquetas se superponen. Para la gravedad de las incidencias, define el impacto en términos operativos, como la pérdida de funcionalidad o la disponibilidad de alternativas. Palabras como «grave» dejan demasiado margen de interpretación al modelo.

Qué cambia el precio en la práctica

La guía fija un precio de entrada de $0.10 por 1M de tokens en gpt-6-luna, sin cargos por salida, lectura de caché ni escritura en caché. Pueden aplicarse recargos por procesamiento regional y multiplicadores de entrada para contextos largos. Estas tarifas corresponden a Decisions; no apliques esta regla de facturación a las llamadas habituales al mismo modelo. Precios de Decisions

El siguiente es un cálculo ilustrativo para un lote, no una medición de uso ni un precio fijo por decisión. Supongamos 100,000 llamadas de clasificación, cada una con 1,000 tokens de entrada sin caché, incluidas las instrucciones y las opciones. Para la llamada existente a Responses, supongamos además 50 tokens de salida facturados en total por llamada. El cálculo usa las tarifas base estándar para contextos cortos, sin escrituras en caché, recargos regionales, reintentos ni otros cargos.

Las tarifas habituales del modelo proceden de la tabla de precios estándar de OpenAI. En este ejemplo, eliminar la facturación de salida ahorra $2.50 en todo el lote. Por sí solo, ese ahorro justifica poco la reescritura de una integración que ya funciona.

El argumento más sólido es operativo: menos espera en un flujo secuencial, menos código para procesar respuestas o menos clasificación manual con la misma tasa de error. Compara los resultados con tu factura real y tu carga de revisión. Un modelo actual más caro o respuestas generadas más largas cambian el cálculo, al igual que los descuentos de caché existentes. El tiempo de ingeniería y los tickets mal asignados también deben entrar en el presupuesto de migración.

Dos productos que vale la pena construir

Primera opción: asignación de tickets con revisión e historial de correcciones

Un responsable de operaciones de soporte podría pagar por un conector que sugiera colas de un conjunto fijo, retenga los casos inciertos y convierta las correcciones del personal en datos de evaluación. El producto útil es el flujo completo de asignación, incluido su mantenimiento.

DataForSEO estima 170 búsquedas mensuales en Google en Estados Unidos para «ticket triage», según la consulta del 11 de octubre de 2026. Es una señal limitada de demanda informativa, no un recuento de compradores. Las plataformas de soporte existentes también cubren esta necesidad: Zendesk ofrece clasificaciones mediante triaje inteligente y exige su complemento Copilot para utilizarlas en flujos de trabajo. Guía de triaje de Zendesk

La versión mínima útil podría integrarse con una plataforma de soporte, importar tickets históricos, mostrar una vista previa de las asignaciones y ofrecer una bandeja de revisión con la posibilidad de corregirlas. La mejor prueba para venderla sería la reducción de traspasos evitables que consiga el cliente. El obstáculo es lo que ya cubre la plataforma existente: si asigna bien las colas, añadir otro sistema implica más mantenimiento. Busca un problema concreto de responsabilidad entre equipos o de traspaso entre sistemas.

Segunda opción: un espacio de revisión para etiquetas predefinidas

Un equipo de investigación o de datos podría pagar por una herramienta que sugiera etiquetas, recoja correcciones y muestre qué categorías siguen provocando desacuerdos. DataForSEO estima 90 búsquedas mensuales en Google en Estados Unidos para «automated data labeling», según la misma consulta. Esto indica interés en la tarea, no una disposición demostrada a pagar por esta implementación.

Una primera versión podría recibir un CSV, aplicar un conjunto de etiquetas con control de versiones, presentar las filas inciertas para su revisión y exportar los resultados corregidos. Conserva un conjunto de evaluación reservado para comparar de forma justa los cambios en las etiquetas. El riesgo es que un modelo puede reproducir a bajo costo una taxonomía poco clara. El producto necesita buenas herramientas de revisión y gestión de categorías; una simple interfaz para una llamada a la API es fácil de copiar.

El sistema de asignación de tickets es la mejor primera opción. La responsabilidad sobre cada cola permite identificar errores visibles, contar con un operador que pueda corregirlos y demostrar valor en un flujo recurrente. Habla con ese operador antes de construir una plataforma general de decisiones.

Cuándo conviene mantener la solución actual

Conserva la Responses API cuando necesites extraer campos con tu propio esquema JSON, obtener una explicación escrita o recibir una solicitud del modelo para llamar a una herramienta con argumentos. Decisions cubre los tipos de respuesta más acotados que se describen arriba. Recomendaciones de OpenAI para elegir la interfaz

Mantén las reglas deterministas cuando la respuesta ya esté en un campo de la cuenta o en una política explícita. Un modelo aporta poco a una regla como «asigna los clientes de esta región a este equipo». Conserva la autorización humana y las comprobaciones de permisos de la aplicación para las acciones con consecuencias importantes. Una decisión de asignación puede orientar un flujo de reembolso; no puede establecer el derecho del cliente a recibirlo ni la autoridad del operador para concederlo.

Revisa estas condiciones de integración antes de programar una migración:

• Imágenes: la guía solo permite URL de datos base64 incluidas directamente en la solicitud; es decir, los bytes de la imagen se codifican dentro de ella. Según las instrucciones de la guía, no se admiten URL de imágenes alojadas mediante HTTP o HTTPS ni file_id, el identificador de un archivo subido previamente. Requisitos para imágenes de entrada
• Controles de datos: la guía indica compatibilidad con Zero Data Retention, o ZDR, y con el uso bajo HIPAA para los clientes que cumplan los requisitos. La residencia de datos y el procesamiento regional están disponibles en Estados Unidos y Europa, concretamente el EEE + Suiza. Se aplican requisitos de elegibilidad, acuerdos, configuraciones y limitaciones; estas opciones no se activan automáticamente en todas las cuentas. Disponibilidad de Decisions, Controles de datos de OpenAI
• Madurez del producto: la beta pública es un motivo para conservar una vía de reversión. Si el clasificador actual cumple sus objetivos y cambiarlo no aporta una mejora medible, mantenlo.

Alternativas: Jev, Clef y Microsoft-Decision-1

Compara la misma carga de trabajo etiquetada entre las opciones antes de cambiar de proveedor. Jev, de TypeSafe, recibe el estado y preguntas tipadas a través de su System One API. Cloudflare Clef ofrece decisiones tipadas en Workers AI. Microsoft-Decision-1 está disponible en Microsoft Foundry para tareas como clasificación, enrutamiento y priorización. Inicio rápido de TypeSafe, Documentación de Cloudflare Clef, Anuncio de Microsoft

Las integraciones existentes, los requisitos de alojamiento, los resultados de evaluación y la gestión de excepciones deben guiar la selección. Nuestra guía de enrutamiento de tickets de soporte con Jev explica el patrón de asignación; ¿Jev Router es gratis? aclara la diferencia entre el software de enrutamiento y la inferencia alojada. Evalúa por separado el formato de solicitud y el comportamiento de la confianza de cada proveedor.

Por dónde empezar el lunes

Elige la llamada de clasificación que envía tickets a un conjunto de colas ya establecido. Pide a su responsable que revise una muestra representativa y etiquetada, deje por escrito las tasas de error y revisión aceptables, y compare Decisions en paralelo con la llamada actual sin cambiar las asignaciones. Sustitúyela solo cuando Decisions demuestre que merece ocupar ese lugar en el flujo.

Si necesitas un flujo de asignación adaptado a las herramientas que ya utilizas, desarrollamos sistemas de IA para producción.