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

Un marco para empezar por la decisión, no por la tecnología

Elegir una solución de inteligencia artificial empieza por definir qué decisión o tarea se quiere mejorar. La pregunta no es qué tecnología está de moda, sino qué resultado necesita el proceso, con qué datos se cuenta, qué consecuencias tendría un error y qué recursos hay para desarrollar y mantener la solución. En muchos casos, una regla explícita o un proceso manual mejorado es más adecuado que un modelo de aprendizaje automático.

Esta guía propone un método operativo para comparar tres familias: reglas deterministas, modelos predictivos y sistemas generativos. No es una clasificación normativa ni una escala validada por estudios comparativos. Es una plantilla de trabajo que cada organización debe adaptar y probar con sus propios datos, restricciones y obligaciones. Los escenarios de finanzas, logística y recursos humanos que aparecen más adelante son ejemplos hipotéticos para mostrar cómo usarla; no se presentan como casos reales ni como prueba de eficacia.

Clasifica la tarea y los datos antes de elegir

Una tarea estructurada tiene entradas, estados y resultados que pueden describirse con campos, categorías o condiciones definidas. Por ejemplo, verificar si una factura supera un importe autorizado o si un paquete incumple una restricción de peso. Si la lógica es estable y conocida, unas reglas pueden ofrecer trazabilidad y control sin necesidad de entrenar un modelo.

Una tarea no estructurada suele requerir interpretar texto libre, imágenes, audio u otras señales cuya variación no cabe cubrir con una lista pequeña de condiciones. Clasificar una reclamación escrita o resumir una conversación son ejemplos. La distinción no es absoluta: una organización puede convertir parte del material no estructurado en campos y combinar reglas con modelos. El tipo de dato, por sí solo, no determina la tecnología: importan también la calidad, el volumen, la variabilidad, la posibilidad de etiquetar ejemplos y el coste de equivocarse.

Árbol de decisión: descarta opciones que no encajan

Un árbol de decisión representa preguntas sucesivas y sus posibles resultados. Cada nodo plantea una condición y cada rama conduce a la siguiente pregunta o a una opción final. Los árboles también son una familia de modelos predictivos; aquí, sin embargo, usamos el término para describir un diagrama de triaje organizativo, no un algoritmo entrenado. La estructura ayuda a hacer explícitas las razones de una elección, pero no garantiza que las respuestas sean correctas ni que se hayan considerado todas las consecuencias.

Empieza preguntando si el proceso puede expresarse con condiciones estables. Si la respuesta es sí, prueba primero reglas deterministas. Si no, pregunta si la meta es asignar una categoría, estimar una probabilidad o un valor, o producir contenido nuevo. Clasificar o predecir con ejemplos históricos puede justificar probar un modelo predictivo. Redactar, resumir o transformar contenido puede justificar un sistema generativo, siempre con límites claros y validación de resultados. También se pueden combinar métodos: un modelo propone y unas reglas restringen lo permitido.

Puntuación orientativa: ordenar alternativas sin fingir precisión

Una matriz puede ayudar a comparar propuestas cuando hay varias opciones plausibles. Puntúa cada alternativa de 1 a 5 en adecuación a la tarea, ajuste a los datos, riesgo y controles, viabilidad económica y capacidad de operación. En esta escala, una puntuación alta debe significar una condición más favorable: por ejemplo, mejor adecuación, datos más preparados, riesgo residual mejor controlado y costes más sostenibles. Para riesgo, puntúa la capacidad demostrada de mitigarlo, no la gravedad del riesgo en sí.

No existe en las fuentes consultadas una ponderación validada que combine tipo de dato, riesgo regulatorio y presupuesto para escoger entre reglas, modelos predictivos e IA generativa. Por eso los pesos que siguen son un punto de partida explícitamente provisional. El presupuesto no debe premiar automáticamente la opción más barata: considera coste total de propiedad, incluidos integración, pruebas, licencias o cómputo, supervisión, auditoría, actualización, seguridad y salida del proveedor. Antes de decidir, repite la comparación con diferentes pesos y comprueba si cambia el resultado.

Riesgo: mide impacto y exposición, no solo una cifra

Una puntuación única de riesgo puede ocultar diferencias importantes entre seguridad, privacidad, discriminación, fiabilidad, cumplimiento y continuidad operativa. Conviene mantener un registro por dimensión: qué daño se considera, a quién puede afectar, con qué frecuencia podría producirse, cuán grave sería, qué controles existen y quién los verifica. Las escalas cualitativas pueden servir para priorizar una conversación, pero no deben presentarse como una métrica regulatoria oficial.

