Benchmark IA: de la puntuación a la prueba auditable

Lo esencial

• Un benchmark IA mide cómo se comporta un modelo ante un conjunto fijo de tareas, bajo una regla de puntuación conocida. Responde a qué modelo rinde mejor en esa prueba, no a si su sistema resulta idóneo para la finalidad prevista.
• El Reglamento de IA obliga a los proveedores de sistemas de alto riesgo a declarar sus métricas de exactitud en las instrucciones de uso. La obligación recae sobre su métrica, no sobre la clasificación de un tercero.
• Las puntuaciones públicas pierden valor probatorio: las pruebas más citadas están saturadas y sus preguntas, al publicarse, acaban en los corpus de entrenamiento.
• Un resultado solo se convierte en evidencia cuando puede acreditarse qué se ejecutó, sobre qué datos, contra qué versión del modelo, por quién y cuándo.
• La evidencia que supera una auditoría casi siempre procede de un conjunto de prueba interno derivado de la finalidad prevista, no de una clasificación pública.

Qué mide realmente un benchmark IA

Un benchmark IA es una prueba normalizada: un conjunto fijo de datos de entrada, unas salidas esperadas y una regla de puntuación que convierte el comportamiento del modelo en un número comparable. Puesto que todos los modelos afrontan las mismas entradas bajo la misma regla, el benchmark transforma una impresión en una cifra sobre la que dos interlocutores pueden discutir con los mismos hechos delante. Es una herramienta genuinamente útil, y ahí empiezan precisamente los problemas. Un benchmark es una muestra finita extraída de una distribución. El trabajo al que usted destina un modelo de inteligencia artificial pertenece, en cambio, a un conjunto abierto de situaciones procedentes de una distribución mucho más desordenada. La puntuación sigue siendo siempre una medida indirecta, y la distancia entre esa medida y lo que a usted le importa nunca aparece impresa en la clasificación.

Los tres componentes de un benchmark

Todo benchmark consta de tres elementos, y cada uno puede fallar con independencia de los demás.

• El conjunto de datos: las entradas y, por lo general, las salidas de referencia contra las que se puntuúa.
• El método de evaluación: la regla que convierte las salidas en puntuación. Cotejo de respuestas en los cuestionarios de opción múltiple, ejecución de pruebas unitarias en el código, o un juez algorítmico para las producciones abiertas.
• La clasificación: la tabla que hace comparables los resultados y que, de paso, los vuelve rentables de manipular.

La verdad de referencia merece atención particular, porque limita en silencio todo lo que se apoya sobre ella. Si la clave de corrección es errónea, una respuesta correcta del modelo se contabiliza como fallo y el resultado entero hereda ese ruido.

Las familias de capacidades y sus puntos ciegos

Ninguna prueba aislada recoge lo que un modelo sabe hacer, de modo que la disciplina divide la evaluación por capacidades. Solo una lectura transversal ofrece una imagen honesta.

• Conocimiento (MMLU, MMLU-Pro): amplitud del recuerdo factual. El MMLU original está ya muy saturado, de manera que las diferencias pequeñas entre modelos punteros no transmiten señal alguna.
• Razonamiento (GPQA Diamond, Humanity’s Last Exam): resolución en varios pasos sobre preguntas deliberadamente difíciles. Difíciles hoy, objetivo de contaminación mañana.
• Código (SWE-bench Verified, LiveCodeBench): corrección de incidencias reales en un repositorio en lugar de redacción de funciones aisladas. Las pruebas a nivel de función han perdido casi todo su poder discriminante.
• Agentes (GAIA): planificación y uso de herramientas a lo largo de varios pasos. Los resultados dependen tanto del andamiaje que rodea al modelo como del modelo mismo.
• Multimodal (MMMU): razonamiento sobre texto, imágenes y diagramas. Un modelo textual solvente puede obtener aquí una puntuación débil.
• Preferencia humana (Arena Elo): qué respuesta prefieren las personas en comparaciones ciegas. Mide preferencia y estilo, no corrección, y ambas divergen con más frecuencia de lo que la clasificación sugiere.

Para los equipos que trabajan específicamente con modelos de lenguaje, el desglose familia por familia figura en nuestra guía de benchmarks de LLM. Lo que sigue vale para cualquier clase de modelo.

Cuándo la puntuación se convierte en obligación normativa

La mayor parte de la literatura trata el benchmark IA como una costumbre de ingeniería. Para quien introduce un sistema en el mercado europeo se parece más a una obligación documental, y ese cambio de marco modifica lo que se entiende por buen benchmark.

