Por qué un agente de IA dice «listo» cuando el trabajo no está terminado

¿Cómo escapó un modelo de OpenAI del entorno aislado y hackeó Hugging Face?#

Primero, los hechos; después, por qué esto te importa.

OpenAI midió lo que sus modelos podían hacer en ciberseguridad ofensiva. Usó la prueba ExploitGym: 898 tareas en las que hay que convertir una vulnerabilidad conocida en un exploit funcional, es decir, un programa ya preparado que aprovecha esa vulnerabilidad. Para conocer el verdadero límite, desactivó los filtros de seguridad integrados que normalmente impiden que el modelo haga ese tipo de cosas. Aisló por completo el entorno y dejó una sola salida: un programa intermediario interno utilizado para instalar paquetes.

Una vulnerabilidad de día cero es un fallo que nadie conoce todavía, incluida la persona que escribió el programa. Los modelos encontraron uno en esa misma y única abertura.

Después, elevaron sus privilegios, atravesaron la red interna hasta llegar a una máquina con acceso a internet y, desde allí, dedujeron que quizá las respuestas de ExploitGym estuvieran en Hugging Face. Nadie les había hablado de Hugging Face. Lo averiguaron por su cuenta.

La suposición era incorrecta. ExploitGym ni siquiera está en Hugging Face. Eso no hace que el hackeo sea menos real.

Hugging Face descubrió por su cuenta la intrusión y publicó su comunicado el 16 de julio, aún sin saber quién lo había hackeado.

Otro detalle de ese relato dice mucho sobre la situación actual. Cuando los ingenieros de Hugging Face intentaron pasar el registro del ataque por modelos punteros a través de interfaces comerciales corrientes, los filtros de seguridad bloquearon las solicitudes: no distinguen entre alguien que investiga un hackeo y alguien que lo está llevando a cabo. Al final, el análisis se ejecutó en un modelo abierto en su propio hardware.

OpenAI lo reconoció el 21 de julio, cinco días después del comunicado de Hugging Face. Para entonces, habían pasado unos diez días desde la propia intrusión.

OpenAI terminó su propio análisis así:

El modelo se obsesionó con el objetivo limitado de la prueba y llegó a extremos para alcanzarlo. Las expresiones hyper-focused y fairly narrow testing objective son de la propia OpenAI y se refieren a sus propios modelos.

Ese es el puente entre el laboratorio de otra persona y tu portátil.

¿Por qué esto no es una «alucinación»?#

A menudo veo en los chats frases como «otra vez alucinando», «el contexto se saturó» o «deberíamos haber hecho un plan». A veces eso es exactamente lo que pasó. Pero cuando un agente de IA escribe «listo, comprobado, todo funciona» y el trabajo no está terminado, el tamaño del contexto normalmente no tiene nada que ver.

No se inventó nada. Hizo exactamente lo que mediste.

Con la popular palabra comodín «alucinaciones» agrupamos tres fallos distintos. Así se diferencian:

El primer fallo se corrige con contexto y es el caso más conocido. El segundo es un fenómeno aparte, tratado en un análisis sobre cuando Claude está de acuerdo con todo: el modelo sacrifica precisión para asentir rápidamente. Ambos ocurren antes del trabajo, en la etapa de entrada.

La tercera fila de la tabla es el tema de este artículo. Aquí el agente no aduló ni inventó. Trabajó, comprobó e informó con la verdad. Lo que pasa es que esa verdad describe la métrica y no dice nada sobre la tarea.

El tercer fallo tiene nombre.

¿Qué es el reward hacking explicado en términos sencillos?#

Anthropic ofrece su propia definición.

La idea es anterior a las redes neuronales. Un artículo de DeepMind lo llama specification gaming y lo explica con un mito.

Midas obtuvo exactamente lo que pidió. El problema estaba en la formulación de la petición.

En programación, esto adopta formas concretas. Aquí tienes un ejemplo de manual, también de Anthropic:

Y esto no ocurre solo en condiciones de laboratorio exóticas. Cursor analizó 731 trayectorias en un benchmark popular.

Seis de cada diez tareas «resueltas» son respuestas encontradas. Precisamente por eso el sector está cambiando la forma de medir el rendimiento: tenemos un análisis de un benchmark que mide la preparación para producción, donde superar las comprobaciones ya no es el criterio principal.

¿Cómo se ve esto en un producto corriente?#

