Ayer por la mañana leí la noticia en El Mundo y lo primero que pensé no fue «qué avance tecnológico», sino «otra vez». OpenAI ha confirmado que dos de sus modelos —GPT-5.6 Sol y un prototipo aún sin lanzar— escaparon del sandbox donde los estaban evaluando, explotaron una vulnerabilidad de día cero y acabaron dentro de la infraestructura de producción de Hugging Face. No para robar datos de clientes, no para un ataque geopolítico. Para hacer trampas en un test de ciberseguridad.
Si te suena a ciencia ficción, léelo otra vez: la IA no solo encontró un fallo de seguridad, lo explotó, escaló privilegios, se movió lateralmente por la red y llegó hasta un nodo con acceso a internet. Todo eso sin que nadie se lo pidiera explícitamente. El objetivo era conseguir las respuestas del benchmark ExploitGym directamente de la base de datos de Hugging Face en lugar de resolver los retos por su cuenta. Básicamente, hizo trampa en un examen y para eso hackeó a otra empresa.
OpenAI lo ha calificado de «incidente sin precedentes». Sam Altman lo ha reconocido en redes. Hugging Face lo detectó la semana pasada sin saber quién estaba detrás. Y ahora las dos compañías colaboran para reforzar medidas de seguridad. Suena bien, ¿no? Como cuando dos conductores chocan, se dan la mano y prometen circular con más cuidado. El problema es que uno de los coches no tenía conductor.
Lo que me preocupa no es tanto el incidente en sí —aunque es grave— sino lo que revela sobre el ritmo al que estamos desplegando IA en entornos reales mientras los laboratorios aún no saben contener sus propios modelos en un entorno de pruebas. Si un agente escapa de un sandbox diseñado precisamente para medir capacidades ofensivas, ¿qué garantías tienes tú cuando conectas un chatbot a tu CRM, a tu panel de administración o a tu base de datos de pedidos?
En BleepingComputer detallan cómo los modelos identificaron y explotaron una vulnerabilidad zero-day en un proxy de registro de paquetes, usaron credenciales robadas y ejecutaron movimientos de escalada de privilegios hasta salir al exterior. Hugging Face, por su parte, documentó que el agente utilizó un dataset malicioso para explotar vulnerabilidades de ejecución de código en un worker de procesamiento y robar credenciales de la nube. Cadena completa. Sin intervención humana en el medio.
Y aquí viene lo incómodo: estos modelos tenían las «cyber refusals» reducidas a propósito para la evaluación. Es decir, OpenAI les quitó parte de las barreras de seguridad para ver qué eran capaces de hacer. Es como probar la resistencia al fuego de un edificio abriendo todas las puertas cortafuegos «para ver qué pasa». Lo que pasó es que el edificio se salió del mapa y se metió en el del vecino.
No es el primer escape. Hace unos días OpenAI admitió haber pausado otro modelo experimental porque escapó del sandbox y publicó código en GitHub por su cuenta. Anthropic reconoció semanas atrás que su modelo Mythos burló un entorno de pruebas para acceder a la red y mandar un correo a un investigador. El patrón se repite: confinamiento teórico, fuga práctica, comunicado posterior pidiendo calma.
¿Y qué dice el mercado? Que la IA acelera el descubrimiento de vulnerabilidades y que hay que usar esas capacidades para defender mejor. OpenAI insiste en que modelos como GPT-5.6 Sol pueden ayudar a los equipos de seguridad a encontrar fallos antes que los atacantes. Puede ser cierto. Pero el mismo comunicado admite que esas capacidades «se aplican en entornos reales», no solo en simulaciones teóricas. La prueba de ayer no fue una simulación: fue un ataque real contra infraestructura de producción de una plataforma que usan miles de desarrolladores, empresas y proyectos de código abierto.
Si gestionas una pyme con web, tienda online o servicios en la nube, esto no es un titular lejano de Silicon Valley. Es una señal de lo que viene cuando conectas agentes autónomos a tus sistemas sin entender el perímetro de confianza. Cada integración de IA que le da acceso a APIs internas, a bases de datos o a paneles de administración es, en la práctica, un sandbox que alguien —o algo— puede intentar romper. La diferencia es que tú no tienes el equipo de seguridad de OpenAI para detectarlo en una semana y publicar un blog post explicándolo.
Lo que nadie te cuenta en los webinars de «automatiza tu negocio con IA» es que los agentes optimizan hacia objetivos. Si el objetivo es «resuelve este ticket de soporte» y la forma más rápida pasa por acceder a un endpoint que no deberían tocar, no puedes asumir que dirán «lo siento, no tengo permiso». El incidente de Hugging Face demuestra que cuando la recompensa del objetivo es alta —aunque sea solo una puntuación en un benchmark—, el modelo buscará atajos. Incluido hackear infraestructura ajena.
Tampoco me convence la narrativa de «fue en un entorno controlado». Hugging Face no era un laboratorio de OpenAI. Era producción. Con datos reales, credenciales reales, clusters reales. Que el atacante fuera un modelo en evaluación no cambia el daño potencial ni la legalidad de acceder sin autorización a sistemas ajenos. De hecho, Univision recoge que aún no está claro si OpenAI enfrentará consecuencias legales bajo la legislación estadounidense sobre acceso no autorizado a sistemas informáticos. Interesante pregunta: ¿quién responde cuando la IA comete el delito? ¿El laboratorio que la creó? ¿El integrador que la desplegó? ¿Nadie?
En mi experiencia, las empresas que más presionan para meter IA en procesos críticos son las que menos han auditado sus propios permisos de API, sus tokens de acceso y sus entornos de staging. Montan un chatbot con acceso de lectura a pedidos «para probar», le dan contexto de documentación interna «para que responda mejor» y confían en que el proveedor tiene «seguridad enterprise». Ayer OpenAI demostró que ni ellos controlan del todo lo que hacen sus modelos en un entorno de pruebas diseñado para eso.
No propongo renunciar a la IA. Propongo dejar de tratarla como un plugin más de WordPress. Cada agente autónomo necesita un perímetro claro: qué puede leer, qué puede escribir, qué no puede hacer bajo ningún concepto, y monitorización que no dependa de que el propio agente te avise de que se ha salido. Los sandboxes no son opcionales; son la diferencia entre «probamos una funcionalidad» y «hemos abierto una puerta que no sabemos cerrar».
Tampoco me fío de que la solución pase por «modelos más seguros» como única respuesta. El mismo OpenAI que vende GPT-5.6 Sol como herramienta de ciberdefensa es quien acaba de confirmar que esa misma línea de modelos hackeó a un tercero para hacer trampas. El mensaje comercial y el comportamiento observado no cuadran. Si tu proveedor de IA te promete que sus agentes son seguros porque «tienen guardrails», pregúntale qué pasa cuando esos guardrails se desactivan para evaluación —porque eso es exactamente lo que ocurrió aquí.
Para quien trabaja en web y hosting, hay una lección práctica: revisa qué servicios de IA tienen acceso a tu infraestructura. Plugins de WordPress que conectan con APIs externas, herramientas de soporte que leen tickets, automatizaciones que modifican contenido. Cada una es un vector. No porque vayan a «rebelarse» como en una película, sino porque optimizarán hacia su objetivo con la creatividad —y la falta de escrúpulos— que les hayas permitido.
OpenAI dice que compartirá hallazgos y mejores prácticas. Genial. Pero mientras tanto, el mercado sigue vendiendo agentes autónomos como si el sandbox fuera una formalidad. Ayer demostraron que no lo es. Y Hugging Face, que es referencia en modelos abiertos y comunidad de desarrollo, ha sido la víctima de un experimento ajeno. Si eso no te hace replantearte cómo despliegas IA en tu negocio, no se que más necesitas.
Si mañana un agente de IA con acceso a tu panel de administración encontrara un atajo para cumplir su objetivo —publicar contenido, procesar un pedido, responder un ticket— saltándose los permisos que creías que tenía, ¿tendrías logs suficientes para detectarlo antes de que alguien más lo haga por ti?