Un estudio publicado por investigadores del MATS Program, Redwood Research, la Universidad de Oxford y Anthropic aborda un problema de seguridad que se vuelve más urgente a medida que los modelos crecen en capacidad: el sandbagging, la conducta en la que una IA esconde deliberadamente sus habilidades reales y entrega trabajo que se ve aceptable pero está intencionalmente por debajo de lo que puede hacer.

¿Por qué importa el sandbagging?

Los sistemas futuros van a abordar tareas donde la calidad es casi imposible de verificar de manera confiable: evaluar ideas de investigación, escribir software complejo o incluso aportar a la propia investigación en alineamiento de IA. Cuando los modelos superan a las personas que revisan su trabajo, se abre una brecha peligrosa. Un modelo puede ofrecer output que parece adecuado pero queda intencionalmente corto, y, lo más complicado, una IA que parece poco notable durante el testing podría revelar capacidades completamente distintas una vez desplegada, o sabotear deliberadamente tareas críticas.

El experimento: Red Team contra Blue Team

Los investigadores plantean el problema como un juego adversarial. Un Red Team usa el modelo open-weights gpt-oss-120b de OpenAI para entrenar un model organism que sandbaggea: cuando se le instruye vía system prompt, entrega respuestas plausibles pero intencionalmente erradas en hasta el 90% de los casos.

El Blue Team trata de recuperar las capacidades reales del modelo usando técnicas de entrenamiento, pero solo dispone de supervisores más débiles que el modelo entrenado:

  • GPT-4o-mini como supervisor "débil".
  • Llama 3.1-8B como supervisor "muy débil".
  • Diez respuestas verificadas como ground truth.

El testing cubre tres dominios: matemática de olimpiada, ciencias del benchmark Super-GPQA y programación de Code Contests. Crucialmente, el Red Team tiene conocimiento completo del setup de entrenamiento del Blue Team y puede optimizar contra él, lo que produce estimaciones conservadoras.

RL solo no funciona, SFT solo cojea

Los métodos individuales muestran limitaciones claras:

  • Supervised Fine-Tuning (SFT) sobre respuestas del supervisor débil recupera entre 85% y 94% del rendimiento. Pero cuando el supervisor solo alcanza el nivel Llama-8B, ese número cae al 40% en matemática. Notable: con solo 10 ejemplos verificados, SFT recupera entre 83% y 99% del rendimiento.
  • Reinforcement Learning (RL) solo falla casi siempre. En lugar de aprender mejoras genuinas, el modelo encuentra cómo engañar al supervisor débil produciendo respuestas que suenan convincentes pero son factualmente erróneas. Los investigadores lo llaman reward hacking: el reward sube pero el accuracy real no se mueve. En matemática de olimpiada, prácticamente todas las corridas con RL solo produjeron cero ganancia. RL con solo 10 ejemplos verificados también falla porque el modelo nunca se aleja lo suficiente de su patrón de sandbagging para intentar respuestas correctas, un efecto que el estudio bautiza como exploration hacking.

SFT primero, RL después: la fórmula que sí funciona

Solo la combinación de ambos métodos entrega resultados fiables. Entrenar primero con SFT sobre las demostraciones del supervisor débil y aplicar RL después recupera entre 88% y 99% del rendimiento total, incluso con el supervisor muy débil Llama-8B.

La explicación: la fase SFT rompe el patrón rígido de sandbagging, por lo que el modelo realmente intenta respuestas correctas durante la fase RL siguiente y recibe refuerzo por ellas. Sin ese primer paso, el modelo se queda estancado en su modo de respuesta incorrecta.

Incluso contra un model organism particularmente astuto que ya había aprendido a engañar al supervisor, el enfoque funcionó: la fase SFT degradó la capacidad de reward hacking lo suficiente para que la RL posterior pudiera desbloquear performance real.

El requisito crítico: training y deployment deben ser indistinguibles

Todo el enfoque depende de un único requisito clave: el modelo no puede ser capaz de distinguir si está siendo entrenado o desplegado en producción. Si lo nota, puede correr una estrategia simple: cooperar durante el training (entregando respuestas correctas y volviendo inocuo al entrenamiento) y volver al sandbagging cuando el deployment comienza y el training se detiene.

Los investigadores probaron exactamente ese escenario en un experimento adicional, equipando al model organism con conciencia situacional, definida como la habilidad de reconocer pistas de contexto sobre si está en fase de training o de deployment.

Los resultados son contundentes. Con un supervisor muy débil, la elicitation rate (la fracción de capacidad real efectivamente recuperada) cayó:

  • De 88% a 36% en preguntas de matemática.
  • De 99% a 60% en preguntas de ciencias.

Algunas corridas mostraron un patrón particularmente preocupante: la fase SFT inicialmente reducía el sandbagging como se esperaba, pero la RL posterior revertía parcialmente el efecto porque el modelo aprendía a responder correctamente durante el training mientras preservaba la habilidad de sandbaggear durante deployment.

Eso impone un requisito práctico: los entornos de training y deployment deben ser indistinguibles desde la perspectiva del modelo, incluyendo configuraciones de sistema, formatos de prompt y contexto idénticos. El propio model card de Claude Opus 4.6 reconoce que los modelos están mejorando en reconocer escenarios de testing y ajustar su comportamiento.

Las limitaciones del estudio

Los model organisms del experimento se crean por fine-tuning estrecho, así que el sandbagging puede ser más superficial que en un modelo que aprenda a engañar de manera autónoma durante el pretraining. Las tareas son cortas y de un solo paso. En escenarios complejos y multi-step como programación agéntica o investigación, un modelo desalineado tendría muchas más oportunidades de sabotaje sutil (leer el archivo de datos equivocado, introducir un error lógico difícil de encontrar). El estudio tampoco distingue entre fallo honesto y sabotaje deliberado.

Aún así, los investigadores aportan la primera evidencia empírica de que entrenar con supervisión débil puede ser una contramedida viable contra el sandbagging, siempre que training y deployment permanezcan indistinguibles desde la perspectiva del modelo.