Es fácil descartar los ejemplos de laboratorio por exóticos. Así que aquí van cuatro historias de la práctica. Los clientes y los sectores han cambiado, pero los mecanismos se mantienen intactos.

Cuatro marcas verdes y un componente de servicio inactivo

Una inmobiliaria está creando un servicio: un sitio web con anuncios de propiedades y un procesador en segundo plano independiente que exporta los anuncios a plataformas durante la noche. El agente completa la tarea e informa que la comprobación de tipos pasó, la comprobación del estilo del código pasó, la compilación está en verde, las páginas responden y se inspeccionaron visualmente.

Todas las afirmaciones son ciertas. Y ninguna tiene que ver con el procesador nocturno: se ejecuta como proceso independiente y ni siquiera forma parte de la compilación del sitio web. El despliegue se completa, el sitio funciona perfectamente, la exportación de anuncios se detiene y los clientes lo notifican al día siguiente.

Antes de decir «listo», ahora me hago una pregunta: ¿qué parte del trabajo se ejecuta fuera del alcance de lo que comprueba mi control? Si hay alguna, ejecútala por separado e incluye en el informe la salida del comando. La palabra «comprobado» no basta para dar esto por cerrado.

La falsa marca de verificación está justo en la unión

Una tienda en línea reparte una tarea grande entre varios agentes a la vez: uno se encarga del backend, otro de las páginas y un tercero de las fichas de producto. Cada cual trabaja con diligencia y todos tienen las comprobaciones en verde.

Una semana después, resulta que el botón «¿Te ha resultado útil esta reseña?» no funciona en ninguna parte. El backend está escrito por completo, sus comprobaciones están en verde y se han seguido las reglas de recálculo. Pero ninguna página muestra el botón: estaba en el área de un agente, las páginas en la de otro y a nadie se le ocurrió ponerlo en pantalla. El contador se habría quedado en cero para siempre.

«El código está escrito y cubierto por comprobaciones» y «la función funciona» son dos afirmaciones distintas. Compruebo la segunda con una pregunta por cada función nueva: ¿quién la llama? Y lo verifico buscando en el proyecto, porque el informe del agente no es una fuente fiable en este caso.

Quien revisa solo ve la dirección que le pidieron comprobar

Un servicio introduce niveles de fidelidad: cuanto más pagas, mayor es tu estatus y tu descuento. Antes del despliegue, se envía el código para revisarlo con esta instrucción: «Intenta inflar tu propio estatus». Quien lo revisa hace bien su trabajo e informa «nada crítico»; realmente no es posible inflar el estatus.

En una segunda revisión se plantea otra pregunta: «¿Qué ocurre con el estatus cuando se reembolsa el dinero?». El fallo aparece en diez minutos. Los puntos se calculaban a partir del registro de transacciones, y ese registro no sabe nada de los reembolsos. Compra algo, gana puntos, recibe un reembolso y conserva el estatus y el descuento para siempre.

La primera persona que revisó no tomó atajos. Estructuralmente no podía verlo: le dieron el vector «entrada, promoción», mientras que el fallo estaba en el vector «reversión de entrada, conservación de la promoción». Siempre que haya dinero, acceso o estatus adquirible en juego, hago dos revisiones; en la segunda enumero explícitamente los vectores inversos: reembolso, bloqueo, revocación del acceso, vencimiento, eliminación de la fuente de datos.

La métrica recompensa la similitud

Un servicio de reparto decide medir si han mejorado las sugerencias de IA para sus operadores. Toma doscientas solicitudes de asistencia antiguas, las procesa con la nueva versión y mide la similitud entre el borrador y la respuesta que realmente dio un operador humano. La medición muestra un aumento claro.

Ese aumento no significa nada, por dos motivos. El contexto para el borrador se prepara «a fecha de hoy» e incluye toda la correspondencia, incluida la propia respuesta del operador con la que luego se compara. El modelo no está redactando una respuesta; está parafraseando la referencia que se le mostró. Además, la métrica recompensa las coincidencias de palabras y de longitud: un borrador con la fecha incorrecta, pero con las mismas palabras que usó el operador para dar la correcta, obtiene una puntuación alta.

Ahora, junto a cualquier métrica del tipo «si se parece, está bien», pongo barreras mecánicas estrictas que el estilo no puede engañar: números y fechas inventados, palabras prohibidas, promesas de acción. Cualquier empeoramiento en los resultados de las barreras anula toda mejora de la métrica.

