Preferencias de entrenamiento IA en robots.txt

El 30 de octubre de 2026, tres días calendario antes de esta publicación en America/Lima, OpenAI y Google anunciaron que planean respetar el token común __usage_ai-training. Ese mismo día se publicó el Internet-Draft que define cómo usar un grupo ordinario de robots.txt para expresar una preferencia a favor o en contra de emplear un recurso en entrenamiento generativo. La decisión concreta para un founder o CTO no es copiar dos líneas y declarar el problema resuelto. Es convertir la intención editorial y legal sobre cada familia de contenido en una política versionada, probar cómo convive con controles específicos de proveedor y medir qué consumidores la respetan. El token reduce duplicación para participantes compatibles; no vuelve privado un recurso público, no expulsa por sí solo a un crawler y no demuestra que un dataset histórico haya sido eliminado.

La novedad sigue siendo una adopción anunciada, no una cobertura universal ya desplegada. OpenAI dice que apunta a implementarla en los próximos meses y conservará sus controles existentes. Google proyecta soporte a inicios de 2027 y explica que, cuando no exista una regla explícita para Google-Extended, interpretará el opt-out común como un disallow equivalente para ese control. El Internet-Draft expira el 3 de mayo de 2027 si no progresa y puede cambiar durante la discusión del IETF. Por eso el rollout debe registrar versión, fecha y comportamiento observado, en lugar de tratar el borrador como un estándar terminado.

El borrador reutiliza la gramática y el matching por rutas de RFC 9309. Un grupo con User-Agent: __usage_ai-training y Disallow: / expresa una preferencia contra el entrenamiento para todo el sitio; un Allow más específico puede abrir, por ejemplo, /press-kit/. Si el token no aparece, no se expresa preferencia dentro de este mecanismo. El grupo comodín User-Agent: * no debe interpretarse como si coincidiera con el token. Esta separación importa porque los parsers existentes pueden ignorar el grupo desconocido sin alterar su comportamiento de crawling.

La palabra clave es uso. El borrador define entrenamiento IA como emplear un activo para modificar parámetros aprendidos de un modelo generativo. Clasificación, ranking y scoring quedan fuera de esa categoría, aunque el sistema produzca una explicación. El mismo robots.txt puede contener una preferencia sobre uso y reglas para el tráfico de un crawler, pero son planos ortogonales. Si necesitas impedir acceso, proteger secretos o limitar carga, debes conservar autenticación, autorización, rate limiting, reglas específicas de crawler y controles de infraestructura.

Ejemplo hipotético: una empresa publica documentación, un blog, fichas comerciales y un portal autenticado. Quiere que el blog y las fichas sigan visibles en búsqueda y puedan respaldar respuestas con enlaces, pero no desea expresar consentimiento para entrenamiento generativo. A la vez, sí permite entrenamiento con un press kit licenciado. La matriz de decisión debe clasificar primero el propósito y la sensibilidad de cada ruta; después produce la regla común, las excepciones por proveedor y los controles de acceso. Empezar por la sintaxis invierte el problema y suele mezclar objetivos incompatibles.

La implementación mínima sería negar entrenamiento en / y permitir /press-kit/, mientras mantiene reglas independientes para crawlers y protege /portal/ detrás de identidad. Pero la empresa todavía debe decidir qué hacer con subdominios, CDN, assets, feeds, copias regionales y contenido distribuido por terceros. robots.txt se resuelve por origen; una regla en www.example.com no gobierna automáticamente assets.example.com ni una réplica de un partner. La política también debe fijar quién aprueba excepciones y qué contrato prevalece cuando existe un acuerdo privado, porque el borrador permite que acuerdos privados sustituyan la preferencia pública.

Trata el cambio como una migración de política, no como una edición aislada. El owner de contenido debe aprobar la matriz de usos; legal debe revisar contratos y jurisdicciones; plataforma debe generar y servir reglas válidas; SEO debe comprobar que la indexación deseada sigue funcionando; seguridad debe confirmar que ninguna ruta sensible depende de robots.txt; y observabilidad debe conservar una foto del archivo efectivo y de las respuestas de los proveedores. Cada gate debe producir evidencia fechada y una condición clara de rollback.