Artículo 15: declarar la métrica de exactitud propia

El artículo 15 del Reglamento de IA exige que los sistemas de alto riesgo alcancen un nivel adecuado de exactitud, solidez y ciberseguridad, y que funcionen de manera uniforme en esos aspectos durante todo su ciclo de vida. La frase decisiva para los equipos de gobernanza es la siguiente: los niveles de exactitud y las métricas de exactitud pertinentes deben declararse en las instrucciones de uso que acompañan al sistema. Esta redacción invierte el reflejo habitual. La obligación no consiste en puntuar bien en una prueba pública reconocida, sino en nombrar la métrica que usted considera pertinente para su sistema, declarar el nivel alcanzado y responder de ambos. Una posición en una clasificación no libera de este deber, y citarla en lugar de una medición propia deja una laguna que un evaluador detecta enseguida. El texto sí contempla referencias compartidas. Encomienda a la Comisión que, en cooperación con las partes interesadas y con organizaciones como las autoridades de metrología y evaluación comparativa, fomente el desarrollo de parámetros de referencia y metodologías de medición. Ese trabajo sigue en curso, de modo que la carga de elegir y justificar una métrica recae por ahora sobre el proveedor. El artículo 15 se aplica desde el 2 de agosto de 2026, plazo que cae dentro del horizonte de planificación descrito en nuestra guía operativa del Reglamento de IA.

Modelos de uso general: artículo 55 y código de buenas prácticas

Los proveedores de modelos de uso general soportan una obligación de evaluación propia y mucho más explícita. El código de buenas prácticas GPAI publicado por la Oficina Europea de IA en julio de 2025 obliga a los proveedores de modelos con riesgo sistémico, umbral fijado hoy en una potencia de cálculo de entrenamiento superior a 10^25 FLOPs, a mantener un marco de seguridad que abarque evaluaciones del modelo, ejercicios de equipo rojo, seguimiento posterior a la comercialización, ciberseguridad y notificación de incidentes. Aquí la evaluación ya no es un ejercicio comparativo, sino una argumentación de seguridad, y debe mantenerse tras la publicación en lugar de producirse una sola vez en el lanzamiento. Quienes despliegan sobre estos modelos heredan las consecuencias, razón por la cual tratamos las evidencias de evaluación del proveedor como un dato de compra y no como una curiosidad técnica, tal y como se explica en nuestro manual del Reglamento europeo de inteligencia artificial.

ISO 42001 y NIST AI RMF: la lectura de sistema de gestión

Dos referencias voluntarias convierten la evaluación comparativa de actividad en proceso gobernado. La norma ISO/IEC 42001 sitúa la evaluación del desempeño dentro de un sistema de gestión certificable. Desde el momento en que una campaña de medición cae bajo el capítulo 9, deja de ser una diapositiva para convertirse en un registro con responsable, periodicidad y pista de auditoría. El NIST AI Risk Management Framework resulta más directo. Su función MEASURE aplica métricas, parámetros de referencia, pruebas y análisis a las características de fiabilidad, y reclama una evaluación comparativa periódica tanto del sistema como de la práctica de gestión de riesgos que lo rodea. Los trabajos del NIST sobre prueba, evaluación, verificación y validación fijan el listón sin rodeos: esos procesos deben ser objetivos, repetibles o escalables, estar implantados, seguirse y documentarse, y ajustarse a las normas científicas, jurídicas y éticas en un procedimiento abierto y transparente. Esa única frase es la especificación más útil de un benchmark defendible que se haya escrito. Conviene reparar en lo que no dice: nada sobre qué prueba ejecutar, y todo sobre si un tercero podría repetirla y obtener el mismo resultado.

Por qué una puntuación pública es una evidencia débil

La crítica a las puntuaciones publicadas no es una postura contraria por gusto: procede de la propia literatura de la evaluación.

Saturación y contaminación

Las pruebas más citadas están saturadas. Los modelos punteros se agrupan a uno o dos puntos unos de otros, y la dispersión restante obedece a menudo a preguntas ambiguas o mal etiquetadas antes que a una diferencia de capacidad. Un examen en el que todos sacan la máxima nota ya no puede cumplir su única función. Más grave resulta la contaminación. Los benchmarks se publican abiertamente para que la comunidad pueda reproducirlos, lo que envía sus preguntas y respuestas a los corpus web con los que se entrena la generación siguiente. Un modelo que ha visto de hecho la prueba durante el entrenamiento la aprueba sin generalizar. Las revisiones sobre contaminación lo expresan sin rodeos: la puntuación mide memorización y no capacidad, y desde la clasificación no se aprecia la diferencia.

