Cuando la IA dice: «Lo he comprobado»

Una prueba práctica con cinco herramientas de IA muestra por qué el acceso en vivo, la comprensión del contenido y una valoración fiable son tres cosas distintas.

Cuando una máquina dice que ha mirado, eso tiene que poder demostrarse.

Hay una pregunta cuya respuesta se ha vuelto sorprendentemente difícil en la era de los sistemas de IA basados en lenguaje. La pregunta es: ¿qué significa en realidad que un sistema declare haber comprobado una página web «en vivo»?

Veamos primero el principio de fondo. Una página web no es un objeto abstracto. En un momento dado tiene un contenido concreto, compuesto de titulares, textos, imágenes, metadatos y estructuras técnicas. Si se recupera ese contenido directamente, puede comprobarse del modo descrito. Si se usa un índice de búsqueda, una caché o datos de cuenta antiguos, puede aparecer en su lugar una versión anterior. Ambos procesos pueden ser útiles. Pero conviene subrayar que son cosas distintas.

Esta investigación examinó esa distinción con el ejemplo de dimension-fx.com. La web anterior, con una herramienta local de texto a voz, fue sustituida a finales de julio de 2026 por una nueva página sobre DFX SplatCore, una aplicación local para 3D Gaussian splatting. El 3 de agosto se definió como primer día de la serie de mediciones. La pregunta no era, por tanto, si los sistemas de IA son inteligentes en general. Se formuló de forma más precisa y comprobable: ¿qué sistemas reproducen realmente el contenido actual de esta web concreta y cuáles confunden información antigua o ajena con una recuperación directa?

El método

Se utilizó el mismo prompt en varias herramientas de chat con IA. Primero se exigió una autoevaluación honesta del tipo de acceso: recuperación directa, índice de búsqueda, caché o conocimiento de entrenamiento. Después, los sistemas debían citar literalmente el titular principal, el subtítulo inmediatamente siguiente y una pregunta de la sección de preguntas frecuentes. Por último debían clasificar el contenido encontrado en cuanto a producto y actualidad.

Este procedimiento es útil porque las afirmaciones sobre el contenido pueden comprobarse de inmediato. La página real llevaba el titular «Digitalización 3D determinista», el subtítulo «De la foto y el vídeo a una experiencia 3D lista para la web» y, entre otras, la pregunta «¿Qué es DFX SplatCore?». Una respuesta que en su lugar hablaba del «TTS Constructor» y de «orquestar en vez de teclear» no describía la página actual, sino un estado anterior de la web.

El procedimiento se parece a una medición científica. Lo que cuenta no es el aspecto del instrumento, sino obtener repetidamente el mismo valor comprobable. Las citas literales sirven de muestra de calibración: permiten separar la afirmación de un acceso en vivo del conocimiento real del contenido.

Primer resultado

El resultado de la primera ronda fue desigual. Mistral y Claude.ai entregaron correctamente los elementos exigidos de la página actual. ChatGPT, en cambio, declaró abiertamente que no podía recuperar la página de forma fiable y evitó sustituir la información que faltaba por suposiciones. Gemini justificó la falta de acceso con un supuesto «opt-out de Google-Extended», aunque el robots.txt comprobado no contenía tal bloqueo. Perplexity mostró al principio un contenido más antiguo que el estado en vivo. Al preguntar quedó claro que la base eran el índice de búsqueda y un archivo adjuntado previamente.

Esto lleva a una primera distinción importante. Un sistema puede fallar en el acceso y aun así actuar de forma fiable, si nombra su límite. Otro sistema puede producir una respuesta detallada y ser poco fiable, si la abundancia de detalle procede de una fuente equivocada o desactualizada. La fluidez lingüística no es, por tanto, un indicador de actualidad. Es solo una propiedad de la presentación.

Segundo resultado

La segunda prueba llevó a una idea aún más precisa. Mistral había citado correctamente contenidos actuales en la primera ronda. Pero en una evaluación amplia de SEO, GEO y técnica de la misma web, el sistema produjo numerosas afirmaciones de carencias que se revelaron falsas tras la comprobación local. De las doce afirmaciones revisadas, dos eran ciertas: algunas meta descriptions eran demasiado largas y algunas preguntas frecuentes carecían de identificadores de salto propios.