En la Unión Europea, la clasificación jurídica depende del uso previsto y del encaje del sistema en las categorías y condiciones correspondientes; no se deduce simplemente de que un proyecto sea «de alto», «medio» o «bajo» riesgo para el negocio. La Comisión Europea publicó un proyecto de directrices para ayudar a evaluar si ciertos sistemas deben clasificarse como de alto riesgo. Al ser un borrador, no debe describirse como una guía final ni como un sustituto del reglamento aplicable. Fundación Cotec, por su parte, describe un enfoque práctico de gobernanza que incluye identificar casos de uso y roles, analizar riesgos e integrar controles en el ciclo de vida.

Presupuesto y coste total: decidir con horizonte operativo

Asignar un peso al presupuesto no consiste en dar ventaja automática a la opción más barata. Primero define un horizonte de evaluación común —por ejemplo, el periodo presupuestario de la organización— y estima costes iniciales y recurrentes: preparación de datos, integración, pruebas, cómputo, licencias, revisión humana, monitorización, seguridad, formación y mantenimiento. Incluye también costes de salida, sustitución o reversión si el proveedor cambia condiciones o la solución deja de ser adecuada.

Compara ese coste con un beneficio definido de antemano, como menor tiempo de procesamiento, menos errores o mejor cobertura de una tarea. No supongas que la automatización crea ahorros netos: si se requiere verificación manual frecuente, el coste puede trasladarse en vez de desaparecer. Ejecuta primero un piloto acotado, con criterios de éxito y de parada. Si el presupuesto es limitado, prueba una solución más simple antes de reducir controles que protegen a las personas o la operación.

Tres escenarios para aplicar el marco

Los siguientes escenarios son ilustrativos y no documentan implantaciones reales ni resultados medidos. Sirven para mostrar cómo cambia el análisis según la tarea, los datos, el impacto y la posibilidad de supervisión. En cualquier dominio, el nombre del sector no basta para determinar la categoría regulatoria: importan el propósito previsto, el contexto y la configuración concreta.

En cada caso se identifica una opción inicial razonable, una alternativa que podría probarse y los controles a considerar. La elección final depende de datos y pruebas locales. Un piloto debe comparar la propuesta con una línea base y evaluar no solo precisión promedio, sino también errores relevantes, costes, efectos sobre personas y desempeño en condiciones distintas de las usadas para desarrollar la solución.

Validación, supervisión y reglas para detenerse

Antes de desplegar, acuerda qué significa que la solución funciona. La evaluación debe usar datos separados de los empleados para ajustar el sistema y representar razonablemente el uso previsto. Para clasificación, registra errores por tipo y por segmentos pertinentes; para predicción, compara con una línea base y mide el error en condiciones operativas; para generación, revisa exactitud, omisiones, coherencia, privacidad y respuestas no admitidas. La métrica debe corresponder a la consecuencia del error, no solo a la facilidad de medirla.

Define quién revisa las salidas, qué decisiones puede tomar el sistema, cuándo debe abstenerse y cómo se corrigen errores. Registra versión, cambios, incidencias, aprobación y motivos de actualización. Establece condiciones de parada: por ejemplo, degradación más allá de un límite acordado, incidentes de seguridad, resultados desiguales no mitigados o incapacidad para mantener una revisión efectiva. La guía institucional de Cotec recomienda integrar la gobernanza en el ciclo de vida y mantener roles e inventario de sistemas; el proyecto de directrices de la Comisión Europea ayuda a entender la clasificación de alto riesgo, pero no valida este marco de puntuación.

Conclusión: una decisión defendible es mejor que una puntuación atractiva

El árbol de triaje ayuda a separar tareas de reglas, predicción y generación; la matriz hace visibles los compromisos entre datos, adecuación, riesgo, coste y capacidad operativa. Ninguno determina automáticamente la solución correcta. Las puntuaciones son útiles solo si se explican, se prueban frente a supuestos alternativos y se actualizan cuando cambia el contexto.

El método práctico es empezar con una tarea concreta, evaluar primero reglas y líneas base sencillas, y probar modelos solo cuando exista una necesidad clara y datos adecuados. En tareas de impacto significativo, la supervisión debe influir realmente en la decisión, no ser un trámite. Las fuentes disponibles sostienen la utilidad general de los árboles de decisión, la necesidad de gobernanza y la relevancia de clasificar los sistemas según su uso; no demuestran que esta plantilla sea eficaz ni fijan pesos universales. La decisión final debe apoyarse en pruebas locales y revisión legal cuando corresponda.

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.