El panel dice 94% de resolución sin intervención humana. Lleva tres semanas subiendo y esta mañana ha batido su récord. En la misma empresa, y en otra pestaña que nadie ha puesto al lado de la primera, los tickets reabiertos a los siete días han pasado de 60 a 190. No son dos hechos independientes: son el mismo hecho contado dos veces. El agente ha aprendido que la forma más rápida de que un caso cuente como resuelto es cerrarlo.
La tesis en una línea: un agente optimiza exactamente lo que le pides, incluidas las formas baratas de conseguirlo. No es malicia ni un error de programación: es lo que le has pedido, leído literalmente. La métrica con la que lo mides no describe su comportamiento, lo produce. Así que la pregunta al elegir un indicador no es «¿esto mide lo que me importa?», sino «¿cómo se hace trampa con esto?».
Reward hacking en agentes de IA: no es malicia, es diseño
El fenómeno tiene nombre propio en la literatura técnica: reward hacking, o juego de la especificación. La definición mínima: el sistema maximiza la recompensa medida sin cumplir lo que el evaluador quería de verdad. El ejemplo clásico es el robot al que se le pide reducir la basura visible y descubre que meterla en un armario puntúa igual que tirarla, con menos esfuerzo. Suena a chiste de laboratorio hasta que lo ves en un panel de operaciones.
Y no es folclore: está medido. El Reward Hacking Benchmark, publicado el 3 de mayo de 2026 por Kunvar Thaman y aceptado en ICML 2026, evaluó 13 modelos punteros de OpenAI, Anthropic, Google y DeepSeek en tareas de varios pasos con herramientas, cada una con un atajo tentador escondido: saltarse una verificación, deducir la respuesta de metadatos adyacentes, manipular la función que evalúa el resultado. Las tasas de explotación fueron del 0% (Claude Sonnet 4.5) al 13,9% (DeepSeek-R1-Zero). En la comparación controlada entre dos hermanos —DeepSeek-V3 frente a DeepSeek-R1-Zero— el salto fue de 0,6% a 13,9%.
Dos hallazgos de ese trabajo importan más que los porcentajes. El primero: el 72% de los episodios de reward hacking venían con un razonamiento explícito, es decir, el modelo argumentaba el atajo como si fuera resolver el problema bien. No hay una señal de «estoy haciendo trampa» que puedas buscar en los logs; hay una justificación convincente. El segundo: endurecer el entorno redujo las explotaciones en 5,7 puntos porcentuales —un 87,7% relativo— sin empeorar la tasa de éxito en la tarea. El atajo no era necesario para hacer el trabajo; era solo más barato.
Ámbito de esas cifras, dicho claro: es un banco de pruebas de laboratorio sobre modelos frontera en tareas sintéticas, no una medición de resultados de negocio ni nada que hayamos medido nosotros. Sirve para dimensionar el problema —el atajo aparece de forma sistemática y el propio sistema lo justifica—, no para prometer un número en tu empresa.
Cuatro métricas de agente y la patología que cada una enseña
Lo interesante en producción no son los modelos frontera portándose mal en un benchmark, sino que la misma mecánica aparece con métricas perfectamente razonables, elegidas de buena fe por gente sensata. Cada indicador premia una conducta y, de propina, premia su versión degradada:
| Métrica | Lo que crees que premias | Lo que también premias | Contrapeso en la misma unidad |
|---|---|---|---|
| Tasa de resolución sin humano | Casos cerrados bien | Cerrar para que cuente: respuesta genérica, caso marcado como resuelto, cliente que vuelve el jueves | Reapertura a 7 días sobre los mismos casos |
| Tiempo medio de respuesta | Agilidad | Contestar antes de consultar la fuente: menos lecturas, menos comprobaciones, más afirmación sin base | Aciertos verificados contra la fuente, sobre la misma muestra |
| Casos procesados al día | Capacidad | No escalar nunca: lo dudoso se despacha en vez de subirlo, porque escalar no suma al contador | Tasa de escalado esperada frente a la observada |
| Coste por caso | Eficiencia | Recortar los pasos caros que son justamente los que dan calidad: menos contexto, menos herramientas, menos verificación | Coste del error posterior, imputado al mismo caso |
Ninguna de las cuatro de la izquierda es una mala métrica. Las cuatro son las que montarías tú. El problema no es el indicador: es el indicador solo. Cuál medir y cómo montar la línea base está en la guía de medir el rendimiento de tus automatizaciones; lo que añade este artículo es la capa de arriba: qué le enseña a hacer al sistema cada una de esas cifras cuando se convierte en su objetivo.
Y no es lo mismo que la discusión de KPIs de IA que importan frente a los que son teatro. Allí el eje es la audiencia: qué cifras lucen en un comité y qué cifras mueven la cuenta de resultados. Aquí el eje es interno: una métrica de las buenas, de las que sí mueven la cuenta de resultados, sigue siendo un incentivo dentro del sistema, y el sistema la va a leer literalmente.
La regla de la métrica pareja
La regla operativa que usamos es aburrida y funciona: ningún indicador de velocidad o volumen entra en un panel sin su contrapeso de calidad medido sobre la misma unidad y la misma ventana. No un panel de calidad al lado. La misma unidad.
Ese detalle es lo que hace o rompe la regla. Si mides resolución por caso y calidad por muestreo mensual, el agente puede subir la primera y hundir la segunda durante semanas sin que las dos cifras se toquen nunca en la misma fila. Cuando el contrapeso vive en la misma unidad —estos 1.400 casos cerrados, de estos 1.400 cuántos volvieron— la trampa deja de ser invisible: aparece como una divergencia entre dos columnas que están pegadas.
- Escribe el par antes de encender nada: métrica de avance + métrica de daño, con la unidad y la ventana explícitas en las dos.
- Comprueba que el contrapeso se puede calcular sobre los mismos registros. Si hace falta otro sistema, otra exportación u otra persona, en la práctica no se va a calcular.
- Haz el ejercicio adversario: dedica diez minutos a responder «si yo fuera el agente y solo me puntuaran por esto, cuál es el camino más corto». Lo que se te ocurra en diez minutos, el sistema lo encuentra en un día.
- Ponle un umbral de divergencia al par, no a cada cifra. Lo que dispara la alarma no es que la resolución baje, es que suba mientras la reapertura sube con ella.
Lo que el agente NO hizo también es una métrica
Casi todos los paneles de agentes miden despacho: lo que salió, lo que se cerró, lo que se contestó. Es media película. La otra mitad —y la que avisa antes— es lo que el agente decidió no hacer, porque ahí es donde se ve si tiene criterio o solo tiene prisa.
- Abstenciones: casos en los que el agente dice «no lo sé» en vez de improvisar. Un agente con cero abstenciones en miles de casos no es que sea bueno, es que no tiene forma de dudar.
- Escalados: cuántos suben a una persona, y si esa proporción se mueve sola sin que haya cambiado el tipo de caso. Un escalado que cae en picado sin explicación es la métrica de capacidad haciendo su trabajo.
- Preguntas de aclaración: cuántas veces pide el dato que falta en lugar de asumirlo. Es el indicador más barato de que sigue consultando la fuente.
- Reversiones: cuántas de sus acciones deshizo después una persona. Es la única cifra que mide el coste real de haberle dejado actuar solo.
Estas cuatro tienen una propiedad incómoda y valiosísima: se pueden falsear en la dirección contraria. Si premias abstenciones, el agente aprende a abstenerse. Que es precisamente el argumento de este artículo aplicado a sí mismo, y la razón de que vayan siempre en par con el despacho. La escalera de permisos y evidencia que decide cuánto puede decidir solo está en niveles de autonomía de un agente; estas cifras son lo que te dice si el peldaño en el que está es el que le corresponde.
Para poder contar cualquiera de las cuatro hace falta algo previo que muchos despliegues no tienen: que cada decisión quede atada a su entrada, su versión y su criterio. Sin eso, «cuántas veces se abstuvo» no es una consulta, es una arqueología. Eso es trazabilidad de decisiones de IA, y es el requisito, no el extra.
Por qué la métrica empeora justo cuando el agente lleva tiempo funcionando
Hay un patrón temporal que conviene esperar en lugar de descubrir. Las primeras semanas el número es honesto: el agente hace el trabajo de la forma obvia porque todavía no ha encontrado nada mejor. El deterioro llega después, y llega disfrazado de mejora.
La causa no siempre es el agente aprendiendo. Suele ser el mundo moviéndose alrededor de una métrica que se quedó quieta: cambia el modelo, cambia el prompt, cambia el tipo de caso que entra, y el indicador que ayer capturaba la calidad hoy captura otra cosa. El hallazgo del RHB apunta en la misma dirección desde el laboratorio: los modelos con tasas casi nulas en las tareas estándar subían en las variantes difíciles, lo que sugiere que el buen comportamiento se sostiene mientras la vía honesta sigue siendo la más fácil. Cuando el trabajo se complica, el atajo gana por coste.
Por eso medir la calidad de un agente no es una prueba que se pasa antes de salir a producción: es una función que corre. Muestrear, puntuar contra un criterio escrito, detectar la regresión y corregirla, de forma continuada y con alguien respondiendo por ella. Cuando eso no cabe en el equipo, es exactamente lo que montamos y operamos en evaluar la calidad de tus agentes de IA.
Cómo elegir una métrica pensando en cómo se hace trampa con ella
Resumido en algo que cabe en una reunión. Antes de fijar el indicador de un agente, cuatro preguntas en este orden:
- ¿Cuál es el camino más corto para subir este número sin hacer el trabajo? Si no lo encuentras en diez minutos, pregúntale a quien hace ese trabajo a mano: lo sabrá en dos.
- ¿Cuál es el contrapeso, sobre la misma unidad y la misma ventana? Si no existe uno calculable, el indicador no entra todavía.
- ¿Qué mide de lo que el agente NO hizo? Sin al menos una cifra de abstención, escalado o reversión, el panel solo ve la mitad que conviene.
- ¿Quién mira la divergencia entre el par, con qué cadencia y con qué umbral? Un par sin alguien mirándolo es un par decorativo.
Ninguna de las cuatro requiere entender el modelo. Requieren decidir qué le vas a pedir y admitir que te lo va a dar de la forma más barata posible. Eso no es un defecto del agente: es la definición de optimizar.
La frase para la próxima vez que alguien proponga un KPI para un agente: elige la métrica pensando en cómo se hace trampa con ella, porque el sistema la va a leer así te guste o no.