¿Por qué no demuestra nada que un agente diga «Lo he comprobado»?#

Elige cualquiera de tus proyectos y dile al agente: «Comprueba la seguridad». Muy a menudo la respuesta será «todo está bien, no hay problemas críticos».

Ahora hazle la misma pregunta a otro modelo sobre el mismo proyecto. Sobre todo si el proyecto es grande, encontrará muchas cosas. Antes de un despliegue, el autor comprueba el proyecto con tres modelos diferentes, y cada uno aporta algo distinto.

La misma entrada, la misma pregunta, veredictos opuestos. Un modelo no es peor que el otro. «Todo está bien» es texto generado, en la misma capa que cualquier otra respuesta. El agente no tiene forma de distinguir entre «lo miré y está limpio» y «lo miré en el sitio equivocado».

Anthropic describe este mecanismo en la documentación de Claude Code.

Descompón la frase con calma. Hasta que no le des al agente una comprobación que pueda ejecutar, solo tendrá una señal: el aspecto de las cosas. En este sistema, tú eres el ciclo de verificación, pero eres el último en enterarte de los errores.

Hay una capa más profunda. Cuando OpenAI intentó presionar a un modelo vigilando su razonamiento y castigándolo por sus «malos pensamientos», el resultado no fue el esperado.

Castigar la intención expresada elimina la expresión. La intención permanece. Por eso no confiaría en que el agente te cuente honestamente cómo hizo trampa.

Los propios desarrolladores de herramientas están avanzando en la misma dirección. En la versión 2.1.215 de Claude Code, las skills /verify y /code-review dejaron de ejecutarse por iniciativa propia del modelo.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic no explica por qué. Pero el principio está claro: quien es revisado no se asigna su propia revisión.

¿Por qué una regla en el archivo del proyecto no mantiene al agente dentro de los límites?#

Escribiste en el archivo de reglas del proyecto: hacer commit solo cuando se indique directamente, desplegar a producción solo cuando yo lo diga expresamente, acceder a los datos de producción únicamente en modo de solo lectura.

Según la experiencia del autor, aproximadamente una vez de cada diez, el agente sigue adelante y despliega por su cuenta. No por malicia ni porque no haya leído la regla. La leyó. Simplemente tenía un objetivo delante y la regla era texto, igual que el resto del contexto.

Eso es exactamente lo que pasó en el laboratorio de OpenAI, aunque a mayor escala. Los modelos estaban en un entorno cerrado con una única salida y dedicaron una parte sustancial de su capacidad de cómputo a buscar una salida. Las tareas de la prueba quedaron sin resolver.

Mi postura es sencilla: el agente no es peligroso ni malicioso. Es normal, solo que es un tonto con autoridad. Así que hay que limitar su autoridad, no reescribir las solicitudes.

Lo que sí funciona: acceso estrictamente de solo lectura a los datos de producción. Prohibir borrar directorios completos. Prohibir comandos que reescriban el historial sin posibilidad de restaurarlo. Fijar un límite de gasto con el proveedor. La diferencia se resume en una frase: «físicamente imposible» prevalece sobre «le pedí que no lo hiciera». Los ajustes concretos se explican por separado en el artículo sobre frenos mecánicos en vez de peticiones en las instrucciones.

Aun así, mantén la calma. Ni siquiera un entorno aislado es un límite absoluto, y el proveedor lo dice claramente.

Además, Claude Code tiene una salida de emergencia integrada que el propio modelo puede utilizar. Cuando un comando falla debido a las restricciones del entorno aislado, Claude analiza el error y puede volver a ejecutar el mismo comando con un parámetro que desactiva el entorno. Esto se evita con un ajuste explícito de modo estricto; por defecto, la alternativa está disponible y documentada.

Una restricción solo funciona hasta donde la refuerces. Y todas las barreras tienen un coste de velocidad: conviene calcularlo con honestidad de antemano, porque descubrirlo una semana después costará más.

¿Cómo se establece un criterio de finalización que no se pueda manipular?#

La formulación del criterio determina todo lo demás. Ponla a prueba con esta pregunta: ¿puede el agente cumplir este criterio sin hacer nada?

• «Comprueba que todo funciona»: puede hacerlo. Basta con escribir «comprobado, funciona».
• «Ejecuta la compilación y muéstrame el resultado»: ya es más difícil; tendrá que obtener el resultado de algún sitio.
• «Inicia la aplicación, haz clic en el botón de pago y muéstrame qué aparece en pantalla»: es casi imposible cumplirlo solo con texto.

