Qué es un modelo de decisión (System One)

Una tienda de recambios de Valladolid recibe mensajes sobre pedidos. Los casos de Valladolid y Zaragoza son ejemplos ilustrativos, con datos ficticios, no clientes ni resultados medidos. El modelo propone enviar cada incidencia a facturación, envíos o atención al cliente. La encargada quiere separar los mensajes para que lleguen a la persona adecuada. No le está encargando redactar una respuesta ni resolver una reclamación.

El programa que recibe esa propuesta aplica las reglas del negocio. Puede asignar internamente los casos claros y dejar los dudosos pendientes de revisión. En este diseño no debe cambiar datos de cobro, devolver dinero ni cerrar reclamaciones. Son límites que la tienda debe configurar: contratar un modelo no los activa por sí solo.

TypeSafe llama System One a una familia de modelos que recibe información y devuelve resultados acotados, como una elección entre opciones. El nombre alude al pensamiento rápido popularizado por Daniel Kahneman. Aquí hablamos de ese uso del término «modelo de decisión», con Jev como ejemplo. No es una definición única para cualquier producto que utilice esas palabras. Tampoco indica que el sistema pueda actuar por su cuenta: esa capacidad depende de lo que construyas alrededor del modelo.

También hay modelos de decisiones de negocio basados en diagramas y tablas de reglas. Decision Model and Notation, abreviado DMN, es un estándar de OMG para representarlos. No exige esta clase de IA. Si un proveedor te ofrece un «modelo de decisión», pídele que concrete qué recibe, qué devuelve y qué parte del proceso pretende resolver.

Puedes limitar las respuestas a facturación, envíos y atención al cliente. Eso impide devolver una categoría inventada, pero no evita elegir mal entre las admitidas. Un mensaje sobre un envío perdido puede acabar en facturación con un formato perfectamente válido. Al evaluar la prueba, comprueba si el destino es correcto y qué trabajo provoca corregirlo. Si solo verificas que aparece uno de los departamentos admitidos, estarás comprobando el formato y dejando fuera precisamente el juicio que necesitabas evaluar.

En Jev, la confianza es un valor que resume cómo se reparten las probabilidades de las opciones. No es un porcentaje de acierto aplicable a cualquier caso. La calibración, es decir, comprobar si las probabilidades se corresponden con los resultados observados, se evalúa sobre grupos de predicciones. No asegura una respuesta individual correcta. El nivel que aceptes debe depender de las consecuencias del error.

Empieza por el dato que ya tienes. Si el cliente selecciona el departamento en un formulario, puedes repartirlo con una comparación. En n8n, el paso Switch permite escoger rutas según condiciones. Añadir un modelo a esa comparación no resuelve una necesidad nueva. Si no conoces este tipo de proceso, consulta qué es una automatización.

Si necesitas interpretar mensajes escritos de formas distintas, tiene sentido evaluar un modelo con una pregunta acotada. Pide solo el juicio necesario, con la información pertinente. Para repartir incidencias, pregunta por el departamento; no le encargues también decidir excepciones comerciales. La preparación de una devolución puede combinar preguntas separadas y comprobaciones de datos que ya sean inequívocos. Cuando la información no permita resolver una pregunta, deja el expediente pendiente para la persona responsable en vez de forzar una elección.

Para evaluar Jev, prueba mensajes como los tuyos. Su documentación sitúa el inglés como idioma principal de entrenamiento y de mejor precisión; no da un porcentaje de acierto en castellano. Revisa las clasificaciones y no traslades resultados del fabricante a tu empresa. Para distinguir quién organiza el trabajo, consulta qué es un agente de IA.