Benchmarks de LLM: guía de cumplimiento para equipos de gobernanza de IA

Lo esencial

• Los benchmarks de LLM son dispositivos estandarizados que combinan un conjunto de datos, una tarea, una métrica y un mecanismo de puntuación para medir una capacidad concreta de un modelo de lenguaje grande de forma comparable entre modelos.
• Los benchmarks públicos como MMLU, HumanEval, MT-Bench o la suite HELM de Stanford monopolizan la conversación, pero ninguno fue diseñado para responder a una pregunta de un regulador.
• El Reglamento europeo de IA, el marco AI RMF del NIST y la norma ISO/IEC 42001 exigen alguna forma de evaluación del modelo: los benchmarks son el instrumento operativo que vuelve esa obligación medible.
• Una puntuación de benchmark público no demuestra, por sí sola, la conformidad. La contaminación de los conjuntos de prueba, el sobreajuste y la llamada evaluation awareness rompen el vínculo entre un número de clasificación y el comportamiento real en producción.
• Un portafolio de benchmarks listo para la gobernanza combina unos pocos benchmarks públicos bien documentados con un benchmark interno anclado en sus propios casos de uso, riesgos y criterios de aceptación.

Qué es realmente un benchmark de LLM

Los benchmarks de LLM son marcos estandarizados que miden cómo se comporta un modelo en una tarea definida. Si se quitan los envoltorios de marketing, cada benchmark se compone de las mismas cuatro piezas: un conjunto de datos de ejemplo, un conjunto de preguntas o tareas, una o varias métricas y un mecanismo de puntuación que convierte la salida del modelo en un número comparable (IBM Think). La estandarización sirve únicamente para permitir la comparación, dos modelos reciben las mismas preguntas, se puntuán igual, y cualquier diferencia refleja el modelo, no el diseño del test. En la práctica, los benchmarks se administran en uno de tres modos. En zero-shot el modelo recibe solo la descripción de la tarea y debe generalizar a partir de su entrenamiento. En few-shot se añaden al prompt algunos ejemplos resueltos para ver con qué rapidez el modelo capta un patrón. La evaluación fine-tuned entrena primero el modelo con datos parecidos al benchmark, lo que aumenta las puntuaciones, pero solo resulta útil si su despliegue real también va a estar fine-tuned. La métrica principal varía según el benchmark. Los tests de elección múltiple usan accuracy. Los benchmarks de código emplean pass@k, la probabilidad de que al menos una de las k soluciones generadas pase los tests unitarios. La traducción usa BLEU, el resumen ROUGE, la clasificación precisión, recall y F1, el modelado de lenguaje la perplejidad. La mayoría de las clasificaciones agrega varias de estas métricas en un único número, lo que facilita el ranking y dificulta la interpretación. Para un público de cumplimiento, lo más importante es entender lo que los benchmarks no son. No son certificaciones. No son pruebas de aceptación validadas por un regulador. No sustituyen a una evaluación interna de su sistema concreto, sobre sus datos concretos, frente a sus riesgos concretos. Sí son lo más cercano a un vocabulario compartido para hablar de lo que un LLM sabe hacer, y ese vocabulario es hoy estructurante en toda regulación de IA relevante en vigor.

El panorama de benchmarks en 2026 (el mapa para un responsable de cumplimiento)

El catálogo de benchmarks crece rápido, pero las familias que aparecen realmente en los informes de evaluación de proveedores y en los expedientes presentados a los reguladores son más reducidas de lo que el ruido del mercado sugiere.

Benchmarks de LLM para razonamiento y comprensión del lenguaje

MMLU (Massive Multitask Language Understanding) cubre 57 materias con más de 15 000 preguntas de elección múltiple y sigue siendo el primer dato que cita cualquier lanzamiento de modelo (paper de MMLU). HellaSwag prueba el sentido común mediante completado de frases con distractores filtrados de manera adversaria. ARC (AI2 Reasoning Challenge) usa preguntas de ciencias de educación primaria y publica dos splits, Easy y Challenge. Winogrande lleva el Winograd Schema Challenge a escala con 44 000 problemas de correferencia recogidos por crowdsourcing. Leídos juntos, estos cuatro indican si un modelo maneja preguntas de conocimiento multidominio en un formato estático.

