Por qué las evaluaciones LLM importan para la gobernanza de IA

Si entregas algo construido sobre un gran modelo de lenguaje, convives con una verdad incómoda. No puedes saber que funciona correctamente en cada caso. El espacio de entradas posibles es, en la práctica, infinito, e incluso el proveedor del modelo no puede garantizar consistencia entre dos prompts casi idénticos. Esa incertidumbre es la razón por la que los equipos de gobernanza quieren ahora ver resultados de evaluación antes de que cualquier cosa salga en vivo.

Este post es una mirada práctica a qué miden las evaluaciones, por qué los equipos las saltan y cómo se conectan con los marcos de gobernanza de IA que los reguladores están aplicando ahora: el EU AI Act, la ISO/IEC 42001 y las expectativas de documentación que se derivan de ambos.

Los cuatro riesgos que las evaluaciones están diseñadas para sacar a la luz

Cuando los equipos preguntan «¿es el modelo lo bastante bueno?», normalmente quieren decir una de cuatro cosas muy distintas. Las evaluaciones son la manera de separarlas.

Alucinación. El modelo produce una salida que suena plausible pero no es cierta. Pasa con datos de entrenamiento débiles, pero más a menudo cuando una empresa le da al modelo sus propios datos (una base de conocimiento, una biblioteca de políticas, registros de clientes) y el modelo los lee mal o inventa alrededor de los huecos. Lo pruebas ejecutando un conjunto de preguntas conocidas y comprobando si la respuesta del modelo coincide con lo que está en la fuente.

Sesgo y equidad. Esta es la parte que más interesa a los reguladores. No hay mucha regulación que exija precisión bruta, pero hay mucha regulación que exige trato justo entre grupos. Una evaluación de sesgo útil hace la misma pregunta variando género, ingresos, etnia, edad, geografía y unas 20 otras dimensiones, y luego comprueba si la respuesta cambia de maneras en las que no debería.

Imprecisión por fine-tuning. En el momento en que haces fine-tuning de un modelo base con tus propios datos, cambias su comportamiento. Ese cambio puede ser útil. También puede introducir errores y sesgos en silencio. Las evaluaciones son la manera de pillar la regresión antes de que se envíe.

Defectos heredados del modelo. Los modelos open-weights más pequeños tienen debilidades conocidas. Los modelos frontera más grandes de OpenAI o Anthropic tienen las suyas. Tu evaluación tiene que sacar a la luz las que afectan a tu caso de uso específico.

Si estás entregando RAG o un agente, el vocabulario de métricas se expande (fidelidad y precisión contextual para retrieval, corrección de herramientas y adherencia al plan para agentes), pero los cuatro riesgos subyacentes y el argumento de gobernanza no cambian.

La revisión solo humana ya no escala

Hace unos años, evaluabas un LLM poniendo a humanos delante de cada salida. Así funcionaba el RLHF en los grandes laboratorios. Las personas investigadoras leían respuestas, las marcaban y devolvían la señal al entrenamiento. Sigue funcionando. Simplemente no aguanta el volumen de evaluaciones que la IA en producción demanda hoy.

El estándar actual es LLM-as-a-judge. Usas un modelo fuerte para evaluar las salidas del modelo que vas a entregar. El juez lee cada respuesta, la puntúa contra una métrica definida (corrección, alucinación, sesgo, equidad, etc.) y devuelve tanto la puntuación como un breve razonamiento escrito, para que un humano pueda auditar la valoración en vez de confiar en ella a ciegas.

Los métodos de evaluación puramente matemáticos siguen existiendo (exact-match, BLEU, ROUGE, similitud de embeddings) y tienen su lugar. Pero para las preguntas cualitativas que importan a la gobernanza («¿fue esta respuesta justa?», «¿estaba anclada en el material fuente?»), LLM-as-a-judge se ha convertido en el valor por defecto.

