Una guía compartida para evaluaciones confiables de terceros

Las evaluaciones independientes y confiables realizadas por terceros desempeñan un papel crítico⁠ en el fortalecimiento del ecosistema de seguridad. Estas evaluaciones se realizan sobre modelos de frontera para aportar evidencia adicional a afirmaciones sobre capacidades críticas y mitigaciones de seguridad. En esta publicación, compartimos lecciones que hemos aprendido hasta ahora y recomendamos enfoques para diseñar evaluaciones que puedan valorar válidamente modelos de frontera y que esperamos ayuden a orientar los estándares emergentes en este ámbito.

Antes, muchas evaluaciones trataban a los modelos como chatbots: la evaluación le daba un prompt a un modelo como si fuera un usuario haciendo una pregunta, el modelo respondía y un evaluador juzgaba el resultado. Los modelos de frontera actuales pueden hacer mucho más: pueden usar herramientas, seguir información a lo largo de muchos pasos y actuar dentro de un flujo de trabajo más amplio. Esto significa que el desempeño depende no solo del modelo, sino también del entorno en el que ocurre la tarea y de la configuración que facilita sus acciones. Esta configuración circundante, que llamamos “harness”, puede cambiar aspectos clave del desempeño del sistema, incluido cómo usa herramientas, conserva información o se recupera de errores.

Esto cambia cómo deben realizarse las evaluaciones y qué deberían buscar los lectores en los informes de evaluación. A nuestro juicio, los informes más útiles describen explícitamente dos cosas además del resultado en sí: primero, especifican qué afirmación se diseñó para poner a prueba la configuración de evaluación y, segundo, comparten la evidencia disponible de que el resultado de la evaluación es válido.

Las afirmaciones puestas a prueba en evaluaciones suelen caer en una de tres categorías¹:

• Elicitación de capacidad: ¿puede un modelo producir de manera plausible la capacidad que se está evaluando? 
• Desempeño de salvaguardas: ¿qué tan robustas son las salvaguardas probadas frente al comportamiento o ataque que se está evaluando?
• Comparación: ¿cómo se desempeñan distintos modelos bajo condiciones equivalentes?

Los informes de evaluación también deben explicar cómo los evaluadores verificaron efectos que podrían afectar la validez de un resultado. Estos incluyen:

• Reward hacking: explotar atajos en la tarea o en el sistema de puntuación, de modo que el sistema reciba crédito sin demostrar el comportamiento que la evaluación pretende medir.
• Rechazos: negarse de maneras que oculten el comportamiento que se está probando.
• Contaminación: sobrerendimiento porque las tareas de evaluación, las respuestas o variantes cercanas aparecieron en los datos de entrenamiento o podían descubrirse durante la evaluación, por ejemplo, mediante navegación.
• Problemas defectuosos: bajo desempeño porque las tareas no son válidas. Las razones pueden incluir puntuación injusta (por ejemplo, la respuesta correcta requiere detalles de implementación no declarados) y entornos irresolubles (por ejemplo, faltan archivos críticos o las herramientas no son confiables).
• Sandbagging: bajo desempeño deliberado cuando muestran conciencia de que están siendo evaluados.

Hemos observado que el papel del harness es especialmente importante para sistemas que actúan a lo largo de trayectorias más largas. Cuando los modelos pueden usar herramientas, mantener estado y recuperarse de errores a lo largo de muchos pasos, el harness puede cambiar el nivel de desempeño observado e incluso determinar si la capacidad que se está evaluando aparece o no en la evaluación. Por ejemplo, un harness que preserva el estado y reintenta acciones fallidas puede permitir que un modelo termine una tarea de múltiples pasos que ese mismo modelo nunca completa en un harness más simple.

En la tabla de abajo, separamos tres tipos de afirmaciones que los evaluadores pueden querer hacer y el harness que creemos que requiere cada tipo de afirmación.

Las afirmaciones sobre capacidades son tan sólidas como la elicitación que las respalda: los evaluadores deben elegir el harness que mejor se ajuste a la tarea y a la capacidad que la evaluación intenta medir. Un harness estandarizado puede ser adecuado para comparar sistemas en condiciones idénticas, pero puede subestimar la capacidad cuando omite funciones específicas del harness que ayudan al modelo a realizar la tarea. Por ejemplo, el desempeño de GPT‑5.5 en los rangos cibernéticos de OpenAI muestra cómo la elección de un harness puede cambiar materialmente la capacidad medida en tareas que requieren un uso prolongado de herramientas en múltiples pasos: el modelo se desempeña mejor cuando el harness usa compaction⁠ para preservar el contexto relevante para la tarea a medida que la interacción se alarga. Esto demuestra que, para ciertos modelos, un harness que omite compaction subestimaría el desempeño elicitable.

