Microsoft Decision-1: qué es un modelo de decisión y cuándo usarlo

La mayoría de las llamadas dentro de una aplicación de IA no son peticiones de prosa. Son decisiones: a qué cola va este ticket, si esta llamada a herramienta es segura, si esta respuesta generada cumple la rúbrica, cuál de cuatro acciones viene después. Los equipos venían tomando esas decisiones con un modelo de lenguaje y una expresión regular sobre su salida, pagando precios de buque insignia por un sí o un no.

Microsoft Decision-1, anunciado el 9 de octubre de 2026, es la respuesta de Microsoft a ese despilfarro: un modelo que puntúa un conjunto fijo de opciones y devuelve una probabilidad por cada una, sin generar texto. Este artículo explica qué significa eso, en qué se diferencia de un gran modelo de lenguaje, qué afirma Microsoft y qué está verificado, y los casos de uso en los que encaja. Es el complemento de ¿Qué LLM usar?, donde Decision-1 aparece como una de nueve familias de modelos, y reutiliza los patrones de agente y evaluación de mi proyecto de inteligencia documental en Azure.

La respuesta corta

Decision-1 es un modelo de decisión, no un chatbot. Dale un texto (el estado) y un conjunto de preguntas con respuestas fijas, y devuelve una probabilidad calibrada por respuesta en una pasada: sí/no, una de varias opciones, o una posición en una escala ordenada. Está postentrenado a partir de Qwen3.5-9B, acepta hasta 32.768 tokens de texto, cuesta 0,042 $ por millón de tokens de entrada con salida gratuita, y corre en Microsoft Foundry y en OpenRouter. Úsalo para enrutar, clasificar, priorizar, controlar agentes y calificar. Usa un modelo de lenguaje cuando la respuesta haya que escribirla.

¿Qué diferencia hay entre un modelo de decisión y un LLM?

Un modelo de lenguaje genera una respuesta token a token; un modelo de decisión evalúa opciones que tú le das y las puntúa. La diferencia está en el contrato, no en la inteligencia. Con un LLM escribes "analiza esta queja y di qué deberíamos hacer", recibes un párrafo y lo interpretas, esperando que el formato se mantenga. Con un modelo de decisión envías la queja más las opciones "reembolso, reposición del pedido, escalar, no hacer nada", y recibes una probabilidad por cada una. La Figura 1 muestra los dos flujos sobre la misma entrada.

¿Cómo funciona la API de Decision-1?

La petición tiene tres partes: el texto a puntuar, las preguntas y el nombre del despliegue. Cada pregunta tiene un tipo, instrucciones y las respuestas permitidas. Microsoft Learn documenta tres tipos en la Decisions API de Foundry, y la entrada de Decision-1 en el catálogo lista las mismas formas con otros nombres: sí/no, opción múltiple y valoración.

Esta es la forma de una pregunta de elección y de su respuesta en la Decisions API de Foundry, tal como la documenta Microsoft Learn el 21 de octubre de 2026. Los valores son ilustrativos, como en el propio ejemplo de Microsoft.

{
  "model": "TU-NOMBRE-DE-DESPLIEGUE",
  "input": "Me han cobrado dos veces el pedido.",
  "questions": [
    {
      "type": "choice",
      "name": "departamento",
      "instructions": "¿Qué departamento debe atender esta queja?",
      "choices": [
        { "value": "facturacion", "description": "Pagos y reembolsos." },
        { "value": "tecnico", "description": "Problemas del producto." },
        { "value": "envios", "description": "Entrega y seguimiento." },
        { "value": "otro", "description": "Cualquier otra petición." }
      ]
    }
  ]
}

{
  "type": "choice",
  "name": "departamento",
  "choice": "facturacion",
  "probabilities": [
    { "value": "facturacion", "probability": 0.95 },
    { "value": "tecnico", "probability": 0.02 },
    { "value": "envios", "probability": 0.01 },
    { "value": "otro", "probability": 0.02 }
  ],
  "confidence": 0.93
}

Cuatro reglas de la documentación que ahorran una semana de depuración:

1. Dale a cada pregunta un nombre único. El array de respuestas vuelve en el mismo orden, y el nombre es como las emparejas.
2. Pon las preguntas independientes en una sola petición. Varias preguntas sobre el mismo texto son una llamada; una pregunta que depende de una respuesta anterior es una segunda llamada.
3. Incluye una opción de reserva como "otro" o "no se puede saber" cuando las categorías no cubran todas las entradas, y trata un rechazo como algo distinto de una probabilidad baja.
4. Elige cada umbral con ejemplos etiquetados de tu propia aplicación, según el coste de un falso positivo y de un falso negativo en ese escenario.