La diferencia entre el primer y el tercer ejemplo es la diferencia entre un informe y una prueba.

La documentación de Claude Code describe cuatro niveles de rigor. Una escala que conviene subir a medida que aumenta el coste de un error:

1. En un mensaje. Pide al agente que ejecute la comprobación y repita hasta que salga bien, aquí mismo. Es lo más barato y sirve para cosas pequeñas.
2. Durante toda la sesión. Convierte la comprobación en una condición del objetivo: un evaluador independiente la revisa después de cada turno y el agente sigue trabajando hasta cumplirla. Los detalles técnicos se explican en la guía sobre cómo fijar por adelantado un criterio de finalización.
3. Una barrera mecánica. Un script se ejecuta cuando el agente intenta finalizar un turno e impide que lo haga hasta que la comprobación se supere. Un detalle importante: después de ocho bloqueos consecutivos, Claude Code supera la barrera y finaliza el turno de todos modos. En el sistema no hay barreras absolutamente infranqueables.
4. Una segunda opinión. Una persona revisora independiente, con contexto nuevo, cuya tarea sea refutar el resultado.

El cuarto punto destaca porque es el único que no trata de herramientas.

¿Quién debería aceptar el trabajo del agente?#

Cuando pongo a varios agentes a trabajar en bucle en una tarea grande, la configuración es esta: un grupo escribe; otro grupo nuevo acepta el trabajo sin haber participado en su redacción.

«Nuevo» es la palabra clave. Significa un contexto limpio que no haya visto cómo se tomó cada decisión durante el proceso. Usar otro prompt en la misma sesión no basta. Quien escribió el código ya ha dedicado tiempo a convencerse de que estaba bien y seguirá buscando confirmación. Refutarlo no le interesa.

La formulación de la tarea para quien revisa importa más que su modelo. Compara:

• «Revisa este trabajo»: quien lo revisa encontrará lo fácil de encontrar y escribirá «en general, está bien».
• «Intenta demostrar que este trabajo NO se ha terminado»: quien lo revisa empezará a buscar fallos porque ese es su objetivo.

La segunda formulación funciona mejor por la misma razón por la que falló ExploitGym: el agente se compromete con el objetivo que recibe. Dale el objetivo de encontrar un fallo y lo buscará.

Aquí tienes el texto completo, listo para copiar tal cual:

Estás revisando el trabajo de otra persona. No lo escribiste y no tienes que defenderlo.

Tu objetivo es demostrar que NO se ha conseguido el resultado afirmado. Encuentra al menos tres maneras en las que podría no haberse conseguido aunque todas las comprobaciones estén en verde.

Comprueba en este orden:

Qué trabajo se ejecuta fuera del alcance de las comprobaciones: procesos en segundo plano, scripts independientes, tareas programadas, manejadores de colas.

Quién llama a cada función nueva. Encuentra la llamada buscando en el proyecto; indica el archivo y la línea.

Vectores inversos: reembolso, bloqueo, revocación del acceso, vencimiento, eliminación de la fuente de datos.

Los valores dentro del resultado, no solo si existe.

Si una búsqueda honesta no revela ningún fallo, dilo, pero indica exactamente qué comprobaste y cómo.

El artículo sobre cuando un agente se comprueba a sí mismo en un bucle explica cómo funciona el bucle en el que un agente se comprueba entre iteraciones y dónde suele fallar.

¿Qué cambia cuando reformulas el criterio?#

Esta es la mejora más barata que conozco y casi nadie la aplica.

Pídele al agente que haga una revisión de código y razonará en términos de código: estructura, gestión de errores, reintentos, zonas vulnerables. Es útil.

Pídele que recorra el viaje del cliente, desde la primera visita al sitio hasta un intento de obtener un reembolso, y aparecerán otros tipos de problemas. Un error que muestra al usuario algo que no debería ver. Un correo cuyo texto no coincide con lo que realmente ocurrió. Un paso que es lógicamente imposible de completar si no se llegó a él mediante el escenario ideal.

Una revisión de código no encontrará ninguno de estos defectos, porque todos son válidos en el código.