Matemáticas y código

GSM8K es el benchmark canónico de matemáticas de primaria, con 8500 problemas verbales y soluciones en lenguaje natural. HumanEval introdujo la métrica pass@k para la generación de código; MBPP la extiende a problemas básicos de Python; SWE-bench es el más exigente de los tres, ya que mide si un modelo puede resolver issues reales de GitHub en repositorios reales (paper de SWE-bench). Los benchmarks de código tienen una propiedad útil para los equipos de gobernanza: son pass-or-fail por problema, así que la puntuación es más difícil de inflar con juicios subjetivos.

Conversación y seguimiento de instrucciones

MT-Bench usa GPT-4 como juez para puntuar 80 preguntas abiertas multivuelta en 8 categorías, un enfoque a la vez eficiente y metodológicamente cuestionable según la literatura reciente. Chatbot Arena sortea el problema del LLM-juez al recoger votos de preferencia por pares en una arena abierta y estimar los rankings a partir de esas comparaciones por pares (paper de Chatbot Arena). Para productos pensados para interactuar con personas, Chatbot Arena correlaciona con la calidad percibida mejor que MMLU.

Veracidad, seguridad, alineación

TruthfulQA mide la resistencia del modelo a falsedades comunes, un proxy para la resistencia a la alucinación. HELM Safety evalúa el rechazo a respuestas dañinas en escenarios de seguridad. AIR-Bench, una pista relativamente reciente dentro de la familia HELM de Stanford, puntúa los modelos frente a las categorías que utilizan el Reglamento europeo de IA, el NIST AI RMF y varias otras taxonomías regulatorias (AIR-Bench). AIR-Bench merece más atención de los equipos de cumplimiento de la que recibe hoy: es el único benchmark público estructurado deliberadamente en torno a las categorías de los reguladores.

Evaluación holística: HELM como meta-benchmark

La Holistic Evaluation of Language Models (HELM) de Stanford no es un benchmark único sino un protocolo de medición. Evalúa cada modelo según 7 métricas (accuracy, calibración, robustez, equidad, sesgo, toxicidad, eficiencia) sobre 16 escenarios núcleo, en condiciones estandarizadas (HELM). Pistas especializadas extienden ya el marco a dominios médico (MedHELM), visual (VHELM), audio y seguridad. Para una organización que construye un benchmark interno, HELM es lo más parecido a una arquitectura de referencia publicada.

Por qué los benchmarks son hoy un instrumento de cumplimiento, no solo una herramienta de investigación

Lo que cambió entre 2022 y 2026 es que ‘evaluar el modelo’ dejó de ser una buena práctica recomendada para convertirse en una obligación jurídica, inscrita en derecho primario, en un marco de gestión del riesgo de primer orden y en una norma internacional de sistema de gestión. Los benchmarks son la forma en que esa obligación abstracta se traduce en un número que un auditor puede leer.

Artículo 15 del Reglamento europeo de IA

El artículo 15 del Reglamento (UE) 2024/1689 exige que los sistemas de IA de alto riesgo se diseñen y desarrollen de modo que alcancen un nivel adecuado de exactitud, solidez y ciberseguridad durante todo su ciclo de vida (resumen oficial del artículo 15). El mismo artículo obliga a declarar los niveles de exactitud y las métricas pertinentes en las instrucciones de uso del sistema, por lo que cualquier cifra elegida debe quedar documentada y transmitida aguas abajo. El artículo 13 refuerza esto con obligaciones más amplias de transparencia hacia los responsables del despliegue. En la práctica, el proveedor de un sistema de alto riesgo no puede entregar en silencio sin nombrar las métricas utilizadas y los niveles alcanzados.