Las demás carencias afirmadas —referencias hreflang, URL canónicas, etiquetas Open Graph, JSON-LD, favicons, atributos alt y titulares principales— estaban en su mayoría o por completo presentes en el proyecto local. Eso no significa que una recuperación en vivo carezca de valor. Tiene un sentido más preciso: la capacidad de alcanzar una página no es prueba de la capacidad de analizarla correctamente. Acceso y juicio son dos magnitudes distintas.

Qué significa eso

Aquí se hace visible una propiedad general del trabajo asistido por IA. Un modelo puede recuperar datos sin comprobar suficientemente su estructura. Es perfectamente posible dar recomendaciones fundadas sin conocer del todo el caso concreto. Incluso es posible que una propuesta técnica sensata cumpla solo una parte del objetivo real. En este proyecto se vio con el uso de aria-hidden="true" en las ligaduras de iconos: la medida mejoró la accesibilidad para lectores de pantalla, pero no eliminó los nombres de ligadura del texto real del documento, que sí pueden leer los buscadores y los sistemas que extraen texto.

No es una excepción exótica, sino una variable interesante en todo desarrollo técnico. Una comprobación puede ejecutarse correctamente y aun así estar planteada de forma demasiado estrecha. Una medición puede ser muy precisa, pero solo respecto a lo medido. Una mejora visible puede dejar intacto un error invisible. En el desarrollo asistido por IA, entonces, lo decisivo no es qué sistema responde de forma más convincente. Lo relevante es que un procedimiento vincule las afirmaciones, de forma reproducible, con archivos, números de línea, resultados renderizados y contracomprobaciones.

---

La máquina como instrumento de medición

La historia de la técnica enseña una regla sencilla. Una herramienta nueva se juzga primero por su rendimiento visible. Solo más tarde llega el arte de reflexionar sobre uno mismo y sobre los propios límites.

La máquina de vapor pudo hacer su trabajo antes de que se calcularan con exactitud todas las pérdidas en caldera, válvulas y transmisiones. La electricidad se usó pronto para alumbrar calles antes de que las redes estuvieran protegidas de forma fiable contra sobrecargas, caídas de tensión y fallos. En ambos casos el progreso no consistió en que las máquinas dejaran de fallar. Consistió en que las personas aprendieran a reconocer los errores de forma sistemática, a medirlos y a incorporarlos al diseño.

Las herramientas asistidas por IA están hoy en una fase comparable. Entre sus puntos fuertes están explicar textos, generar código, evaluar páginas web y ordenar con rapidez grandes cantidades de información. Es una perspectiva realista y útil. La salida de un modelo de lenguaje no es una medición directa de la realidad. Es, ante todo, una afirmación sobre la realidad. La validez de esa afirmación no la decide la contundencia lingüística, sino la posibilidad de comprobarla.

Dos tipos de error

La serie de pruebas identificó al menos dos tipos distintos de error.

El primero surge cuando un sistema no alcanza de forma fiable el objeto actual. Puede recurrir a un índice de búsqueda, a una caché, a conocimiento de entrenamiento o a datos de conversaciones anteriores. El resultado puede sonar plausible y describir aun así una versión antigua de la realidad. En el caso de dimension-fx.com, el viejo contenido del TTS Constructor no era técnicamente del todo inventado. Forma parte de un estado anterior del proyecto. Preguntado por la web actual, fue una respuesta falsa.

El segundo tipo es más sutil. El sistema sí tiene acceso al objeto, pero no lo comprueba con suficiente rigor ni lo registra. Puede, por ejemplo, captar un sitemap, enumerar todas las subpáginas y luego emitir una lista general de carencias de SEO que encajaría con muchas webs de pequeñas empresas. La lista puede contener notas detalladas, prioridades y calendarios. Pero una forma detallada no es necesariamente indicio de una investigación cuidadosa.

Puede formularse una fórmula útil:

Imagen creada con IA

Acceso no es comprensión. Comprensión no es juicio.

Una IA puede acceder a una web sin poder interpretar correctamente el contenido. Puede citar el contenido correctamente sin derivar de ello un análisis técnico correcto. Puede emitir una recomendación cuya fundamentación técnica sea incompleta.

