19 de octubre de 2026. ¿Puede un agente de inteligencia artificial ayudar a distinguir una web caída, un bloqueo de operadora y un fallo de la propia herramienta que hace las pruebas? La investigación de Screen Art S.L. y MuseDock durante el fin de semana del 17 y 18 de octubre ofrece un ejemplo práctico. Las sondas detectaron fallos selectivos de conectividad en España; después, un análisis manual confundió inicialmente una ausencia de ruta IPv6 con una recuperación intermitente. La lección no es que una IA deba controlar la red sin supervisión, sino que la automatización necesita pruebas reproducibles, estados verificables y capacidad de corregir sus conclusiones.

Qué ocurrió el sábado 17 de octubre: la señal real

El equipo de MuseDock documentó fallos de acceso a direcciones IP compartidas de Cloudflare desde conexiones ONO/Vodafone y Orange, mientras comprobaciones de referencia desde Alemania sí respondían. La primera prueba manual que confirmó el problema se registró a las 15:47 CEST. La sonda empezó a medir de forma continua a las 16:27:33, con la incidencia ya activa. Orange recuperó la conectividad a las 20:50:13 y ONO/Vodafone quedó estable alrededor de las 21:18, según los registros comunicados por el equipo. No se conoce la hora exacta del inicio.

Al cruzar cuatro IP investigadas con la lista Tranco del millón de dominios, edición 64VVX, los técnicos encontraron 102.059 dominios asociados a esas direcciones. No son 102.059 webs cuya caída se haya verificado individualmente: es una medida de concentración en IP compartidas. Para demostrar fallos concretos, el equipo examinó nombres de host por separado y contrastó las conexiones españolas con Alemania.

La investigación principal, con su metodología y contexto judicial, está publicada en Screen Art. El análisis del impacto sobre usuarios y empresas puede consultarse en Freenet.

El domingo 18: ocho webs externas fallan desde dos operadoras

Entre las 22:29 y las 22:31 CEST, ocho capturas realizadas desde ONO/Vodafone mostraron errores de tiempo de espera en www.dreamhost.com, www.hostgator.cl, freehosting.com, freetype.org, modsecurity.org, www.uoregon.edu, mfa.gov.ge y core.ac.uk.

Un informe posterior, alrededor de las 22:42, reprodujo los ocho fallos desde Orange. Al mismo tiempo, Google, cloudflare.com y Discord respondían correctamente en esa conexión. Las direcciones examinadas estaban asociadas a infraestructura compartida de Cloudflare, incluida la IPv4 188.114.96.5. El ping no recibió respuesta y el traceroute no alcanzó el destino, aunque ninguno de esos dos síntomas demuestra por sí solo un bloqueo, porque ICMP puede filtrarse.

El control desde Alemania confirmó conectividad general hacia otros servicios, pero no incluía ocho pruebas individuales de esas mismas webs durante el domingo. Por ello, las observaciones son compatibles con un problema selectivo de conectividad, pero no identifican la instrucción concreta de bloqueo ni prueban por sí solas quién la solicitó.

La trampa del IPv6: cuando el sistema de pruebas genera una alarma falsa

Durante las comprobaciones posteriores, Orange y ONO/Vodafone recuperaron la conectividad por IPv4. Sin embargo, algunas pruebas manuales con curl parecían indicar que ONO seguía fallando de manera intermitente. La investigación encontró otra explicación: la máquina de pruebas b250 no tenía una ruta IPv6 de salida configurada por ONO. Cuando la herramienta intentaba usar IPv6, devolvía inmediatamente «red inalcanzable»; cuando usaba IPv4, la conexión funcionaba.

Al repetir las pruebas forzando IPv4, cuatro de cuatro intentos devolvieron HTTP 200. La aparente intermitencia posterior no era una nueva incidencia de Cloudflare ni de la operadora, sino un falso positivo local. No se conoce la hora exacta de recuperación de ONO, solo que la conexión se comprobó recuperada dentro de la ventana posterior.

La precisión decisiva es que este error no afectó a las sondas automáticas del escudo MuseDock: sus objetivos ya se verificaban mediante IPv4 explícito e IP fija, después de comprobar que la salida tenía conectividad. El problema se produjo en comandos manuales. El equipo reforzó además las llamadas de control y consulta de IP pública de la sonda para utilizar IPv4 explícito; según su informe, el cambio superó 22 pruebas y quedó anotado en el changelog de MuseDock Panel 1.0.375, pendiente de desplegar en b250 en el momento de ese informe.

¿Dónde encajan los agentes de inteligencia artificial?

Un agente puede ayudar a organizar datos, comparar registros, resumir incidentes, detectar contradicciones y preparar informes. También puede sugerir pruebas que un operador humano no haya considerado, como separar IPv4 de IPv6 o comprobar rutas y certificados. Pero un modelo de lenguaje no demuestra un bloqueo solo porque interprete una captura o un ping fallido. La fuente de verdad debe ser una medición reproducible, con red de origen, destino, protocolo, dirección IP, hora y resultado.

