Una guía compartida para evaluaciones fiables de terceros

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

Antes, muchas evaluaciones trataban los modelos como chatbots: la evaluación 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 vanguardia 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 rendimiento no depende solo del modelo, sino también del entorno en el que tiene lugar la tarea y de la configuración que facilita sus acciones. Esta configuración circundante, que llamamos «harness», puede cambiar aspectos clave del rendimiento del sistema, incluido cómo usa herramientas, cómo sigue la información o cómo se recupera de errores.

Esto cambia cómo deben realizarse las evaluaciones y en qué deberían fijarse los lectores en los informes de evaluación. En nuestra opinión, los informes más útiles describen explícitamente dos cosas además del propio resultado: 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 encajar en una de estas tres categorías¹:

• Elicitación de capacidades: ¿puede un modelo producir de forma plausible la capacidad que se está evaluando? 
• Rendimiento de las salvaguardas: ¿hasta qué punto son robustas las salvaguardas probadas frente al comportamiento o ataque que se está evaluando?
• Comparación: ¿cómo rinden distintos modelos en condiciones equivalentes?

Los informes de evaluación también deben explicar cómo comprobaron los evaluadores los efectos que podrían afectar a la validez de un resultado. Entre ellos se incluyen:

• Reward hacking: explotar atajos en la tarea o en el sistema de puntuación, de modo que el sistema obtenga crédito sin demostrar el comportamiento que la evaluación pretende medir.
• Negativas: negarse de formas que oculten el comportamiento que se está probando.
• Contaminación: sobrerendir 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 rendimiento porque las tareas no son válidas. Las razones pueden incluir una puntuación injusta (p. ej., la respuesta correcta requiere detalles de implementación no indicados) y entornos irresolubles (p. ej., faltan archivos críticos o las herramientas no son fiables).
• Sandbagging: rendir deliberadamente por debajo de lo esperado cuando muestran conciencia de estar siendo evaluados.

Hemos observado que el papel del harness es especialmente importante para los 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 rendimiento observado e incluso determinar si la capacidad que se está valorando aparece o no en la evaluación. Por ejemplo, un harness que preserve el estado y reintente acciones fallidas puede permitir que un modelo termine una tarea de varios pasos que ese mismo modelo nunca completa en un harness más simple.

En la tabla siguiente, 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 solo son tan sólidas como la elicitación que hay detrás: 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 infravalorar la capacidad cuando omite funciones específicas del harness que ayudan al modelo a realizar la tarea. Por ejemplo, el rendimiento de GPT‑5.5 en los rangos cibernéticos de OpenAI muestra cómo la elección de un harness puede cambiar sustancialmente la capacidad medida en tareas que requieren un uso prolongado y de varios pasos de herramientas: el modelo rinde 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 omita compaction infraelicitaría el rendimiento.

Otras evaluaciones publicadas² también muestran que las elecciones de 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 ventana nueva), aumentar el presupuesto de 10M a 100M tokens mejoró el rendimiento hasta en un 59 %, y el rendimiento 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 rendimiento sigue mejorando con presupuesto adicional, la puntuación debe describirse como rendimiento 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 por todas. Cuando el éxito puede medirse a lo largo de intentos repetidos, los informes también deberían considerar el coste esperado por resolución exitosa, no solo la tasa de éxito con un presupuesto fijo de tokens. Esto puede facilitar la interpretación de la gravedad: una tasa de éxito baja puede seguir siendo relevante en la práctica si el coste de los intentos repetidos encaja en el modelo de amenaza pertinente. Para las afirmaciones sobre capacidades, una infraelicitación evitable es un fallo de medición: si el harness o el presupuesto impiden que el sistema muestre 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 rendimiento sigue mejorando, los informes deberían decirlo claramente y dejar claro que el resultado es solo una estimación de cota inferior.

Las pruebas de salvaguardas pueden infravalorar si un ataque puede tener éxito y cuán grave podría ser si no tienen en cuenta 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 ventana nueva), su red teaming experto encontró un jailbreak universal que elicitó contenido cibernético infractor en las consultas maliciosas proporcionadas por OpenAI, incluso en entornos agénticos de varios turnos. Usaron Codex para crear un harness personalizado con el fin de reforzar el rendimiento de ataque del modelo: incorporaba a la interacción un patrón reutilizable de evasión de salvaguardas, preservaba ese patrón entre turnos y bloques y lo aplicaba a las consultas cibernéticas maliciosas proporcionadas por OpenAI. Las pruebas de salvaguardas deben ajustarse al adversario. Si la afirmación trata sobre la robustez frente a un uso indebido por expertos, la prueba debería evaluar la estrategia de ataque integral creíble más fuerte con 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 que alcanza el ataque como su probabilidad de éxito una vez operacionalizado el método de elicitación, y también podrían exagerar la probabilidad o gravedad de un problema si se le asigna demasiado presupuesto.

