Por qué los modelos de lenguaje alucinan

Una respuesta de un modelo de lenguaje puede ser clara, específica, bien estructurada y completamente falsa. Ese contraste explica por qué las llamadas alucinaciones son más peligrosas en entornos profesionales que un simple error visible: el problema no es solo que el modelo se equivoque, sino que puede equivocarse con una forma que parece razonable.

Para auditoría, la consecuencia es inmediata. Un texto generado por IA puede ser útil para explorar una hipótesis, resumir documentación o preparar un borrador. Pero su fluidez no aumenta automáticamente su valor como evidencia.

La tesis es sencilla: los modelos de lenguaje no fueron diseñados como bases de datos de hechos, sino como sistemas de generación probabilística de lenguaje. Por eso, el control adecuado no consiste en esperar que nunca alucinen, sino en diseñar el uso de la IA asumiendo que una salida plausible puede ser incorrecta.

Una respuesta convincente no es lo mismo que una respuesta verdadera

El NIST AI Risk Management Framework: Generative Artificial Intelligence Profile utiliza el término confabulation para describir situaciones en las que un sistema de IA generativa presenta contenido erróneo o falso con aparente confianza. El mismo fenómeno suele llamarse hallucination o alucinación.

La distinción importa porque un LLM no consulta, por defecto, una tabla interna de hechos y luego redacta una respuesta. Genera secuencias de texto que son estadísticamente plausibles a partir del contexto disponible y de los patrones aprendidos durante su entrenamiento. Esa capacidad produce respuestas extraordinariamente útiles, pero la optimización por plausibilidad lingüística no equivale a una comprobación de verdad.

Por eso el modelo puede inventar una referencia, atribuir una obligación inexistente a una norma, combinar dos hechos reales de forma incorrecta o completar una laguna con una explicación que “suena” correcta. NIST subraya además que este riesgo es especialmente relevante en respuestas abiertas, dominios especializados y decisiones de consecuencias importantes.

La calidad lingüística es una propiedad de la respuesta. La fiabilidad es una propiedad de la evidencia que la respalda.

Por qué ocurre la alucinación

El mecanismo puede entenderse sin entrar en matemáticas avanzadas. Un LLM recibe un contexto y estima qué fragmentos de lenguaje son más probables a continuación. Repite este proceso hasta formar una respuesta completa. El resultado puede coincidir con la realidad, pero el proceso de generación no contiene por sí mismo una prueba de que cada afirmación sea cierta.

Cuatro condiciones aumentan el problema:

Contexto insuficiente o ambiguo. Si faltan datos, el modelo puede completar huecos con patrones aprendidos en vez de declarar que no sabe.
Conocimiento desactualizado o incompleto. El modelo puede no disponer de la versión vigente de una norma, política o hecho reciente.
Fuentes externas deficientes. Incluso un sistema con búsqueda o RAG puede recuperar documentos incompletos, irrelevantes o desactualizados y producir una síntesis incorrecta.
Exceso de confianza del usuario. Una respuesta bien escrita reduce la fricción cognitiva y puede favorecer el sesgo de automatización: aceptar el resultado porque parece competente.

Un mejor prompt puede reducir ambigüedad, pedir que el modelo explicite supuestos o exigir referencias. Eso mejora el proceso, pero no convierte al modelo en una fuente primaria. De la misma manera, RAG puede aportar documentos autorizados y trazabilidad, pero no elimina el riesgo: la recuperación puede fallar y el modelo todavía puede interpretar mal, omitir o exagerar lo recuperado.

El control debe diseñarse según la consecuencia del error

La pregunta útil no es “¿alucina este modelo?”, porque ningún control serio debería depender de una respuesta binaria. La pregunta es: ¿qué ocurre si esta salida es incorrecta y alguien confía en ella?

El COSO, en su guía de 2026 sobre control interno y GenAI, parte precisamente de esta característica: la IA generativa es probabilística, no determinista, y sus resultados deben tratarse como afirmaciones que requieren validación, no como hechos aceptados por defecto. La guía propone controles como validación antes y después del despliegue, revisión humana basada en riesgo, pruebas de desempeño, trazabilidad de fuentes y monitoreo de errores.