Ley de Goodhart y validez de constructo

Cuando una medida se convierte en objetivo, deja de ser una buena medida. Desde el momento en que un benchmark es la cifra que los laboratorios anuncian y por la que filtran los compradores, el incentivo se desplaza de construir mejores modelos a obtener mejores puntuaciones. El fenómeno está documentado. Una meta-revisión interdisciplinar vinculada al Centro Común de Investigación de la Comisión Europea, Can We Trust AI Benchmarks?, identifica nueve problemas sistémicos de la evaluación comparativa, entre ellos incentivos desalineados, deficiencias de validez de constructo y riesgos de manipulación. La validez de constructo es la cuestión más silenciosa: pregunta si una prueba mide de verdad lo que dice medir, y una proporción sorprendente de los benchmarks publicados no logra acreditarlo. El manual divulgativo Benchmarks 101 de Aspen Digital propone una taxonomía de fallos en tres apartados: datos de baja calidad, medición o diseño defectuosos, resultados mal interpretados. Conviene tener presente su ejemplo ante la próxima puntuación de titular. Diversos investigadores comprobaron que alrededor del 30 por ciento de las preguntas de biología y química de Humanity’s Last Exam, un benchmark concebido precisamente para ser difícil, tenían respuestas erróneas o insostenibles.

La brecha entre el laboratorio y el terreno

Los benchmarks miden en laboratorio, no sobre el terreno. Además intervienen antes de lo que suele suponerse en el ciclo de vida, en la definición de objetivos y en la construcción del modelo, mientras que la evaluación de impacto y los ejercicios de equipo rojo llegan después, cuando ya existe un sistema al que someter a prueba. Las consecuencias no son teóricas. Aspen Digital documenta modelos de dermatología evaluados sobre el conjunto de datos de la International Skin Imaging Collaboration: su puntuación global era alta, y su rendimiento se degradaba de forma apreciable en pieles oscuras en cuanto las métricas se desglosaban por fototipo. La cifra agregada era exacta y la conclusión que de ella se extraía era falsa. Ese ejemplo traza la frontera de la que trata este artículo. Una puntuación de capacidad no equivale a una garantía en materia de derechos fundamentales, y ninguna cantidad de puntuación sustituye a las pruebas desglosadas que describe nuestra guía sobre el sesgo de la IA. La evaluación de la equidad es una obligación distinta, con método distinto, y no un apartado de la medición del rendimiento.

Qué puede y qué no puede probar un benchmark

Los equipos de gobernanza necesitan una frontera aplicable sin reabrir cada vez el debate científico. Esta es la nuestra.

Un benchmark PUEDE probar	Un benchmark NO PUEDE probar
Una capacidad relativa sobre una tarea definida, en un momento dado	La idoneidad para su finalidad prevista
Una regresión entre dos versiones del modelo sobre un conjunto interno congelado	Por sí solo, la métrica de exactitud declarada que exige el artículo 15
Que existe y se ha seguido un procedimiento de medición documentado y repetible	La ausencia de impacto discriminatorio sobre los grupos afectados
Un filtro previo para elaborar una lista corta	La resistencia frente a entradas adversarias o fuera de distribución
El progreso agregado de una capacidad a lo largo del tiempo	El mantenimiento del rendimiento tras una actualización silenciosa del proveedor
Que una afirmación concreta se ha verificado y no solo enunciado	Por sí solo, el cumplimiento de cualquier marco

La lectura cabe en una frase. Un benchmark solo resulta admisible como evidencia si puede acreditarse qué se ejecutó, sobre qué datos, contra qué versión del modelo, por quién y cuándo. Todo lo que figura en la columna izquierda depende de que ese registro exista. Nada de la columna derecha se vuelve cierto porque una puntuación fuera alta. Allí donde el benchmark no puede soportar la carga, esta recae sobre los controles descritos en nuestra guía de gestión de riesgos de IA.

Cómo construir un benchmark interno que resista una auditoría

La conclusión práctica de todo lo anterior es que el benchmark que merece inversión suele ser el que usted construye.

Partir de la finalidad prevista, no de la clasificación

