Nuestra cadena de contenido usa un modelo de IA sin acceso a internet. Cuando necesita citar una fuente, hace lo que haría cualquier estudiante pillado a última hora: se la inventa con una seguridad pasmosa. Le conectamos búsqueda real de Google para que dejara de alucinar. Funcionó a la primera. Y entonces dos enlaces de un artículo recién publicado amanecieron muertos.
TL;DR: El resumen sin rodeos
- Alucinaciones con fuentes: los LLM fabrican el 36% de las referencias que citan (Nature, 2024). Sin internet, tu modelo inventa estudios que no existen.
- Grounding = internet real: conectas al modelo a búsqueda web para que parta de hechos verificados, no de su memoria.
- La trampa de las URLs: las fuentes que devuelve el sistema son redirecciones temporales que caducan en ~1 hora. Tu validador las da por buenas porque al publicar aún funcionan.
- La solución: resolver cada URL a su destino final en el mismo instante de la generación. No después.
¿Por qué tu modelo de IA se inventa las fuentes?
Los modelos de lenguaje fabrican aproximadamente el 36% de las referencias que generan, según un estudio de Nature (2024). Va de serie.
Un LLM no "busca" información. Predice la siguiente palabra más probable dada una secuencia. Si le pides que cite un estudio, generará algo que parece real: título plausible, autores con nombre y apellido, URL con formato de revista científica. TODO inventado.
El problema no es que mienta. Es que no sabe que miente. Publica contenido con esas fuentes y tu lector confía en ti, hace clic, y se come un 404. O peor: aterriza en una página que no tiene nada que ver con lo que afirmabas.
Si generas contenido con IA y no supervisas las fuentes, date por hecho que te está pasando. La cuestión es cuántas de tus referencias son humo.
¿Qué es el grounding y por qué no basta con activarlo?
El grounding conecta al modelo a fuentes externas verificables durante la generación: responde con hechos trazables, no desde su memoria probabilística. La implementación más extendida es RAG (Retrieval-Augmented Generation): antes de que el modelo escriba, un paso previo busca en internet y le pasa los resultados como contexto.

Google ofrece esto integrado en su API de Gemini como "grounding con búsqueda de Google". 1.500 búsquedas al día gratis. Lo activas, el modelo deja de alucinar fuentes y empieza a citar URLs reales de medios reales. Ya no inventa: trabaja con datos verificados y devuelve las URLs de donde los sacó.
Suena a final feliz.
No lo es.
URLs que validan como vivas y mueren en una hora
Las URLs que devuelve el sistema de búsqueda no son la URL del medio original. Son enlaces de redirección intermedios que pasan por la infraestructura de búsqueda antes de llevarte al destino. Y tienen fecha de caducidad.
En nuestra experiencia, la ventana de validez ronda la hora. Pasado ese margen, el enlace temporal deja de redirigir y devuelve un error.
¿Qué significa esto en la práctica? Publicas un artículo a las 10 de la mañana. Tu validador automático lo revisa a las 10:05. Todo verde. A las 11:15, un lector hace clic en tu fuente y se come un 404.
Lo peor: tu sistema de supervisión no lo pilla porque cuando validó, el enlace aún vivía. Es un fallo invisible hasta que alguien se queja o un rastreador lo detecta días después.
Nosotros lo descubrimos con dos artículos ya publicados. Los enlaces parecían perfectos en el momento de la publicación. Al día siguiente, muertos (ojo, con nota verde del validador y todo). Los arreglamos buscando el título de cada fuente original y sustituyendo la URL caduca por la del estudio real. Unos minutos que habrían sido cero si hubiéramos resuelto las redirecciones desde el principio.
Cómo resolver las redirecciones en el momento de la generación
El arreglo es más simple de lo que parece. En el mismo instante en que generas el contenido, antes de guardarlo, resuelves cada URL a su destino final.
Técnicamente es una petición HTTP HEAD con seguimiento de redirecciones activado. El patrón está documentado para prácticamente cualquier lenguaje: en Python con requests, en Java con HttpURLConnection. No descargas el cuerpo de la página: solo sigues la cadena de redirecciones 301/302 hasta obtener la URL canónica.
Así queda la cosa:
- El modelo genera el artículo con las URLs que le da el sistema de búsqueda.
- Un paso intermedio toma cada URL, sigue las redirecciones y obtiene la URL canónica del medio original.
- Si la resolución falla (tiempo de espera agotado, dominio caído), plan B: búsqueda fresca con el título de la fuente para recuperar la URL real.
- Solo entonces se publica.
No después de publicar. No con una tarea programada que revise enlaces cada 24 horas. En el momento. Porque una hora después, la puerta ya está cerrada.
Lo que esto enseña sobre automatización con IA
Apostaría a que este problema afecta a más procesos de contenido de los que nadie admite. Cada capa de automatización que añades hereda los supuestos de la capa anterior. El sistema de búsqueda de Google asume que quieres acceso temporal a los resultados. Tu proceso de publicación asume que las URLs son permanentes. Nadie documenta ese hueco porque ambos supuestos son razonables por separado.

Este es el patrón que más daño hace en automatización con IA: no te muerden los fallos evidentes (esos los pillas rápido). Te muerden las partes que funcionan "lo bastante bien" como para pasar la validación. El enlace estaba vivo. El validador dijo OK. El artículo se publicó. Todo correcto, excepto que no lo era.
Ojo con el SEO: los enlaces rotos no penalizan directamente el posicionamiento, pero el daño indirecto es real. Desperdicias presupuesto de rastreo y pierdes la autoridad que ese enlace transmitía. Para Google y para tus lectores, es dejadez. Si tu contenido aspira a ser la referencia que un asistente de IA cite como fuente, no puedes permitirte que tus enlaces lleven a un callejón sin salida.
Si usas IA para generar contenido, no te fíes de lo que valida como correcto en el instante de publicar. Pregúntate cuánto va a durar esa validez. Aquí duraba 60 minutos. Ni uno más.


