El riesgo silencioso de una IA que responde con información desactualizada

Estamos cada vez más acostumbrados a confiarle a la IA nuestras decisiones. En el trabajo, en el día a día, hasta en temas personales le preguntamos y actuamos según lo que responde.

Pero, ¿qué pasaría si un agente te da información que a primera vista parece confiable, con una fuente real detrás, pero en realidad tiene dos años de antigüedad o más?

Imagina que ese agente está en el portal de un banco, una clínica o una entidad del Estado. Y que, en base a esa respuesta, tomas una decisión.

¿Te imaginas que fuera la información para inscribirte a un evento, sacar una cita médica o pagar un impuesto? Que el agente te confirme una fecha, un requisito o un monto que ya no aplica, y tú lo tomes como válido porque, bueno, te lo dijo la IA.

Ese es el escenario que quiero desarrollar hoy, porque no es ciencia ficción. Es un riesgo real, silencioso, y que casi nadie está diseñando para prevenir.

No es una alucinación, y eso es lo grave

Cuando hablamos de errores de IA generativa, lo primero que se nos viene a la mente es la alucinación: el modelo inventa una fuente, cita un dato que no existe, construye una respuesta con seguridad absoluta sobre algo que jamás verificó. Ya aprendimos a desconfiar cuando algo se ve raro.

Este otro error es distinto y más peligroso, justamente porque no se ve raro. El documento existe. La fuente citada es real. El agente la interpretó correctamente. Todo pasa cualquier revisión superficial sin problema.

El error no está en lo que el modelo inventó. Está en lo que el sistema decidió que era la mejor información disponible, sin darse cuenta de que ya no estaba vigente.

Por qué el sistema no distingue esto

La mayoría de estos agentes funcionan con una arquitectura de RAG (Retrieval-Augmented Generation): antes de responder, el sistema busca en una base de documentos.

El problema está en ese segundo paso. Los documentos se dividen en fragmentos y cada fragmento se convierte en una representación numérica de su significado. Cuando alguien pregunta algo, el sistema recupera los fragmentos que más se parecen semánticamente a esa pregunta, no cuáles siguen vigentes.

Imagina dos versiones del mismo procedimiento, una de hace dos años y su reemplazo reciente. Comparten casi el mismo vocabulario, la misma estructura, el mismo tema.

Para el sistema, ambas son candidatas casi perfectas. No tiene ninguna noción incorporada de que una reemplazó a la otra. Simplemente elige la que matemáticamente se acerca más a la pregunta, sin importarle cuál sigue siendo válida hoy.

El modelo que redacta la respuesta final tampoco puede corregir esto, porque para cuando el texto llega a sus manos, ya fue seleccionado. El error no ocurre durante la redacción. Ocurre antes, en la selección del conocimiento que se le permitió usar.

Lo que casi nadie diseña

Hay tres piezas que suelen faltar en estas implementaciones, y son justamente las primeras que se dejan para después:

Metadata temporal. No basta con que un archivo se llame "version_final_2026.pdf". El sistema necesita campos estructurados: fecha de vigencia, fecha de expiración, estado, qué versión reemplazó a cuál. Sin esos datos, para el sistema todas las versiones son igual de válidas.

Una fuente única de verdad. En muchas organizaciones conviven varias versiones de un mismo documento en distintas carpetas, con nombres como "final", "final2" y "nueva". Una persona con experiencia puede intuir cuál usar. El sistema no puede, a menos que se lo digamos explícitamente.

Una capa de validación entre la búsqueda y la respuesta. La búsqueda semántica encuentra candidatos. Decidir cuáles de esos candidatos pueden usarse debería ser una regla determinista, no algo que dependa de qué tan convincente suene el texto.

La arquitectura que sí lo resuelve

Aquí es donde muchas organizaciones se equivocan de diagnóstico. Cuando un agente comete este tipo de error, la reacción natural es pensar que hace falta un modelo más grande o más nuevo. Pero un modelo más potente no resuelve nada si sigue recibiendo el mismo contexto mal seleccionado.

La solución agrega un paso entre la búsqueda semántica y la generación de la respuesta:

Solo lo que pasa esa validación llega al modelo como contexto autorizado. Versiones, estados y fechas se verifican con reglas simples y deterministas, no con el criterio del modelo.

Y hay una segunda pieza igual de importante: el agente debe tener permitido no responder. Cuando no existe una fuente vigente y confiable, la respuesta correcta puede ser simplemente decir que no se puede confirmar esa información en este momento. Muchos agentes terminan diseñándose, implícita o explícitamente, para intentar responder siempre. Y una respuesta incompleta pero honesta es infinitamente mejor que una respuesta completa construida sobre información que ya caducó.

La arquitectura empieza antes del modelo

No comparto este caso solo como advertencia técnica. Lo comparto porque creo que esta es exactamente la conversación que todavía no estamos teniendo con la profundidad que necesita, mientras nos apuramos por implementar IA generativa, mostrar casos de uso y no quedarnos atrás.

Un agente de IA en una institución que maneja citas, trámites, pagos o aprobaciones no es un experimento de innovación aislado. Es un sistema que puede terminar influyendo decisiones reales de las personas que confían en él. Y si algo he aprendido en más de quince años trabajando con sistemas críticos es que la gestión documental descuidada, con IA o sin IA, tarde o temprano se paga caro.

La pregunta que deberíamos estar haciéndonos ya no es solo qué tan inteligente es el modelo que estamos usando. Es qué información le estamos permitiendo usar, con qué reglas, y qué pasa cuando esa información deja de ser válida. Ese diseño no lo resuelve un mejor prompt ni un modelo más nuevo. Lo resuelve arquitectura, gobierno documental y sentido común aplicado con disciplina.