La finalidad prevista es la noción eje del Reglamento de IA y el punto de partida correcto para un conjunto de prueba. Deje por escrito para qué sirve el sistema, a quién afecta y cuánto cuesta una respuesta equivocada en cada caso. Reúna después entradas reales, incluidas las incómodas: solicitudes ambiguas, casos límite, datos mal formados. Exige más trabajo que leer una clasificación, y la evaluación resultante no se generalizará más allá de su caso de uso. Ese es justamente el objetivo. Un modelo que encabeza una referencia pública y rinde mal en su tarea sigue siendo el modelo equivocado para su despliegue, sean cuales sean sus puntuaciones.

Procedencia de los datos y conjuntos reservados

Tres propiedades separan un conjunto de prueba fiable de otro que le desvía en silencio.

1. El modelo no ha visto los datos. Utilice datos reservados, datos generados al efecto o datos posteriores a la fecha de corte del entrenamiento. En caso contrario está midiendo memorización.
2. Los datos reflejan su dominio real. Un texto web genérico no dice nada sobre cómo trata un modelo informes clínicos, expedientes de crédito o incidencias internas, cuyo vocabulario, estructura y ambigüedad no se parecen en nada a un párrafo enciclopédico.
3. La verdad de referencia es realmente correcta. Cada puntuación se mide contra una clave de corrección, y una clave defectuosa pone techo a un buen modelo mientras premia los comportamientos equivocados.

Estas exigencias se contraponen entre sí, y conviene decirlo con claridad. Los datos más realistas suelen ser los más sensibles, por tanto impublicables, y publicarlos contaminaría de todos modos los modelos futuros. El etiquetado manual a gran escala introduce precisamente los errores de referencia contra los que advierte la tercera propiedad. Los equipos lo resuelven con generación sintética, seudonimización cuidadosa o conjuntos estrechos pero rigurosamente curados. Ninguna opción elimina del todo la disyuntiva.

Versionado, reproducibilidad y conservación

La repetibilidad y la reproducibilidad no son aquí una comodidad de ingeniería. El marco de pruebas AI Verify las trata como principio de gobernanza por derecho propio y estructura cada control en tres tiempos: el resultado buscado, el proceso y la evidencia que lo valida. Ese esquema coincide con lo que un evaluador reclamará. Una campaña de medición debe dejar tras de sí un registro que contenga, como mínimo:

• el protocolo de prueba y la regla de puntuación
• la versión del conjunto de datos y su huella
• el identificador del modelo, su versión y el punto de acceso empleado
• el entorno de ejecución, los parámetros y el carácter zero-shot o few-shot de la campaña
• la fecha, la persona que ejecutó la prueba y las salidas en bruto junto a la puntuación calculada
• el plazo de conservación y la ubicación de los artefactos

Esa lista es lo que transforma un número en un artefacto. Es también lo que separa un sistema auditable de otro que sencillamente rindió bien una vez, distinción que desarrollamos en auditabilidad de la IA. Estos registros pertenecen a la documentación técnica que exige el Reglamento de IA, y no a una carpeta aparte en manos del equipo de ciencia de datos.

Cómo interrogar las puntuaciones que declara un proveedor

Las tablas de benchmark son la primera evidencia que todo proveedor pone sobre la mesa, y rara vez se cuestionan. Siete preguntas hacen casi todo el trabajo.

1. ¿Qué regla de puntuación se ha usado, y coincide con nuestra comparación? Exactitud, pass@k y Elo no son intercambiables. Un pass@1 y un pass@10 del mismo modelo miden cosas distintas, y una diferencia de Elo describe una tasa de victorias en enfrentamiento directo, no un porcentaje de capacidad.
2. ¿Zero-shot o few-shot? Las cifras few-shot resultan sistemáticamente más altas.
3. ¿Conjunto completo o subconjunto verificado? Los subconjuntos revisados por personas, depurados de elementos defectuosos, arrojan números más limpios y más altos.
4. ¿Quién realizó la evaluación? Una puntuación producida por el proveedor en su propio entorno no es comparable con una medición independiente.
5. ¿Es público el conjunto de prueba, y pudo filtrarse al entrenamiento? Quien no haya examinado la contaminación entrega una puntuación inservible.
6. ¿Cuándo se midió, respecto de la versión que hoy sirve la API? Los proveedores actualizan modelos en silencio detrás de nombres de API estables.
7. ¿Aceptarían repetir la campaña sobre nuestro conjunto reservado, bajo acuerdo de confidencialidad? La respuesta a esta es la más reveladora de todas.

