Alucinación de IA y la disciplina aburrida que evita el problema

Has leído las historias. Abogados que presentan escritos con jurisprudencia inventada. Chatbots que inventan políticas de reembolso que su empresa nunca tuvo. Los gurús de LinkedIn llamando a la tecnología «fundamentalmente poco fiable» y los consejeros delegados asintiendo porque la palabra «alucinación» suena a defecto que debería tener arreglo. En Converly apenas metemos una alucinación en el trabajo con clientes, y la razón es más aburrida de lo que esperarías. No hay plataforma, ni prompt listo, ni capa de detección. Hay una disciplina. Aquí va qué es una alucinación, la comprobación de dos pasos que hacemos sobre cada afirmación que importa, y qué cambiaría en tu empresa si tu equipo aplicara la misma comprobación a la suya.

Qué es una alucinación, mecánicamente

Un modelo de lenguaje grande no tiene un almacén de hechos. Tiene una distribución de probabilidad sobre qué palabra debería ir a continuación dadas las palabras anteriores. Cuando el modelo escribe «Saturno tiene 146 lunas», no está recuperando un número de una tabla. Está prediciendo la secuencia de tokens más probable dada la pregunta. Cuando el modelo acierta, esa predicción coincide con la realidad porque la realidad estaba en los datos de entrenamiento y el patrón está bien ensayado. Cuando el modelo se equivoca, la predicción sigue siendo fluida y segura, porque la fluidez y la verdad las produce maquinaria distinta.

Ese es todo el mecanismo. El modelo no miente. El modelo no tiene señal interna de la diferencia entre «sé esto» y «estoy completando la frase de forma que suena bien». Cada salida que produce le resulta igual de segura, porque la confianza está en la fluidez, no en la verdad.

Saber esto cambia el tipo de arreglo que buscas. Dejas de buscar una función que haga que el modelo «deje de alucinar». Empiezas a buscar un proceso que cace las salidas incorrectas antes de que se publiquen.

Las cuatro formas que adopta

Los consejeros delegados con los que trabajo llevan mejor la conversión cuando ponemos nombre a lo que estamos viendo. La mayoría de avisos de «alucinación» encajan en una de cuatro formas:

Factual. El modelo afirma un número, fecha, nombre o aseveración equivocados. «Sonnet 4.5 soporta una ventana de contexto de 1M de tokens» cuando 4.5 es 200K. Es el caso de manual y el que mejor maneja el proceso de cazarlo pronto.

Atribución. El modelo cita una fuente que no existe, o atribuye una cita real a la persona equivocada. «Según el informe de Gartner de 2024 sobre pipelines de recuperación…» cuando no se publicó tal informe. El modelo ha producido la cita que más verosímil suena, no la real.

Capacidad. El modelo acepta que puede hacer algo que no puede. «Sí, puedo leer los datos de tu CRM directamente». No puede. Este muerde a los equipos que se creen al pie de la letra lo que el modelo dice de su propio comportamiento.

Asentimiento. El modelo acepta una premisa defectuosa en la pregunta del usuario y produce una respuesta fluida dentro de ese marco erróneo. «Dada la conocida correlación entre X e Y, ¿puedes hacerme un resumen sobre…?»: el modelo sigue adelante sin cuestionar si X e Y correlacionan en absoluto.

Cada forma necesita un músculo distinto. Las dos primeras las caza la comprobación que vamos a describir. La tercera necesita escepticismo hacia las afirmaciones del modelo sobre sí mismo. La cuarta necesita no ir con tu conclusión por delante al preguntar.

La lectura honesta: casi no la sufrimos. Aquí va el método poco impresionante.

A veces uso la palabra «eval» cuando hablo con otros que trabajan en esto. La palabra hace mucho trabajo social. En el mundo de la ingeniería de IA significa suites de pruebas automatizadas que puntúan las salidas del modelo frente a un comportamiento de referencia: RAGAS, Braintrust, lm-eval-harness, una pila entera de frameworks. En Converly los usamos cuando el trabajo lo justifica, lo cual es más o menos nunca en el lado editorial y a veces en el lado de poner agentes en producción.

