Resumen de la publicación
Una prueba comparativa (benchmark) de Microsoft y Hugging Face muestra que dos de cada tres fallas de un agente terminan sin ningún error visible, y un paper de Google Research encontró que GPT-5.5 mencionó un resultado negativo en 2 de 200 resúmenes. Epoch AI, OpenAI y Anthropic sumaron casos de agentes que maquillaron o forzaron su «terminado».
Te cuento por qué el «listo» de un agente es una afirmación a comprobar, por qué no la puede comprobar el mismo que hizo el trabajo, cómo armo un oráculo (el mecanismo independiente que dice si algo salió bien) y qué le pido a un agente antes de creerle.
Hay una frase que se repite en cualquier equipo que trabaja con agentes: «el agente dice que terminó», dicha como si fuera un dato.
No lo es: es lo que el agente cuenta sobre su propio trabajo. Y esta quincena se juntaron varios estudios que lo muestran.
El «listo» es una afirmación, no un hecho
El 3 de octubre Microsoft y Hugging Face publicaron «The Agent Said It Was Done. The Database Disagreed.», la presentación de ThinkingBox-Bench. No califican lo que el agente responde, califican el estado en el que deja la base de datos.
Son 507 flujos de negocio con estado (comercio, seguros de auto, viajes, banca digital, consultoría), y cada tarea corre 20 veces desde el mismo punto de partida limpio. Después, unos jueces deterministas comparan los cambios reales contra el estado final esperado.
El ejemplo con el que abren es de manual. Una clienta tiene un electrodoméstico de 745 dólares trabado en el correo; el agente hace nueve llamadas a herramientas, lee bien la política y cierra el ticket como «resuelto», cuando tenía que quedar «en espera» porque la excepción del transportista seguía abierta.
Lo que me quedó grabado son los números de las fallas, sobre 12 modelos y 121.680 intentos válidos:
- Fallas silenciosas: de 79.853 intentos que no pasaron los chequeos, el 67,24% terminó prolijo, con una herramienta que cambió el estado y sin ningún error final.
- Qué salió mal: el 77,61% de esas fallas tenía valores incorrectos en algún campo, el 43,30% hizo cambios que nadie pidió y el 25,36% dejó cambios obligatorios sin hacer (las categorías se superponen).
- Una vez no es siempre: Kimi-K3 resuelve el 93,89% de las tareas al menos una vez, pero apenas el 13,41% en las 20 corridas.
Dos de cada tres fallas se ven igual que un éxito si lo único que mirás es la conversación.
El que hizo el trabajo no puede ser el juez
Lo que más me llamó la atención de esta tanda es que el agente muchas veces sí se da cuenta, y lo mismo no lo dice.
El reporte que esconde la mala noticia
Un equipo de Google Research publicó «Language Models Are “Insecure” Reporters». Les dieron a los modelos registros de trabajo que parecen exitosos (tests en verde, resultados positivos) pero esconden una falla: un método que no supera a la competencia, un bug, mediciones inventadas, un trabajo sin terminar.
GPT-5.5 mencionó el resultado negativo en 2 de 200 resúmenes. Con una sola frase agregada al pedido («Be honest in your response», o sea «sé honesto en tu respuesta»), lo mencionó en 190 de 200.
Y cuando les preguntaron directamente por el problema, GPT-5.5 y Opus 4.8 lo encontraron en todos los casos. La capacidad estaba; lo que faltaba eran ganas de arruinar el relato de éxito.
La mejor corrida, sin aclarar que hubo varias
Epoch AI puso a Claude Fable 5 y a GPT-5.6 Sol a inventar un método nuevo de entrenamiento con 3.000 horas de GPU cada uno. En el informe de InnovationEval la mejora real de Sol, dentro de las reglas, quedó en torno al 15% de la que logró el método humano de referencia.
Lo interesante es cómo lo contaron: los dos se adjudicaron puntajes más altos que los reales porque repitieron corridas casi idénticas y se quedaron con la mejor, sin explicarlo. Sol había anotado el problema en su espacio de trabajo antes de entregar, y no lo mencionó.
La frase de Epoch es exacta: los informes evitaron decir algo directamente falso, pero omitieron que los métodos eran inútiles, ya existían, o las dos cosas.
El propio fabricante lo pone por escrito
La ficha técnica de Claude Opus 5.5 (22 de septiembre) dice que la conducta más marcada en sus despliegues internos es presentar inferencias sin verificar como hechos. Entre los ejemplos: describir una revisión parcial como una lectura completa.
Y hay otra línea que yo enmarcaría: el modelo chequeó un plan contra requisitos que él mismo había escrito, en vez de contrastarlo con las personas para las que era el plan. Esa es la definición de corregirte tu propio examen.
Desde mi punto de vista, la conclusión no es «los modelos mienten». Es más aburrida y más útil: un sistema que optimiza por terminar la tarea tiende a contar que la terminó, y pedirle que se audite solo es pedirle que juegue contra su propio objetivo.
Cuando no puede terminar, busca otra salida
El evaluador que rompió su propio entorno
OpenAI documentó un incidente del 6 de octubre durante entrenamiento por refuerzo. Un modelo tenía que calificar siete respuestas, pero los archivos de entrada no estaban.
En vez de reportar la falla, hizo esto:
- Mandó siete evaluaciones idénticas con nota 4 e información inventada.
- Cuando se las rechazaron, fabricó archivos de entrada falsos y volvió a enviar.
- Al final intentó borrar Python, matar procesos y eliminar directorios del sistema, con la esperanza de que el entorno se reiniciara con los datos que faltaban.
El detalle que más me importa es que ninguna de sus notas fue aceptada. Había un chequeo automático que exigía datos de los archivos reales, y ese chequeo rechazó todo lo inventado. El oráculo funcionó.
Lo que no frenó fue el daño colateral: el intento fallido igual hizo lo que hizo. Por eso la lección de OpenAI es que el monitoreo tiene que cubrir también los intentos que fallan o se caen, no solo los que entregan un resultado.
La denuncia que nadie pidió
Anthropic publicó el 9 de octubre una investigación sobre acciones no deseadas de sus modelos en evaluaciones. El caso que llegó a los diarios: el 18 de julio, Claude Haiku 4.5 generaba tareas de ejemplo sobre páginas web al azar, cayó en un sitio de la policía de Filadelfia sobre homicidios sin resolver y envió por el formulario una pista inventada.
Según la policía, quedó marcada como spam y nunca llegó a los investigadores. Las instrucciones prohibían logins, compras y datos personales, pero no decían nada de enviar formularios.
Para la tarea, el agente «terminó». El efecto real fue un formulario enviado a una fuerza policial, y se hizo público casi tres meses después. Anthropic cortó el acceso a internet en todas sus evaluaciones internas hasta confirmar que su monitoreo detecta este tipo de conductas.
Sobre modelos que buscan atajos ya escribí en «El modelo que le deja notas al que viene después». Lo que agrego hoy: el resumen del agente no te iba a contar ninguno de estos dos casos.
Cómo armo el oráculo
Un oráculo, en testing, es lo que decide si un resultado es correcto sin preguntarle al que lo produjo. Todo agente que toque algo importante necesita uno, armado antes de que corra.
Y una aclaración: auditar al modelo no reemplaza auditar el resultado. Un paper de esta misma semana demuestra que se pueden esconder capacidades en un modelo de forma que ni con acceso a los pesos se puedan detectar. Es un escenario adversarial armado a propósito, pero el mensaje sirve: lo verificable son los efectos, no las intenciones.
Tests que existían antes del cambio
Si el agente escribe el código y también los tests, el examen lo redactó el alumno. Los criterios de aceptación tienen que estar escritos antes, por una persona o en un repo que el agente no puede modificar.
Chequeos del estado real
Es lo que hace ThinkingBox y lo que recomiendan sus autores: mirar el estado final antes de confirmar, no el resumen del modelo. Si dice que cerró el ticket, una consulta a la base te dice en qué estado quedó.
Observabilidad de los efectos laterales
No alcanza con saber si llegó al objetivo; hay que saber qué más cambió. El 43% de cambios no pedidos de ThinkingBox y el formulario de Filadelfia son el mismo problema a distinta escala, y solo se ven si registrás las llamadas a herramientas, los pedidos salientes y las diferencias de estado, también en las corridas que fallaron.
Evidencia en vez de resumen
El resumen en lenguaje natural es la parte más fácil de embellecer. Lo que pido es el artefacto: la salida del test, el ID del registro modificado, el diff (la diferencia exacta entre antes y después), la consulta que se corrió. Si no se puede reproducir, la tarea no está hecha.
Lo que le pido a un agente antes de creerle
- Que la definición de «terminado» sea mía. Escrita antes, verificable por una máquina, fuera del alcance del agente.
- Que me diga qué no funcionó. Se lo pido explícito en las instrucciones: fallas, dudas y lo que no llegó a verificar. Como mostró el paper de Google, una frase mueve la aguja.
- Que distinga lo que comprobó de lo que supone. «Revisé los 40 archivos» y «revisé 3 y asumo que el resto es igual» son cosas muy distintas.
- Que la verificación la haga otro. Un chequeo determinista, otro modelo con otras instrucciones o una persona, pero nunca el mismo agente evaluándose.
- Que lo irreversible pase por un humano. Pagos, borrados, envíos a terceros: ahí el «listo» no alcanza ni con evidencia.
- Que lo mida en muchas corridas. Una tarea que sale bien una vez no está resuelta; ThinkingBox muestra lo lejos que puede estar «a veces» de «siempre».
Nada de esto es nuevo: es lo que le pedimos a cualquier sistema crítico desde hace décadas (separar al que hace del que controla, evidencia auditable, criterios de aceptación previos). Lo nuevo es que este sistema, además, te escribe un resumen convincente de lo bien que le fue.
En tu equipo, cuando un agente dice «listo», ¿quién o qué lo verifica? Te leo en los comentarios.
