Traducir reglas de negocio y decisiones

Los workflows empresariales están llenos de frases que parecen reglas hasta que intentas ejecutarlas: “aplica el descuento habitual”, “si el cliente es importante”, “si el documento parece correcto” o “si hay riesgo, escálalo”. Para automatizar una decisión hay que convertir estas expresiones en criterios observables y asignar correctamente qué tipo de mecanismo debe resolverlas.

DMN —Decision Model and Notation— se creó precisamente para especificar decisiones y reglas de negocio de forma comprensible y ejecutable. No necesitas adoptar DMN como herramienta para aplicar el principio central: separar la lógica de decisión del resto del flujo y hacer explícitas sus entradas, reglas y resultados.

Separa cuatro clases de decisión

Antes de escribir una regla, clasifica el problema.

Cálculo determinista

La salida se obtiene mediante una fórmula o transformación conocida. Por ejemplo, calcular impuestos, sumar importes o convertir una fecha a un periodo.

Aquí no existe una razón para introducir IA si la fórmula está bien definida.

Regla de negocio

La organización ha establecido una política explícita: “si el importe supera 20.000 €, requiere aprobación de dirección” o “si el país no pertenece a la lista admitida, detener el alta”.

Estas reglas deben tener propietario y versión. El hecho de que puedan codificarse no significa que sean inmutables.

Inferencia con IA

La salida depende de interpretar información no completamente estructurada: clasificar un correo, extraer datos de un documento variable, resumir una solicitud o sugerir una categoría.

La IA produce una propuesta que necesita criterios de aceptación, tratamiento de incertidumbre y, en ciertos casos, revisión.

Juicio humano

Algunas decisiones requieren contexto, responsabilidad o criterios que la organización no desea delegar. Un descuento excepcional, una aprobación contractual o una decisión de alto impacto pueden permanecer humanas aunque el resto del proceso esté automatizado.

Redacta una ficha de decisión

Para cada decisión relevante crea una ficha con:

• nombre;
• propósito;
• propietario;
• entradas;
• fuente de cada entrada;
• resultado posible;
• regla o mecanismo;
• prioridad entre reglas;
• comportamiento cuando faltan datos;
• tratamiento de conflicto;
• evidencia que debe conservarse;
• fecha o versión de la política cuando proceda.

Esta ficha evita que una condición crítica quede escondida dentro de un prompt, una fórmula en una hoja de cálculo o un fragmento de código sin propietario.

Usa tablas de decisión para descubrir huecos

Una tabla de decisión permite probar combinaciones de entradas antes de implementar.

Ejemplo simplificado:

La tabla obliga a preguntar qué ocurre en combinaciones no contempladas. También ayuda a detectar solapamientos: dos reglas podrían ser verdaderas al mismo tiempo y producir salidas incompatibles.

Distingue política de configuración

No todos los umbrales deberían estar incrustados en código. Si un límite cambia por decisión de negocio, conviene tratarlo como configuración gobernada: con propietario, historial y fecha de vigencia.

La configuración tampoco debe ser un cajón sin control. Cambiar un umbral puede modificar cientos de decisiones futuras, por lo que necesita trazabilidad y pruebas.

Diseña el papel de la IA como una decisión limitada

Cuando una decisión necesita inferencia, define exactamente qué tarea hace el modelo y qué no hace.

Por ejemplo: “clasificar el motivo principal del correo entre seis categorías permitidas” es más controlable que “decidir qué hacer con el cliente”. El workflow puede usar la categoría como una entrada más y aplicar después reglas deterministas.

Define:

• entrada autorizada;
• categorías o salida esperada;
• formato;
• criterio de aceptación;
• qué ocurre si la salida no es válida;
• cuándo se pide revisión humana;
• qué datos deben conservarse para evaluar el comportamiento.

No conviertas el prompt en la única especificación de negocio. La decisión debe poder describirse fuera del modelo.

Trata ausencia y conflicto como casos diseñados

Los datos reales pueden faltar o contradecirse. Si el CRM dice que el cliente es estratégico y el ERP lo clasifica como estándar, el workflow necesita una regla de precedencia o una ruta de reconciliación.

Del mismo modo, “dato ausente” no debe convertirse automáticamente en falso. Puede significar desconocido, pendiente o error de integración.

Diseña estados distintos cuando esas diferencias cambien la acción.

Ejemplo: autorización de descuento

Supongamos que un borrador contiene un descuento propuesto. El proceso puede separar:

1. cálculo del porcentaje: determinista;
2. política de umbrales: regla de negocio;
3. extracción del descuento solicitado desde un correo libre: inferencia con IA;
4. autorización excepcional: juicio humano.

La automatización coordina los cuatro mecanismos, pero no los confunde.

Ejercicio: crea el catálogo de decisiones

Selecciona cinco decisiones del workflow. Para cada una:

1. clasifica el tipo: cálculo, regla, IA o humano;
2. escribe entradas y fuente;
3. define salidas posibles;
4. especifica comportamiento ante dato ausente;
5. identifica conflicto posible;
6. asigna propietario;
7. decide qué evidencia debe quedar registrada.

Después transforma al menos una regla en una tabla de decisión y busca combinaciones no cubiertas.

Resultado de la lección

Las decisiones del workflow quedan separadas de la secuencia de pasos y expresadas en términos comprobables. Ya puedes saber qué lógica pertenece al negocio, qué puede resolverse de forma determinista, dónde aporta IA y dónde debe conservarse responsabilidad humana. El siguiente paso es conectar esa lógica con los sistemas que contienen y modifican los datos reales.