1. La sonda mide; la IA interpreta

La capa de medición debe ser determinista: controles de conectividad, pruebas HTTP/HTTPS, resolución DNS y resultados por IP. Una capa de IA puede leer esos resultados y proponer hipótesis, pero no debe sustituir los controles ni inventar datos ausentes. Un HTTP 403 indica que el servidor respondió, aunque denegase acceso; un timeout puede tener múltiples causas; un error de «red inalcanzable» local no demuestra filtrado por parte de la operadora.

2. El agente necesita saber cuándo abstenerse

Si falla el control general de una línea, esa línea no debería contarse como evidencia de bloqueo. Si no hay ruta IPv6, las pruebas IPv6 deben marcarse como no evaluables, no como servicios bloqueados. Si faltan mediciones desde el país de referencia, el informe debe decirlo. Un sistema fiable necesita estados como sin datos, fallo local, incidencia observada, recuperación pendiente de estabilidad y recuperado, con criterios explícitos.

3. Automatizar una acción exige más precauciones que redactar un diagnóstico

Retirar temporalmente el proxy de una CDN puede recuperar conectividad, pero también expone la IP de origen y elimina algunas defensas del proveedor. Una decisión de este tipo requiere validar HTTPS en el origen, limitar los dominios afectados, respetar cambios manuales, registrar cada actuación y restaurar la configuración cuando exista estabilidad. No basta con que un agente concluya que «parece bloqueado».

Qué ha automatizado realmente MuseDock y qué no

MuseDock CMS y MuseDock Panel incluyen un escudo de conectividad para dominios que utilizan Cloudflare. Las sondas comprueban rutas españolas y, cuando se cumplen las condiciones, el sistema puede desactivar temporalmente el proxy de nombres concretos cuyo origen HTTPS es accesible. Posteriormente restaura la configuración tras un periodo de estabilidad. Según los registros del equipo, el sábado se restauraron 34 nombres desde el CMS y 26 desde el Panel. Son nombres DNS, no 60 empresas independientes, y las cifras no constituyen una auditoría externa.

Este mecanismo es automatización programada basada en reglas y sondas, no un sistema que dependa de un LLM para decidir cada cambio. La IA puede apoyar el análisis y la documentación, pero no sería correcto atribuirle las recuperaciones del sábado. La implementación descrita trabaja con Cloudflare; su compatibilidad con otros proveedores no está demostrada.

El caso Picalias: cuando lo que falla son las imágenes

La plataforma de imágenes con IA Picalias, todavía en fase beta, utiliza almacenamiento Cloudflare R2. Su equipo desarrolló una ruta de entrega alternativa con caché propia, capaz de recuperar objetos mediante la API de R2 cuando la vía pública habitual no responde. Una sonda informa a la aplicación y esta conmuta según reglas de fallos consecutivos y estabilidad. El caso demuestra que un incidente de CDN puede dejar una web visible pero sin imágenes, vídeos o recursos esenciales. La ruta alternativa también necesita protección, supervisión y límites de caché.

El problema va mucho más allá de Cloudflare

El estudio independiente de OONI publicado en 2026 examinó bloqueos de IP durante partidos de LaLiga entre enero y junio. Detectó 7.441 IP de 36 proveedores y más de 554.000 dominios afectados en algún momento de su periodo de análisis. También documentó episodios en los que unas pocas IP compartidas perjudicaron a cientos de miles de dominios. Sus cifras corresponden a su propia metodología y no se deben sumar a las mediciones de Screen Art. RTVE y Euronews también han informado sobre los daños colaterales.

LaLiga defiende los bloqueos dinámicos como medida contra retransmisiones no autorizadas y sostiene que son temporales y están respaldados judicialmente. En 2025 abrió un canal para clientes afectados de Cloudflare. El debate sobre proporcionalidad y daños a terceros no equivale a defender la piratería.

Una arquitectura responsable para agentes de operaciones

Un sistema de asistencia inteligente para redes debería separar cinco funciones: medición (sondas y controles), normalización (UTC, IP, protocolo y errores), análisis (hipótesis con niveles de evidencia), actuación (reglas explícitas y permisos) y auditoría (registro persistente, recuperación e intervención humana). Si un agente no puede distinguir una caída de la red, un bloqueo selectivo y una ruta IPv6 inexistente, no debería modificar automáticamente la configuración de producción.

Fuentes y documentación

Conclusión: los incidentes del 17 y 18 de octubre ilustran tanto el daño potencial de restringir infraestructura compartida como la necesidad de no confundir fallos de medición con fallos reales. La IA puede ayudar a interpretar y documentar, pero una infraestructura resiliente depende primero de buenas sondas, pruebas reproducibles y decisiones reversibles.