Cómo elegir entre reglas, modelos predictivos e IA generativa: una guía de triaje

Empieza por el problema, no por la tecnología

Una tarea compleja no exige automáticamente un modelo de lenguaje. El primer paso es describir el trabajo como una decisión concreta: qué información entra, qué resultado se necesita, quién lo revisa y qué ocurre si el resultado es incorrecto. Solo entonces tiene sentido comparar reglas, modelos predictivos, IA generativa o la opción de no automatizar.

Esta guía es un marco de triaje, no una afirmación de que una técnica sea siempre superior a otra. La evidencia aportada explica árboles de decisión como algoritmos aplicables a clasificación y regresión, pero no compara directamente LLM, modelos predictivos y reglas, ni establece umbrales legales o costes unitarios. Por eso, las rutas siguientes son recomendaciones de diseño que cada organización debe validar con sus datos, procesos y obligaciones aplicables.

Criterio 1: identifica la forma del dato y la salida

Separa el formato de entrada del tipo de tarea. Las tablas, registros de transacciones y variables numéricas suelen permitir formular preguntas precisas sobre campos conocidos: contar, filtrar, calcular o predecir una etiqueta. Antes de introducir un modelo, comprueba si una consulta SQL, una validación de esquema o una regla expresa la decisión de forma suficiente.

El texto libre, las imágenes y otros contenidos no estructurados pueden requerir extracción, clasificación semántica o generación de borradores. Eso no significa que cada paso deba resolverse con un LLM: puede utilizarse una combinación de extracción, reglas de validación y revisión humana. Un árbol de decisión, en sentido técnico, es un algoritmo que aprende condiciones para clasificar o estimar valores; no debe confundirse con el diagrama de decisiones que un equipo dibuja para escoger una arquitectura.

Criterio 2: determina qué significa equivocarse

No basta con medir la exactitud promedio. Especifica los errores que importan: una transacción legítima rechazada, una alerta omitida, una respuesta inventada o un dato sensible revelado. Estima su impacto financiero, operativo, reputacional y sobre las personas afectadas; después establece qué clase de error obliga a revisión, reversión o escalamiento.

Si un resultado activa pagos, denegaciones, decisiones sobre personas o acciones difíciles de deshacer, limita la autonomía hasta demostrar que los controles son adecuados. Trazabilidad tampoco equivale a que el modelo sea interpretable: registra la entrada permitida, la versión del sistema, el resultado, las validaciones y la intervención humana. La documentación proporcionada no permite afirmar qué obligaciones concretas del AI Act aplican a un caso particular ni que una ley imponga siempre reglas deterministas o un modelo explicable. Esa evaluación requiere analizar el uso, el mercado, la fecha y la configuración del sistema.

Criterio 3: calcula el coste del sistema completo

Una comparación económica útil incluye más que el precio de inferencia. Cuenta integración, limpieza y mantenimiento de datos, pruebas, monitorización, revisiones humanas, gestión de errores, seguridad, cambios de proveedor y coste de oportunidad. Las reglas pueden ser baratas cuando el proceso es estable, pero costosas de mantener si proliferan excepciones. Un modelo puede reducir trabajo repetitivo, pero añade evaluación, operación y controles; el coste depende del diseño y del uso real.

Para estimar el gasto de un modelo generativo, recoge precio vigente, tokens medios de entrada y salida, número de llamadas por tarea, reintentos y llamadas a herramientas. Para reglas, mide horas de desarrollo y mantenimiento, incidencias y tiempo de operación. No hay en las fuentes aportadas una tarifa verificable de modelos ni cifras comparables de mantenimiento; por tanto, no es posible calcular aquí el coste real de un millón de transacciones al mes.

Matriz: cuatro rutas posibles

Las cuatro rutas son categorías operativas, no una escala de madurez ni una obligación de adoptar IA. “Determinista” significa que una lógica explícita produce la salida; “predictivo” estima una clase o valor a partir de ejemplos; “generativo asistido” prepara una salida que una persona verifica; “generativo autónomo” permite ejecutar una acción sin aprobación caso por caso. Cuanto mayores sean el impacto y la dificultad de corregir un error, más justificadas están las barreras y la supervisión.