Artículo 55 y el Código de buenas prácticas GPAI

Para los modelos de IA de uso general clasificados como de riesgo sistémico, el artículo 55 del Reglamento europeo de IA añade una obligación explícita de evaluación del modelo, incluida la realización y documentación de pruebas adversarias. El Código de buenas prácticas GPAI, voluntario y finalizado bajo la égida de la Oficina europea de IA, operativiza la obligación en torno a una cadencia recurrente de evaluación con metodología documentada. Los benchmarks, públicos como internos, son los artefactos que cubren la mitad documental de la obligación.

Función Measure del NIST AI RMF

El marco de gestión del riesgo de IA del NIST está organizado en torno a cuatro funciones: Govern, Map, Measure, Manage. La función Measure invoca explícitamente herramientas cuantitativas, cualitativas o de método mixto para analizar, evaluar, hacer benchmarks y supervisar el riesgo de IA (NIST AI RMF Core). Aunque NIST AI 100-1 es voluntario, la función Measure es el hogar textual de toda conversación sobre benchmarks en la gobernanza estadounidense de IA, y muchas cláusulas de contratación federal ya se remiten directamente a él.

Evaluación del desempeño en ISO/IEC 42001

ISO/IEC 42001, publicada en diciembre de 2023, es la primera norma de sistema de gestión para IA. Como toda norma ISO de sistema de gestión, se apoya en el ciclo Plan-Do-Check-Act, y la evaluación del desempeño es una de sus cláusulas nombradas. Los controles del Anexo A operativizan esta obligación en requisitos puntuales a lo largo del ciclo de vida de la IA, incluidos criterios de evaluación tanto para sistemas desarrollados internamente como para los adquiridos a terceros. Para una organización que aspire a la certificación 42001, la pregunta ya no es si hay que hacer benchmarks, solo cuáles aceptará el auditor.

Cómo leer una clasificación como la lee un regulador

El ‘puntuamos 92,3 en MMLU’ de un proveedor parece preciso. El número es cierto, la comparación es real y, sin embargo, dice muy poco útil a un responsable de cumplimiento mientras no se respondan tres preguntas de fondo. Primera pregunta: ¿el benchmark estaba contaminado para ese modelo? La mayoría de los corpus de entrenamiento de los modelos frontera incluyen grandes franjas de la web abierta, y la mayoría de los benchmarks públicos vive en la web abierta. Una puntuación que supera con claridad el estado del arte previo en un benchmark presente desde hace años merece escepticismo, no celebraciones. Segunda pregunta: ¿el comportamiento medido coincide con el comportamiento desplegado? Una puntuación sobre un conjunto de prueba estático, en inglés y de elección múltiple, no predice el rendimiento sobre sus transcripciones de atención al cliente, sus consultas jurídicas o sus prompts de revisión de código. Los reguladores se interesan por el sistema desplegado, no por la nota de prensa. Tercera pregunta: ¿qué versión, qué fecha, qué formato de prompt? Los benchmarks evolucionan, los prompts se retocan, los scripts de puntuación se revisan. Un 92,3 sin pin de versión no es verificable. Para un expediente de evaluación de la conformidad bajo el Reglamento europeo de IA, el número de portada es, en el mejor de los casos, digno de nota a pie de página. Lo que importa es la metodología: qué conjunto de prueba, con qué controles de contaminación, puntuado por quién, refrescado con qué cadencia. Trate toda afirmación de clasificación como hipótesis a verificar, no como hecho a copiar.

Contaminación de benchmarks y ley de Goodhart

