La web se construyó para navegadores y después se optimizó para personas, anunciantes, analítica, plataformas, buscadores y sistemas de seguridad. Las máquinas siempre estuvieron ahí, pero sobre todo en funciones toleradas: rastreadores de búsqueda, monitores de disponibilidad, generadores de vistas previas de enlaces, lectores de feeds, validadores, scrapers y bots. Algunas eran bienvenidas; otras, bloqueadas. La mayoría quedaba en una clasificación ambigua dentro de una infraestructura que no tenía motivos para interesarse por su intención.
Los agentes de IA llegan a esa misma web con otra expectativa. Además de obtener páginas, intentan entender sistemas.
Esa diferencia importa.
Un rastreador puede obtener HTML y extraer enlaces. Un agente necesita saber qué observó, qué le faltó, qué falló, qué infirió, qué no estaba disponible y si el resultado en el que se apoya representa el estado real del runtime del sitio. Sin eso, los agentes se convierten en sistemas que adivinan con seguridad dentro de un entorno diseñado para ocultar, transformar, postergar, personalizar y limitar lo que ven.
La web moderna es cada vez más hostil a las máquinas, muchas veces por buenas razones.
La protección contra bots está delante de muchos sitios. Vercel, Cloudflare, Fastly, Akamai y otras plataformas ayudan a defender aplicaciones del abuso, scraping, ataques contra credenciales, spam y tráfico de denegación de servicio. Esa protección es necesaria. Pero para un agente legítimo, la experiencia suele ser indistinguible de un fallo. Una solicitud puede recibir un desafío, un 403, un 429, un bucle de redirecciones o una respuesta artificial distinta de la página que vería una persona.
Los límites de solicitudes también son ambiguos. Un 429 puede significar «intentá más tarde», «bajá el ritmo», «parecés automatizado», «este endpoint está sobrecargado» o «no podés conocer este sitio de esa manera». Un rastreador que oculta ese fallo produce una falsa confianza. Un sistema útil para agentes debería conservarlo como registro de lo ocurrido.
Las aplicaciones que dependen completamente de JavaScript generan otra opacidad. Una solicitud HTTP estática puede ver una estructura vacía, un contenedor de carga o una referencia a un bundle, mientras que el estado significativo de la aplicación aparece después de la hidratación, llamadas a API, autenticación, banderas de funciones o navegación del lado del cliente. Si un agente lee esa estructura y resume el sitio como vacío, se equivoca. Si no ejecuta nada y aun así informa éxito, es peor: borró las condiciones de observación.
Las redirecciones complican la identidad de la fuente. Las etiquetas canónicas complican la identidad de las rutas. La autenticación complica la cobertura. Los CDN complican la consistencia. Una página de inicio puede anunciar rutas distintas de las del sitemap; el sitemap puede incluir URLs viejas. `robots.txt` puede decir una cosa y el servidor hacer otra. Una página puede devolver 200 y mostrar un error. La web está llena de estados ocultos y los agentes necesitan poder decir «esto vi, así lo vi y acá termina mi observación».
Ese es el argumento a favor de los registros observables del runtime, o *runtime receipts*.
Qué es un registro
Un registro del runtime no es texto promocional, un prompt ni una vaga insignia de «listo para IA». Es un registro estructurado de una observación.
Debería responder preguntas básicas:
- ¿Qué URL de origen se solicitó?
- ¿Qué URL final se observó?
- ¿Se ejecutó JavaScript?
- ¿Se siguieron las redirecciones?
- ¿Qué rutas se obtuvieron?
- ¿Qué rutas fallaron?
- ¿Qué códigos de estado se devolvieron?
- ¿Se obtuvo `robots.txt`?
- ¿Se descubrió `sitemap.xml`?
- ¿Se aplicaron las directivas o sólo se registraron?
- ¿Había descripciones, títulos, canónicas y encabezados?
- ¿Se generaron los artefactos de manera determinista?
- ¿Se pueden validar esos artefactos?
Son preguntas cotidianas. Esa es la idea. La confianza operativa se construye con registros de lo que ocurrió.
Muchas veces, el problema de las herramientas de IA es que no distinguen de manera confiable entre «esto es cierto», «esto fue visible», «esto se infirió», «esto falló» y «esto no se comprobó». En la web, esa distinción es fundamental.
Un artefacto legible para agentes no debería presentar un rastreo parcial como completo, borrar los 429, describir aplicaciones renderizadas con JavaScript como si el HTML estático contara toda la historia ni esconder metadatos faltantes para mostrar un resultado más prolijo. Debería hacer explícita la ambigüedad.
Esto cambia el objetivo del rastreo. Ya no se trata solamente de extraer datos, sino de observar dejando constancia de las condiciones y los resultados.
Por qué importa validar
Por eso también importa la validación. Si un sitio genera `system.json`, `runtime.json`, `context.json` y `llms.txt`, esos archivos deberían coincidir entre sí. Sus hashes deberían ser estables. El inventario debería corresponder a los archivos generados. Sus advertencias deberían poder inspeccionarse y su esquema, ponerse a prueba. Un registro que no se puede validar es otro archivo de texto que pide confianza.
El futuro más interesante para estas herramientas podría estar en la integración continua, o CI, además de en un rastreador más inteligente.
Imaginá un sitio que genera registros del runtime legibles por máquinas durante el despliegue. El build podría fallar si desaparecen artefactos esperados, hay regresiones en rutas, deja de descubrirse el sitemap, aumentan los fallos de rastreo, cambia inesperadamente la identidad canónica o crece la dependencia de JavaScript más allá de un umbral aceptado. En ese escenario, la legibilidad para agentes pasa a formar parte del contrato operativo del sitio.
Ese contrato también ayudaría a las personas.
Los desarrolladores sabrían cuándo el sitio generado dejó de explicarse. Los equipos de plataforma verían cuándo la protección contra bots vuelve imposible un acceso legítimo. Quienes mantienen la documentación detectarían metadatos rotos antes que los usuarios. Los agentes consumirían diagnósticos explícitos en lugar de inventar alrededor de un estado faltante.
Los límites son parte del sistema
No todos los sitios deberían estar completamente abiertos a todas las máquinas. Algunos deben bloquear rastreadores; algunas páginas requieren autenticación y algunos datos deben permanecer inaccesibles. Los registros observables hacen legibles esos límites sin eliminarlos.
La web necesita mejores formas de describir qué ocurrió en el límite entre una máquina y un sistema en ejecución. Eso puede ayudar a los agentes sin reducir la seguridad.
La web se volvió hostil a las máquinas porque tuvo que defenderse de ellas. Los agentes de IA heredan esa desconfianza. La respuesta no es intentar sortearla con scraping cada vez más agresivo. Es construir artefactos que permitan a los sistemas declarar directamente su estructura observable, sus límites, fallos y garantías.
Los agentes no necesitan una web imaginaria en la que todas las páginas sean limpias, estáticas, públicas y estén perfectamente documentadas.
Necesitan registros de la web real.