Uso de IA	Riesgo principal	Control proporcional	Evidencia que un auditor esperaría
Lluvia de ideas o borrador interno	Error con baja consecuencia	Revisión del usuario antes de reutilizar contenido	Guía de uso y responsabilidad claramente asignada
Resumen de políticas o normas	Omisión, cita falsa o contenido desactualizado	Fuentes autorizadas, control de vigencia y verificación de citas	Inventario de fuentes, versiones, muestras revisadas y registros de cambios
Análisis incorporado a papeles de trabajo	Conclusión no respaldada	Corroboración independiente y trazabilidad hasta la evidencia original	Referencias cruzadas, revisión supervisora y documentación del procedimiento
Decisión o acción de alta consecuencia	Error escalado o automatizado	Umbrales, aprobación humana, pruebas previas, monitoreo y capacidad de detener o revertir	Resultados de pruebas, logs, aprobaciones, excepciones e incidentes

Este enfoque también es coherente con ISO/IEC 42001:2023, que exige un sistema de gestión para abordar riesgos y oportunidades de IA, evaluar el desempeño y mantener información documentada. La norma no promete que un sistema de IA sea infalible; exige que la organización establezca procesos para gobernarlo, evaluarlo y mejorarlo.

Para auditoría interna, una salida de IA no debe convertirse en evidencia por accidente

Aquí la conexión con las Normas Globales de Auditoría Interna es directa. La Norma 14.2 exige que los auditores internos analicen información relevante, fiable y suficiente para desarrollar posibles hallazgos. Si una afirmación de IA entra en un papel de trabajo sin que pueda demostrarse de dónde proviene y cómo fue validada, el problema ya no es solamente tecnológico: es un problema de calidad de evidencia.

La guía del IIA AI Prompting for Internal Auditors lo lleva a la práctica: los resultados generados por IA que se incorporen a papeles de trabajo, informes o entregables de asesoramiento deben verificarse de forma independiente frente a fuentes autorizadas y tratarse como un punto de partida, no como un producto final.

Eso cambia la disciplina de uso. Un auditor puede pedir a un LLM que identifique contradicciones entre documentos, proponga procedimientos o sintetice entrevistas. Pero la responsabilidad profesional sigue siendo humana: decidir qué es evidencia, evaluar su fiabilidad, buscar corroboración y documentar la base de la conclusión.

El Artificial Intelligence Auditing Framework del IIA refuerza la misma lógica al situar transparencia, trazabilidad, gobernanza y control como elementos centrales del aseguramiento sobre IA.

Cinco preguntas que convierten la alucinación en un problema auditable

Para evaluar un caso de uso basado en LLM, un equipo de auditoría puede comenzar con cinco preguntas:

¿Qué decisiones dependen de la salida? Cuanto mayor sea la consecuencia, menor debe ser la tolerancia a una salida no validada.
¿Qué fuente autorizada permite comprobarla? Si no existe una fuente verificable, debe quedar claro que el contenido es una hipótesis o análisis, no un hecho.
¿Cómo se conserva la trazabilidad? Prompts, fuentes, versiones, configuraciones, revisiones y cambios pueden ser relevantes para reproducir el resultado.
¿Qué sucede cuando el modelo se equivoca? Deben existir mecanismos de detección, corrección, escalamiento y, cuando corresponda, reversión.
¿Quién sigue siendo responsable? La incorporación de IA no debe diluir la responsabilidad del propietario del proceso, del revisor o del auditor.

Estas preguntas desplazan la conversación desde “¿qué tan inteligente es el modelo?” hacia “¿qué tan confiable es el sistema de uso alrededor del modelo?”. Esa es una diferencia fundamental para auditoría.

El objetivo no es eliminar toda alucinación, sino impedir la confianza injustificada

Esperar un LLM que nunca produzca una afirmación falsa es una estrategia de control débil. La mejor arquitectura combina límites claros de uso, fuentes gobernadas, pruebas, trazabilidad, revisión humana proporcional al riesgo y monitoreo continuo.

En usos de bajo impacto, una revisión razonable puede ser suficiente. En auditoría, cumplimiento, información financiera, decisiones regulatorias o acciones automatizadas, la exigencia debe ser mayor. Lo importante es que la organización pueda demostrar por qué confía en una salida concreta y qué controles impiden que un error plausible se convierta en una decisión real.

La alucinación no convierte a los LLM en herramientas inútiles. Obliga a utilizarlos con una idea que los auditores ya conocen bien: una afirmación no se vuelve fiable por estar bien presentada; se vuelve fiable cuando existe evidencia suficiente para sostenerla.