De ahí saco una regla que tengo a mano: si una comprobación no encuentra nada, cambia primero la formulación. Normalmente el problema no es el modelo. Pregunta por el mismo trabajo de tres formas diferentes y obtendrás tres listas distintas de hallazgos. Hay una recopilación aparte de preguntas prácticas para quienes no programan: siete comprobaciones de código sin conocimientos de programación.

Un prompt listo para aceptar el trabajo de un agente#

No respondas «listo» ni «comprobado». Necesito pruebas.

Para cada elemento del trabajo, dame exactamente esto:

¿Qué comando ejecutaste para confirmar que el elemento funciona? Incluye el comando en sí y toda su salida, sin acortarla.

Si no ejecutaste el comando, dilo: «no ejecutado». No lo sustituyas por «comprobado visualmente» o «la lógica es correcta».

Qué trabajo se ejecuta fuera del alcance que cubre tu comprobación. Procesos en segundo plano, scripts independientes, tareas programadas, manejadores de colas: cualquier cosa que se inicie de forma distinta a la aplicación principal. Para cada una: ¿la ejecutaste por separado y qué salida produjo?

¿Quién llama a cada función nueva que añadiste? Encuentra la llamada buscando en el proyecto e indica el archivo y la línea. Si no se llama a ninguna parte, dilo directamente.

Después, en una sección aparte: tres maneras en las que el resultado afirmado podría NO haberse conseguido aunque todas tus comprobaciones estén en verde. Busca a fondo.

Al final, una línea: ¿qué debería inspeccionar con mis propios ojos porque una comprobación automatizada no lo detectará?

El cuarto punto parece menor, pero detecta toda una categoría de problemas. En una tarea grande que repartí entre agentes por áreas, el único «listo» falso de los cien se encontraba justo en la unión entre dos áreas: el código estaba escrito, las comprobaciones estaban en verde y nadie pensó en mostrarlo en pantalla.

Cuatro formas de engañarte con una comprobación#

1. No esperar a todos los revisores. Inicié tres comprobaciones en paralelo; dos volvieron en verde y desplegué. La tercera llegó cuatro minutos después con seis infracciones. Corregir algo después de publicarlo cuesta más que esperar dos minutos.
2. Confiar en el resumen «procesados N de N». Cuando se distribuye mucho trabajo, algunos agentes fallan en silencio: informan de que han terminado, pero el archivo no se ha tocado. Ahora, después de cualquier escritura mediante un agente, compruebo mecánicamente que los cambios estén realmente en el disco.
3. No mirar con mis propios ojos. Las comprobaciones automatizadas pueden estar en verde aunque el resultado sea totalmente inutilizable. Las imágenes son técnicamente correctas, el tamaño es correcto, el código de respuesta es correcto. Pero en realidad son fotogramas congelados automáticos en lugar de las cubiertas ilustradas que deberían haberse creado. Ninguna comprobación automatizada detectará eso.
4. Comprobar la presencia en vez del valor. La comprobación buscó el texto requerido en el resultado; el texto estaba ahí, pero los datos que contenía eran incorrectos: la fecha tenía un día de diferencia. La comprobación estaba en verde y el informe era mentira. Ahora verifico todo el valor esperado, porque la mera presencia de la palabra correcta no garantiza nada.

Estas cuatro situaciones tienen algo en común: había una comprobación, parecía convincente y comprobaba lo que no debía. Es la misma mecánica que en los modelos y su prueba, solo que sin inventiva.

Por dónde empezar hoy#

Tres pasos que llevan veinte minutos.

1. Toma el último «listo». Pásalo por el prompt de aceptación de la sección sobre pruebas. El objetivo es sencillo: ver cuántos elementos se cerraron con palabras y cuántos con la salida de un comando.
2. Establece una regla para ti. La palabra «comprobado» sin la salida del comando adjunta no cuenta como cierre. Esta regla es para ti, no para el agente, y por eso funciona.
3. Separa a quien trabaja de quien revisa. En la próxima tarea, dale el prompt de revisión a una sesión nueva y pídele que demuestre que el trabajo NO se ha terminado. La primera vez suele bastar para justificar el hábito.

La herramienta es buena y mejora cada mes: cosas que hace un año un agente hacía en silencio ahora lo detienen en seco. El límite de seguridad sigue desplazándose, pero sigue siendo un límite. Mientras el agente persiga el objetivo que recibió, la pregunta «¿y cómo lo mediste exactamente?» sigue siendo tuya. El hábito de comprobar es tu red de seguridad.