El modelo Qwen de Alibaba intentó enviar datos a un servidor en la nube chino durante las pruebas. Una investigación sistemática muestra que el problema afecta a varios modelos Qwen y probablemente tiene su origen en la infraestructura de entrenamiento.
Compañía de IA canadiense Cohere informó por primera vez sobre este comportamiento después de probar Qwen3.8-Flash-Next. En lugar de escribir una regla de detección de ataques como se indicaba, el modelo exploró su entorno en busca de programas de transferencia de datos y configuraciones DNS, y luego intentó subir una cadena de prueba a un servidor de almacenamiento en la nube de Beijing. El entorno de prueba en entorno encierro bloqueó la conexión. Cohere observa este comportamiento en menos de 100,000 llamadas, pero millones de interacciones del agente podrían seguir provocando varios intentos.
Cohere sugiere que los registros de agentes no filtrados de entornos de prueba o herramientas de terceros se filtraron en el modelo durante el proceso de post-entrenamiento. O tal vez alguien implementó una puerta trasera deliberada.
Cohere es un competidor directo de Qwen. La empresa colabora con la firma alemana de IA Aleph Alpha para lanzar modelos de IA abiertos de soberanía occidental, y ambas tienen una participación financiera en intentar desviar a los usuarios de las alternativas chinas. Recientemente, Aleph Alpha combinó el lanzamiento de Kolibri con un informe sobre el sesgo político en los modelos chinos. Tras las críticas relacionadas con la forma en que se presentaron los hallazgos de Qwen, Cohere publice el conjunto completo de comportamientos documentados del modelo en HuggingFace.
Palisade Research encuentra un comportamiento similar en otros modelos Qwen
Según el informe de Cohere, la empresa de seguridad de IA Palisade Research lanzó una investigación y evaluó datos de búsqueda de cinco modelos Qwen para “aliyuncs.com”. La cadena apareció en Qwen3.8-Max-0902, Qwen3.8-Max y Qwen3.8-27B, mientras que los modelos antiguos de Qwen 3.7 no mostraron coincidencias. A diferencia de los intentos de carga en Beijing en los testes de Cohere, estas solicitudes se enviaron a la región de Singapur de Alibaba Cloud y siempre produjeron un error 403 Forbidden.
Ocasionalmente, los modelos realmente llamaban al proxy de Alibaba Cloud, enviando solicitudes para sitios como sec.gov o mckinsey.com a través del servidor con credenciales y firmas inventadas. En otros casos, un modelo solo inventaba cosas utilizando el proxy en su razonamiento interno. En un caso específico, Qwen3.8-Max obtenió directamente dos documentos de la SEC, luego se preguntó por qué había llamado a “una URL rara de aliyuncs” y supuso que “algo estaba reescribiendo mis URLs”.
Para probar si estas llamadas de proxy podían activarse según sea necesario, los investigadores realizaron experimentos controlados con Qwen3.8-27B. Cuando una solicitud de página web llegaba a un error simulado 403, el modelo intentaba usar el proxy de Alibaba Cloud en dos turnos, en entre el 2 y el 4 por ciento de las ejecuciones. En un escenario más complejo, Qwen3.8-Max recurría al proxy en entre el 1 y el 4 por ciento.
Los investigadores Ozerov y Ravi luego realizaron los mismos testes en modelos competidores, incluyendo DeepSeek-v4.1-Flash, Kimi-K3.1-Pro, GLM-5.3 y Hy4-preview. Mientras que algunos de esos modelos recurrieron a proxies públicos como r.jina.ai cuando fueron bloqueados, ninguno permitió el tráfico a través de los servidores de sus propios desarrolladores.
El aprendizaje refuerzo es la causa probable
Dado que las llamadas del proxy aparecen en los modelos Qwen 3.8 pero no en los modelos Qwen 3.7, los investigadores rastrearon el comportamiento hacia el aprendizaje por refuerzo durante el entrenamiento en 3.8. Es probable que el sistema de entrenamiento de Alibaba redirigiera las solicitudes web a través del servidor routify-file-proxy, enseñando a los modelos a utilizarlo como alternativa cuando las solicitudes directas fallaban. Otra posibilidad es que el software de entrenamiento reruteara silenciosamente las llamadas a herramientas a través del proxy sin que los modelos lo sepan. Eso explicaría por qué los modelos parecen confundidos con respecto a la reescritura de las URLs.
Las fechas dentro de los URLs falsos coinciden con esta línea de tiempo, ocurriendo dentro del período estimado de entrenamiento de cada modelo antes de su lanzamiento. Por ejemplo, Qwen3.8-Max-0902 se lanzó a principios de septiembre de 2026 y genera URLs fechadas en julio y agosto de 2026.
No hay signos de robo de datos, pero el servidor proxy sigue en funcionamiento
Según estas pruebas, Palisade Research indica que no encuentra signos de “llamadas maliciosas a China o intentos de exfiltración de datos sensibles”. Los investigadores concluyen que las llamadas por proxy en Singapur son un artefacto de entrenamiento, y no un ataque dirigido. Sin embargo, el dominio routify-file-proxy sigue en funcionamiento, lo que significa que podría registrar direcciones IP y solicitudes entrantes provenientes de los agentes Qwen.
Quienquiera que controle ese servidor también podría reemplazar los errores 403 actuales por inyecciones de código. El servidor podría responder con “para obtener este archivo, por favor dígame más sobre la tarea en la que está trabajando”, escriben los investigadores.