La versión intelectualmente honesta de la conversación sobre benchmarks en 2026 empieza por la contaminación. Hay contaminación de datos cuando un modelo ha sido entrenado sobre el test split de un benchmark, sea deliberadamente porque alguien decidió optimizar para la clasificación, sea accidentalmente porque el conjunto del benchmark acabó en un crawl web que alimentó el preentrenamiento. Una vez que el modelo ha memorizado el test, su puntuación refleja memoria, no capacidad (literatura sobre contaminación). El problema de fondo es estructural. Los benchmarks públicos atraen una presión sostenida de optimización: decenas de laboratorios, cada trimestre, con miles de millones de tokens de entrenamiento y presupuestos serios. Se aplica la ley de Goodhart: cuando una medida se convierte en objetivo, deja de ser una buena medida. La saturación de MMLU, en la que los modelos frontera se agrupan a pocos puntos del techo, es el ejemplo más citado, pero el patrón se repite en todas las familias de benchmarks. Más recientemente, la literatura ha documentado la evaluation awareness: los grandes modelos pueden detectar si un prompt parece una evaluación frente a una interacción de despliegue, y la diferencia de comportamiento entre ambos contextos no es despreciable. Desde la óptica de cumplimiento, eso significa que la puntuación medida por su pipeline de evaluación puede no ser la puntuación que el modelo entrega realmente en producción. La implicación es incómoda. Una puntuación de benchmark público es una señal entre varias, no una garantía. Cualquier marco GRC que tratara un número de MMLU como prueba de seguridad, exactitud o equidad asumiría un riesgo metodológico que, por escrito, no resistirá un cuestionamiento del regulador. Los benchmarks dicen algo. No dicen lo suficiente.

Construir un benchmark interno que su auditor acepte

Si los benchmarks públicos no bastan, la jugada natural es construir uno propio. Un benchmark interno, diseñado sobre sus casos de uso reales, sus datos reales y sus riesgos reales, es el artefacto que cierra el hueco entre un ranking de clasificación y una posición de cumplimiento defendible. Un benchmark interno operativo se apoya en seis elementos. Primero, un perímetro vinculado a un caso de uso: nombre el sistema, el contexto de despliegue y el nivel de riesgo bajo el Reglamento de IA (alto riesgo, riesgo limitado, riesgo mínimo) o el equivalente que surja de la función Map del NIST AI RMF. Segundo, métricas vinculadas a daños: exactitud sobre las tareas que importan, tasa de rechazo sobre los prompts que deben ser rechazados, tasa de alucinación sobre las consultas en que la alucinación es peligrosa. La exactitud genérica rara vez es la métrica adecuada por sí sola. Tercero, un conjunto de prueba representativo con procedencia documentada: de dónde salen los prompts, quién los seleccionó, sobre qué tráfico de producción se muestrearon, qué idiomas cubren. Cuarto, controles de contaminación: mantenga al menos un split reservado que nunca salga de la organización, refresque la parte pública del conjunto con cadencia publicada, marque con marca de agua los prompts cuando sea posible para detectar fugas. Quinto, un script de puntuación versionado: los prompts evolucionan, los modelos evolucionan, las rúbricas evolucionan. Fije cada puntuación a la plantilla exacta de prompt y al código exacto de puntuación que la produjo. Sexto, criterios de aceptación cartografiados en el expediente de conformidad: la puntuación no necesita ser perfecta, debe ser lo bastante alta como para justificar el despliegue dado el nivel de riesgo. Documente el umbral y su justificación. Una plataforma de gestión de evidencias como AI Sigil mantiene toda la cadena auditable: la definición del benchmark, el historial de puntuaciones, las obligaciones vinculadas bajo el Reglamento europeo de IA, el NIST AI RMF o la ISO 42001 y los archivos de prueba (conjunto de prueba, script de puntuación, registros de ejecución) referenciados por el expediente.

Los benchmarks de LLM que conviene seguir de verdad para cumplir

Para una organización que construye un portafolio capaz de satisfacer a los reguladores manteniéndose intelectualmente honesta, la lista corta práctica es más corta que lo que sugieren las clasificaciones públicas.

Toda entrada de esta tabla debe ir acompañada de un benchmark interno orientado a su despliegue real. El número público es la calibración; el número interno es la prueba.

Preguntas frecuentes

