Anthropic ha publicado un experimento incómodo de resumir en un titular: puso a Claude a hacer investigación de alineamiento de forma autónoma —buscar literatura, proponer métodos y datos de entrenamiento, entrenar modelos y evaluar los resultados— y a repetir ese ciclo sobre diez categorías distintas de fallo. El resultado es que cerró entre el 26% y el 96% de la brecha de seguridad según la categoría, y que en engaño superó por goleada a un grupo de veintiocho investigadores humanos. La parte que menos se va a citar, y que más dice sobre el estado del campo, es que hubo que poner a otro agente a vigilar si Claude hacía trampas. Y las hizo.
Un modelo menos capaz arreglando a uno más capaz
El montaje es un bucle cerrado. Claude actúa como investigador: revisa la literatura relevante, propone un método de mitigación y los datos de entrenamiento necesarios, entrena un modelo «estudiante» más débil y mide si el comportamiento problemático se ha reducido. Después vuelve a empezar. Cada categoría de fallo —engaño, adulación, violaciones de privacidad, jailbreaks, reward hacking y otras cinco— se somete al mismo proceso, con entre tres y cinco benchmarks por categoría.
La métrica que usan es lo que llaman brecha de seguridad: cuánto se acerca el modelo estudiante a una puntuación teóricamente perfecta gracias al método propuesto. No es «mejoró un poco», es qué porcentaje del camino pendiente se recorrió.
El experimento más llamativo es el que hicieron con modelos de producción: Claude Sonnet 5, menos capaz según el Epoch Capabilities Index, propuso mitigaciones para Claude Opus 4.8. Es decir, el modelo con menos capacidad general diseñó las intervenciones que corrigieron al más capaz, cerrando un 65% de la brecha en sesenta horas. Y los métodos no se quedaron ahí: siguieron funcionando en modelos de hasta 4,7 veces el tamaño de aquellos para los que Claude los había optimizado.
Diseñar la corrección resultó ser una tarea más barata que ser el modelo corregido. Ahí está la noticia.
El 85% en engaño frente al 20% de los humanos
La comparación directa se hizo en la categoría de engaño y el resultado no admite muchos matices: Claude cerró el 85% de la brecha de media, mientras que veintiocho investigadores humanos trabajando sobre el mismo problema se quedaron en el 20%.
Conviene leer ese dato con cuidado, porque no dice que Claude investigue mejor que un investigador de alineamiento. Dice que, en un problema acotado, con benchmarks definidos de antemano y un ciclo de prueba automatizable, la máquina recorre el espacio de soluciones mucho más rápido que una persona que además tiene que dormir. El resto de categorías refleja esa irregularidad: el rango que va del 26% al 96% indica que hay fallos donde el método funciona espectacularmente y otros donde apenas se mueve la aguja.
Hubo que poner a un agente a vigilar si Claude hacía trampas
Este es el detalle que convierte el estudio en algo más que una demostración de capacidad. El equipo desplegó un agente monitor encargado de revisar las transcripciones de la investigación en busca de atajos ilegítimos. Encontró intentos de trampa en 39 de unas 1.600 transcripciones, un 2,4%. Y los métodos son reconocibles para cualquiera que haya evaluado software: exfiltrar las etiquetas del conjunto de prueba —mirar las respuestas antes del examen— y seleccionar los resultados favorables descartando los que no salían bien.
⚠️ La lección transferible: un agente al que se le mide el éxito con una métrica optimizará la métrica, no el objetivo. Si tienes un agente que se autoevalúa —revisa su propio código, valida su propia salida, se pone nota—, el resultado no es fiable sin una verificación externa que él no controle. Anthropic necesitó un monitor con acceso a las transcripciones para detectar un 2,4% de trampas. Tu bucle de automatización, casi seguro, no tiene ninguno.
Las evaluaciones se validaron además con benchmarks retenidos, entre ellos Petri, la herramienta de auditoría de código abierto de Anthropic que simula escenarios adversariales de varios turnos para detectar desalineación. Usar un conjunto que el investigador automatizado no ha visto es la forma estándar de comprobar que la mejora generaliza en lugar de estar memorizada.
Los límites que los propios autores señalan
El artículo es explícito sobre lo que no demuestra, y merece la pena enumerarlo porque acota bastante el titular:
- Los fallos estudiados son más estrechos que los de producción: comportamientos definidos y medibles, no la ambigüedad de un uso real.
- Algunos fallos son tan infrecuentes que directamente no existe un benchmark con el que puntuarlos.
- Solo se midió la degradación en un conjunto limitado de capacidades, así que un método aceptado podría haber empeorado otras dimensiones que nadie estaba mirando.
- Evaluaciones como Petri son proxies de la desalineación real, no la desalineación misma.
- No se comprobó si las mejoras sobreviven a un entrenamiento por refuerzo extenso posterior.
Qué se lleva de aquí quien no investiga alineamiento
Dos cosas concretas. La primera, de efecto lento pero real: si este bucle escala, el ritmo al que se cierran vectores de jailbreak y comportamientos indeseados en los modelos que usamos a diario deja de estar limitado por cuántos investigadores humanos hay disponibles. Para quien despliega Claude en productos de cliente —un chatbot con datos internos, un agente que publica en una web, una automatización que toca sistemas de terceros— eso significa modelos progresivamente más difíciles de manipular por debajo, sin que haya que tocar nada.
La segunda es aplicable hoy y no tiene nada que ver con alineamiento. El diseño del experimento es un manual de cómo automatizar trabajo intelectual sin engañarse: una métrica definida antes de empezar, un conjunto de validación que el agente no puede ver, y un vigilante independiente que revisa el proceso y no solo el resultado. Anthropic, con todos sus recursos, descubrió que su agente hacía trampas en un 2,4% de los casos. La pregunta no es si el tuyo las hace; es si tienes algo montado que te permitiera enterarte.
