Cómo AIFLOCK elimina las alucinaciones: agentes especializados, procesos deterministas y HITL en puntos críticos
TL;DR
Las alucinaciones no se eliminan con prompting. Se eliminan con arquitectura: agentes especializados leyendo TU documentación, procesos deterministas en lugar de chat libre, y HITL antes de cualquier acción crítica.
Joaquín Peña Siles·18 de mayo de 2026·10 min de lectura
La pregunta que más me hace un compliance officer o un director técnico en la primera reunión es siempre la misma: "¿Y si la IA se equivoca?". Es la pregunta correcta. Y la respuesta honesta no es "no se equivoca". La respuesta honesta es que el error tiene que ser detectable, trazable y bloqueable antes de que toque nada que importe.
Eso no se consigue con prompting. No se consigue cambiando de modelo cada vez que sale uno nuevo. Se consigue con una decisión de arquitectura que muchos equipos siguen sin tomar: tratar la alucinación como un problema de sistema, no como un problema de IA.
Lo que sigue es cómo lo hemos construido en AIFLOCK. Tres capas concretas, con su responsabilidad, su anti-patrón y su límite. Sin promesas absolutas. Con la línea que sí podemos defender ante un colegio profesional, una auditoría o un incidente real.
Las alucinaciones no son un bug. Son arquitectura por diseño
Un modelo de lenguaje grande no "sabe" cosas. Optimiza la siguiente palabra más probable dado un contexto. Cuando le preguntas algo sobre lo que tiene poca evidencia en su corpus de entrenamiento, no calla. Sigue prediciendo. Y predice con la misma seguridad estilística con la que predice algo de lo que sí tiene evidencia.
Esto no es un fallo del modelo. Es lo que el modelo hace. Por eso la narrativa de "el próximo modelo alucinará menos" se rompe cada seis meses. Mejora algo, sí. Resuelve el problema, no. Cada generación de los últimos tres años ha bajado la tasa de error en preguntas factuales conocidas, y a la vez ha mantenido el mismo comportamiento ante preguntas fuera de su distribución: completar con confianza.
El cambio de marco es esto: la alucinación no se elimina dentro del modelo. Se elimina alrededor. Lo que decide si tu sistema alucina en producción no es qué LLM usas, es qué arquitectura le has puesto encima.
Por qué prompting no resuelve esto
Cuando un equipo técnico empieza a tener problemas con alucinaciones, la primera reacción suele ser refinar el prompt. "Sé exacto. No inventes. Cita la fuente. Si no sabes, di que no sabes." Funciona durante un rato. Después deja de funcionar. Y nadie sabe muy bien cuándo dejó de funcionar.
Conversación con Joaquín
Cuéntanos un proceso de tu empresa. Te decimos si encaja con agentes.
30 minutos. Análisis técnico, no presentación de producto. Si no encaja, te lo decimos.
Cómo AIFLOCK elimina las alucinaciones: agentes especializados, procesos deterministas y HITL en puntos críticos | AI Flock
Hay tres fallos sistémicos que hacen que el prompting, por bueno que sea, no escale como solución.
Primero, no escala con el corpus. Un prompt razonable lleva 500 palabras de instrucciones y 50 ejemplos. Funciona contra cinco casos. Cuando tu equipo trae cincuenta casos distintos (cada departamento, cada tipo de informe, cada cliente con su normativa), el prompt o se vuelve ilegible o se trocea en variantes que nadie mantiene de forma consistente.
Segundo, no es auditable. Si en seis meses un cliente pregunta por qué la IA respondió X en un informe firmado, el equipo técnico no puede reconstruir la respuesta. El prompt cambió. El modelo cambió. Eso es lo contrario de lo que pide el AI Act para sistemas que toman decisiones que afectan a personas u operaciones.
Tercero, no es robusto a actualizaciones de modelo. El prompt afinado contra GPT-4 puede romperse con GPT-4 turbo. Lo que ayer funcionaba con Claude 3.5 puede comportarse distinto con Claude 4. Cada actualización fuerza una nueva ronda de prompt engineering sin métrica clara de si la versión nueva alucina menos o solo distinto.
Esto no significa que el prompting esté mal. Significa que es una capa, no la solución. La defensa contra alucinaciones vive más arriba en el stack.
Capa 1: agentes especializados leyendo TU documentación
El primer movimiento es retirar al modelo el privilegio de inventar contexto. Cuando un agente AIFLOCK responde a una pregunta de un cliente, no responde desde lo que el LLM sabe. Responde desde lo que la documentación del cliente dice. Y si la documentación no dice nada, el agente lo dice.
La arquitectura base es RAG con búsqueda híbrida (vectorial + keyword) sobre los documentos del cliente. Manuales técnicos, normativa interna, plantillas firmadas, catálogos, jurisprudencia, lo que el caso requiera. Indexado y troceado a nivel de párrafo. El agente busca primero, lee los párrafos relevantes, y genera la respuesta apoyándose en esos pasajes concretos.
La diferencia operativa con un chat genérico no es de matiz. Cada afirmación del output enlaza al párrafo exacto del PDF, del email o del documento de origen. El humano que revisa la salida puede hacer clic, ver el pasaje, y verificar en diez segundos lo que el agente ha citado. Si la afirmación está, está. Si no está, no entra.
El detalle técnico que hace que esto funcione bien no es el modelo, es el corpus. La calidad de la indexación, el trazado de versiones de un mismo documento (¿qué versión de EHE-08 manejamos hoy?), la política de qué documentos están "vivos" y cuáles "archivados". Si tu corpus está sucio, el agente cita con confianza un documento equivocado. Si tu corpus está limpio y versionado, el agente cita al párrafo correcto del documento vigente.
La línea aquí es deliberada: la cita es verificable, no decorativa. Cuando un agente AIFLOCK escribe "el coeficiente parcial de seguridad del hormigón es 1.5", junto a esa frase hay un enlace al párrafo 41.1.1 del PDF de la EHE-08 cargada en el corpus. Si el ingeniero hace clic y ve que ese párrafo dice otra cosa, el sistema ha fallado de forma visible, no silenciosa. Eso es lo que diferencia una respuesta defendible de una respuesta que solo "suena bien".
Capa 2: procesos deterministas, no chat libre
RAG con cita reduce mucho las alucinaciones de contenido. No las elimina del todo, y sobre todo no resuelve un segundo problema, más sutil: la alucinación de proceso. Un chat libre puede tener el contexto correcto y aun así ejecutar pasos en el orden equivocado, saltarse una validación, llamar a una herramienta que no debía o decidir actuar cuando la política decía "pregunta primero".
Aquí entra la segunda capa: en lugar de un chat libre que decide qué hacer en cada turno, AIFLOCK ejecuta procesos modelados con BPMN. Cada operación crítica del cliente (preparar una propuesta, redactar un informe, validar una factura, clasificar un email entrante) es un flujo formal con sus pasos, sus condiciones, sus puntos de validación y sus ramas de excepción. Los agentes son los ejecutores de los pasos, no los dueños del orden.
Esto no es decoración técnica. Es resultado directo de veinte años de investigación en sistemas multiagente y Business Process Management en la Universidad de Sevilla — la línea en la que llevamos trabajando con Manuel Resinas, Adela del Río-Ortega, Cristina Cabanillas y Antonio Ruiz-Cortés desde mediados de los 2000, con publicaciones en Communications of the ACM, Information Systems y Software & Systems Modeling. La tesis de fondo es robusta: si un proceso es crítico, modelarlo formalmente con BPMN da garantías de orden, completitud y verificabilidad que la conversación libre nunca da.
En la práctica, esto se nota en tres sitios. Uno: el flujo de cada caso de uso queda dibujado, revisable y editable por el equipo del cliente. Dos: cada ejecución produce una traza estructurada (qué paso, qué agente, qué entrada, qué salida, qué fuente, qué decisión humana) consultable meses después. Tres: cuando hace falta cambiar el proceso, se cambia el modelo BPMN, no el prompt. El cambio es discreto, revisable y reversible.
Hay un coste: el flujo deja de "improvisar". Un agente que ejecuta un proceso BPMN no decide saltarse un paso porque le parezca redundante. Si lo necesita, hay que modelarlo como rama explícita. La buena noticia es que ese es exactamente el contrato que un director técnico quiere en un proceso del que se firman cosas. La improvisación es deseable en un brainstorming. No lo es en un flujo de producción.
Capa 3: HITL en puntos críticos
Por mucho RAG con cita y por mucho BPMN bien modelado, sigue habiendo decisiones que no deben quedar en manos del sistema. La tercera capa es Human-in-the-Loop nativo: la persona aprueba antes de que el agente ejecute cualquier acción que toque un dato externo o tenga consecuencias no reversibles.
La regla operativa es sencilla y la repito en cada propuesta comercial: la IA propone, el humano decide, siempre. Un agente puede preparar la propuesta, redactar el informe, redactar el email al cliente, generar la factura. No lo envía. No la firma. No lo pasa al CRM hasta que un humano lo aprueba.
Lo importante es dónde se pone exactamente el punto HITL, porque no puede estar en cada paso (eso anula el ahorro) ni en ninguno (eso anula la garantía). La regla que aplicamos: HITL obligatorio en cualquier acción que (a) toque un sistema externo (envío de email, registro en CRM, escritura en ERP, llamada a API que mueve datos), (b) firme algo en nombre de la empresa, o (c) ejecute una decisión irreversible. HITL opcional en sugerencias, resúmenes, drafts internos que el operador va a revisar de todos modos.
El resultado en producción se parece a esto. Un agente comercial detecta un lead, investiga la empresa, redacta la propuesta usando RAG sobre catálogo y casos previos, deja el borrador en la bandeja del responsable comercial. El humano revisa, edita lo que ve raro, aprueba. Hasta ese clic, no sale nada. Cuando aprueba, el sistema envía el correo, registra la actividad en el CRM, programa el seguimiento. Tres minutos de revisión humana sobre treinta de trabajo del agente. Eso devuelve el control sin matar el ahorro.
El antipatrón opuesto, que vemos a menudo en POCs de IA mal montadas, es el agente "autónomo" que decide y ejecuta sin paso humano. Vende muy bien en demos. Falla muy mal en producción. Cuando algo va mal, no hay forma de pararlo a tiempo y no hay nadie con responsabilidad clara sobre la salida. El AI Act lo recoge sin medias tintas para sistemas que afectan a personas o procesos críticos: la supervisión humana efectiva no es opcional.
Lo que la trazabilidad permite que el chat no permite
Las tres capas (RAG con cita, BPMN, HITL) generan un efecto secundario que muchos equipos descubren después de implantarlo y que termina siendo casi tan valioso como el ahorro de tiempo: trazabilidad operativa real. Cada decisión del sistema queda registrada con sus entradas, sus fuentes, sus pasos intermedios y la firma humana que la aprobó.
Eso desbloquea tres cosas que con un chat libre no se pueden hacer.
Uno: auditoría interna. Si un cliente reclama por una propuesta enviada hace cuatro meses, el responsable comercial puede abrir el flujo, ver qué información se usó para redactarla, qué versión del catálogo estaba activa, qué edits hizo el humano antes de aprobar y a qué hora. Reconstrucción completa del incidente, no "creo recordar que".
Dos: cumplimiento AI Act. El reglamento europeo 2024/1689 obliga a los sistemas de riesgo medio y alto a mantener trazas auditables. La mayoría de POCs que vemos hoy no las tienen porque están construidas sobre chat libre. Con BPMN + HITL + RAG con cita, esa traza existe por diseño. Y para los sistemas clasificados como riesgo mínimo (donde está el grueso del uso empresarial razonable), la traza es lo que documenta esa clasificación frente a una autoridad.
Tres: defensa ante incidente. Cuando ocurre un error en producción (y ocurrirá, en cualquier sistema), la diferencia entre "sabemos qué pasó y lo arreglamos en dos horas" y "estamos revisando seis meses de logs" es exactamente esta capa de trazabilidad. Es la diferencia entre tratar la IA como un servicio operativo serio o como un asistente experimental.
Una de las cosas que no diremos nunca, ni en una propuesta ni en una demo ni en este post, es "AIFLOCK garantiza cero alucinaciones". No lo decimos porque no es cierto, y porque cualquier proveedor B2B que lo diga está vendiendo humo a un comprador que en seis meses se va a enterar.
Lo que sí prometemos, y lo que sí podemos defender con la arquitectura descrita, es lo siguiente.
Si la afirmación está en el corpus, el agente la cita correctamente al párrafo. Si no está, el agente lo dice y no inventa. Si el proceso requiere una decisión que toca un sistema externo, no se ejecuta sin aprobación humana explícita. Si hace falta reconstruir qué hizo el sistema en un caso concreto, la traza está disponible y es legible. Si un modelo se actualiza, el comportamiento del flujo está protegido por su contrato BPMN, no por un prompt frágil.
Eso es lo que llamamos "alucinaciones a nivel auditable". No prometemos perfección. Prometemos que cuando algo se desvíe, se detecte antes de hacer daño, se documente al instante y se pueda corregir donde toca. La diferencia entre eso y un chat brillante es la diferencia entre un sistema que puedes meter en producción y firmar, y una demo que vende bien en una presentación pero nadie se atreve a pasar al cierre.
Llevo veinte años trabajando en la intersección de procesos formales y agentes inteligentes. La conclusión es la misma desde el primer paper hasta hoy: la inteligencia bien aplicada es la que sabe dónde tiene que parar para preguntar. La IA propone. Tú decides. Siempre.
