Por qué la IA se inventa cosas y qué se hace para evitarlo

Un empleado le pregunta al asistente de IA de la empresa cuántos días de plazo tiene un cliente para devolver un pedido. La respuesta llega al instante, con una cifra concreta, redactada con la misma seguridad que cualquier otra respuesta correcta que ese asistente ha dado antes. El empleado se la traslada al cliente. El cliente reclama semanas después, porque la política real de la empresa dice otra cosa. Nadie mintió a propósito. El asistente tampoco falló en el sentido en que falla una máquina rota. Hizo exactamente lo que estaba construido para hacer, y ese es justo el problema que este artículo intenta explicar.

#Qué hace en realidad un modelo de lenguaje

Sin entrar en matemáticas: un modelo de lenguaje no consulta una base de datos de verdades comprobadas cuando responde. Ha leído una cantidad enorme de texto durante su entrenamiento y, a partir de esa lectura, ha aprendido a predecir cuál es la palabra más probable que sigue a las anteriores, una y otra vez, hasta formar una respuesta completa. No «sabe» cosas en el sentido en que una persona sabe algo por haberlo comprobado. Estima, con muchísima habilidad, qué texto encaja bien a continuación de la pregunta que le has hecho.

La mayor parte del tiempo, esa estimación coincide con la realidad, porque la realidad es justo lo que domina la mayoría del texto con el que aprendió. Pero cuando le preguntas algo muy concreto de tu negocio —una política interna, un dato que cambió la semana pasada, un número que nunca estuvo en ningún texto público— el modelo no tiene un mecanismo para darse cuenta de que ahí no hay nada fiable que recordar. Sigue haciendo lo mismo que hace siempre: generar el texto que le parece más probable. Solo que esta vez ese texto probable no está anclado a ningún hecho real. Eso es lo que se llama, en el sector, una alucinación.

#Por qué suena igual de seguro cuando acierta y cuando falla

El modelo no tiene un indicador interno de «esto lo sé bien» frente a «esto me lo estoy inventando», y ahí es donde el asunto deja de ser una curiosidad técnica y se vuelve peligroso de verdad. Genera cada frase con el mismo mecanismo, tanto si la respuesta es exacta como si no lo es, y ese mecanismo produce siempre un texto fluido, bien construido y con un tono de seguridad idéntico en ambos casos. No hay una duda audible en el resultado que avise de que algo no está fundamentado. Suena igual de convincente diciendo la verdad que diciendo algo falso, porque para el modelo las dos cosas son el mismo tipo de tarea: continuar un texto de la forma más probable.

Un proveedor que dude en voz alta, un compañero que diga «no estoy seguro», un documento que marque un dato como pendiente de confirmar: todos esos avisos existen porque quien los da tiene, de alguna forma, acceso a su propio nivel de certeza. Un modelo de lenguaje, en su forma más básica, no lo tiene. Por eso el error no llega acompañado de ninguna señal de alarma, y por eso hace más daño que un error humano equivalente: el humano suele dudar antes de un dato que no domina; el modelo no.

Esto explica también por qué la primera impresión que da un asistente de este tipo suele ser tan buena. Las respuestas correctas y las inventadas comparten la misma redacción cuidada, la misma estructura ordenada, el mismo tono resolutivo. Un usuario que solo ha visto acertar al modelo unas cuantas veces tiende a extender esa confianza a la siguiente respuesta, sin darse cuenta de que el modelo no ha cambiado de comportamiento entre una pregunta y otra: sigue haciendo lo mismo, y esta vez ha tenido menos suerte con el terreno que pisaba.

#Por qué pedirle que «no se invente nada» no funciona

Es la instrucción que casi todo el mundo prueba primero, y la razón por la que no funciona está en lo que se acaba de explicar: pedirle al modelo que no invente no le da acceso a ningún dato nuevo ni le añade un mecanismo de comprobación que no tenía. Es como pedirle a alguien que adivine mejor. La instrucción cambia, como mucho, el tono de la respuesta —puede volverla más cautelosa, más llena de matices— pero no cambia de dónde sale esa respuesta, que sigue siendo la misma predicción de texto probable, con o sin la frase «no te inventes nada» delante. El modelo no distingue entre lo que sabe con certeza y lo que está completando por probabilidad, así que no hay instrucción de texto capaz de activar una distinción que no existe por dentro.

#Las tres cosas que sí funcionan

Ninguna de las tres cambia cómo funciona el modelo por dentro. Cambian lo que hay a su alrededor, que es donde de verdad se puede actuar.

Darle los datos buenos en el momento de responder. En lugar de confiar en lo que el modelo recuerda de su entrenamiento —genérico, y posiblemente desactualizado—, se le entrega el documento, la política o el dato concreto justo antes de pedirle la respuesta, para que la construya apoyado en eso y no en su memoria general. Es la diferencia entre preguntarle a alguien «¿cuál es la política de devoluciones?» de memoria, o dársela impresa delante y pedirle que la resuma.

Conectarlo a sistemas reales para que consulte en vez de recordar. Cuando la pregunta tiene una respuesta que vive en un sistema —el stock disponible, el estado de un pedido, el saldo de una cuenta— la forma fiable de resolverlo es que el modelo consulte ese sistema en el momento, no que intente recordarlo. Un modelo conectado a la fuente real contesta con el dato de ahora mismo; uno que solo recuerda contesta con lo más probable, que puede llevar meses de desfase.

Dejar que diga que no lo sabe. Un sistema bien diseñado alrededor del modelo puede reconocer cuándo la pregunta no tiene una fuente fiable a mano y devolver, en su lugar, «no tengo ese dato» en vez de forzar una respuesta. Suena a poco, pero es la diferencia entre un asistente que falla en silencio y uno que avisa cuando no puede ayudar. Dejar esa puerta abierta a propósito, en el diseño del sistema, es de las decisiones más rentables que existen en este terreno.

#La regla de negocio que se deriva de todo esto

Cuanto más caro sea el error, menos autonomía debería tener el modelo para cometerlo sin supervisión. Redactar un primer borrador de un correo tiene un coste de error bajo: si se equivoca, alguien lo lee y lo corrige antes de enviarlo. Aprobar un reembolso, confirmar un envío o modificar un dato de un cliente sin que nadie revise esa acción tiene un coste de error mucho más alto, y ahí la autonomía del modelo debería ser menor, no mayor, por muy bien que suene automatizarlo del todo.

Esta regla tiene una consecuencia práctica que conviene fijar por escrito antes de poner en marcha cualquier asistente: clasificar de antemano qué tipo de respuestas puede dar el sistema sin que nadie las revise, y cuáles necesitan pasar por una persona antes de llegar a producir un efecto real. No es una clasificación que se haga una sola vez y se olvide; a medida que el sistema demuestra ser fiable en una categoría, tiene sentido revisar el umbral y ampliar poco a poco su autonomía, siempre en esa dirección y nunca al revés por comodidad.