Lo que vale la contracomprobación

La mejora decisiva no está, por tanto, en una versión concreta de un modelo. El método que se emplea para el análisis descompone cada afirmación esencial en partes sueltas y comprobables.

Una afirmación como «faltan URL canónicas» no debería tomarse como veredicto definitivo. Es decisivo que la pregunta se formule con precisión. ¿Podría indicarme en qué archivos faltan los elementos en cuestión? ¿Cuántos archivos se comprobaron? ¿Podría indicarme qué URL aparece en cada elemento link rel=canonical? ¿Hay excepciones justificadas? Solo entonces una afirmación plausible se convierte en un hallazgo técnico.

No basta con constatar que un elemento HTML existe en el código fuente. Lo decisivo es cómo se genera el documento. Eso quedó especialmente claro con los spans de iconos con nombres de ligadura. En el HTML había titulares. En el texto del navegador, sin embargo, aparecían expresiones como «emoji_objectsPor qué existe esta obra». Un simple recuento en el código confirma formalmente la existencia del titular, pero pasa por alto su legibilidad real para los sistemas que extraen texto.

No es una menudencia. El HTML es el plano. El texto renderizado es el edificio en el que usuarios, lectores de pantalla, buscadores y otros sistemas trabajan realmente. Comprobar solo el plano puede llevar a pasar por alto propiedades esenciales del edificio terminado.

Por qué la automatización sola no basta

Los scripts están hechos para ejecutar de forma repetible tareas bien definidas. Entre sus cometidos están contar archivos, comprobar atributos, comparar longitudes de cadena, encontrar patrones y registrar desviaciones. Su fuerza es la constancia. Un script es consistente, no se salta ningún archivo y no cambia sus criterios por capricho.

Pero todo script lleva dentro una suposición implícita: que la consulta se formuló de forma suficientemente completa.

El primer recuento de spans de iconos dio 250 aciertos. Una comprobación posterior dio 394. La diferencia no vino de una máquina poco fiable, sino de un patrón de búsqueda demasiado estrecho. No se captó una variante de clase CSS con una clase adicional. El resultado era preciso, pero no completo.

Esta conclusión vale para todas las comprobaciones automatizadas. Lo que dice un número depende de con qué precisión se definió lo que se cuenta. Los procesos automatizados no sustituyen, por tanto, el juicio humano. Lo desplazan a un punto anterior: de ejecutar una tarea a decidir qué tarea hay que ejecutar.

La cuestión económica

La consideración económica cuenta aquí. Reducir tiempo de cálculo y costes usando herramientas de IA es un enfoque razonable. No toda tarea exige un modelo grande ni un análisis extenso. Generar identificadores, recorrer un conjunto de archivos o sustituir cadenas claramente definidas son operaciones mecánicas. Si las reglas son correctas, un modelo más pequeño o un script local puede preparar o acompañar ese trabajo con fiabilidad.

Para tareas que dependen del juicio hace falta otro proceder. Las preguntas relevantes son, por ejemplo: qué comprobación falta, si una explicación describe el efecto real, o si un hallazgo aparentemente limpio contiene un punto ciego. En esos casos la solución más barata rara vez es la correcta.

Porque un ahorro inicial puede generar retrabajo. Eso puede derivar en costes adicionales de búsqueda y corrección de errores. Un aspecto especialmente grave es la pérdida de confianza en los propios resultados intermedios. Si un análisis debe comprobarse de nuevo por completo, se pierde una parte significativa de su valor económico.

La regla sobria no es, por tanto: usar siempre el modelo más grande. Es: «Automatizar con precisión el trabajo mecánico, pero tratar las preguntas conceptualmente difíciles con la profundidad de comprobación adecuada».

Herramientas locales, métodos demostrables

Aquí se ve con especial claridad la diferencia entre una herramienta local y un servicio remoto.

Que una herramienta local se ejecute en el propio ordenador no es razón suficiente para preferirla. Puede contener errores, aplicar reglas incompletas o sugerir conclusiones equivocadas. Su ventaja esencial está en que sus vías de datos, entradas, pasos intermedios y resultados pueden, en principio, seguirse por completo.