Un proveedor incapaz de responder le está pidiendo que acepte una cifra de marketing como artefacto de garantía. Eso es un hallazgo de riesgo de terceros, no una nota técnica al pie, y corresponde a la misma evaluación que las cuestiones de plataforma tratadas en nuestro análisis de herramientas de gobernanza de IA.

Preguntas frecuentes

¿Qué es un benchmark IA? Un benchmark IA es una prueba normalizada, compuesta por un conjunto de datos fijo y una regla de puntuación, que produce cifras de rendimiento comparables entre modelos. Se emplea para comparar candidatos, seguir el progreso entre versiones y detectar regresiones. Mide el rendimiento sobre las tareas de la prueba, que pueden parecerse o no a las que a usted le importan. ¿Exige el Reglamento de IA realizar benchmarks? No en esos términos. El artículo 15 requiere de los sistemas de alto riesgo un nivel adecuado de exactitud, solidez y ciberseguridad, un funcionamiento uniforme a lo largo del ciclo de vida y la declaración de los niveles y las métricas de exactitud pertinentes en las instrucciones de uso. Eso presupone una práctica de medición defendible, sin prescribir una referencia pública concreta. El texto encomienda además a la Comisión fomentar el desarrollo de parámetros de referencia y metodologías de medición junto a las autoridades de metrología y evaluación comparativa, trabajo todavía en curso. Los proveedores de modelos de uso general con riesgo sistémico afrontan una obligación de evaluación más explícita al amparo del artículo 55 y del código de buenas prácticas GPAI. ¿Siguen siendo útiles los benchmarks públicos? Sí, como primer filtro y no como veredicto. Reducen rápidamente un campo de candidatos y dejan al descubierto las debilidades evidentes. No pueden decirle cómo se comporta un modelo con sus datos, en su dominio y bajo sus restricciones, y la saturación y la contaminación han ensanchado esa brecha. Trate una posición en la clasificación como una hipótesis por verificar. ¿Qué es la contaminación de datos de benchmark? Hay contaminación cuando las preguntas y respuestas de un benchmark aparecen en los datos de entrenamiento de un modelo. Como los benchmarks se publican abiertamente para permitir su reproducción, acaban de forma habitual en los corpus de entrenamiento. Un modelo contaminado devuelve respuestas memorizadas y obtiene una puntuación alta que se desmorona ante problemas nuevos del mismo tipo. El fenómeno es difícil de detectar, rara vez se declara y constituye la razón principal de la divergencia entre puntuaciones públicas y rendimiento real. ¿En qué se diferencia un benchmark de una auditoría de IA? Un benchmark mide el rendimiento de un modelo sobre una tarea definida. Una auditoría de IA examina el sistema y la organización que lo rodea: gobernanza, gestión de riesgos, procedencia de los datos, supervisión humana, documentación y las evidencias que respaldan cada afirmación. Los resultados de benchmark son un insumo de la auditoría. Tomados en solitario responden a una pregunta técnica estrecha, y el auditor querrá saber cómo se diseñó, versionó y conservó la campaña antes de aceptar la cifra. ¿Cuántos benchmarks conviene ejecutar sobre un sistema de alto riesgo? Menos de los que la mayoría de los equipos supone, pero mejor escogidos. Un conjunto de prueba interno derivado de la finalidad prevista vale más que cinco referencias públicas, porque es el único cuyos resultados hablan de idoneidad para el uso. Añada una evaluación de equidad con resultados desglosados por grupo afectado y una prueba de resistencia frente a entradas adversarias y fuera de distribución. Esas tres campañas, versionadas y repetibles, componen un expediente más sólido que cualquier colección de citas de clasificaciones.

Conclusión

El benchmark IA no está averiado, está mal archivado. Tratado como ejercicio de clasificación produce teatro de compras: una tabla de cifras que nadie puede repetir, sobre tareas que nadie en la sala ha examinado, referidas a versiones de modelo ya sustituidas. Tratado como práctica de medición produce algo que un evaluador sí puede utilizar. El cambio es pequeño y sobre todo organizativo. Derive la prueba de la finalidad prevista. Reserve los datos. Registre protocolo, versiones, operador y fecha. Guarde los artefactos donde reside el resto del expediente técnico. Diga con claridad qué no prueba el resultado. Esta última disciplina es la que más pesa. La posición más sólida ante un regulador no es una puntuación alta, sino una medición documentada, una exposición honesta de sus límites y controles que cubran todo aquello que la medición deja abierto. Enlazar esos registros con los controles que sostienen, en lugar de dispersarlos entre presentaciones y cuadernos, es el trabajo concreto de un marco de gobernanza de la IA.