Los árboles de decisión ilustran una familia de modelos predictivos: aprenden condiciones para clasificar o estimar valores y pueden ser una opción cuando los datos y la tarea son adecuados. No son equivalentes a reglas escritas a mano, aunque ambos puedan dar lugar a decisiones expresadas mediante condiciones. La elección debe apoyarse en una evaluación con datos representativos y en requisitos de operación, no en el nombre de la técnica.

Ejemplos aplicados en ámbitos distintos

En operaciones financieras, si una regla contractual define con claridad un recargo o un límite, calcula primero con lógica explícita y conserva una ruta para excepciones. Si la tarea consiste en priorizar casos con patrones históricos, evalúa un modelo predictivo frente a una línea base sencilla. Si el caso requiere entender un mensaje libre, la generación puede ayudar a resumirlo, pero la decisión de pago o rechazo puede mantenerse separada y controlada.

En soporte al cliente, recuperar una respuesta aprobada y preparar un borrador son tareas distintas. Un flujo generativo asistido puede proponer texto a partir de materiales autorizados; la persona que atiende verifica que responde a la pregunta y que no añade información sin respaldo. Solo tendría sentido considerar una respuesta autónoma para un conjunto limitado de consultas con pruebas de calidad, límites de acceso y escalamiento claro.

En mantenimiento industrial, un umbral físico o una condición de seguridad puede implementarse como regla de alarma; estimar qué equipo requiere atención puede ser una tarea predictiva si existe historial útil; resumir observaciones de técnicos puede ser una tarea generativa asistida. Separar estas funciones evita que una salida lingüística sustituya controles críticos sin justificación.

Volumen y presupuesto: no confundas escala con idoneidad

Un volumen alto hace más importante medir el coste por resultado correcto, pero no convierte automáticamente un LLM en la mejor opción. Si cada registro tiene campos estructurados y una operación inequívoca, procesa primero esa información con consultas o reglas. Si se necesita generalizar a partir de patrones y hay etiquetas suficientes, contrasta una línea base predictiva. Reserva el procesamiento generativo para el componente que realmente requiera interpretar o producir contenido.

En bajo volumen, una automatización compleja puede costar más que el tiempo que ahorra; una asistencia sencilla o un proceso manual documentado podría ser razonable. En alto volumen, estima tanto los costes marginales como la gestión de excepciones. La decisión final necesita pruebas en condiciones representativas, incluidos picos, entradas raras, cambios de distribución y el tiempo de revisión humana.

Errores comunes y cómo evitarlos

Usar un LLM para sumar, filtrar o consultar campos bien estructurados suele introducir complejidad sin necesidad demostrada. Del mismo modo, elegir reglas para una tarea con señales cambiantes puede producir una maraña de excepciones. No presupongas que la salida fluida de un modelo es correcta, ni que un modelo predictivo es justo o estable porque tenga una puntuación general alta.

Otro error es confundir un diagrama de árbol para organizar alternativas con un árbol de decisión entrenado con datos. También es arriesgado llamar “autónomo” a un sistema porque ejecuta una llamada de API: la autonomía depende de si puede producir consecuencias sin revisión, del alcance de sus permisos y de la posibilidad de revertir la acción. Define esos límites antes del despliegue.

Criterios prácticos para cerrar el triaje

Antes de aprobar una inversión, deja por escrito la tarea, la entrada disponible, la salida requerida, los errores tolerables, los controles y el coste total estimado. Compara al menos una alternativa sencilla y una ruta con mayor capacidad solo cuando la naturaleza del problema la justifique. Define quién revisa resultados, quién mantiene el sistema y qué indicador desencadena una pausa o una reevaluación.

La documentación disponible respalda únicamente aspectos generales sobre árboles de decisión y su uso en clasificación o regresión. No aporta pruebas comparativas de eficiencia entre modelos predictivos tradicionales y LLM para datos estructurados, una interpretación aplicable del AI Act ni precios para calcular un millón de transacciones. Esas preguntas deben permanecer abiertas hasta disponer de evidencia primaria y específica para el caso.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.