El juez no es un cheque en blanco. Estudios han mostrado que los jueces LLM favorecen sus propias salidas, puntúan de forma inconsistente entre ejecuciones y se les escapan errores cuando una respuesta se entrega con seguridad. Así que el juez en sí mismo necesita comprobaciones de muestra: una revisora humana lee una pequeña muestra de salidas juzgadas y confirma que el juez coincide con su propia lectura. El modelo y la versión del juez deben constar en el rastro de auditoría junto con todo lo demás.

Tres estadios de madurez en evaluación

La evaluación no es binaria. La mayoría de los equipos pasan por tres estadios, y saber en cuál estás te dice en qué invertir a continuación.

Estadio 1: aserciones deterministas. Baratas, rápidas, frágiles. Comprobaciones con regex, validación de esquema, límites de longitud, detección de rechazo. Capturan los fallos obvios y corren en cada commit. Una cantidad sorprendente del valor de gobernanza viene simplemente de hacer esto de manera consistente.

Estadio 2: LLM-as-a-judge sobre un conjunto de datos estático. Una colección curada de prompts, un modelo más fuerte puntuando contra métricas definidas por rúbrica, un informe versionado. Este es el nivel que la mayoría de reguladores asume implícitamente cuando piden «evidencia de pruebas» bajo el EU AI Act.

Estadio 3: evaluación continua sobre tráfico de producción. Muestreo de peticiones en vivo, jueces sin referencia ejecutándose sobre ellas, alertas cuando las puntuaciones derivan. Aquí vive la ISO 42001, y es el estadio en el que casi nadie está todavía.

No puedes saltarte realmente un estadio. Intentar el estadio 3 sin un dataset de estadio 2 es solo monitorizar ruido del que no tienes una línea base.

Cómo se conecta esto con el EU AI Act y la ISO 42001

Las evaluaciones son útiles para la gobernanza porque producen algo que los reguladores piden explícitamente: evidencia de cómo se comporta el sistema, no solo evidencia de cómo se construyó.

Bajo el EU AI Act, proveedores y deployers de sistemas de IA de alto riesgo deben mantener documentación técnica, realizar pruebas y demostrar que los riesgos del sistema se han identificado y mitigado. Un informe de evaluación con puntuaciones de alucinación, sesgo y equidad, con las muestras subyacentes y el razonamiento del juez adjuntos, es un artefacto concreto que puedes poner delante de un auditor. Más difícil de discutir que «usamos un modelo reputado».

La ISO/IEC 42001, la norma del sistema de gestión de IA, pide algo parecido: una garantía continua y documentada de que el sistema sigue rindiendo dentro de los umbrales de riesgo que has definido. Las evaluaciones convierten ese requisito abstracto en algo medible. Un umbral por métrica. Un estado pass/fail. Un rastro versionado.

Continua es la palabra clave. Una sola ejecución de evaluación antes del lanzamiento no cumple la ISO 42001. La norma espera un ritmo recurrente: reevaluación periódica contra el mismo dataset, monitorización muestreada del tráfico en vivo y una respuesta documentada cuando las puntuaciones derivan. Una prueba puntual valida el lanzamiento pero no mantiene el sistema dentro del alcance después.

Para más comparación entre ambos marcos y sus puntos de divergencia, mira nuestro análisis EU AI Act vs ISO 42001.

Lo que aguanta en una auditoría no es la puntuación. Es el rastro detrás: quién probó qué, contra qué dataset, en qué versión del modelo, con qué juez, contra qué métricas, con qué resultado.

Qué necesita una evaluación de verdad

Cuatro ingredientes:

