Los scrapers [es una técnica utilizada mediante programas de software para extraer información de sitios web] del Modelo Extenso de Lenguaje [LLM] están derribando la infraestructura de los proyectos de FOSS [Software libre y de código abierto], y la situación está empeorando.
Por Niccolò Venerandi, 20 de marzo de 2025
Hace tres días, Drew DeVault, fundador y director ejecutivo de SourceHut, publicó una entrada de blog titulada «Por favor, dejad de externalizar vuestros costes directamente en mi cara», en la que se quejaba de que las empresas de LLM rastreaban datos sin respetar el archivo robosts.txt y causaban graves interrupciones en SourceHut.
Pensé: «¡Interesante!», y seguí adelante.
Luego, ayer por la mañana, la infraestructura de GitLab de KDE se vio desbordada por otro rastreador de IA, con IPs de un rango de Alibaba; esto provocó que GitLab estuviera temporalmente inaccesible para los desarrolladores de KDE.
Luego descubrí que, hace una semana, una muñeca de anime comenzó a aparecer en la instancia de GitLab de GNOME, cuando se cargaba la página. Resulta que es la página de carga predeterminada de Anubis, un sistema de prueba de trabajo que bloquea los rastreadores de IA que están causando interrupciones.
A estas alturas, debería estar bastante claro que esto no es una coincidencia. Los rastreadores de IA son cada vez más agresivos y, dado que el software FOSS se basa en la colaboración pública, mientras que las empresas privadas no tienen ese requisito, esto supone una carga adicional para las comunidades de código abierto.
Así que intentemos obtener más detalles, volviendo a la entrada del blog de Drew. Según Drew, los rastreadores LLM no respetan los requisitos de robots.txt e incluyen costosos puntos finales como git blame [Es un comando que se utiliza para ver los cambios realizados en un archivo, lo cual resulta útil en el trabajo en equipo], en cada página de cada registro git y en cada confirmación de cambios en su repositorio. Lo hacen utilizando agentes de usuario aleatorios de decenas de miles de direcciones IP, cada uno de los cuales no realiza más de una solicitud HTTP, tratando de mezclarse con el tráfico de usuarios.
Debido a esto, es difícil conseguir un buen conjunto de contramedidas. Drew dice que varias tareas de alta prioridad se han retrasado durante semanas o meses debido a estas interrupciones, los usuarios se han visto afectados ocasionalmente (porque es difícil distinguir entre bots y humanos) y, por supuesto, esto provoca interrupciones ocasionales de SourceHut.
Drew no distingue aquí entre qué empresas de IA son más o menos respetuosas con los archivos robots.txt, o más precisas en sus informes de agente de usuario; podremos profundizar más en eso más adelante.
Por último, Drew señala que no se trata de un problema aislado. Dice:
Todos mis amigos administradores de sistemas están lidiando con los mismos problemas, [y] cada vez que me siento a tomar unas cervezas o a cenar para socializar con amigos administradores de sistemas, no pasa mucho tiempo antes de que nos quejemos de los bots. […] La desesperación en estas conversaciones es palpable.
Lo que me lleva de vuelta a los problemas de KDE GitLab de ayer. Según Ben, parte del equipo de administradores de sistemas de KDE, todas las IP que estaban realizando este DDoS afirmaban ser MS Edge, y se debían a empresas chinas de IA; menciona que los operadores occidentales de LLM, como OpenAI y Anthropic, al menos estaban estableciendo una UA adecuada, de nuevo, más sobre esto más adelante.
La solución, por ahora, fue prohibir la versión de Edge que los bots afirmaban ser, aunque es difícil creer que esta sea una solución definitiva; estos bots parecen interesados en cambiar los agentes de usuario para tratar de mezclarse lo más posible.
De hecho, GNOME ha estado experimentando problemas desde noviembre pasado; como solución temporal, habían limitado la velocidad para que los usuarios no registrados no vieran las solicitudes de fusión y las confirmaciones, lo que obviamente también causó problemas a los invitados humanos reales.
La solución a la que finalmente se llegó fue cambiar a Anubis. Se trata de una página que presenta un desafío al navegador, que luego tiene que dedicar tiempo a hacer algunos cálculos y presentar la solución al servidor. Si es correcta, se obtiene acceso al sitio web.
Según el desarrollador, este proyecto es «una especie de respuesta nuclear, pero los bots rastreadores de IA que rastrean de forma tan agresiva me han obligado a hacerlo. Odio tener que hacer esto, pero esto es lo que obtenemos de la Internet moderna porque los bots no se ajustan a estándares como robots.txt, incluso cuando dicen hacerlo».
Sin embargo, esto también está causando problemas a los usuarios. Cuando muchas personas abren el enlace desde el mismo lugar, puede suceder que se les presente un ejercicio de mayor dificultad que les llevará algún tiempo completar; hay un usuario que informa de un retraso de un minuto, y otro, desde su teléfono, que tiene que esperar unos dos minutos.
¿Por qué? Bueno, ¡porque se había pegado un enlace de GitLab en una sala de chat! Algo similar ocurrió cuando se publicó el artículo sobre la solicitud de fusión de GNOME de triple almacenamiento en búfer en Hacker News, que recibió mucha atención. Como dijo el desarrollador, es una opción nuclear para los rastreadores, pero también tiene consecuencias en las personas.
Sobre Mastodon, un administrador de sistemas de GNOME, Bart Piotrowski, compartió amablemente algunas cifras para que la gente comprendiera plenamente el alcance del problema. Según él, en unas dos horas y media recibieron un total de 81 000 solicitudes, y de ellas solo el 3 % superó la prueba de trabajo de Anubi, lo que sugiere que el 97 % del tráfico eran bots, ¡una cifra de locos!
Dicho esto, al menos eso ha funcionado. A otras organizaciones les está costando más lidiar con estos scrapers.
Por ejemplo, Jonathan Corbet, que dirige la fuente de noticias LWN, advierte a los usuarios de que el sitio web podría ser «ocasionalmente lento»… debido a los DDoS de los bots scraper de IA. Afirma que «solo una pequeña fracción de nuestro tráfico está sirviendo a lectores humanos reales», y en algún momento, los bots «deciden atacarnos desde cientos de direcciones IP a la vez. [..] No se identifican como bots, y lo único que no leen del sitio es robots.txt».
Muchos expresaron su solidaridad, incluido Kevin Fenzi, administrador de sistemas del proyecto Fedora. También han tenido problemas con los rastreadores de IA: en primer lugar, hace un mes tuvieron que luchar para que pagure.io siguiera vivo:
Sin embargo, las cosas fueron empeorando con el tiempo, por lo que tuvieron que bloquear un montón de subredes, lo que también ha afectado a muchos usuarios reales. En un momento dado, Kevin decidió, desesperado, prohibir a todo el país de Brasil para que las cosas volvieran a funcionar; según tengo entendido, esta prohibición sigue vigente, y no está tan claro dónde se podría encontrar una solución a largo plazo.
Y, como señala Neal Gompa, incluso bloquear un país entero solo te lleva hasta cierto punto, y aparentemente la infraestructura de Fedora ha estado «regularmente inactiva durante semanas» debido a los rastreadores de IA.
Otro proyecto que se ha visto afectado por este problema en la última semana es Inkscape. Según Martin Owens, no se trata de «los habituales ataques DDoS chinos del año pasado, sino de un montón de empresas que empezaron a ignorar nuestra conf spider y a falsificar la información de su navegador. Ahora tengo una lista de bloqueo de Prodigius. Si trabajas para una gran empresa que se dedica a la IA, es posible que ya no puedas acceder a nuestro sitio web».
Y, bueno, Martin no es el único desarrollador que ha creado una «lista de bloqueo prodigiosa». Incluso BigGrizzly, de Frama Software, se vio desbordado por un rastreador LLM malicioso y creó una lista de 460 000 IP con agentes de usuario falsos para prohibir; se ofrece a compartir la lista.
Otro intento más exhaustivo es el proyecto «ai.robots.txt», una lista abierta de rastreadores web asociados a empresas de IA. Ofrecen un archivo robots.txt que implementa el Protocolo de Exclusión de Robots y un archivo .htaccess que devolverá una página de error al recibir una solicitud de cualquier rastreador de IA de su lista.
Podemos obtener más cifras sobre los rastreadores si retrocedemos unos meses. Aquí hay un artículo de Dennis Schubert sobre la infraestructura de Diaspora (una red social descentralizada de código abierto), donde dice que «mirar los registros de tráfico le enfadó muchísimo».
En la entrada del blog, afirma que una cuarta parte de todo su tráfico web se debe a bots con un agente de usuario OpenAI, el 15 % se debe a Amazon, el 4,3 % se debe a Anthropic, etc. En total, estamos hablando de que el 70 % de todas las solicitudes proceden de empresas de IA.
Según él,
no se limitan a rastrear una página una vez y luego seguir adelante. Oh, no, vuelven cada 6 horas porque, jaja, ¿por qué no? Tampoco les importan una mierda los
robots.txt, porque ¿por qué deberían? […] Si intentas limitar su tasa, simplemente cambiarán a otras IP todo el tiempo. Si intentas bloquearlos por cadena de agente de usuario, simplemente cambiarán a una cadena de agente de usuario que no sea de bot (no, en serio). Esto es literalmente un DDoS en todo Internet.
El proyecto Read the Docs ofrece una cifra similar. En una entrada de blog titulada «Los rastreadores de IA deben ser más respetuosos», afirman que el bloqueo inmediato de todos los rastreadores de IA redujo su tráfico en un 75 %, pasando de 800 GB/día a 200 GB/día. Esto hizo que el proyecto ahorrara alrededor de 1500 dólares al mes.
El resto del artículo también es bastante impresionante; hablan de rastreadores que descargan decenas de terabytes de datos en unos pocos días, o más. Es difícil bloquearlos por completo, ya que utilizan varias IP diferentes.
Me pregunto cuánto de esto es rastreo para datos de entrenamiento y cuánto es en cambio la función de «búsqueda» que proporcionan la mayoría de los LLM; no obstante, según Schubert, los rastreadores «normales» como los de Google y Bing solo suman una fracción de un solo punto porcentual, lo que sugiere que otras empresas sí están abusando de sus poderes web.
Pero no se trata solo de recopiladores, o habría titulado este artículo «Recopiladores de IA», no «Empresas de IA». Otro problema con el que ha estado luchando la comunidad de código abierto son los informes de errores generados por la IA, por ejemplo.
Esto fue notificado por primera vez por Daniel Stenberg del proyecto Curl, en una entrada de blog titulada «La I en LLM significa Inteligencia». Curl ofrece un proyecto de recompensas por errores, pero últimamente se han dado cuenta de que muchos informes de errores son generados por IA. Estos parecen creíbles y requieren mucho tiempo de los desarrolladores para comprobarlos, pero también contienen las típicas alucinaciones que cabría esperar de las IA.
Es una locura tener que revisar tu propio código porque un informe de error te dice con seguridad que hay que solucionar un problema de seguridad crítico y… no encontrarlo, porque todo el asunto es solo una alucinación de la IA.
Seth Larson, que forma parte del equipo de clasificación de informes de seguridad de CPython, pip, urllib3, Requests y otros, informó de un asunto similar. Dice:
Recientemente he notado un aumento en los informes de seguridad de muy baja calidad, spam y alucinaciones de LLM a proyectos de código abierto. El problema está en la era de los LLM, estos informes parecen a primera vista potencialmente legítimos y, por lo tanto, requieren tiempo para refutarlos.
Este es un problema bastante considerable. Como señala, responder a los informes de seguridad es caro, y responder a informes de errores inventados pero creíbles supone una carga adicional significativa para los mantenedores, lo que podría expulsarlos del mundo del código abierto.
El artículo termina con una petición: por favor, no utilicen sistemas de IA o LLM para detectar vulnerabilidades. Dice: «Estos sistemas actuales no pueden entender el código, encontrar vulnerabilidades de seguridad requiere entender el código Y comprender conceptos a nivel humano como la intención, el uso común y el contexto».
Una vez más, quiero señalar que estas cuestiones afectan de manera desproporcionada al mundo del software libre; los proyectos de código abierto no solo suelen tener menos recursos en comparación con los productos comerciales, sino que, al ser proyectos impulsados por la comunidad, gran parte de su infraestructura es pública y, por tanto, susceptible tanto a los rastreadores como a los informes de errores o problemas generados por la inteligencia artificial.
——————-