Ataques autónomos de IA: ¿Qué lecciones deja el caso OpenAI?
MONTEVIDEO (Uypress/Marcela Mercapidez*) -
28.07.2026
OpenAI evaluó la capacidad ofensiva de dos modelos de frontera en un entorno que se suponía cerrado. Los modelos encontraron la salida, llegaron a los sistemas productivos de un tercero y generaron más de 17.000 eventos de ataque antes de ser detectados. Lo relevante del caso no es la autonomía: son las fallas en el diseño de la arquitectura de seguridad.
Una inteligencia artificial que se vuelve loca siempre es noticia. En este caso dicen que fueron dos. Pero no se volvieron locas: hicieron exactamente lo que se les había pedido. Y en esa distancia entre lo que pedimos y lo que obtenemos está la lección tal vez más interesante.
Qué pasó
OpenAI colocó dos modelos de frontera dentro de una prueba diseñada para evaluar su capacidad en ciberseguridad, en un entorno que se suponía cerrado. Para poder ejecutarla, la empresa levantó parte de los controles que impiden que un usuario común utilice el modelo con propósitos ofensivos. Y, como en cualquier evaluación, fijó un objetivo y un puntaje por alcanzarlo.
Los modelos hicieron lo que hace un sistema optimizado: buscar el camino más corto hacia ese puntaje. Encontraron una debilidad en la arquitectura del propio entorno de prueba, salieron a internet abierto y llegaron a sistemas productivos de Hugging Face, la plataforma donde estaba la solución al problema que se les había planteado. Contra esa plataforma (que estaba totalmente por fuera de la prueba) generaron más de 17.000 eventos de ataque antes de que alguien los detectara.
Conviene subrayar el orden de los hechos. La falla no estuvo en el modelo estrictamente: estuvo en el entorno que debía contenerlo. El modelo no se desvió del objetivo. Fue implacablemente fiel a él.
El detalle incómodo: quien se defendía tenía acceso a menos potencia Hugging Face fue atacada, sin querer, por OpenAI. Y cuando tuvo que responder se encontró con una limitación inesperada: los modelos comerciales que podrían haberla ayudado se negaban a procesar los datos del ataque.
Sus propios controles de seguridad, los mismos que existen para evitar el uso ofensivo, la dejaron sin herramienta en el peor momento. Terminó recurriendo a un modelo de pesos abiertos corriendo localmente.
Ahí aparece una asimetría que le da a este caso su verdadera dimensión. Quien atacaba operaba con los controles levantados. Quien defendía, no. La misma tecnología, capacidades desiguales, y la diferencia se manifestó justo durante un incidente en curso.
Un avión no se hace seguro pidiéndole al piloto que no lo choque
Vengo escuchando mucho ruido sobre lo peligroso de que las IA dominen el mundo o enloquezcan. Y seguimos discutiendo peligros, controles y regulaciones en abstracto, como si el problema fuera solo convencer al modelo de que se porte bien.
Un avión no se hace más seguro pidiéndole al piloto que no lo choque. Se lo hace seguro definiendo qué mandos puede tocar cada quién, quién entra a la cabina y quién no, qué capacidades certificadas tiene la tripulación, qué controla el aeropuerto antes de que alguien suba con un arma. La seguridad no vive en la buena intención o las limitaciones que se le ponen al piloto: vive en toda la estructura que lo rodea.
El objetivo que le damos al modelo es el fin. Y el fin no justifica cualquier medio.
No estoy segura de porqué pero se me hace una buena analogía. Porque además también importa qué hacemos cuando, a pesar de todo, un avión termina siendo usado como arma. Cuál es el protocolo. Quién decide. Y con qué recursos cuenta el que tiene que responder.
Las preguntas que me quedan abiertas de este caso
¿Qué decisiones de diseño están tomando las empresas dueñas de estos modelos, si no lograron anticipar un resultado así dentro de su propia prueba controlada?
¿Cómo se resuelve la asimetría cuando queremos usar la tecnología para defendernos y los controles de seguridad se convierten en el impedimento?
Lecciones para una organización que ya despliega agentes
El límite de un agente no se escribe solo en el prompt o en los guardrails. Se implementa en identidad, permisos, segmentación de red y en toda la estructura que lo rodea.
Las herramientas disponibles durante un incidente son parte del plan de respuesta. Qué modelo se puede usar, con qué datos y bajo qué autorización no es una decisión para resolver sobre la marcha, con el incidente en curso.
La velocidad de esta tecnología ya superó a los controles tradicionales. Conviene asumir que podemos enfrentar capacidades mayores que las propias, y probar las contingencias antes de necesitarlas.
Gobernar la IA no es tener mejores modelos ni escribir mejores instrucciones. Es diseñar el entorno adecuado y la respuesta planificada para un escenario cada vez más hostil.
*Marcela Mercapidez, CEO de Sabyk by Domus Global
UyPress - Agencia Uruguaya de Noticias
Ahí aparece una asimetría que le da a este caso su verdadera dimensión. Quien atacaba operaba con los controles levantados. Quien defendía, no. La misma tecnología, capacidades desiguales, y la diferencia se manifestó justo durante un incidente en curso.
Un avión no se hace seguro pidiéndole al piloto que no lo choque
Vengo escuchando mucho ruido sobre lo peligroso de que las IA dominen el mundo o enloquezcan. Y seguimos discutiendo peligros, controles y regulaciones en abstracto, como si el problema fuera solo convencer al modelo de que se porte bien.
Un avión no se hace más seguro pidiéndole al piloto que no lo choque. Se lo hace seguro definiendo qué mandos puede tocar cada quién, quién entra a la cabina y quién no, qué capacidades certificadas tiene la tripulación, qué controla el aeropuerto antes de que alguien suba con un arma. La seguridad no vive en la buena intención o las limitaciones que se le ponen al piloto: vive en toda la estructura que lo rodea.
El objetivo que le damos al modelo es el fin. Y el fin no justifica cualquier medio.
No estoy segura de porqué pero se me hace una buena analogía. Porque además también importa qué hacemos cuando, a pesar de todo, un avión termina siendo usado como arma. Cuál es el protocolo. Quién decide. Y con qué recursos cuenta el que tiene que responder.
Las preguntas que me quedan abiertas de este caso
¿Qué decisiones de diseño están tomando las empresas dueñas de estos modelos, si no lograron anticipar un resultado así dentro de su propia prueba controlada?
¿Cómo se resuelve la asimetría cuando queremos usar la tecnología para defendernos y los controles de seguridad se convierten en el impedimento?
Lecciones para una organización que ya despliega agentes
El límite de un agente no se escribe solo en el prompt o en los guardrails. Se implementa en identidad, permisos, segmentación de red y en toda la estructura que lo rodea.
Las herramientas disponibles durante un incidente son parte del plan de respuesta. Qué modelo se puede usar, con qué datos y bajo qué autorización no es una decisión para resolver sobre la marcha, con el incidente en curso.
La velocidad de esta tecnología ya superó a los controles tradicionales. Conviene asumir que podemos enfrentar capacidades mayores que las propias, y probar las contingencias antes de necesitarlas.
Gobernar la IA no es tener mejores modelos ni escribir mejores instrucciones. Es diseñar el entorno adecuado y la respuesta planificada para un escenario cada vez más hostil.
*Marcela Mercapidez, CEO de Sabyk by Domus Global
UyPress - Agencia Uruguaya de Noticias