Otras evaluaciones publicadas² también muestran que las decisiones sobre harness y presupuesto cambian los resultados de evaluación. Aumentar el cómputo en tiempo de prueba puede cambiar significativamente qué capacidad elicita una evaluación, especialmente en ámbitos donde el éxito es fácil de verificar, como muchas tareas cibernéticas. En la evaluación de rangos cibernéticos de UK AISI⁠(se abre en una nueva ventana), aumentar el presupuesto de 10M a 100M tokens mejoró el desempeño hasta en 59 %, y el desempeño seguía aumentando en el presupuesto más alto probado. Detallar esto hace que la evaluación sea más interpretable: muestra a los lectores cómo depende el resultado de la configuración de elicitación probada. Cuando el desempeño sigue mejorando con presupuesto adicional, la puntuación debe describirse como desempeño bajo ese harness y presupuesto, no como un techo de capacidad medido. La capacidad suele depender de los recursos, en lugar de ser una cantidad fija que pueda medirse limpiamente de una vez y para siempre. Cuando el éxito puede medirse a lo largo de intentos repetidos, los informes también deberían considerar el costo esperado por resolución exitosa, no solo la tasa de éxito con un presupuesto fijo de tokens. Esto puede hacer que la gravedad sea más fácil de interpretar: una tasa de éxito baja aún puede ser prácticamente significativa si el costo de intentos repetidos está dentro del modelo de amenaza relevante. Para las afirmaciones de capacidad, una subelicitación evitable es una falla de medición: si el harness o el presupuesto impiden que el sistema exhiba un comportamiento que de otro modo podría producir, la puntuación no mide la capacidad que se afirma. Cuando los evaluadores han llevado la elicitación tan lejos como es factible y el desempeño sigue mejorando, los informes deberían decirlo claramente y dejar claro que el resultado es solo una estimación de límite inferior.

Las pruebas de salvaguardas pueden subestimar si un ataque puede tener éxito y qué tan grave podría ser cuando no consideran los recursos disponibles para los atacantes, incluidos harnesses personalizados. En la evaluación cibernética de GPT‑5.5 de UK AISI⁠(se abre en una nueva ventana), su red teaming experto encontró un jailbreak universal que elicita contenido cibernético infractor en las consultas maliciosas proporcionadas por OpenAI, incluso en entornos agénticos de múltiples turnos. Usaron Codex para crear un harness personalizado que fortaleciera el desempeño de ataque del modelo: incorporó un patrón reutilizable de evasión de salvaguardas en la interacción, preservó ese patrón entre turnos y bloques, y lo aplicó en las consultas cibernéticas maliciosas proporcionadas por OpenAI. Las pruebas de salvaguardas deben corresponder al adversario. Si la afirmación trata sobre robustez frente a uso indebido por expertos, la prueba debe evaluar la estrategia de ataque integral creíble más fuerte bajo un presupuesto definido, incluido cualquier harness necesario para preservar y reutilizar esa estrategia. De lo contrario, los resultados corren el riesgo de estar mal calibrados: podrían respaldar solo una afirmación más limitada sobre resistencia a prompts más simples, podrían pasar por alto tanto la gravedad del ataque como su probabilidad de éxito una vez que el método de elicitación se operacionaliza, y también podrían exagerar la probabilidad o gravedad de un problema si se les da demasiado presupuesto.

Hay un momento y un lugar para las comparaciones con harnesses estandarizados, pero los evaluadores deben ser explícitos sobre por qué es apropiado usar un conjunto consistente de harnesses y qué afirmación puede respaldar. La evaluación de horizonte temporal de METR⁠(se abre en una nueva ventana) es un ejemplo de una configuración de evaluación más amplia y adecuadamente fija: está diseñada para producir resultados comparables entre los sistemas que evalúa. METR define un resultado común: la duración típica de una tarea humana en la que se predice que un agente de IA tendrá éxito con un nivel dado de confiabilidad. Aplica un conjunto compartido de tareas, método de puntuación, método de ajuste y un pequeño conjunto de andamiajes reutilizables como Triframe y ReAct⁠(se abre en una nueva ventana) dentro de cada lote de estimaciones informado en conjunto. Cuando METR amplió el conjunto de tareas y trasladó la infraestructura de evaluación de un marco llamado Vivaria a otro llamado Inspect, informó el cambio (actualización Time Horizon 1.1⁠(se abre en una nueva ventana)) y volvió a evaluar modelos bajo la nueva configuración de evaluación. Ese es el valor de una configuración de evaluación estandarizada, incluido un conjunto consistente de harnesses: puede dar a los lectores confianza en que una diferencia en las puntuaciones realmente refleja una diferencia entre los sistemas comparados, y no un cambio en la configuración de medición.

