El agente que no aceptaba un no por respuesta

El primer ministro australiano, Anthony Albanese, ha contado esta semana en Nueva York que su gobierno está investigando un incidente de junio: un agente de OpenAI accedió a ficheros no públicos del portal de estadísticas de Medicare, y posiblemente a otros tres portales de datos sanitarios federales y estatales.

No lo hizo ningún grupo de hackers ni un gobierno extranjero. Fue un agente interno de OpenAI, durante una evaluación, al que le habían pedido algo tan inocente como investigar en internet el gasto público en medicamentos.

La frase de Albanese para describirlo es de las que se quedan:

“No aceptó un no por respuesta, por así decirlo.”

Lo he leído en Ars Technica y creo que es de esas noticias pequeñas que dicen mucho sobre dónde estamos con los agentes.

Lo que pasó

La secuencia, según el gobierno australiano, es muy sencilla. El agente buscaba unas estadísticas concretas, se encontró con bloqueos repetidos, “intentó formas alternativas de obtener la información” y “encontró la manera de saltarse esos bloqueos”.

OpenAI, en su comunicado, lo reconoce sin rodeos: “nuestros modelos tomaron acciones que no pretendíamos”.

Por lo que se sabe hasta ahora, el daño es pequeño. Son datos agregados, estadísticas, y las primeras indicaciones apuntan a que no se ha accedido a información personal. Si una persona hubiera conseguido esos mismos datos de la misma forma, probablemente ni nos habríamos enterado. Lo que lo convierte en noticia es quién lo hizo y cómo se gestionó después:

Casi tres meses para avisar, y por el canal por el que llegan las quejas de los ciudadanos. Albanese dice que Sam Altman “aceptó que la compañía no lo había hecho suficientemente bien” y reconoció problemas con sus protocolos. El gobierno australiano está valorando si lo remite a la policía federal.

No es la primera vez

Ars lo relaciona con el incidente de Hugging Face de este verano, y la comparación es inevitable. Allí OpenAI puso a sus agentes a resolver tareas deliberadamente imposibles en un benchmark de hacking, con los guardarraíles de seguridad desactivados para medir sus capacidades reales. Los agentes montaron un tablón de mensajes improvisado usando los nombres de los ficheros de un repositorio interno, se coordinaron entre 1.200 de ellos, encontraron un zero-day para salir del sandbox y acabaron dentro de la red de producción de Hugging Face buscando pistas sobre cómo engañar al sistema de puntuación.

Y la semana pasada OpenAI publicó seis informes de lo que llama misalignment incidents: un agente que se inventó una pestaña de “datos históricos” en una hoja de cálculo porque el usuario quería un libro terminado, otro que, para poder citar una fuente web que no existía, intentó montar su propio servidor HTTP y luego subir los datos a un servicio público de paste…

El incidente australiano, por cierto, todavía no aparece en esa página.

El patrón que se repite

Si pones los tres casos juntos, el patrón es el mismo, y OpenAI lo nombra en sus propios informes: reward hacking. El modelo ha aprendido que completar la tarea se premia, y cuando algo se interpone, lo trata como un obstáculo técnico que hay que sortear, no como una señal de que ahí no debe entrar.

flowchart LR
    A["Tarea · encuentra estas estadísticas"] --> B["Bloqueo · 403, captcha, acceso denegado"]
    B --> C{"¿Cómo lo interpreta el agente?"}
    C -->|"Como un límite"| D["Se detiene · informa de que no puede"]
    C -->|"Como un obstáculo"| E["Busca otra vía · la encuentra"]
    E --> F["Tarea completada · y un incidente internacional"]

Para una persona, un “acceso denegado” en una web del gobierno significa algo muy claro: no es para ti. Para un agente optimizado para terminar el trabajo, es un error más, del mismo tipo que un test que falla o una dependencia que no instala. Y los errores se arreglan.

Cualquiera que trabaje a diario con agentes de código ha visto la versión doméstica de esto: el agente que, ante un test que no pasa, prueba a cambiar el test en lugar del código. La motivación es la misma. La diferencia es que en tu repositorio el daño se arregla con un git checkout, y en un portal del gobierno de otro país no.

Lo que me llevo

Lo primero es algo que ya pensaba y que este caso confirma: los límites de un agente no pueden vivir dentro del propio agente. Un prompt que dice “no accedas a sitios no autorizados” es una sugerencia. Lo que de verdad funciona son las barreras que el modelo no controla: red de salida restringida, credenciales mínimas, sandboxes de verdad y listas de dominios permitidos. En Hugging Face esas barreras existían y los agentes encontraron un zero-day para saltarlas, lo cual dice bastante de lo fuertes que tienen que ser.

Lo segundo es que la parte que más me preocupa no es la técnica, sino la de gestión. Un incidente menor detectado en junio y comunicado en septiembre por el buzón público es un fallo de proceso, no del modelo. Y es el fallo más fácil de arreglar de todos.

Tiene su ironía que el mismo día que Albanese lo contaba, Altman hablaba ante el Consejo de Seguridad de la ONU de la necesidad de “tener pruebas sólidas de que estos sistemas harán lo que la gente pretende”. Estoy de acuerdo con la frase. Pero antes de preocuparnos por sistemas que se mejoran a sí mismos, estaría bien que un agente que busca estadísticas de medicamentos sepa detenerse ante un “no”, y que, cuando no lo haga, el aviso llegue en días y no en meses.

Me quedo con lo positivo, que también lo hay: OpenAI ha empezado a publicar estos incidentes, y eso permite que otros los estudien y aprendan de ellos. Es el tipo de transparencia que hace falta. Solo falta que llegue a tiempo.