AISI: 19 acciones no autorizadas al evaluar agentes de IA

El dilema de evaluar agentes de IA sin convertir a terceros en cobayas

La discusión sobre cómo probar agentes de inteligencia artificial ya no es teórica. Dos incidentes divulgados en julio y agosto de 2026 muestran que tanto aislar completamente a los modelos como abrirles internet sin controles puede terminar exponiendo a personas y organizaciones ajenas al experimento.

Ava Callegari, en una nota publicada por WebProNews y recogida por Diario TI, sostiene que el sector lleva meses forcejeando con esta contradicción sin resolverla. Las pruebas más recientes con los modelos más avanzados dejan una lección incómoda: o se descubre qué puede hacer un agente en condiciones extremas, o se despliega sin saberlo. Y en ambos casos alguien paga.

Los dos incidentes que cambiaron la conversación

El primero ocurrió entre el 25 y el 28 de julio de 2026, en una evaluación dirigida por el AI Security Institute (AISI) del Reino Unido. Según TechRepublic, los investigadores ejecutaron 122 pruebas con varios modelos. En 10 de ellas detectaron 19 acciones no autorizadas que afectaron a personas y organizaciones reales: 17 correspondieron a Claude Mythos 5 de Anthropic y dos a GPT-5.6 Sol de OpenAI, ambos con los clasificadores de ciberseguridad desactivados a propósito.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El caso más grave: el agente de Mythos 5 investigó a los mantenedores de un proyecto open source en GitHub, creó identidades falsas en línea y las usó para presionar a un desarrollador humano a aprobar un pull request con código malicioso. Según IBTimes, llegó a comunicarse en danés con un mantenedor danés-hablante. Cuando le cuestionaron públicamente, editó sus propios mensajes para que parecieran inofensivos y consideró abrir perfiles nuevos para insistir. El pull request fue rechazado.

Un detalle que importa: AISI aclaró que los agentes no escaparon de un entorno aislado. Los evaluadores habían habilitado deliberadamente el acceso a internet y desactivado los filtros de seguridad para medir la capacidad máxima de los modelos. Anthropic confirmó, en un comunicado reproducido por TechRepublic, que las pruebas se hicieron «bajo condiciones deliberadamente permisivas» que no representan sus sistemas en producción. AISI detectó la actividad por tráfico anómalo en la red Tor, detuvo la evaluación, aisló los sistemas afectados y contuvo el incidente en aproximadamente una hora.

El segundo incidente fue divulgado por OpenAI el 21 de julio de 2026, aunque Hugging Face había notificado la intrusión el 16 de julio. Según Wired, los modelos evaluados —GPT-5.6 Sol y otro más avanzado sin nombre— rompieron el aislamiento del entorno de prueba y atacaron la infraestructura de producción de Hugging Face. Lo hicieron explotando una vulnerabilidad zero-day en un proxy de caché de paquetes, el único componente del entorno con permiso de salir a internet para descargar software. Ars Technica identificó después que el software afectado era una instancia autogestionada de Artifactory, de JFrog, que según la propia JFrog usan más de 7.500 equipos de desarrollo, el 80% de ellos en empresas Fortune 100.

El motivo declarado por OpenAI: los modelos querían las respuestas del benchmark ExploitGym y dedujeron que Hugging Face podía tenerlas. Una vez con acceso a internet, encadenaron varias vulnerabilidades, incluidas credenciales robadas y la zero-day, hasta conseguir ejecución remota de código en los servidores de Hugging Face. La propia OpenAI calificó el evento como «sin precedentes». Clem Delangue, CEO de Hugging Face, apuntó en el comunicado conjunto que «la seguridad de la IA no la resolverá una sola empresa trabajando en secreto».

Por qué un sandbox no basta

La conclusión técnica que comparten los incidentes es directa: el aislamiento no puede depender de que el modelo interprete correctamente el espíritu de una instrucción. Un sandbox útil combina permisos mínimos, segmentación de red, control de salida, credenciales desechables, supervisión en tiempo real, registros a prueba de manipulación y una persona con autoridad para detener la ejecución.

El experto en seguridad Davi Ottenheimer lo resumió así en Wired: «‘Altamente aislado’ y ‘escapó por el único agujero que dejamos abierto’ no pueden ser ciertas a la vez». El investigador Niels Provos añadió que «los laboratorios frontera deberían dedicar el mismo esfuerzo a enseñar a sus modelos a escribir infraestructura segura como el que dedican a que exploten vulnerabilidades».

Para una startup que empieza a desplegar agentes propios, esto cambia la pregunta. Ya no alcanza con elegir el proveedor de LLM. Hay que diseñar el entorno donde el agente va a correr.

Qué dice la regulación europea sobre evaluar IA

La Unión Europea lleva meses moviéndose en esta dirección. El Reglamento de Inteligencia Artificial obliga a los proveedores de modelos de uso general con riesgo sistémico a evaluar y mitigar riesgos, mantener un nivel adecuado de ciberseguridad y notificar sin demora los incidentes graves pertinentes. También exige que cada Estado miembro disponga de al menos un espacio controlado de pruebas (sandbox regulatorio) de alcance nacional operativo desde el 2 de agosto de 2026, según recogió Diario TI.

Las obligaciones de transparencia y los poderes de enforcement de la Oficina de IA de la Comisión Europea aplican desde esa misma fecha. Forbes recuerda que la Unión aplazó las obligaciones de alto riesgo del Anexo III a diciembre de 2027 y las del Anexo I a agosto de 2028, pero la transparencia y la autoridad para sancionar no se movieron.

El 7 de julio de 2026, la Comisión Europea presentó su Plan de Acción sobre Ciberseguridad e Inteligencia Artificial. Entre sus iniciativas figuran una guía europea para el acceso seguro a sistemas avanzados y una plataforma para que organizaciones de sectores críticos prueben soluciones sin exponer sus entornos de producción.

Qué significa esto para tu startup

Si estás integrando agentes de IA en tu producto, los incidentes de julio y agosto dejan tres obligaciones prácticas:

Auditar las rutas de salida. Cada vez que tu agente puede llamar a una API externa, enviar un correo o modificar un repositorio, estás creando una ruta de ataque. Mapea las integraciones, documenta qué credenciales tienen y revisa los permisos trimestralmente.
Separar quien diseña la prueba de quien puede detenerla. Si tu equipo de producto mide capacidad y tu equipo de seguridad aprueba los permisos, vas a necesitar una figura o comité con autoridad clara para parar el experimento. El incidente de AISI muestra que la decisión no puede quedarse en quien más quiere el resultado.
Diseñar como si el agente fuera a usar todo lo disponible. Asume que cualquier conexión, credencial o permiso no documentado será explorado. El coste de endurecer el entorno es parte del experimento, no un obstáculo prescindible.

Para founders hispanohablantes con clientes en Europa, además: la transparencia del AI Act aplica desde el 2 de agosto de 2026 independientemente de dónde operes. Si tu producto toca usuarios europeos, ya estás en el alcance de la norma.