La guía de Microsoft Learn de la Decisions API usa el modelo gpt-6-luna y el endpoint /openai/v1/decisions; Decision-1 se despliega desde el catálogo de Foundry como modelo propio, con los mismos tres tipos de pregunta. Comprueba la entrada del catálogo para el endpoint exacto de tu despliegue.

¿Qué afirma Microsoft, y qué está verificado de forma independiente?

Todo lo que sigue procede del anuncio de Microsoft y de sus páginas de Learn. Nada había sido reproducido por una evaluación independiente a 6 de noviembre de 2026, y los análisis de terceros señalan que el catálogo de Foundry describe la metodología de los benchmarks sin publicar cifras. Lee la tabla como las afirmaciones del proveedor.

La lectura honesta: el argumento de arquitectura es sólido y el precio es real, y los números de calidad son lo que debes medir tú mismo con unos cientos de ejemplos etiquetados antes de fiarte de un umbral.

¿Cuándo usar Decision-1 en vez de un LLM?

Hazte una pregunta: ¿puedes enumerar todas las respuestas aceptables antes de la llamada? Si sí, y no necesitas una explicación escrita, un modelo de decisión encaja. Si la respuesta hay que escribirla, resumirla o explicarla, no.

La conclusión de arquitectura es la misma que recorre la comparación de LLM: un agente puede tomar treinta decisiones en una ejecución, y la mayoría no necesita un modelo de razonamiento. Un modelo de decisión ligero se encarga de los controles y las comprobaciones; el modelo potente, de la planificación y la redacción.

¿Dónde se coloca un modelo de decisión en un sistema real?

La Figura 2 muestra los tres sitios donde yo lo pongo: triaje de soporte, un bucle de agente y un pipeline de evaluación. Toca una capa para leer qué pasa en ella.

Support triageAgent loopEvaluation and labelling

Cada ticket se puntúa una vez: si es urgente, qué departamento, cuánta frustración hay. Un modelo de lenguaje solo redacta la respuesta, y solo para los tickets que la necesitan.

1. EntradaEmail, chat, web form
2. Modelo de decisiónMicrosoft Decision-1
3. EnrutadoQueue per departmentSLA timers
4. Redacción de la respuestaGPT-6.1 TerraClaude Sonnet 5.5
5. Control de calidadMicrosoft Decision-1
6. PersonasAgent review

Uso típico: Centros de soporte, buzones compartidos, formularios y cualquier cola donde miles de elementos al día necesitan las mismas pocas etiquetas.

Toca una capa para leer qué hace esa tecnología en esta pila.

Support triage. Cada ticket se puntúa una vez: si es urgente, qué departamento, cuánta frustración hay. Un modelo de lenguaje solo redacta la respuesta, y solo para los tickets que la necesitan. Uso típico: Centros de soporte, buzones compartidos, formularios y cualquier cola donde miles de elementos al día necesitan las mismas pocas etiquetas.

Capa	Tecnología	Qué hace
Entrada	Email, chat, web form	El texto del ticket es el estado que puntúa el modelo; la ficha del cliente puede añadirse como contexto.
Modelo de decisión	Microsoft Decision-1	Tres preguntas en una llamada: ¿urgente? (sí/no), departamento (elección), frustración (puntuación). Cada respuesta es una probabilidad por opción.
Enrutado	Queue per department, SLA timers	Los umbrales que elegiste con tickets etiquetados deciden la cola; todo lo que queda por debajo va a una persona.
Redacción de la respuesta	GPT-6.1 Terra, Claude Sonnet 5.5	Un modelo de lenguaje de gama media redacta la respuesta con la política recuperada; es el único paso que genera texto.
Control de calidad	Microsoft Decision-1	Una pregunta con rúbrica califica el borrador: ¿se apoya en la política? ¿es cortés? ¿está completo? Las puntuaciones bajas vuelven atrás o a una persona.
Personas	Agent review	Las personas ven los casos inciertos y las muestras que auditas; sus etiquetas alimentan la siguiente revisión de umbrales.

Agent loop. Un modelo de razonamiento planifica y escribe; un modelo de decisión controla cada llamada a herramienta y comprueba cada resultado. Treinta decisiones por ejecución cuestan céntimos en vez de dólares. Uso típico: Agentes que tocan sistemas reales: actualizaciones de CRM, pagos, despliegues, cualquier cosa donde una llamada equivocada a una herramienta tiene un coste.

