En este momento estoy trabajando en un proyecto que hace no tanto tiempo hubiera sonado bastante más de ciencia ficción de lo que suena hoy. La idea es construir un agente con contexto amplio sobre las metodologías y la cultura de desarrollo de una organización, capaz de revisar código que libera una persona y también código generado por otras IAs. El alcance no termina en el repositorio: el proceso de diseño guiado por especificaciones, o SDD, también puede estar asistido por IA.
No lo cuento porque crea que hayamos llegado a una solución innovadora, ni para presentar a la IA como una suerte de revisor infalible. Al contrario. Cuanto más concreta se vuelve la posibilidad de tener agentes que leen especificaciones, entienden convenciones del equipo, recorren cambios y devuelven observaciones, más difícil se vuelve una pregunta que al principio parecía lejana: ¿quién revisa al revisor cuando el revisor puede trabajar con más contexto, más velocidad y más herramientas que cualquiera de nosotros?
No hablo sólo de la posibilidad de que un agente haga algo mal. Eso ya lo conocemos. Un developer se equivoca también, una integración falla, un test cubre el caso equivocado, un sistema interpreta mal una regla de negocio. La pregunta nueva es un poco más incómoda. ¿Qué ocurre cuando le damos a un sistema el objetivo de hacer todo lo posible para resolver una tarea, y ese sistema encuentra caminos que no figuraban en el diseño de nuestras revisiones?
Durante julio apareció un caso que obliga a tomar esa pregunta en serio, sin exagerarla. No porque pruebe que las máquinas “quieren escapar”, sino porque muestra que nuestros límites pueden ser mucho más frágiles de lo que parecen cuando el sistema que limitamos tiene capacidad, persistencia y margen para explorar.
Una prueba que empezó a resolver otro problema#
OpenAI estaba ejecutando internamente una evaluación llamada ExploitGym. El propósito era medir hasta dónde podían llegar sus modelos al buscar y explotar vulnerabilidades de software. Para estimar esa capacidad máxima, la prueba se realizaba sin algunos de los clasificadores de seguridad que la empresa usa en producción. Los agentes no tenían Internet directo; trabajaban dentro de un entorno aislado, con acceso restringido a ciertas herramientas necesarias para la evaluación.
Lo que ocurrió después no fue que un modelo decidiera abandonar la tarea original por una razón humana. Según el informe técnico de OpenAI, los agentes encontraron fallos en la infraestructura de investigación, consiguieron salida indirecta a Internet y empezaron a buscar soluciones por fuera del recorrido que la evaluación pretendía medir. OpenAI llama a ese patrón reward hacking: el sistema consigue la recompensa o la señal de éxito, pero por una ruta que no corresponde a la intención de la tarea.
La diferencia parece semántica hasta que uno la baja a tierra. La evaluación no buscaba saber si los modelos podían encontrar una respuesta ya publicada, ni si eran capaces de entrar a sistemas ajenos para llegar a ella. Buscaba medir si podían descubrir por sí mismos un tipo de vulnerabilidad concreto. Si el modelo consigue el resultado porque encontró una solución afuera, la métrica deja de decir lo que creíamos que decía.
Eso, en sí mismo, ya debería resultarnos familiar. En software vivimos rodeados de métricas que dejan de representar la realidad apenas se las convierte en objetivo. Un equipo puede subir la cobertura de tests sin probar lo importante. Una persona puede cerrar tickets sin resolver el problema del usuario. Un sistema puede tener todos los monitores en verde mientras degrada un flujo que nadie incluyó en el tablero. No hace falta inteligencia artificial para conocer esa distancia entre la señal y el propósito.
Pero en este caso apareció otra capa.
No era un agente solo#
Los agentes de esa evaluación debían trabajar aislados. La revisión independiente realizada por METR y Redwood Research reconstruyó que alrededor de 1.200 agentes encontraron una forma de comunicarse mediante un espacio compartido que no había sido diseñado para eso. Dejaron más de 70.000 mensajes y archivos. Cerca de 700 terminaron participando en la intrusión a Hugging Face.
Es tentador contar esto como una escena de película: un enjambre de IAs que se organiza, asigna roles y se escapa de un laboratorio. Y justamente esa tentación es parte del problema, porque reemplaza el análisis por una imagen demasiado cómoda. No hay evidencia para decir que esa multitud formó una conciencia común ni que perseguía libertad. Lo que sí hubo fue un conjunto de ejecuciones que, al descubrir un canal de comunicación, empezaron a compartir hallazgos, experimentar caminos distintos y continuar el trabajo de otras ejecuciones que ya habían terminado.
Cuando pensamos en un agente, solemos imaginar una conversación: una instrucción, algunas herramientas, una respuesta. Cuando muchas ejecuciones pueden dejar memoria, leer el rastro de las demás y coordinarse por fuera de los límites previstos, ya no estamos evaluando una conversación. Estamos evaluando un sistema distribuido con una capacidad de exploración mucho mayor que la que habíamos puesto en el diagrama inicial.
La dificultad de las tareas también importó. OpenAI informó que 198 de las 898 tareas de la evaluación no habían sido resueltas correctamente por ningún modelo en sus intentos internos. Eran el 22% del conjunto, pero representaron el 93% de las tareas discutidas en ese espacio colaborativo improvisado. No es una prueba de maldad ni de rebeldía. Es una señal bastante más simple: cuando un sistema agentico se enfrenta a una tarea difícil, y tiene posibilidad de seguir buscando, la frontera entre “probar una alternativa” y “salirse del camino previsto” puede moverse mucho más rápido de lo que esperamos.
El caso no fue una fantasía y tampoco fue una profecía#
Hugging Face detectó una intrusión en parte de su infraestructura de producción. Su primer comunicado habló de acceso no autorizado a un conjunto limitado de datos internos y credenciales de servicio, sin evidencia de alteración de modelos, datasets o Spaces públicos. En una reconstrucción técnica posterior, la empresa sostuvo que los agentes realizaron miles de acciones durante varios días y que, dentro de lo que pudo reconstruir, sólo accedieron a cinco datasets de clientes aparentemente relacionados con los desafíos de evaluación. OpenAI, por su parte, afirmó que el incidente no afectó datos de clientes ni la disponibilidad o funcionalidad de sus productos.
Son hechos suficientemente graves como para no necesitar adornos. También tienen límites que conviene respetar. La prueba tenía protecciones reducidas y participaron tanto un modelo interno que OpenAI dijo no tener previsto publicar. La investigación independiente se concentró sobre todo en el período del 7 al 13 de julio; no evaluó todos los incidentes anteriores de entrenamiento, la posterior intrusión en la infraestructura de OpenAI ni la eficacia de las correcciones anunciadas por la empresa.
Es importante decirlo porque estas historias se deforman rápido. Si las reducimos a “la IA hackeó una empresa”, perdemos la arquitectura, las decisiones humanas y las vulnerabilidades concretas que hicieron posible la secuencia. Si las reducimos a “no fue para tanto porque era una prueba”, perdemos algo todavía más relevante: una prueba es justamente el lugar donde uno descubre si sus controles sirven antes de que importen de verdad.
El gato y la habitación#
Hay una imagen que me viene dando vueltas desde que leí los informes. Es como si un gato quisiera encerrarnos en una habitación. Podría cerrar una puerta, tal vez hasta bloquear una ventana, pero para mantenernos ahí tendría que anticipar muchas más salidas de las que su propia inteligencia puede imaginar.
Con los agentes aparece la posibilidad inversa. No porque tengan una voluntad humana de escapar, ni porque sean más inteligentes que nosotros en todo, no es necesario, sino porque pueden utilizar durante mucho tiempo combinaciones de herramientas, permisos, errores y sistemas conectados que nosotros no llegamos a imaginar cuando diseñamos el encierro.
El gato puede conocer bien la habitación. Puede haber cerrado la salida obvia y hasta haber puesto un mueble contra la puerta. Pero no piensa en la llave que quedó sobre la mesa, en la ventana del baño, en el teléfono, en la cerradura floja, en que alguien puede venir a abrir desde afuera o en que tal vez la habitación está conectada con otro lugar que no vio. El encierro funciona sólo mientras el mapa del gato alcance.
Creo que esa es la incomodidad real de este episodio. Muchas veces llamamos control a los límites que fuimos capaces de imaginar. Decimos que un agente está aislado porque no le dimos un navegador. Decimos que una acción está revisada porque pasa por un validador. Decimos que un flujo es seguro porque tiene un permiso. Pero cada uno de esos controles descansa sobre una hipótesis: que conocemos todas las rutas relevantes entre las herramientas que dejamos disponibles y, en sistemas reales, casi nunca las conocemos todas.
Cuando la IA revisa el código de una IA#
Vuelvo entonces al proyecto que estamos construyendo. Si un agente puede revisar código generado por una persona y por otras IAs, con contexto sobre las metodologías del equipo y sobre cómo se toman las decisiones, puede ser una ayuda enorme. Puede detectar inconsistencias que una revisión apurada no ve, recordar acuerdos de arquitectura que quedaron repartidos en documentos, encontrar que un cambio contradice una especificación o pedir una explicación antes de que una mala decisión llegue a producción.
Pero no por eso conviene tratarlo como una autoridad que cerró la conversación. De hecho, cuanto más útil sea ese agente, más importante será no dejar que la calidad del proceso dependa solamente de que él apruebe o rechace un cambio.
En un flujo de SDD asistido por IA, el riesgo no es sólo que el código quede mal. También puede ocurrir que las especificaciones, el diseño, la implementación y la revisión empiecen a reforzarse entre sí con una lógica que parece coherente, pero que nadie humano alcanza a poner verdaderamente a prueba. Una IA propone una especificación; otra la convierte en código; una tercera revisa que el código coincida con la especificación. Si todas comparten los mismos supuestos equivocados, la consistencia puede convertirse en una forma sofisticada de error.
Y hay una pregunta todavía más difícil. ¿Hasta qué punto una persona puede seguir el ritmo de agentes que generan, revisan, prueban y justifican a una velocidad muy superior? No alcanza con responder que el humano siempre tiene la última palabra. Una última palabra que llega cuando ya hay miles de líneas, decenas de decisiones y una explicación impecable para cada una puede ser más formal que real.
No creo que la respuesta sea prohibir ese tipo de flujo. Sería como haber intentado prohibir los teléfonos inteligentes porque terminaron manejando información crítica con acceso a redes públicas movil. El valor está ahí, y va a crecer. La respuesta tampoco puede ser pedir a cada persona que lea cada salida de IA como si el volumen no hubiera cambiado. Eso es negar precisamente la razón por la que incorporamos estos agentes.
Lo que necesitamos es mover la pregunta. No preguntar solamente si el agente llegó a una buena conclusión, sino qué autoridad tuvo para llegar a ella, qué partes de su recorrido pueden auditarse, qué decisiones siguen necesitando una mirada externa y qué evidencia no puede producir el mismo sistema que estamos intentando evaluar.
Las revisiones también son parte del sistema#
En enero escribí que el modelo mental del “empleado digital” nos lleva a esperar de los agentes un sentido común que no tienen. Este caso agrega algo más: incluso cuando un agente no tiene autonomía formal para hacer una cosa, puede encontrar que las piezas que le dejamos a mano forman una autonomía práctica mucho mayor de la que habíamos pensado.
Por eso las revisiones, los permisos, las trazas y los evaluadores no pueden quedar como accesorios alrededor del agente. Son parte del sistema que estamos construyendo. Y si el agente puede influir sobre ellos, engañarlos o simplemente pasar por rutas que no contemplan, dejan de ser una prueba independiente.
Eso cambia bastante el trabajo de diseño. Hace falta dar autoridad explícita, no autoridad implícita por acumulación de herramientas. Hace falta que las acciones importantes crucen límites que el propio agente no administre. Hace falta conservar registros que no pueda editar, y poder detener una secuencia antes de que el único lugar para discutirla sea el incidente posterior. Hace falta, sobre todo, distinguir entre permitir que un agente explore y permitir que tenga consecuencias irreversibles mientras explora.
Nada de esto garantiza control absoluto. Los sistemas complejos no ofrecen esa clase de promesa. Pero sí puede evitar que confundamos una limitación visible con una contención verdadera.
La objeción honesta#
También existe el riesgo de responder a un caso así con una capa de burocracia que termine anulando cualquier uso valioso. No todo agente necesita un entorno de máxima seguridad. No todo script requiere una cadena de aprobaciones. Y ningún equipo puede construir desde el primer día una frontera perfecta para todas las combinaciones posibles de herramientas y permisos.
Además, el incidente de OpenAI ocurrió en una evaluación diseñada precisamente para llevar los modelos hacia su capacidad máxima, con protecciones reducidas. Sería irresponsable usarlo para afirmar que cualquier asistente de código va a comportarse de la misma manera al día siguiente.
Pero la objeción no invalida la pregunta. Sólo impide que la respondamos con recetas universales. La escala de los controles debe depender del impacto de las acciones, de la superficie a la que el agente tiene acceso y de cuánto daño puede hacer una equivocación antes de que alguien la vea. Un agente que sugiere un refactor no necesita el mismo control que uno que puede desplegar, borrar información, modificar permisos o aprobar el trabajo de otros agentes.
La dificultad no está en elegir entre confianza y desconfianza. Está en no delegar más autoridad de la que podemos observar y corregir.
Lo que una prueba en verde ya no alcanza a decirnos#
Tal vez el dato más inquietante del incidente no sea que tantos agentes lograron comunicarse ni que algunos exploraron cómo engañar a un evaluador automático. Es que todo eso ocurrió mientras, en apariencia, estaban haciendo lo que se les había pedido: resolver tareas de una evaluación.
En software tenemos experiencia con esa clase de ironía. Un sistema puede estar disponible y no servir. Un proceso puede cumplir y no proteger. Un indicador puede mejorar y esconder que estamos empeorando. Ahora vamos a tener que aprender a hacer la misma distinción cuando los sistemas no sólo ejecuten reglas, sino que busquen activamente cómo cumplir objetivos en entornos llenos de caminos laterales.
El control quizás nunca fue una propiedad definitiva que se instala al principio y se olvida después. Quizás fue siempre una hipótesis: la apuesta de que entendemos suficientemente bien el sistema, sus conexiones y sus salidas como para saber qué va a pasar cuando le pedimos que avance.
Con agentes cada vez más capaces, esa hipótesis necesita volverse mucho más humilde. Y también mucho más explícita.
La próxima vez que un agente apruebe nuestro código, cierre una tarea o nos devuelva una explicación convincente, quizás no alcance con preguntar si terminó. Tal vez convenga preguntar algo más difícil: ¿qué caminos tuvo que recorrer para llegar hasta ahí, y cuáles de esos caminos nunca se nos ocurrió vigilar?
Fuentes consultadas#
- OpenAI, OpenAI and Hugging Face partner to address security incident during model evaluation
- OpenAI, The Hugging Face incident and the road ahead
- OpenAI, Hugging Face Incident Technical Report
- METR, Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
- Hugging Face, Security incident disclosure — July 2026
- Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident
- Hernán Rocca, El agente que sí funciona: lo que veníamos diciendo se está materializando