¿IA o reglas de negocio?

No todas las decisiones necesitan un modelo

Una regla de negocio expresa una condición y una acción: «si el país es España y el importe supera el límite aprobado, envía a revisión». Con entradas estructuradas y condiciones claras, esa regla produce un resultado previsible y puede probarse con casos definidos.

La IA puede interpretar texto, imágenes o lenguaje variable, pero sus salidas pueden cambiar y requieren evaluación. La elección depende de la forma de los datos, la estabilidad de la política y el impacto de equivocarse. Una arquitectura práctica puede usar IA para extraer o sugerir y reglas para validar límites y permisos.

Árbol de decisión

1. ¿La decisión puede expresarse como condiciones verificables? Implementa y prueba las reglas.
2. ¿La entrada es texto libre, documentos o contenido con muchas variantes? Evalúa IA para interpretar o extraer información.
3. ¿Hay límites que nunca deben romperse? Codifícalos como validaciones y controles independientes del modelo.
4. ¿La salida puede causar un efecto relevante? Mantén aprobación humana o una barrera antes de ejecutar.
5. ¿Puedes detectar y corregir errores? Si no, primero diseña esa capacidad; no automatices la decisión completa.

Casos y contraejemplos

Caso	Enfoque inicial	Por qué
Aplicar un límite de gasto aprobado	Regla	La condición es explícita y necesita consistencia
Extraer proveedor y total de facturas con diseños variados	IA más validaciones	La lectura puede ser variable, pero los campos deben cumplir controles
Dirigir correos según una lista cerrada de códigos	Regla	Categorías y correspondencias conocidas
Clasificar una consulta escrita de muchas maneras	IA como propuesta, con revisión	Hay variación lingüística y un resultado incorrecto debe detectarse
Autorizar automáticamente una operación sensible basándose solo en texto generado	No delegar sin controles	La salida necesita política, autorización y trazabilidad explícitas

Una regla también puede ser mala opción si nadie sabe cuál es la política vigente o hay tantas excepciones que se contradicen. En ese caso, aclara el proceso antes de traducirlo a código o IA.

Combina con límites claros

Separa el flujo en pasos que puedan probarse: normalizar entrada, extraer información, aplicar reglas, revisar incertidumbre y ejecutar una acción autorizada. La IA no debería inventar una excepción a la política. Si un dato obligatorio no está, detén el proceso o solicita intervención.

Registra qué parte produjo cada decisión y conserva el motivo de una derivación. Define una «zona de abstención»: niveles de confianza o condiciones bajo las que el sistema no propone una respuesta automática. No tomes un valor de confianza del modelo como garantía estadística sin calibrarlo en datos representativos.

Compara por coste total y riesgo

Considera desarrollo, mantenimiento de reglas, coste variable de IA, revisión humana, auditoría y fallos. Una solución determinista puede requerir actualizar muchas condiciones; un modelo puede reducir esa carga y añadir evaluación continua. Prueba el flujo sobre ejemplos históricos o sintéticos representativos, con resultados esperados revisados por responsables del proceso.

El marco de IA de NIST aporta una estructura para gobernar y medir riesgos. Aplícalo con proporcionalidad al uso: el objetivo es elegir controles verificables, no añadir complejidad sin motivo.