Decisions API: una clasificación útil necesita una política de actuación

OpenAI anunció el 22/10 la disponibilidad general de Decisions API con gpt-6-luna, con hasta 400 preguntas por solicitud. (OpenAI)

La guía distingue respuestas de condición, elección y puntuación: predicate, choice y score. La aplicación conserva la responsabilidad de ejecutar cualquier acción posterior. (OpenAI)

Empieza por una pregunta que puedas corregir

Una primera aplicación razonable sería sugerir a qué equipo derivar una consulta. La persona puede comprobar el contenido y cambiar el destino. Es un problema distinto de aprobar un reembolso, conceder acceso o rechazar a alguien automáticamente. No amplíes la autoridad de un clasificador solo porque ya devuelve una categoría.

Escribe la pregunta operativa antes del prompt: qué debe identificar, qué entradas recibe y qué información no puede inferir. Si solo le entregas el texto de un mensaje, no debería tratar como confirmado un dato que depende del registro del pedido o de una autorización externa.

La probabilidad no es una promesa de acierto

Un valor producido por el modelo solo sirve para actuar después de observar cómo se comporta en tu tarea. No lo interpretes como una garantía sobre una consulta concreta ni como la tasa de éxito de tu negocio. Un umbral elegido porque «parece alto» puede ocultar errores caros.

Prepara un conjunto de casos etiquetados con criterios claros. Incluye mensajes ambiguos, varias necesidades en un texto, categorías poco frecuentes y datos incompletos. Reserva casos distintos de los utilizados para ajustar instrucciones; de lo contrario, puedes mejorar sobre ejemplos conocidos sin saber qué ocurrirá con otros.

El coste del error decide la derivación

Equivocarse de equipo puede causar demora; activar una acción sobre dinero o permisos puede tener consecuencias diferentes. Define el tratamiento por tipo de fallo. En un piloto de enrutado, mide tanto los destinos incorrectos como los casos retenidos para una persona: automatizar muchos mensajes con errores y retenerlos casi todos son resultados operativos distintos.

• Establecer qué etiquetas son válidas y cuándo varias necesidades requieren revisión.
• Registrar aciertos y errores por categoría, no solo una media global.
• Observar qué sucede al cambiar el vocabulario o el tipo de cliente.
• Definir qué hacer ante error de API, respuesta no utilizable o datos insuficientes.
• Revisar cualquier cambio de modelo o instrucciones antes de ampliar el alcance.

Separa el clasificador del ejecutor

ejemplo conceptual, no cuerpo de una petición API:
  preparar evidencia mínima autorizada
  obtener propuesta de clasificación
  validar formato y reglas de la tarea
  si falta evidencia o falla la política: enviar a revisión
  si se permite: sugerir destino y registrar la decisión
  ejecutar acciones sensibles solo con autorización independiente

Mantener esa separación permite cambiar una regla de negocio sin convertir cada ajuste en una nueva promesa del modelo. También facilita explicar por qué se retuvo una solicitud: dato ausente, política incumplida, salida inválida o revisión pendiente no son el mismo motivo.

Qué tendría que justificar pasar del piloto al uso diario

Acordaríamos una matriz de errores, responsables de corrección, coste por caso procesado y comportamiento cuando el servicio no responde. Los límites de la API son capacidad técnica, no una recomendación de agrupar siempre el máximo de preguntas. Define el tamaño de trabajo según tiempos, recuperación y trazabilidad.

No hemos ejecutado un benchmark ni atribuido porcentajes de mejora a esta propuesta. Si necesitas incorporar un clasificador a un proceso real, el alcance de software e IA aplicada debe concretar entradas, permisos, evaluación y criterio de aceptación antes de automatizar acciones.