No reemplaces inmediatamente los tokens propietarios. Durante la transición, publica la regla común junto con controles documentados como Google-Extended o los crawlers de OpenAI cuando la intención sea equivalente, y declara cualquier excepción de forma explícita. Google anticipa que una regla específica para Google-Extended tendrá prioridad sobre su interpretación del token general. Esa precedencia es útil, pero también crea riesgo de configuración contradictoria. Un linter interno debe expandir rutas y proveedores para mostrar el resultado efectivo antes del deploy.

La primera prueba es determinista: descarga robots.txt desde cada origen como un cliente externo, conserva headers y hash, parsea el grupo del token y evalúa una tabla de rutas positivas y negativas. Incluye barras finales, mayúsculas, escapes, parámetros y la regla de coincidencia más larga. Repite el test desde el CDN y después de cada cambio de infraestructura. Un archivo correcto en el repositorio no prueba que la versión efectiva haya salido del edge.

La segunda prueba observa efectos sin inventar causalidad. Segmenta logs por user-agent verificado cuando el proveedor publique un método de verificación, pero recuerda que el policy token puede no aparecer como user-agent de una petición. Mide cambios en crawling, indexación, referrals y apariciones citadas por separado. Si el tráfico cae, no concluyas que el opt-out de entrenamiento lo causó: el borrador dice expresamente que la señal de uso es independiente de las reglas de crawling. Abre un incidente solo con un diff reproducible entre política, comportamiento esperado y comportamiento observado.

La tercera prueba es de gobierno. Revisa trimestralmente la versión del borrador, la lista de proveedores participantes, sus fechas de implementación y sus definiciones. Guarda capturas de la documentación que respaldó la decisión; una promesa futura no debe registrarse como soporte activo. Si un proveedor cambia la relación entre entrenamiento, grounding y búsqueda, vuelve a pasar los seis gates antes de ajustar la regla.

robots.txt es público y declarativo. Un actor no cooperante puede ignorarlo; un user-agent puede falsificarse; una copia obtenida antes del cambio puede seguir bajo otra política; y un distribuidor puede servir el mismo contenido desde otro origen. Tampoco existe en el anuncio una auditoría retroactiva, un recibo universal por recurso ni un mecanismo de borrado. Si el dato es confidencial, personal o contractual, el control correcto está antes de la descarga. Si la organización necesita probar cumplimiento, debe combinar señal, contratos, inventario de distribución, registros verificables y un canal de reclamación.

También existe riesgo comercial. Bloquear indiscriminadamente crawling o grounding para intentar evitar entrenamiento puede reducir descubrimiento y referencias sin mejorar el control buscado. El caso inverso es aceptar todas las formas de uso por miedo a perder SEO. La salida es una política por propósito: definir qué contenido puede entrenar, qué contenido puede fundamentar respuestas con atribución, qué páginas deben indexarse y qué datos nunca deben ser públicos. La señal común hace más barato comunicar una parte de esa matriz; no decide la matriz por ti.

Para un sitio que ya mantiene controles por proveedor, conviene preparar compatibilidad ahora y desplegar cuando la intención por ruta esté aprobada. Mantén ambos niveles durante la transición, automatiza la prueba del archivo servido y marca el soporte de cada proveedor como anunciado, piloto o activo. Para un sitio sin política de uso de contenido, no empieces por robots.txt: crea primero el inventario, los owners y las decisiones sobre entrenamiento, búsqueda, grounding y acceso.

El avance del 30 de octubre importa porque OpenAI y Google respaldaron la misma pieza interoperable y porque el IETF la conectó con una definición explícita de entrenamiento generativo. Su valor real aparecerá cuando las organizaciones puedan explicar una regla, demostrar qué versión publicaron y reconciliarla con contratos y comportamiento observado. Si necesitas convertir esa matriz en arquitectura y controles operables, el servicio de agentes y desarrollo con IA de Wasyra puede ayudarte a diseñar el flujo sin confundir señal, enforcement y evidencia.