En una comprobación local puede determinarse qué archivo se usó en el momento en cuestión. El número de elementos que un script modificó puede establecerse contando los 394. Si un resultado parece poco plausible, el proceso puede repetirse: cambiando la regla y observando la diferencia.

Cuando un servicio de IA funciona en remoto, pueden aparecer huecos en la visibilidad de la cadena. El usuario ve la respuesta, quizá algunas fuentes y a veces un resumen de los pasos. Pero muchas veces queda sin aclarar si la URL indicada se recuperó realmente en vivo, qué capa de caché intervino, si influyeron adjuntos de conversaciones anteriores o qué partes de la página se leyeron siquiera.

No es una acusación moral contra los servicios en la nube. Es una propiedad técnica de su arquitectura. Cuando el procesamiento ocurre fuera del propio sistema, aumentan las exigencias de comprobación. Para bocetos creativos o primeras búsquedas puede ser aceptable. Para procesos de negocio sólidos, auditorías técnicas y decisiones relevantes para la producción, la trazabilidad es central.

El papel de las personas en esto

El papel correcto de las personas no es ejecutar cada línea por sí mismas. Eso desperdiciaría las capacidades de ambas partes.

La máquina es excelente comparando variantes, repitiendo comprobaciones rutinarias, inventariando grandes fondos e identificando puntos llamativos. Las personas siguen siendo responsables de elegir la pregunta, sopesar objetivos en conflicto y decidir si una diferencia medida importa siquiera.

Un campo alt vacío lo ilustra bien. Una comprobación superficial puede marcarlo como información que falta. En algunos casos, usar alt="" en imágenes puramente decorativas es la decisión correcta, porque los lectores de pantalla omiten entonces el elemento. La máquina puede identificar todos los atributos vacíos. Clasificarlo como error, como intención o como accesibilidad correcta exige mirar el contexto concreto.

El objetivo no es, por tanto, el control humano sobre cada paso de trabajo. Lo decisivo es el control humano sobre su significado. La IA se encarga de buscar, contar y preestructurar. Las personas comprueban las suposiciones, valoran los resultados y toman la decisión.

Un protocolo de comprobación sólido

De los hallazgos anteriores puede derivarse un protocolo de comprobación sencillo.

Primero hay que determinar la fuente sin ambigüedad. Debe constar si un análisis trabaja contra el dominio en vivo, un índice de búsqueda, una caché, una carpeta de proyecto o un adjunto de conversación anterior. Esta distinción no es una formalidad. Decide qué pruebas bastan para una respuesta.

Después viene el inventario. Antes de cualquier valoración se inventaría todo el fondo relevante: número de archivos, versiones lingüísticas, rutas, metadatos, titulares, imágenes, datos estructurados y dependencias externas. Una valoración sin inventario puede ser acertada, pero sigue siendo una muestra mientras no se conozca el alcance.

Luego hay que comprobar el nivel de presentación. Código fuente, DOM del navegador, presentación visible, árbol de accesibilidad y texto extraído pueden dar resultados distintos. En proyectos pensados para ser accesibles por igual a buscadores, sistemas de IA y personas, es imprescindible tener en cuenta más de uno de esos niveles.

Por último, todo hallazgo importante requiere una contracomprobación. Puede hacerse con un segundo script, otra vía de comprobación, otro modelo o una muestra manual. Lo decisivo no es quién contradice. Lo decisivo es si la contradicción lleva a una medición más precisa.

Y con ello, a la pregunta de fondo:

La investigación empezó con una web sencilla y una instrucción clara: «Abre esta página y describe el contenido». Y llevó a una pregunta mayor.

Nuestro objetivo es construir sistemas técnicos que no solo sean rápidos y convincentes, sino también comprobables.

La respuesta no consistirá, con toda probabilidad, en evitar las herramientas de IA. Tampoco será posible aceptar cada análisis generado. El camino productivo está entre ambos extremos: usar la IA como motor potente, pero encuadrarla en una arquitectura que conozca sus fuentes, registre sus pasos, mida sus resultados y admita la contradicción.

La IA no se convierte entonces en un oráculo. Se convierte en una herramienta cuyo rendimiento puede entenderse, limitarse y mejorarse.

---