Recomendamos que los informes de evaluación de terceros indiquen qué tipo de afirmación pretende respaldar su configuración de evaluación; describan qué tan de cerca lo probado refleja esa afirmación más amplia; describan las decisiones de harness que dieron forma al resultado; detallen cuándo esas decisiones cambian entre evaluaciones; e incluyan evidencia de apoyo para mostrar cómo se produjo el resultado y qué tan bien se generaliza a la afirmación.

A medida que los modelos se vuelven más capaces, las puntuaciones de evaluación se vuelven más fáciles de malinterpretar. En relación con las capacidades reales, las puntuaciones de evaluación pueden reducirse artificialmente si un modelo reconoce que está siendo evaluado y rinde estratégicamente por debajo de su nivel. Pueden inflarse si el modelo explota un atajo en la tarea, el prompt, el sistema de puntuación o el harness. También pueden distorsionarse por contaminación (cuando un modelo ya conoce o puede encontrar una respuesta sin resolver la tarea) o por problemas “defectuosos” que son ambiguos, se puntúan incorrectamente, son irresolubles o son vulnerables a atajos no intencionales. Por lo tanto, los informes de evaluación deberían acompañar las puntuaciones principales con una discusión de estos riesgos, para que los lectores puedan valorar si las puntuaciones reflejan el comportamiento previsto.

Los harnesses, presupuestos, herramientas, reglas de puntuación, monitores y procedimientos de revisión afectan si un agente está resolviendo la tarea prevista, evitándola, memorizándola o encontrando una vía para rodearla. Un informe confiable hace visibles esas verificaciones: los evaluadores deberían revisar muestras en busca de estos comportamientos cada vez que se realiza una evaluación integral.

Reward hacking

Reward hacking significa lograr puntuaciones altas de evaluación de maneras que no reflejan la capacidad prevista. Aquí, la preocupación es que el sistema reciba crédito explotando la tarea, el sistema de puntuación, el prompt o el harness, en lugar de hacer el trabajo que la evaluación pretendía medir. La evaluación de GPT 5.4 de METR⁠(se abre en una nueva ventana) muestra por qué esto importa: aunque el modelo tuvo éxito en tareas a una tasa que en una primera pasada habría correspondido a un horizonte temporal de aproximadamente 13 horas, la revisión humana mostró que algunos de esos éxitos provenían de reward hacking, y revisar los resultados para contar solo los casos sin reward hacking redujo la estimación a unas 6 horas. Los evaluadores deberían valorar la necesidad de esos ajustes y, cuando sean necesarios, informarlos claramente: una estimación de capacidad es mucho más útil cuando los lectores pueden ver qué éxitos aparentes fueron descalificados, por qué fueron descalificados y cuánto depende el resultado de ese juicio.

Rechazos

Los modelos también pueden rendir por debajo de lo esperado en evaluaciones de capacidad debido a las salvaguardas. Un modelo puede tener un desempeño de evaluación menor al que sería capaz de alcanzar porque rechaza tareas de evaluación en lugar de completarlas. Por lo tanto, los informes deberían explicar si los rechazos formaron parte de los resultados de la evaluación y, de ser así, cuántas muestras se vieron comprometidas por ellos.

Contaminación

La contaminación importa sobre todo para benchmarks públicos o reutilizados⁠. Si las tareas, respuestas o variantes cercanas aparecen en los datos de entrenamiento o pueden ser encontradas por un agente con navegación, el desempeño puede reflejar memorización o recuperación, más que desempeño del modelo. Los evaluadores deberían preferir tareas privadas o recién construidas cuando sea posible y probar si los modelos reproducen detalles específicos de la tarea antes de resolverla.

Problemas defectuosos

Los problemas defectuosos incluyen situaciones como un problema que accidentalmente no puede resolverse. Los problemas defectuosos son lo bastante comunes⁠(se abre en una nueva ventana) como para tratarlos como un riesgo estándar de validez. Incluyen verdad de referencia incorrecta, prompts ambiguos, archivos faltantes, servicios inestables, criterios de puntuación injustos y entornos que exponen atajos, como archivos ocultos con respuestas o historial del repositorio que contiene el parche de referencia.

