Alucinaciones de IA: de dónde salen y cómo limitarlas

Una alucinación de IA —llamada confabulación en los documentos de NIST— es un contenido que suena convincente, pero es falso o carece de base en las fuentes. Es un riesgo de toda la clase de modelos generativos, no únicamente de un proveedor; NIST lo relaciona con el mecanismo de generar respuestas a partir de la distribución de datos de entrenamiento.

No existe una técnica que garantice la ausencia de estos errores. La pregunta mejor es: cómo reducir su frecuencia, detectar la falta de base y disminuir el efecto de un error.

De dónde proceden las alucinaciones

Cuatro mecanismos, cada uno con una defensa distinta:

1. El modelo no tiene la información necesaria. Preguntas por un procedimiento de tu empresa que el modelo nunca ha visto. Rellena el vacío con lo que encaja estadísticamente.
2. El modelo recibe información incompleta o contradictoria. Dos versiones de un documento, una de ellas obsoleta. El modelo elegirá una y no dirá que había dos.
3. La pregunta presupone algo falso. «¿Qué apartado de nuestro contrato regula las penalizaciones por retraso?», cuando ese apartado no existe. El modelo estará dispuesto a señalarlo porque la pregunta sugiere que existe.
4. La tarea exige una precisión que el modelo no posee de forma natural. Cálculos, importes exactos o citas de memoria.

Añadir contexto relevante ayuda sobre todo cuando falta información, pero no resuelve por sí solo las fuentes contradictorias, una pregunta sugestiva ni las tareas que exigen precisión determinista. Estos casos también requieren control de fuentes, diseño de instrucciones y protecciones fuera del modelo.

Seis técnicas que realmente funcionan

1. Fundamentar en datos propios

La base es que el modelo recibe fragmentos relevantes de las fuentes antes de responder. Eso es RAG. Puede limitar errores debidos a falta de conocimiento, pero no garantiza la corrección: el buscador puede recuperar un fragmento erróneo y el modelo puede interpretarlo mal.

2. Exigir una cita de la fuente

Una respuesta que no indica el fragmento en que se basa puede rechazarse o enviarse a una persona. La cita todavía no prueba que la conclusión sea correcta, pero permite comprobarla con rapidez y revela cuando el sistema no tiene base.

3. Dar permiso explícito para decir «no lo sé»

El modelo está optimizado para generar una respuesta, por lo que hay que darle de forma explícita una alternativa segura: si en los fragmentos proporcionados no hay base, el resultado correcto es indicar que faltan datos y señalar dónde buscar. Es un cambio económico en la instrucción y la lógica del flujo, pero su eficacia debe comprobarse con preguntas sin respuesta.

4. Separar: el modelo comprende, el código calcula

Conviene realizar en código la aritmética, las comparaciones y las reglas estrictas, y dejar al modelo la interpretación de la pregunta y la presentación del resultado. Esto limita los errores de cálculo, pero todavía hay que validar la consulta generada por el modelo, los tipos de datos y la forma de presentar el resultado.

5. Verificar con una segunda pasada

Un paso separado comprueba si la respuesta se deriva realmente de los fragmentos entregados. Puede ser una regla, una comparación con datos estructurados o una segunda llamada al modelo con una tarea limitada. Un segundo modelo no es una prueba independiente y puede repetir el mismo error; por eso, cuando hay mucho en juego, hace falta una persona o un control determinista. En tareas de varias etapas puede separarse un rol de verificador, pero también hay que medir su valor.

6. Una persona al final cuando hay mucho en juego

El modo «el sistema prepara y una persona aprueba» no es un fracaso de la automatización. Es una decisión de diseño sobre dónde poner el límite. En respuestas a clientes sobre asuntos contractuales, el nivel de control debe derivarse del riesgo, la política de la empresa y la evaluación legal; el modelo no debería ser el decisor final.

Una técnica que solo parece una solución

La instrucción del prompt: «no inventes; responde solo basándote en hechos».

Ayuda un poco y conviene incluirla, pero tratarla como una salvaguarda es un error. El prompt es una orientación, no una limitación técnica: el modelo puede no seguirlo, especialmente cuando la pregunta es sugestiva o el contexto está incompleto. La protección consiste en que el sistema no acepta una respuesta sin fuente, no en pedir al modelo que sea riguroso.

Cómo medir si ha mejorado

Sin medición, todas estas técnicas son una historia. Una versión mínima de medición incluye:

1. Un conjunto representativo de preguntas reales de tu proceso, con la respuesta esperada, incluidas preguntas cuya respuesta correcta sea «no lo sé». El piloto puede empezar con 30–50 casos si cubren categorías y riesgos importantes, y después ampliar el conjunto con los errores detectados.
2. Tras cada cambio se cuentan tres cosas: respuestas correctas, respuestas erróneas y cuántas veces el sistema reconoció que faltaban datos.
3. El indicador que se observa con especial cuidado: cuántas veces el sistema respondió con seguridad y de forma errónea. Es un error especialmente arriesgado porque puede pasar inadvertido. Un falso «no lo sé» también tiene coste —aumenta escalados y casos sin resolver—, por lo que ambos tipos de error deben informarse por separado.

Cuándo el riesgo de alucinación descarta una idea

• Cuando el error es irreversible. Una transferencia, una decisión de personal o una declaración ante una administración. Aquí queremos código y una persona.
• Cuando nadie sabe evaluar si la respuesta es correcta. Si no hay quien verifique el resultado, no notarás el momento en que el sistema empieza a equivocarse.
• Cuando los datos fuente son contradictorios y nadie quiere ordenarlos. El sistema presentará entonces información obsoleta de manera convincente, algo peor que no tener sistema.

Preguntas frecuentes

¿Un modelo más potente alucina menos?

Puede que sí, pero el resultado depende de la tarea, el idioma, los datos y el modo de evaluación. No conviene presuponer una mejora solo por el nombre del modelo: hay que comparar modelos con el mismo conjunto de preguntas y mantener la fundamentación y el control con independencia del resultado.

¿Se puede llegar a cero alucinaciones?

No debe prometerse en un sistema generativo abierto. Un objetivo de proyecto realista es un riesgo medido, detección de respuestas sin base y limitación de permisos para que un único error no cause una acción irreversible.

¿Quién debe vigilar la calidad después de la implantación?

La persona propietaria del proceso por tu parte, más la ejecución periódica del conjunto de evaluación. La calidad de un sistema de IA puede empeorar sin un fallo evidente, por ejemplo después de un cambio de modelo, de datos o del comportamiento de las personas usuarias.

---

En un sistema basado en conocimiento diseñamos una regla que detiene o escala una respuesta sin base suficiente y medimos la calidad con un conjunto de preguntas, no con una impresión. Consulta second brain para empresas o escribe qué preguntas debe atender tu sistema.