El sistema anti-alucinación de cuatro capas: cómo LucidFlow mantiene fiables sus recomendaciones de IA

Pídale a un LLM genérico que transforme un proceso de negocio y obtendrá una respuesta confiada y bien escrita que es alrededor de un 60 % invención. Nombrará herramientas de automatización que no existen o cuyo precio se inventó. Citará porcentajes de ROI sin base aritmética. Recomendará patrones que no aplican a su sector porque el modelo los ha visto funcionar en contextos no relacionados. La salida se lee preciosa y solo es accionable si ya sabe lo suficiente para verificar cada frase, en cuyo caso no necesitaba la IA.

LucidFlow se construyó específicamente para evitar este modo de fallo. La capa de transformación IA está restringida, validada y es transparente en cuatro capas: cada una atrapa un tipo distinto de alucinación. Ninguna capa por sí sola es suficiente; las cuatro juntas producen un sistema donde cada recomendación es defendible por construcción. No tiene que verificar la salida; el sistema se ha verificado a sí mismo antes de mostrársela.

La primera capa es una base de conocimiento curada de 100 patrones de automatización IA verificados. Cada patrón tiene un ID estable, una descripción, condiciones de disparo bajo las que aplica, entradas y salidas esperadas, prerrequisitos, una a tres herramientas recomendadas con URLs reales y rangos de precio mensual reales, y tres variantes de nivel de madurez (Companion / Automation / Agent) con perfiles distintos de coste-precisión-riesgo. La KB la editan humanos y se mantiene como dato, no la genera la IA.

La decisión de diseño es radical para 2026: la IA no puede inventar patrones. Cuando el motor de transformación evalúa una tarea, su universo de recomendaciones posibles es exactamente los 100 patrones de la KB, no más. Si su tarea no coincide con ninguno, el sistema devuelve «sin patrón coincidente» en lugar de inventar uno. Esa es la línea de código más importante de toda la pila de transformación IA: la negativa a fabricar.

• Los patrones de la KB están versionados: cada entrada tiene historial de revisiones. Cuando cambian las herramientas o el precio de un patrón, la KB se actualiza; el motor IA refleja el cambio inmediatamente en cada nueva recomendación.
• Las referencias a herramientas son canónicas: cada herramienta de la KB tiene URL real. Si una herramienta cierra o la URL devuelve 404, el patrón se marca para revisión.
• Los precios se acotan como rangos: cada herramienta lleva un precio mensual mínimo y máximo en USD, porque el precio real varía por plan y número de puestos. Los precios de un solo punto están prohibidos.

La segunda capa es el clasificador de tareas: el componente que empareja una tarea concreta de su BPMN con un patrón de la KB. El clasificador está restringido: lee la descripción de la tarea y el contexto del proceso, después puntúa cada patrón de la KB por aplicabilidad, y devuelve la mejor coincidencia si la puntuación supera un umbral. Si ningún patrón supera el umbral, el clasificador devuelve «sin patrón aplicable» y la tarea no obtiene recomendación de Intelligize: empujando la evaluación ESSII de vuelta hacia eliminar, simplificar, estandarizar o integrar.

El clasificador nunca genera una recomendación. Solo clasifica y selecciona. Esta es la diferencia mecánica entre «IA que recomienda» y «IA que fabrica»: el clasificador no puede inventar un patrón porque el espacio de patrones está cerrado. Cada recomendación que el usuario ve es un puntero a una entrada de la KB que un humano puso ahí deliberadamente. El trabajo de la IA es emparejar, no escribir.

La tercera capa corre tras ensamblar el plan y antes de mostrarlo al usuario. Cada plan de transformación pasa por seis reglas de validación independientes, cada una atrapando un tipo distinto de incoherencia.

1. validateToolsExist: cada herramienta referenciada en cada paso debe ser una herramienta registrada en la KB para ese patrón en ese nivel de madurez. Las herramientas desconocidas disparan warnings; los patrones indefinidos disparan errores.
2. validateCostCoherence, para cada paso que use múltiples niveles de madurez, el coste debe aumentar de forma monótona: Agent ≥ Automation ≥ Companion. Un paso donde Agent es más barato que Companion señala un error de edición en la KB.
3. validateDependencyOrder: los pasos que declaren prerrequisitos deben ir después de esos prerrequisitos en el orden del plan. Un paso que requiere «datos en CSV limpio» no puede ir antes que el paso que produce el CSV.
4. validateRoiRealism: la proyección de ROI de cada paso debe estar en un rango plausible dado su coste, duración y frecuencia. Un paso que afirma 90 % de ROI sobre una herramienta de 10 USD/mes aplicada a una tarea que corre 5 veces al año falla el realismo.
5. validatePrerequisites: cualquier prerrequisito declarado en el plan debe ser efectivamente cumplido por los pasos previos o por el estado actual del proceso. Los prerrequisitos ausentes son errores, no warnings.
6. validateCoverage: cada tarea automatizable del BPMN fuente debe aparecer en el plan, o estar marcada explícitamente como «no automatizable». Las omisiones silenciosas son errores porque representan planes parciales que se leen como completos.

Cualquier plan que falle al menos una regla a nivel de error no se muestra al usuario: se regenera. Los warnings se exponen al usuario pero no bloquean la visualización. La distinción importa: los errores son alucinaciones o roturas lógicas; los warnings son defaults revisables por humanos, normalmente correctos pero merecen una mirada.

La cuarta capa es la más engañosamente simple: cada recomendación se entrega con su razonamiento y un score de confianza. «Automatizar esta tarea con Claude API a 20 USD/mes» va acompañado de «porque esta tarea coincide con el patrón KB-034 (Extracción de Cláusulas Contractuales), confianza 0,87, razonamiento: la descripción de la tarea menciona 'extraer términos clave de contratos con proveedores' que coincide directamente con la condición de disparo del patrón; Claude API se seleccionó porque su precio de 20 USD/mes está dentro del rango recomendado del patrón para el nivel Companion y soporta el formato de entrada requerido».

La transparencia es un control anti-alucinación porque es difícil alucinar razonamiento para un patrón concreto sin que se note. Si el razonamiento dice «esta tarea coincide con el patrón KB-034» y no hay KB-034, el usuario lo ve y lo reporta. Si dice que la herramienta soporta un formato que la herramienta no soporta, un experto del dominio lo atrapa. En la práctica, la transparencia crea un artefacto revisable que convierte cada recomendación en una afirmación que el usuario puede inspeccionar, en lugar de un pronunciamiento que tenga que creer.

• Capa 1 previene: patrones inventados. Si el patrón no está en la KB, no se puede recomendar.
• Capa 2 previene: patrones mal aplicados. El umbral de score del clasificador mantiene fuera de la recomendación las coincidencias de baja relevancia.
• Capa 3 previene: incoherencia interna. Costes que desafían el orden de niveles de madurez, dependencias en mal orden, números de ROI aritméticamente imposibles: todo atrapado aquí.
• Capa 4 previene: confianza no examinada. Al exponer el razonamiento, el sistema fuerza al usuario a verificar; una alucinación que sobreviviera a las primeras tres capas es mucho más probable que se atrape en revisión humana.

Las cuatro capas se componen. Una alucinación que se cuela por la capa 1 se atrapa en la capa 2; una que sobrevive a las capas 1 y 2 se atrapa en la capa 3; una que sobrevive a las tres queda expuesta a revisión humana en la capa 4. La tasa de fallo compuesta es mucho más baja que la que cualquier capa por separado sugeriría, lo que explica por qué el sistema se puede confiar para producir recomendaciones que un CFO o experto del dominio no le abochorne citando de vuelta.