1. El modelo bajo prueba. El modelo y la versión exactos que pretendes entregar, con la misma configuración con la que correrás en producción.
2. Un dataset. Prompts de entrada y, para métricas medibles, salidas esperadas. El dataset tiene que reflejar la distribución real de preguntas que verá tu sistema, no solo las fáciles. Algunas métricas necesitan salidas de referencia (corrección, exact-match). Otras, como fidelidad, utilidad y toxicidad, son sin referencia y puntúan la respuesta directamente. La evaluación de estadio 3 sobre tráfico de producción es principalmente del segundo tipo, ya que rara vez tienes ground truth para peticiones en vivo.
3. Un juez. Un modelo más fuerte o, para algunas métricas, una comprobación determinista. El juez necesita una rúbrica de puntuación clara y debe estar obligado a dar razonamiento, no solo un número.
4. Métricas y umbrales. Una definición numérica de «lo bastante bueno». Un punto de partida común está en torno a 0,5 a 0,6 por métrica, con cualquier cosa por debajo enrutándose a una revisora humana. Dónde pones el listón es una decisión de producto y de riesgo, no técnica, y deberías documentar esa decisión junto a la puntuación. Los auditores preguntarán por qué elegiste 0,6 y no 0,8, y «la métrica lo tenía por defecto» no es una respuesta.

La salida es un desglose por muestra: cada prompt, la respuesta del modelo, la puntuación del juez, el razonamiento del juez. Para casos de uso de bajo volumen puedes leer cada muestra. Para sistemas de alto volumen, los resúmenes de razonamiento son la manera en que gobernanza e ingeniería revisan los fallos sin chapotear entre miles de respuestas. Los clústeres de fallo son de donde sale el trabajo del próximo sprint. Un patrón de alucinación recurrente es un arreglo de prompt o RAG. Un patrón de sesgo recurrente es un escalado de equidad. Un error de herramienta recurrente es un problema de diseño del agente. Una evaluación que no cambia nada en el siguiente sprint es un informe de estado, no un control.

Por qué los equipos siguen invirtiendo poco aquí

Dos razones, sobre todo.

La primera: las evaluaciones parecen sobrecoste hasta que algo va mal. No hay ticket urgente que pida una auditoría de sesgo hasta que hay un ticket muy urgente preguntando por qué el modelo trató distinto a dos cohortes de clientes.

La segunda: el utillaje lleva años fragmentado. Bibliotecas separadas para métricas, dashboards separados para resultados, hojas de cálculo separadas para la documentación que quieren los reguladores. Los equipos acaban con la lógica de evaluación repartida en tres sitios y sin un solo artefacto que puedan entregar a un auditor o al equipo legal.

Cerrar esa brecha es para lo que sirve un buen utillaje de evaluación. Un solo sitio donde definir el modelo, el dataset, el juez, las métricas y el umbral. Un solo sitio donde ver los resultados por muestra. Un rastro que puedes entregar a quien lo pida.

Qué hacer este trimestre

Si estás entregando algo basado en LLM y aún no tienes un pipeline de evaluación, el paso útil más pequeño es este.

• Elige el caso de uso donde una mala respuesta te costaría más, legal, reputacional o comercialmente.
• Construye un dataset de 50 a 100 prompts reales para ese caso de uso (extraídos de logs de producción cuando sea posible, complementados con casos límite sintéticos generados por un modelo más fuerte) con respuestas esperadas donde aplique.
• Ejecuta una evaluación LLM-as-a-judge contra corrección, alucinación y sesgo. Tres métricas, no 30.
• Pon un umbral. Haz ruido cuando lo cruces.
• Guarda el informe. Versiónalo junto a tu modelo.

Ese es el nivel de rigor que los reguladores esperan de los sistemas de alto riesgo bajo el EU AI Act, y el nivel de evidencia que las auditorías ISO 42001 pedirán cada vez más. Aparte del cumplimiento, también es la manera más barata de descubrir que tu modelo está equivocado antes de que lo descubran tus clientes.

Las evaluaciones no son un ejercicio académico. Son cómo demuestras, sobre el papel, que tu sistema de IA hizo lo que dijiste que haría.

La plataforma de VerifyWise reúne inventario de modelos, evaluaciones, riesgo y evidencia en un mismo espacio de trabajo, de modo que el rastro de auditoría se construye solo mientras tu equipo trabaja. Si tu lógica de evaluación está esparcida entre bibliotecas, dashboards y hojas de cálculo ahora mismo, merece la pena un vistazo.