Capa	Tecnología	Qué hace
Tarea	User goal	La tarea en lenguaje natural, más el contexto que el agente puede ver.
Planificación	Claude Opus 5.5, GPT-6 Sol	El modelo de razonamiento decide qué hacer a continuación y redacta la llamada a la herramienta.
Control previo a la acción	Microsoft Decision-1	¿Está la llamada dentro de la política? ¿Es una escritura? ¿Necesita aprobación? Tres preguntas de sí/no, puntuadas en una pasada antes de ejecutar nada.
Herramientas	MCP tools, APIs and databases	El mismo registro de herramientas sirve al agente y a los clientes MCP; los permisos son por rol.
Comprobación posterior	Microsoft Decision-1	¿Ha tenido éxito el paso? Continuar, reintentar o escalar: una pregunta de elección sobre la salida de la herramienta.
Estado	PostgreSQL, Redis	Puntos de control del bucle, para que una ejecución pueda pausarse ante una persona y reanudarse.
Observabilidad	OpenTelemetry traces, MLflow	Cada decisión, sus probabilidades y su coste acaban en una traza por ejecución.

Evaluation and labelling. Calificar miles de salidas de modelo o etiquetar un conjunto de datos es una decisión por elemento. Un modelo de decisión lo hace de forma consistente y barata; un juez de lenguaje se muestrea para la justificación escrita. Uso típico: Pipelines de evaluación de LLM, etiquetado de datos, colas de moderación de contenido y pruebas de regresión antes de actualizar un modelo.

Capa	Tecnología	Qué hace
Elementos a calificar	Model outputs or raw records	Respuestas del modelo candidato, o registros sin etiquetar que esperan una categoría.
Rúbrica	Ordered levels with criteria	Cada nivel tiene criterios observables; los niveles contiguos deben diferir con claridad, o las probabilidades se difuminan.
Puntuación	Microsoft Decision-1	Una pregunta de puntuación devuelve una probabilidad por nivel y una puntuación ponderada; una pregunta de elección devuelve la etiqueta.
Justificación muestreada	LLM judge, Human audit	Una muestra pequeña recibe una explicación escrita de un modelo de lenguaje y una comprobación humana, para detectar deriva en la propia rúbrica.
Seguimiento	MLflow, Dashboards	Puntuaciones por versión de modelo, por versión de prompt y por conjunto de documentos, lado a lado.
Realimentación	Prompt and threshold updates	Rúbrica, umbrales y prompts cambian con evidencia; el mismo conjunto se vuelve a ejecutar antes de cada actualización.

El bucle de agente es el que más cambia la economía, así que la Figura 3 lo dibuja completo.

El patrón en palabras:

1. Planificar. Un modelo de razonamiento (Claude Opus 5.5, GPT-6 Sol) lee la tarea y redacta la siguiente llamada a herramienta.
2. Controlar. Decision-1 responde tres preguntas de sí/no sobre el borrador: dentro de la política, acción de escritura, necesita aprobación humana. Los umbrales salen de ejemplos etiquetados; cualquier duda espera a una persona.
3. Actuar. La llamada a herramienta corre por el mismo registro que sirve a los clientes MCP, con permisos por rol.
4. Comprobar. Decision-1 puntúa la salida de la herramienta con una pregunta de elección: continuar, reintentar o escalar.
5. Registrar. El estado va a un punto de control en PostgreSQL o Redis para que la ejecución pueda pausarse y reanudarse, y cada decisión con sus probabilidades y su coste acaba en la traza de OpenTelemetry.

Es el mismo agente con aprobación que construí en el proyecto de inteligencia documental en Azure; la diferencia es que entonces los controles eran llamadas a un modelo de lenguaje, y un modelo de decisión los hace más baratos y más consistentes.

¿Qué cuesta a escala?

Aritmética a precio de lista, no un presupuesto. Tres cargas de trabajo, cada una con sus supuestos declarados, comparadas con los mismos tokens en GPT-6.1 Terra a 1 $ por millón de tokens de entrada (sin contar la salida, lo que favorece al LLM).

La proporción es lo importante: con el mismo número de tokens el modelo de decisión cuesta alrededor del 4 por ciento del precio de entrada de un modelo de lenguaje de gama media, y no produce ningún token de salida. La latencia se mueve igual, de segundos a milisegundos, que es lo que hace aceptables treinta controles por ejecución de agente.

¿Cuáles son los límites?