Cuando digo «eval» en el contexto de Converly me refiero sobre todo a: leer lo que ha salido y comprobar las partes que importan. Ese es todo el método. La razón por la que funciona es que va emparejado con un segundo paso que lleva treinta segundos. Juntos cazan el noventa y tantos por ciento de lo que el modelo hace mal.

Los dos pasos

Paso uno: leerlo como lo haría un analista cuidadoso. Antes de que cualquier contenido producido por IA salga del borrador, alguien lo lee en la página. Las preguntas que te haces al leer no son exóticas:

• ¿Esta afirmación cita algo? Si es que sí, ¿la cita es algo real que existe?
• ¿El número está al día? Los modelos entrenados hace seis meses citan cifras de hace dieciocho.
• ¿La confianza del modelo coincide con lo que yo ya sé que es cierto? Un párrafo fluido sobre algo de lo que no sé nada es la forma más peligrosa que puede adoptar una salida.
• ¿Es esto lo que yo habría escrito si tuviera que defenderlo? Si el modelo escribió algo que yo no diría, o me ha enseñado algo o se lo ha inventado. Ambos merecen una comprobación.

Este paso es poco romántico. Es también el paso que la industria sigue intentando saltarse con promesas de capas de detección automatizadas. El problema es que las capas automatizadas no pueden decirte si la salida es verdad; solo pueden decirte si encaja por patrón con cosas marcadas como falsas. No es el mismo problema.

Paso dos: para cualquier afirmación que tenga peso, pásala por dos sistemas fundamentados y comprueba si coinciden. Los dos que más usamos en Converly son Brave Search (para «¿existe siquiera esto?») y Gemini grounded search (para «¿y es esto como el modelo acaba de describirlo?»). Cualquiera de los dos por separado es útil. Los dos juntos producen una señal de consenso que es lo más parecido a una comprobación fiable de verdad que tiene el campo.

Si ambos sistemas fundamentados devuelven la misma respuesta con fuentes, tienes una afirmación verificada. Publícala.

Si no están de acuerdo, tienes una pregunta. Escarba hasta saber cuál tiene razón.

Si ambos devuelven la misma respuesta equivocada, tienes un error compartido en la web pública: raro, pero real. Este es el límite del método, al que volveremos.

Eso es lo que quiero decir con «búsqueda por consenso». El vocabulario de ingeniería lo hace sonar impresionante. También es exactamente lo que hace un periodista competente antes de presentar la pieza.

El ejemplo práctico: el hermano mayor de este artículo cazó tres errores

El artículo que publicamos antes de hoy sobre qué es RAG y qué podría hacer en tu empresa pasó por una verificación de las afirmaciones con nombre antes de salir. La comprobación de nivel Converly cazó tres cosas que el modelo seguro de sí había escrito en el borrador:

El primer borrador decía que Claude Sonnet 4.5 soporta una ventana de contexto de 1M de tokens. Gemini grounded, ceñido a mi pregunta e instruido para fundamentar cada respuesta, me llevó a las notas de versión de Anthropic. Sonnet 4.5 soporta 200K, ampliado a 400K en la API. El modelo con contexto de 1M es Sonnet 4.6. El artículo se publicó corregido.

El mismo borrador decía que la familia GPT-5 de OpenAI soporta 1M de tokens. Brave Search devolvió un máximo de 400K en los tamaños de GPT-5 publicados. Gemini grounded coincidió. Dos fuentes seguras, un veredicto. El artículo se publicó con el número correcto.

El mismo borrador describía Contextual Retrieval de Anthropic como «anteponer un resumen a nivel de documento a cada fragmento antes de embeber». Gemini grounded volvió con el post de ingeniería de Anthropic y el detalle de implementación: la técnica antepone contexto específico de cada fragmento que sitúa cada fragmento en el documento más amplio, no un resumen a nivel de documento. Mecanismo distinto, razón distinta por la que funciona. El artículo se publicó correctamente descrito.

