Cuando tu proveedor de IA te dice "eso ha sido una alucinación", suena a diagnóstico técnico. Casi nunca lo es. En los agentes de IA que hemos revisado en AutoBoost, lo que se mete bajo esa palabra son en realidad tres o cuatro fallos distintos, con causas y arreglos que no se parecen entre sí. La palabra funciona, sobre todo, para no tener que explicar cuál de los cuatro es el tuyo.
Esto no es un matiz académico. La respuesta que aceptes cambia por completo lo que haces después. Si el fallo es de verdad del modelo, probar otro modelo puede ayudar. Si el fallo es cualquiera de los otros tres, cambiar de modelo no arregla nada: vuelve a fallar igual con el modelo nuevo, porque el modelo nunca fue la causa. Y ese es justo el diagnóstico que un proveedor cómodo prefiere no dar, porque el arreglo de verdad casi siempre implica trabajo de integración, no una factura de suscripción nueva.
Las cuatro cosas que se esconden detrás de "alucinación"
1. Le falta una herramienta, no un dato
El caso más común que vemos: un agente de IA le dice a un cliente que hay 40 unidades en stock cuando quedan 3, o aplica una tarifa que ya caducó. No es que "se lo haya inventado" en el sentido en que se suele entender. Es que nadie le dio una forma de consultar ese dato en el momento exacto de responder, así que contestó con lo último que tenía en su contexto, que puede llevar días de desfase. La solución no es meterle más información en el prompt: es darle una función que consulte el ERP en tiempo real. Lo contamos con más detalle en el post sobre herramientas frente a contexto.
2. No tenía la fuente delante, y rellenó de memoria
Distinto del anterior: aquí el agente sí tenía acceso a documentación, pero no estaba obligado a citarla ni a limitarse a ella. Le preguntas por una cláusula de un manual y te devuelve algo plausible que no está en ningún sitio. Es el problema clásico que resuelve un buen diseño de RAG: el agente busca primero en los documentos reales, y solo responde con lo que encuentra ahí, marcando explícitamente cuando no hay nada que citar. Es exactamente el enfoque que aplicamos al montar un asistente de IA sobre manuales que no inventa respuestas: la fuente manda, y si la fuente no dice nada, la respuesta correcta es "no lo sé", no una respuesta bonita.
3. El dato de origen ya estaba mal, y la IA solo lo repitió con seguridad
Este es el que menos se detecta, porque no parece un fallo de la IA: parece un fallo de la IA cuando en realidad es un fallo de los datos que le diste. En una plataforma de datos para un grupo de farmacias, la IA tenía que razonar sobre más de un millón de líneas para reconstruir una cifra de ventas que el propio ERP del cliente calculaba casi a la mitad. El problema no estaba en la IA: estaba en cómo el sistema origen agregaba esas líneas. La IA no "alucinó" la cifra correcta, la reconstruyó bien porque se verificó línea por línea contra el dato real, con una desviación final de 0,0004%. Sin esa verificación, cualquier cifra que hubiera dado (la mala del ERP o cualquier otra) habría sonado igual de convincente. Lo explicamos en detalle en el caso de la plataforma de datos con IA controller y en por qué el dato va antes que la IA.
4. La alucinación de verdad: inventa aunque tenga todo delante
Este es el único de los cuatro que merece el nombre en sentido estricto: el agente tenía la herramienta correcta, tenía el documento correcto delante, y el dato de origen era correcto, y aun así inventó algo que no estaba en ninguna parte. Pasa, sobre todo con preguntas ambiguas o fuera del alcance para el que se diseñó el agente. Aquí sí ayuda ajustar el prompt, añadir un guardarraíl explícito ("si no está en los documentos, di que no lo sabes") o, en última instancia, probar otro modelo. Pero es, con diferencia, el menos frecuente de los cuatro.
Los cuatro fallos, uno al lado del otro
| Lo que parece | Causa real | Quién lo arregla | ¿Cambiar de modelo ayuda? |
|---|---|---|---|
| Inventa el stock o el precio | Falta una herramienta que consulte el dato en vivo | Quien integra la IA | No |
| Inventa una cláusula que no está en el manual | No tenía el documento real delante, sin restricción de fuente | Quien integra la IA | No |
| Da una cifra con total seguridad, y está mal | El dato de origen ya estaba mal antes de que la IA lo tocara | El sistema de datos, antes que la IA | No |
| Inventa aunque la herramienta, el documento y el dato eran correctos | Fallo real del modelo o del prompt | El proveedor de IA | Puede ayudar |
Las tres preguntas antes de aceptar "ha sido una alucinación"
En este orden, porque cada "no" ya te da la respuesta y te ahorra seguir preguntando:
- ¿Tenía una herramienta para consultar el dato real en el momento de responder, o contestó con lo que llevaba en el contexto?
- ¿Tenía delante el documento o el registro que debía citar, o estaba generando algo plausible sin restricción de fuente?
- ¿El dato de origen que usó era correcto, o el propio sistema (el ERP, el Excel, el CRM) ya estaba mal antes de que la IA lo tocara?
Si la respuesta a cualquiera de las tres es "no", no estás ante una alucinación en sentido estricto: estás ante un fallo de diseño, y se arregla sin tocar el modelo. Si las tres respuestas son "sí" y aun así inventó, entonces sí estás en el cuarto caso, el único que de verdad justifica la palabra.
Checklist antes de aceptar el diagnóstico
- ¿El agente tenía una herramienta para consultar el dato en vivo (stock, precio, estado de cliente), o solo contexto fijo pegado en el prompt?
- ¿Tenía delante el documento o el registro real que debía usar, o iba de memoria general?
- ¿Se ha comprobado que el dato de origen era correcto antes de culpar a la IA?
- ¿El proceso verifica el resultado antes de actuar (cuadrar una cifra, comprobar un total) o confía a ciegas en lo que responde el modelo?
- Si todo lo anterior está en orden y aun así inventa, ¿se ha probado con otro modelo o con un prompt distinto?
Por qué esto no es solo semántica
Aceptar "ha sido una alucinación" sin más te lleva a la solución equivocada tres de cada cuatro veces: cambias de proveedor, de modelo o pagas un plan superior, y el mismo fallo reaparece en cuanto vuelve a faltar el stock actualizado o vuelve a preguntarse algo fuera de los documentos que la IA tiene delante. El arreglo de verdad casi siempre está en cómo está integrada la IA en tu sistema real (qué herramientas tiene, qué fuentes puede citar, si verifica antes de actuar), no en qué modelo hay detrás. Es el mismo criterio que aplicamos en cada proyecto: primero se ordena el dato y se define bien qué puede consultar y citar la IA, y solo entonces se juzga si el modelo es el problema. Puedes ver cómo lo montamos en nuestros servicios de IA aplicada.
Si a tu equipo le están diciendo "alucinación" cada vez que algo sale mal y quieres saber cuál de los cuatro casos es el tuyo, escríbenos. En media hora solemos saber si el problema está en el modelo o, como casi siempre, en cómo está montado alrededor.