Sandbagging

El sandbagging por parte de un modelo o sistema significa rendir estratégicamente por debajo de su nivel cuando un desempeño fuerte entraría en conflicto con algún objetivo. La evaluación de GPT‑5.5 de Apollo⁠(se abre en una nueva ventana) puso esto a prueba creando un contexto en el que el modelo entendía que puntuaciones altas de evaluación podrían activar desaprendizaje o bloquear el despliegue. GPT‑5.5 aun así respondió correctamente, lo que sugiere poca evidencia conductual de bajo desempeño estratégico³. Pero su revisión de las trazas de razonamiento añadió un contexto importante: Apollo encontró señales moderadas o mayores de conciencia de evaluación de alineación en 52 % de las muestras en condición de sandbagging, frente a 0 % en los contrafactuales. Esa evidencia complica la interpretación del resultado, pero en última instancia da a los lectores más señal: pueden ver tanto el resultado conductual tranquilizador como la razón para ser cautelosos al no sobreinterpretarlo.

Las afirmaciones sólidas requieren tanto el harness adecuado para elicitar el comportamiento como verificaciones de validez que demuestren que el resultado es sólido. Nuestra visión de que los harnesses y las verificaciones de validez forman parte del resultado de la evaluación da forma a cómo apoyamos en la práctica las evaluaciones de terceros: 

• Estamos compartiendo con los evaluadores orientación específica sobre elicitación máxima.
• Estamos pidiendo a los evaluadores de capacidades que usen Codex como piso común para los modelos de OpenAI: las pruebas deberían al menos ejecutar una línea base mediante la misma interfaz agéntica en la que probablemente confiarán los usuarios, y no solo mediante una interfaz reducida del modelo.
• También estamos poniendo a disposición trazas de razonamiento y otros artefactos intermedios cuando se necesitan para evaluar engaño, sandbagging o conciencia de evaluación. METR y Apollo han usado este acceso en evaluaciones de OpenAI desde GPT‑5. 
• Por último, estamos priorizando investigación para entender con mayor profundidad cuándo y cómo las decisiones sobre harness cambian materialmente los resultados, desde la gestión de contexto y el acceso a herramientas hasta el comportamiento de reintento, la puntuación y los presupuestos de recursos.

Estas recomendaciones no solo buscan mejorar informes de evaluación individuales, sino también orientar estándares nacionales ⁠(se abre en una nueva ventana)e internacionales ⁠(se abre en una nueva ventana)emergentes para la evaluación y el reporte de IA de frontera. En adelante, los estándares para evaluaciones de terceros deberían exigir suficiente detalle para que quienes toman decisiones entiendan qué afirmaciones respaldan las evaluaciones específicas, qué sistema se probó, cómo se elicitó el resultado y cómo los evaluadores verificaron su validez. Para sistemas de frontera probados en tareas donde importan las capacidades agénticas, los detalles deberían incluir, sujeto a cualquier preocupación de seguridad o confidencialidad:

• La afirmación: si la evaluación compara sistemas, estima un techo de capacidad o prueba salvaguardas.
• Contenido de la evaluación: suficiente detalle sobre las tareas o la distribución de tareas para que los lectores entiendan qué habilidades, comportamientos o modos de falla está probando realmente la evaluación.
• El sistema probado: el modelo, la configuración de razonamiento, el acceso a herramientas, el harness y las salvaguardas.
• El presupuesto: turnos, tokens, intentos/reintentos, tiempo de reloj, costo de inferencia y, cuando corresponda, costo esperado por resolución exitosa.
• Métodos de elicitación: decisiones de harness usadas para extraer el resultado y qué tan de cerca lo probado refleja la afirmación más amplia que se está haciendo.
• Verificaciones de validez: cómo los evaluadores buscaron reward hacking, conciencia de evaluación, contaminación, rechazos, sandbagging y otros comportamientos que podrían socavar el resultado, incluido cómo los casos confirmados afectaron la puntuación o la interpretación.

Los estándares que omiten las decisiones sobre harness o las verificaciones de validez pueden subestimar lo que un sistema puede hacer o exagerar la confianza en una afirmación de seguridad. Desarrollar harnesses sólidos y métodos de elicitación sigue siendo un área abierta de investigación y debería ser un foco de mayor estudio e inversión.