• Sin explicación. El modelo devuelve probabilidades y nada más. Cuando un usuario o un auditor necesite una justificación, añade una llamada a un modelo de lenguaje para los casos muestreados.
• Solo texto, 32K tokens. Sin imágenes, audio ni vídeo; los documentos largos hay que trocearlos o resumirlos antes. Para imágenes, la Decisions API de Foundry con gpt-6-luna ofrece los mismos tipos de pregunta.
• Pesos cerrados. Sin descarga, ajuste fino, cuantización ni autoalojamiento. Si lo necesitas, el modelo base Qwen3.5-9B es abierto, y un clasificador entrenado con tus etiquetas sigue siendo la opción clásica.
• Solo benchmarks del proveedor. Las cifras de velocidad, precisión y calibración son las de Microsoft a 6 de noviembre de 2026.
• Una base que se mueve. Microsoft planea reconstruir Decision-1 sobre otros modelos; conserva el conjunto etiquetado y repítelo en cada versión, como harías ante cualquier retirada de modelo.
• No para decisiones trascendentes sobre personas. La ficha del modelo descarta que sea la única base en crédito, empleo, vivienda, seguros, educación, sanidad y derechos legales.
• Los umbrales son tuyos. Una probabilidad solo sirve con un umbral que elegiste con tus propios datos, y una probabilidad máxima baja significa una persona, no una moneda al aire.

¿Cómo se fijan los umbrales?

1. Reúne entre 200 y 500 ejemplos etiquetados por pregunta a partir del tráfico real, incluidos los feos.
2. Pásalos por la pregunta tal como está escrita, y guarda la probabilidad por opción.
3. Dibuja precisión y exhaustividad frente al umbral para cada opción, y elige el punto en el que el coste de un falso positivo y el de un falso negativo se equilibran en ese escenario.
4. Define la banda de escalado: todo lo que quede entre los umbrales, más los rechazos, va a una persona.
5. Vigila la deriva cada semana: la proporción de escalados, la coincidencia con las etiquetas humanas en una muestra y la distribución de las probabilidades máximas. Un cambio significa que cambiaron las entradas o la versión del modelo.
6. Repite el conjunto en cada versión nueva del modelo antes de cambiar el despliegue.

¿Qué servicio elegir para una decisión?

La Figura 4 es la guía de tres preguntas. Termina en Decision-1 más veces de las que esperarías, y en un modelo de lenguaje siempre que la respuesta haya que escribirla.

Fuentes

• Microsoft, Microsoft-Decision-1: Our model for fast decision-making, Achint Srivastava, 9 de octubre de 2026: modelo base, tipos de pregunta, objetivo de calibración, comparaciones de latencia y precisión, casos de uso internos, precio y disponibilidad. Leído el 6 de noviembre de 2026.
• Microsoft Learn, Foundry Models sold by Azure, página fechada el 21 de septiembre de 2026 y actualizada el 29 de octubre de 2026: la fila de Microsoft-Decision-1 (decisión, clasificación de texto, clasificación sin ejemplos; puntuación de decisiones calibrada; preguntas de sí/no, opción múltiple, valoración, clasificación y rúbrica; puntuación en una sola pasada sobre entradas de hasta 32K tokens; solo texto; sin explicaciones).
• Microsoft Learn, guía de la Azure OpenAI Decisions API, página fechada el 21 de octubre de 2026: los tipos de pregunta predicado, elección y puntuación, las formas de petición y respuesta, los rechazos y las indicaciones sobre umbrales.
• Catálogo de Microsoft Foundry, Microsoft-Decision-1: la opción de abstención y la restricción sobre decisiones trascendentes sobre personas. El catálogo se abre dentro del portal de Foundry con sesión iniciada; esos dos puntos están tal como los citan los análisis de abajo, así que compruébalos en tu propio tenant.
• OpenRouter, microsoft/microsoft-decision-1: el listado del 9 de octubre de 2026 con el mismo precio.
• Análisis de terceros leídos el 6 de noviembre de 2026 para el estado de la verificación independiente (sin cifras de benchmark publicadas en la entrada del catálogo; pesos no distribuidos): eesel.ai y Orca Router. Sus números no se usan aquí.
• Mis propias notas de estudio de noviembre de 2026 sobre la tabla de casos de uso, el bucle de agente, la aritmética de costes y el procedimiento de umbrales, escritas a partir de los proyectos de este sitio. Las cifras de coste son aritmética a precio de lista sobre supuestos declarados, no presupuestos.