Las comparaciones con harnesses estandarizados tienen su momento y su lugar, pero los evaluadores deberían explicar explícitamente por qué es apropiado usar un conjunto coherente de harnesses y qué afirmación puede respaldar. La evaluación de horizonte temporal de METR⁠(se abre en una ventana nueva) 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 de fiabilidad dado. Aplica un conjunto compartido de tareas, un método de puntuación, un método de ajuste y un pequeño conjunto de andamiajes reutilizables como Triframe y ReAct⁠(se abre en una ventana nueva) dentro de cada lote de estimaciones informado conjuntamente. Cuando METR amplió el conjunto de tareas y trasladó la infraestructura de evaluación de un marco llamado Vivaria a otro llamado Inspect, informó del cambio (actualización Time Horizon 1.1⁠(se abre en una ventana nueva)) y volvió a evaluar modelos con la nueva configuración de evaluación. Ese es el valor de una configuración de evaluación estandarizada, incluido un conjunto coherente de harnesses: puede dar a los lectores confianza en que una diferencia en las puntuaciones refleja realmente 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 hasta qué punto lo probado refleja esa afirmación más amplia; describan las elecciones de harness que dieron forma al resultado; detallen cuándo esas elecciones cambian entre evaluaciones; e incluyan evidencia de apoyo para mostrar cómo se produjo el resultado y hasta qué punto 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 lo esperado. 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, están puntuados incorrectamente, son irresolubles o son vulnerables a atajos no deseados. Por ello, los informes de evaluación deberían acompañar las puntuaciones principales con un análisis 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 todos a si un agente está resolviendo la tarea prevista, evitándola, memorizándola o encontrando una vía para rodearla. Un informe fiable hace visibles esas comprobaciones: los evaluadores deberían revisar muestras de estos comportamientos cada vez que se realiza una valoración.

Reward hacking

Reward hacking significa lograr puntuaciones altas en la evaluación de formas que no reflejan la capacidad prevista. Aquí, la preocupación es que el sistema obtenga 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 ventana nueva) muestra por qué esto importa: aunque el modelo tuvo éxito en tareas a un ritmo que en una primera pasada habría registrado un horizonte temporal de unas 13 horas, la revisión humana mostró que algunos de esos éxitos procedí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 este tipo de ajustes y, cuando sean necesarios, informar de ellos con claridad: una estimación de capacidad es mucho más útil cuando los lectores pueden ver qué éxitos aparentes fueron descalificados, por qué lo fueron y cuánto depende el resultado de ese juicio.

Negativas

Los modelos también pueden rendir por debajo de lo esperado en evaluaciones de capacidad debido a las salvaguardas. Un modelo puede tener un rendimiento en evaluación inferior a su capacidad porque se niega a realizar tareas de evaluación en lugar de completarlas. Por ello, los informes deberían explicar si las negativas formaron parte de los resultados de la evaluación y, en caso afirmativo, cuántas muestras se vieron comprometidas por ellas.

Contaminación

La contaminación importa sobre todo en benchmarks públicos o reutilizados⁠. Si las tareas, las respuestas o variantes cercanas aparecen en los datos de entrenamiento o pueden ser encontradas por un agente con navegación, el rendimiento puede reflejar memorización o recuperación, en lugar del rendimiento del modelo. Los evaluadores deberían preferir, cuando sea posible, tareas privadas o de nueva construcción y comprobar 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 ventana nueva) como para tratarlos como un riesgo estándar para la validez. Incluyen una verdad de referencia incorrecta, prompts ambiguos, archivos ausentes, servicios inestables, criterios de puntuación injustos y entornos que exponen atajos como archivos de respuestas ocultos 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 lo esperado cuando un rendimiento alto entraría en conflicto con algún objetivo. La evaluación de GPT‑5.5 de Apollo⁠(se abre en una ventana nueva) puso esto a prueba creando un contexto en el que el modelo entendía que unas puntuaciones altas en la evaluación podrían desencadenar un desaprendizaje o bloquear el despliegue. GPT‑5.5 siguió respondiendo correctamente, lo que sugiere poca evidencia conductual de bajo rendimiento estratégico³. Pero su revisión de las trazas de razonamiento añadió un contexto importante: Apollo encontró indicios moderados o superiores de conciencia de evaluación de alineación en el 52 % de las muestras en condición de sandbagging, frente al 0 % en los contrafactuales. Esa evidencia complica la interpretación del resultado, pero en última instancia ofrece más señal a los lectores: pueden ver tanto el resultado conductual tranquilizador como la razón para ser cautos para no sobreinterpretarlo.

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

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

Estas recomendaciones no solo pretenden mejorar los informes de evaluación individuales, sino también orientar las normas nacionales ⁠(se abre en una ventana nueva)e internacionales ⁠(se abre en una ventana nueva)emergentes para la evaluación y la elaboración de informes sobre IA de vanguardia. De cara al futuro, las normas para evaluaciones de terceros deberían exigir suficiente detalle para que los responsables de la toma de decisiones entiendan qué afirmaciones respaldan las evaluaciones concretas, qué sistema se probó, cómo se elicitó el resultado y cómo comprobaron los evaluadores su validez. Para sistemas de vanguardia probados en tareas donde importan las capacidades agénticas, los detalles deberían incluir, con sujeción 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 fallo 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, coste de inferencia y, cuando corresponda, coste esperado por resolución exitosa.
• Métodos de elicitación: las elecciones de harness usadas para extraer el resultado y hasta qué punto lo probado refleja la afirmación más amplia que se está haciendo.
• Comprobaciones de validez: cómo buscaron los evaluadores reward hacking, conciencia de evaluación, contaminación, negativas, sandbagging y otros comportamientos que podrían socavar el resultado, incluido cómo afectaron los casos confirmados a la puntuación o a la interpretación.

Las normas que omiten las elecciones de harness o las comprobaciones de validez pueden infravalorar lo que un sistema puede hacer o exagerar la confianza en una afirmación de seguridad. Seguir desarrollando harnesses sólidos y métodos de elicitación sigue siendo un área de investigación abierta y debería ser un foco de mayor estudio e inversión.