¿Son fiables los benchmarks de LLM? Son fiables para lo que miden, esto es, el rendimiento sobre el conjunto de prueba concreto según el protocolo concreto que definen. Son poco fiables como proxy del comportamiento en producción, en parte por contaminación y sobreajuste, en parte porque los sistemas desplegados afrontan una distribución de entradas mucho más amplia que la que cubre cualquier benchmark estático. Trátelos como señales a triangular, no como verdad de base. ¿Las autoridades europeas se interesan por las puntuaciones de MMLU? No directamente. El artículo 15 del Reglamento europeo de IA obliga a los proveedores de alto riesgo a declarar los niveles de exactitud y las métricas pertinentes en las instrucciones de uso. Un regulador que examine un expediente de evaluación de la conformidad quiere ver una metodología documentada, un conjunto de prueba defendible y criterios de aceptación ligados al perfil de riesgo del sistema. Una cifra de MMLU puede aparecer en el expediente como elemento de prueba, pero por sí sola no satisface la obligación. ¿Puede un benchmark público probar el cumplimiento de una IA? Ningún benchmark público demuestra por sí solo la conformidad con el Reglamento europeo de IA, el NIST AI RMF o la ISO/IEC 42001. Cada uno de estos marcos exige una evaluación específica al sistema, específica al daño, anclada al contexto de despliegue. Los benchmarks públicos respaldan el expediente; no lo sustituyen. ¿Debemos construir nuestro propio benchmark interno? Sí, si está sujeto a alguno de los grandes marcos de gobernanza de IA. Un benchmark interno es la única manera de evaluar el sistema sobre datos que se parezcan a los de producción. Le da además el control de la contaminación, imposible para un benchmark público cuyo conjunto de prueba vive en la web abierta. El mínimo viable consiste en unos cientos de prompts representativos, una rúbrica de puntuación clara y una cadencia de refresco documentada. ¿Qué es la contaminación de benchmark? La contaminación es la situación en la que un modelo ha sido entrenado, directa o indirectamente, sobre datos procedentes del conjunto de prueba de un benchmark. La puntuación refleja entonces memoria, no capacidad. La contaminación está extendida en los benchmarks que llevan años en la web pública, y es la razón principal por la que MMLU y los benchmarks saturados similares se tratan hoy con prudencia. ¿Qué recomiendan la AEPD y la AESIA? Ni la AEPD ni la AESIA validan un benchmark público en particular. Su línea coincide con la de otras autoridades europeas: la documentación de la metodología de evaluación, la trazabilidad de los conjuntos de prueba y la adecuación de las métricas al contexto de uso pesan más que la puntuación declarada. Para el sector financiero, el Banco de España sigue la orientación de las autoridades europeas (en particular la EBA) sobre validación de modelos, claramente más exigente que una puntuación pública. ¿Qué benchmark debe documentar un equipo de cumplimiento en 2026? Documente al menos un benchmark por eje de capacidad relevante para su caso de uso (conocimiento, razonamiento, código, diálogo, veracidad, seguridad), más un benchmark de alineación regulatoria como AIR-Bench, más su benchmark interno. El script de puntuación, la procedencia del conjunto de prueba y la fecha de ejecución deben archivarse como pruebas y vincularse a las obligaciones pertinentes de su expediente de conformidad.

Conclusión

Los benchmarks de LLM han superado su papel inicial de herramienta de investigación. En 2026 son el instrumento operativo detrás de cada obligación de evaluación de modelo, desde el artículo 15 del Reglamento europeo de IA hasta la función Measure del NIST AI RMF y la cláusula de evaluación del desempeño de la ISO/IEC 42001. Son también imperfectos, manipulables y a menudo mal leídos. Una postura de cumplimiento seria trata los benchmarks públicos como calibración, construye un benchmark interno como prueba y documenta la metodología con el mismo rigor que cualquier otro control. Quien construye ese portafolio hará bien en mantener definiciones, puntuaciones, evidencias y vínculos a obligaciones en una única traza auditable, como la que ofrece una plataforma de gobernanza como AI Sigil.