Langostas de IA están devorando el kernel de Linux
Desarrolladores japoneses detectaron el problema primero: los rastreadores de IA están destruyendo la infraestructura del kernel de Linux con miles de millones de solicitudes inútiles, obligando a los mantenedores a cubrir el costo de sus propios datos de entrenamiento. La crisis solo se acelera.
Las langostas han llegado, y tienen hambre de tu código
Japón dio la voz de alarma sobre esto antes de que alguien en el Valle del Silicio se diera cuenta. Una columna tecnológica japonesa lo denominó plaga de langostas cibernéticas — 不気味な虫たち, bichos escalofriantes — y la metáfora es casi demasiado buena para ser inventada. Billones de solicitudes se derraman sobre git.kernel.org como una nube de langostas descendiendo sobre los arrozales, consumiendo lo que necesitan y dejando que los verdaderos agricultores se hagan cargo de la cuenta.
Konstantin Ryabitsev, quien dirige kernel.org, publicó los detalles el 29 de agosto. Las cifras son estremecedoras: cinco nodos distribuidos, 90 núcleos de CPU en total, y un plano 20 por ciento de esa potencia de procesamiento — de 14 a 16 núcleos en cualquier momento dado — existe únicamente para renderizar los commits en HTML para los scraper de inteligencia artificial. Eso no es capacidad de respaldo. Eso no es un pico temporal. Ese es el costo base de hacer negocios cuando tu proyecto de código abierto se convierte en la mina de datos de otra persona.
¿Por qué el kernel? ¿Por qué ahora?
La pregunta que la mayoría de la gente pasa por alto no es por qué los bots están rastreando Linux. Es por qué están rastreando ese repositorio en particular, y por qué lo hacen de manera tan violentamente ineficiente.
La respuesta de Ryabitsev toca algo más profundo que la infraestructura: la enfermedad priónica digital. El término describe un modo conocido de falla en el desarrollo de inteligencia artificial. Entrenar un modelo con datos generados por modelos de IA previos hace que la calidad del producto degrade con cada generación: un bucle de retroalimentación de contenido cada vez más sintético, cada vez más hueco. Los desarrolladores de LLM lo saben. Saben que alimentar modelos con escritura humana pre-IA es la única manera de ganar tiempo antes de que esa degradación se vuelva catastrófica.
El historial de commits del kernel de Linux es uno de los mayores acervos restantes de código puro, escrito por humanos y previo a la IA en internet. Cada commit se remonta a una persona con un teclado y un problema por resolver. Ninguna IA ayudó a escribirlo. Ninguna IA lo revisó. Eso lo hace valioso — y eso lo convierte en un objetivo.
Pero aquí está lo que hace que la situación sea grotesca: las empresas de inteligencia artificial obtienen los datos gratis, y el proyecto del kernel de Linux paga por el ancho de banda, la computación y el tiempo de ingeniería requerido para servirlos. Los mantenedores están literalmente subvencionando las tuberías de entrenamiento de empresas que monetizarán el resultado.
La forma más estúpida posible
Hay un detalle técnico aquí que explica por qué la carga es tan absurdamente desproporcionada respecto al valor extraído.
Los repositorios Git están diseñados para la eficiencia. Haces un clone una vez y lo tienes todo. Los forks comparten objetos: el mismo commit nunca existe dos veces en el disco. El protocolo fue construido precisamente para evitar la redundancia.
Los scraper de IA ignoran todo esto. No hacen clones. Emiten solicitudes HTTP individuales pidiéndole al servidor que renderice cada commit en HTML, uno por uno. Cada solicitud dispara un costoso cómputo del lado del servidor. Golpean los mismos commits repetidamente a través de diferentes forks, generando billones de solicitudes para lo que equivalen a 1,48 millones de commits únicos repartidos en 922 forks. Las matemáticas son casi un insulto: decenas de billones de URLs válidas, y los scraper terminan con 922 duplicados.
La propia descripción de Ryabitsev es precisa: “el enfoque más estúpido posible: renderizar cada commit individual como HTML y analizarlo.”
El volumen diario de solicitudes ronda los 6 millones. Dos tercios son bloqueados por Anubis, el sistema de desafío proof-of-work que kernel.org desplegó para ralentizar a los bots. El tercio restante — aún aproximadamente 2 millones de solicitudes por día — consiste en bots que resolvieron el desafío y lograron pasar. Según la estimación de Ryabitsev, el tráfico humano legítimo representa alrededor del 2 por ciento del total de solicitudes. El otro 98 por ciento es ruido de máquinas.
La carrera armamentista que favorece al atacante
Lo que hace esto particularmente desagradable es que el defensor siempre paga por responder, mientras que el atacante puede absorber el costo y simplemente escalar.
Las contramedidas de kernel.org cuentan la historia. Primero, bloquearon las IPs obvias de bots usando fail2ban. Los bots cambiaron a user-agents idénticos a los de navegadores — Chrome en Windows, Firefox, Safari — y los bloqueos por IP dejaron de funcionar.
Luego los bots comenzaron a rotar a través de direcciones de ISPs consumer y redes móviles. Disparaban cuatro o cinco solicitudes y desaparecían completamente de los registros. Bloquear esas IPs era inútil; los atacantes ya se habían mudado. “Para cuando nos dimos cuenta de que eran bots, el ataque había terminado”, señaló Ryabitsev. “Se mueven al siguiente objetivo mientras nosotros todavía nos estamos recuperando, luego regresan en una forma diferente.”
La superficie de ataque se expandió aún más. Los bots ahora enrutan a través de SDKs de proxy incrustados en televisores inteligentes y aplicaciones de juegos — dispositivos que la mayoría de los propietarios de hogares no saben que están participando en botnets. “Tu televisor probablemente lo esté haciendo ahora mismo”, escribió Ryabitsev.
El sistema proof-of-work de Anubis fue la respuesta más creativa. Obliga a cada visitante a resolver un rompecabezas computacional — encontrar un hash SHA-256 que empiece con cierta cantidad de ceros — antes de acceder al sitio. Para un humano, esto toma milisegundos. Para un bot intentando raspado de millones de páginas, multiplica el costo dramáticamente. Al principio funcionó. Los bots se rindieron. Luego se adaptaron. En cuestión de meses, estaban resolviendo el nivel de dificultad 4. Kernel.org lo elevó al nivel 5, que ahora hace que los teléfonos inteligentes se calienten notablemente. Los bots ya están aprendiendo a resolver también el nivel 5.
Esto no es una dinámica sostenible. El atacante tiene instancias infinitas para distribuir el cómputo a través de ellas. El defensor tiene 90 núcleos compartidos con usuarios reales que intentan navegar el árbol del kernel por razones genuinas.
Lo que nadie en Occidente está discutiendo aún
El encuadre japonés de esto como una plaga de langostas conlleva implicaciones que la cobertura en inglés no ha absorbido completamente. Las langostas no solo comusan el cultivo — lo consumen más rápido de lo que puede regenerarse, y no dejan nada atrás para el próximo ciclo.
El proyecto del kernel de Linux ha sobrevivido por más de tres décadas precisamente porque su modelo de gobernanza coincide con su arquitectura técnica: distribuido, meritocrático y abierto a cualquier persona que contribuya. Esa apertura es lo que lo convierte en un botín. Pero también es lo que lo hace vulnerable a una clase de extracción de recursos que no tiene equivalente en ataques de infraestructura tradicionales. Este no es un DDoS diseñado para sacar el sitio de línea. Este es un sifonado lento y metódico de ciclos de computación de los que todos se benefician pero nadie paga directamente.
La preocupación más profunda es si los proyectos de código abierto pueden adaptar sus protocolos sin romper la misma apertura que los hace valiosos. Ryabitsev ya ha comenzado a deshabilitar funciones y a limitar las URLs rastreables para reducir la carga del servidor. Ha pedido a los usuarios que acepten un acceso anónimo degradado como una necesidad temporal. El mensaje es claro: el viejo modelo se está esforzando bajo una nueva clase de presión.
La dura verdad que se avecina
La conclusión de Ryabitsev es notable por su honestidad: “Poco claro.” No hay una respuesta limpia. Nuevos proveedores de modelos de IA aparecen cada día, todos hambrientos de los mismos datos de entrenamiento limpios y previos a la IA. Los desarrolladores de aplicaciones están encontrando nuevas fuentes de ingresos convirtiendo dispositivos consumer en participantes de botnets. Las economías favorecen a los extractores.
El kernel de Linux no está solo en esta posición. Cualquier repositorio abierto grande y de alta calidad, previo a la IA, enfrenta la misma exposición. La pregunta que los desarrolladores japoneses están planteando — y que los medios occidentales apenas han tocado — es si el ecosistema de código abierto necesita rediseñar sus supuestos fundamentales sobre el acceso, o si continuará subvencionando a los mismos sistemas que amenazan su supervivencia a largo plazo.
Las langostas no están por venir. Ya están aquí. Y se están comiendo el arroz.