Esos son tres errores reales cazados en un artículo corto. Cada uno se habría publicado como prosa fluida, segura y plausible. Cada uno habría dañado la marca. La disciplina es poco romántica y hace su trabajo.

Qué podría ser esto en tu empresa

Sabrás si tu equipo necesita este método según si alguna vez le ha mordido. Si un compañero ha publicado trabajo producido por IA que resultaba contener una mentira fluida, tu empresa tiene un problema de alucinación. El arreglo no es una herramienta que compras. Es un hábito que instalas.

Las dos preguntas que incrustar en cualquier flujo que use un LLM para producir algo que importa (un correo a un cliente, una declaración regulatoria, una diapositiva para el consejo, un commit de código):

• ¿Alguien leyó esta salida antes de publicarla?
• De las afirmaciones que contiene y que tienen peso, ¿alguien las comprobó contra una segunda fuente?

La mayoría de equipos responden «no» a la segunda pregunta y asumen que la primera basta. No basta. Una lectura cuidadosa caza lo obvio y se pierde todo lo que el lector no sepa por casualidad. La segunda comprobación es lo que caza lo que el lector no sabe que no sabe.

No necesitas un proveedor para nada de esto. Necesitas una pequeña cantidad de tiempo integrada en el flujo y un par de herramientas de búsqueda fundamentada disponibles en el momento de escribir. La mayoría de equipos ya las tiene: la brecha es procedural, no tecnológica.

Por dónde falla el método

La comprobación es poco romántica pero no perfecta. Dos modos de fallo que merece que un consejero delegado conozca:

Errores compartidos. Cuando la web pública se equivoca, las fuentes fundamentadas se equivocan a la vez. El método te da consenso, no verdad. Donde las apuestas son muy altas (médico, legal, regulatorio), el consenso debería ser el listón bajo, con el listón alto en una persona con autoridad en la materia que lea el trabajo. Los sistemas fundamentados te llevan el 95 % del camino. El último 5 % necesita una persona.

Actualidad. Brave y Gemini indexan rápido, pero una afirmación sobre un producto lanzado la semana pasada puede caer en el hueco. Cuando la afirmación es sensible a la actualidad, ve a la fuente primaria: la página de anuncios de la empresa, el registro del regulador, el release de GitHub.

Anclaje. Si formulas tu consulta de modo que condicione la respuesta, ambos sistemas fundamentados te llevarán de vuelta por el mismo camino. «¿Por qué X causa Y?» te da una respuesta segura incluso cuando X no causa Y. Formula la pregunta de forma neutral y el consenso tiene sentido. Formula con tu conclusión metida dentro y el consenso es teatro.

La única regla

Si te llevas una sola cosa de este artículo, llévate esta. El modelo no miente cuando alucina. El modelo no tiene concepto de mentira. El arreglo no es una función del modelo. El arreglo es un hábito del equipo que publica el trabajo. Lee la salida. Comprueba las afirmaciones que sostienen el peso contra una segunda fuente fundamentada. Repite en cada trabajo que importe.

Esa es toda la disciplina. No impresiona. También funciona.

Si quieres un recorrido estructurado por los flujos de tu empresa que ya usan salida de LLM (qué se comprueba, qué no, dónde falta el hábito de cazarlo antes de publicarlo), para eso está la auditoría de IA de Converly. El Audit produce un informe que el equipo directivo puede aprobar, y el encargo que sigue instala la disciplina junto con las herramientas que elijas poner alrededor.

Para el artículo complementario conceptual sobre la arquitectura que fundamenta las salidas de IA en tus propios documentos, ver qué es RAG y qué podría hacer en tu empresa. Para el enmarque ejecutivo en el que se encaja, ver IA para el director general y el consejero delegado.

Solo educativo, no es asesoramiento financiero ni legal. Probado en el estudio de Converly. Hecho para equipos directivos que prefieren instalar un hábito a comprar una plataforma.