Internet no está habitado solo por usuarios, plataformas y modelos de inteligencia artificial. También está lleno de procesos mínimos que siguen trabajando en segundo plano: bots de mantenimiento, avisadores de errores, vigilantes de canales, scripts que limpian enlaces, automatismos que cierran reportes, cuentas que publican cambios de software, pequeños programas que alguna vez alguien configuró y que después quedaron integrados a la rutina de la red.
No todos son peligrosos. Algunos son útiles. Otros son tiernos. Otros son infraestructura. Pero todos plantean una pregunta cada vez más importante: ¿quién responde por un bot cuando el contexto humano que lo creó ya cambió, desapareció o dejó de mirarlo?
Durante años, la conversación pública sobre bots se concentró en spam, propaganda, fraude o manipulación. Pero hay otra historia más discreta: la de los bots que mantienen funcionando pedazos de internet. Bots que no quieren convencer a nadie, sino archivar enlaces, avisar que una compilación falló, registrar reuniones, responder comandos, cerrar issues abandonados o proteger canales antiguos. El problema no es que todos sean maliciosos. El problema es que muchos operan en zonas donde la responsabilidad humana se vuelve difusa.
Uno de los casos más claros es InternetArchiveBot, un bot de Wikimedia que identifica enlaces rotos, agrega versiones archivadas y monitorea enlaces externos. Su propia documentación señala que corre en más de 300 wikis de Wikimedia; otra página del proyecto indica que monitorea todos los wikis de Wikimedia para nuevos enlaces salientes y hace correcciones activas en más de 400 wikis. Es difícil imaginar una metáfora más precisa: un bot dedicado a reparar la memoria rota de internet.
Otro caso es ClueBot NG, el bot antivandalismo de Wikipedia. No es nuevo ni marginal: fue diseñado para detectar y revertir vandalismo casi en tiempo real, y un estudio académico sobre control de calidad en Wikipedia analizó qué ocurría cuando el bot estaba caído. Según ese estudio, el tiempo medio para revertir vandalismo aumentaba cuando ClueBot NG no estaba operando. Es decir: cuando el bot falta, la comunidad humana siente el hueco.
La capa más vieja y curiosa está en IRC. Eggdrop, creado en diciembre de 1993, se presenta todavía como el bot de IRC más antiguo en desarrollo activo. Nació para ayudar a administrar y proteger un canal, pero terminó convirtiéndose en una pieza extensible de cultura técnica: un bot que puede permanecer conectado, responder comandos, administrar usuarios y sostener presencia en canales. Su importancia no está solo en que sea viejo, sino en que muestra una función original de muchos bots: no publicar, sino quedarse.
Esa lógica sigue viva en comunidades técnicas. Ubottu, por ejemplo, continúa descrito como un bot presente en varios canales de Ubuntu en Libera.Chat, con una base de datos de respuestas y funciones asociadas a bugs y canales de soporte. No es una IA conversacional moderna; es algo más modesto y quizá más interesante: una memoria comunitaria automatizada.
Debian también conserva este tipo de automatización. El bot de #debian-devel-changes, basado en Supybot, vive en un canal de IRC y emite bugs abiertos, cargas aceptadas y bugs cerrados del proyecto Debian. Es un caso precioso porque no “conversa” para simular humanidad: traduce actividad de backend, paquetes, bugs, cambios, en una presencia visible dentro de una comunidad técnica.
En el mundo de desarrollo de software, esta frontera entre bot, backend y comunidad se vuelve todavía más borrosa. Buildbot, una herramienta de integración continua, incluye un bot de IRC que se conecta a canales para anunciar eventos de compilación, responder consultas de estado e incluso recibir comandos. Su documentación advierte que, dependiendo de la configuración, usuarios con acceso al canal o al bot podrían iniciar o detener builds, lo que muestra que estos automatismos no solo informan: también pueden ejecutar acciones.
Jenkins tiene una historia parecida. Su plugin de IRC permite enviar notificaciones de compilación e interactuar con Jenkins mediante un bot; también hay documentación de CloudBees explicando que el bot puede recibir comandos para programar builds. Ahí el bot ya no es una curiosidad cultural: es una interfaz operativa hacia infraestructura de software.
Y luego está el caso más contemporáneo: los bots de mantenimiento en GitHub. Probot Stale, una app diseñada para cerrar issues y pull requests abandonados, aparece hoy marcada como deprecada y sin mantenimiento; la recomendación es usar Stale Action. Pero su ficha todavía existe, y hay proyectos que han discutido migrar porque el bot podía marcar o cerrar issues de forma indeseada. Aquí el bot no fue olvidado por completo, pero muestra otro problema: automatismos que fueron adoptados por muchos repositorios y después entran en una zona de transición, deprecación o reemplazo.
La categoría nueva no es el bot viejo que quedó vivo por accidente, sino el bot abandonable: automatismos que se crean rápido, se copian de un template, se conectan a repositorios, canales, calendarios, tickets, despliegues o wikis, y luego permanecen porque nadie quiere tocar algo que todavía funciona. En ese sentido, Dependabot y Renovate representan la versión institucionalizada de una práctica ya normal: bots que abren pull requests, actualizan dependencias y operan sobre cadenas de suministro de software. Renovate se define como una herramienta automatizada para actualizar dependencias mediante pull requests, mientras GitHub documenta Dependabot como un sistema que abre PRs para actualizaciones de dependencias y seguridad.
La pregunta no es si esos bots son buenos o malos. Muchos son indispensables. La pregunta es si existe una cultura equivalente de inventario, auditoría y retiro. Porque cada bot implica una cadena mínima de poder: credenciales, permisos, comandos, canales, archivos, repositorios, APIs o capacidad de escribir en algún lugar. Mientras alguien lo entiende, es una herramienta. Cuando nadie lo recuerda, empieza a parecerse a una ruina operativa.
Por eso, antes de imaginar a la IA como una fuerza que conquistará internet desde cero, quizá conviene mirar otra posibilidad menos espectacular y más probable: que los nuevos agentes encuentren una red ya llena de automatismos previos. Bots de archivo, bots de soporte, bots de compilación, bots de cierre automático, bots de canales, bots de paquetes, bots de vigilancia, bots de infraestructura. Algunos vivos, otros deprecados, otros migrados, otros apenas documentados.
Internet no solo acumula páginas abandonadas. También acumula procesos obedientes.
El problema no es que los bots quieran quedarse. Es que internet está diseñado para no preguntar demasiado mientras algo siga funcionando. Y en una época en la que nuevas IAs podrán conectarse a herramientas, repositorios, calendarios, gestores de contenido, correo, servidores y APIs, esa capa vieja de automatización merece una revisión urgente.
