Evaluación, Benchmarking y Red Teaming

Las puntuaciones de los benchmarks públicos no le dicen casi nada sobre cómo se comportará un sistema de IA en su despliegue. Diseñamos arneses de evaluación, benchmarks específicos de dominio y programas estructurados de red teaming que miden si los sistemas de IA realmente funcionan para su caso de uso: frente a sus datos, sus casos límite y sus restricciones de coste y seguridad.

Por qué los benchmarks públicos pasan por alto su despliegue

Los modelos de frontera se agrupan por encima del 88 % en MMLU. GPT-5.3 Codex obtiene un 99 %. La Tabla de Clasificación de LLM 2025 de Vellum eliminó MMLU por completo porque ya no diferencia los modelos de ninguna manera significativa. MMLU-Pro, diseñado para corregir esto, ya se acerca al 90 % para los modelos de frontera. Los benchmarks más citados del sector se han convertido en métricas de vanidad.

El problema más profundo es la relevancia. Una puntuación de benchmark predice el rendimiento en producción solo bajo tres condiciones:

• Evalúa tareas similares a las suyas.
• El conjunto de prueba está libre de contaminación de datos; algunos benchmarks muestran ratios de filtración de hasta el 100 %.
• Las diferencias de puntuación son estadísticamente significativas.

Para la mayoría de los despliegues empresariales, no se cumple ninguna de esas condiciones. El rango puede invertirse por completo una vez que evalúa con sus propios datos: el modelo n.º 3 en las tablas de clasificación públicas puede superar al n.º 1 en un 40 % en una tarea de extracción real. Este es exactamente el tipo de brecha que un arnés de evaluación personalizado está diseñado para revelar, y por eso responder a «¿qué modelo rinde mejor con mis datos, mis casos límite y mis restricciones de coste?» requiere una infraestructura de evaluación diseñada para su despliegue.

Las tres capas de un programa de evaluación riguroso

Estructuramos la evaluación en torno a tres capas, cada una de las cuales responde a una pregunta diferente sobre su sistema de IA.

Evaluación de capacidad: ¿hace lo que necesitamos?

Construimos conjuntos de pruebas específicos para cada tarea a partir de sus datos de producción y casos límite realistas, no de muestras de conveniencia. Para un modelo de suscripción de riesgos, eso significa evaluar con solicitudes rechazadas reales, casos límite y los formatos de documento específicos que encuentra su canal de procesamiento.

Cada caso de prueba se documenta con la metodología de recopilación y métricas de calidad de anotación. Medimos con rigor estadístico: múltiples ejecuciones con distintas semillas, intervalos de confianza por bootstrap y pruebas de significación emparejadas. Una mejora del 2 % que cae dentro del intervalo de confianza no es una mejora.

Evaluación de seguridad: ¿dónde falla y con qué gravedad?

Evaluamos los límites de comportamiento mediante sondas estructuradas: pruebas de funcionalidad mínima, pruebas de invariancia (¿cambia la salida cuando no debería?) y pruebas de expectativa direccional. La evaluación desagregada informa del rendimiento en cada segmento de datos operativamente relevante, porque un modelo que funciona en promedio pero falla en una subpoblación crítica no es seguro para desplegar, como se detalla en nuestra investigación sobre por qué las tasas de fallo raras pero catastróficas no pueden descartarse.

Evaluación adversarial: ¿se le puede inducir a comportarse mal?

Esta capa pregunta si alguien puede hacer que el sistema haga algo que no debería. Aquí es donde vive el red teaming.

El red teaming como valoración estructurada de capacidades

El red teaming no es una prueba de penetración con otro nombre. La valoración de seguridad pregunta «¿puede un atacante comprometer este sistema?». El red teaming en el contexto de la evaluación pregunta «¿cuáles son los límites del comportamiento de este sistema y dónde se quiebran esos límites?». Las metodologías se solapan, pero las preguntas, los informes y el público son diferentes.

Operamos bajo una metodología estructurada construida sobre la taxonomía NIST AI 100-2 E2025 , que se amplió significativamente en marzo de 2025 para cubrir las vulnerabilidades de los agentes de IA autónomos y las categorías de ataque específicas de la IA generativa. Nuestros programas de red team siguen una secuencia definida:

1. Definición del modelo de amenazas ajustada al contexto de su despliegue.
2. Enumeración de la taxonomía de ataques que abarca las categorías del OWASP LLM Top 10 v2: inyección de prompts, jailbreaking, envenenamiento de datos, inyección indirecta a través de contenido recuperado, ataques multimodales y evasión basada en codificación.
3. Ejecución sistemática de ataques con procedimientos documentados.
4. Hallazgos clasificados por gravedad con pasos de reproducción.

Red teaming humano y automatizado

Complementamos el red teaming humano con canales adversariales automatizados. Cascade de Haize Labs alcanza tasas de éxito de ataque del 44 % en modelos de frontera, 4 veces superiores a las de referencia de un solo turno. Promptfoo ejecuta más de 50 tipos de vulnerabilidad en CI/CD en más de 300 000 instalaciones de desarrolladores. Las herramientas automatizadas detectan patrones conocidos a escala; los red teamers humanos encuentran vulnerabilidades novedosas que los sistemas automatizados nunca han visto, lo cual importa más allí donde las consecuencias de un modo de fallo no detectado son graves.

Qué entrega cada colaboración

Cada colaboración de red team está delimitada para producir tres entregables:

• Un informe de hallazgos con clasificaciones de gravedad y procedimientos de reproducción.
• Recomendaciones de remediación asignadas a su arquitectura.
• Un conjunto de pruebas de regresión automatizadas derivado de las vulnerabilidades descubiertas que se integra en su canal de despliegue, de modo que las debilidades descubiertas permanezcan corregidas.

Cuándo funciona la evaluación automatizada y cuándo no

La evaluación LLM como juez —usar un modelo de frontera para puntuar las salidas de otro modelo— se ha convertido en la opción predeterminada para los equipos que no pueden permitirse la evaluación humana a escala. Es útil. También es poco fiable de maneras específicas y documentadas. La investigación ha identificado más de 12 tipos distintos de sesgo en los jueces LLM:

• Sesgo de autopreferencia — GPT-4 puntúa más alto las salidas con menor perplejidad, independientemente de si las generó él mismo.
• Sesgo de verbosidad — los jueces prefieren de forma constante las respuestas extensas y formales frente a las concisas y correctas.
• Sesgo de posición — los jueces favorecen a la respuesta que aparece primero.

Estos sesgos son manejables para la comparación general de calidad con técnicas de desesgo como la aleatorización de la posición y los paneles de múltiples jueces. Son descalificadores cuando importa la corrección específica del dominio. Un juez LLM no puede evaluar de forma fiable si un sistema clínico identifica correctamente las interacciones farmacológicas, o si una investigación jurídica cita con precisión la jurisprudencia. Usamos la puntuación automatizada donde el sesgo es manejable y la revisión de expertos humanos donde la corrección requiere conocimiento del dominio.

Evaluación de sistemas de IA agéntica

El benchmarking estático de modelos no funciona para agentes que planifican, usan herramientas y ejecutan flujos de trabajo de varios pasos. Un único número de precisión no puede capturar si el agente seleccionó la herramienta correcta, la invocó con los parámetros correctos, se recuperó con elegancia cuando un paso falló o produjo un resultado coherente a lo largo de 15 operaciones encadenadas. Un agente puede ejecutar correctamente cada paso individual y aun así producir un resultado erróneo porque el razonamiento que conecta esos pasos era defectuoso.

Evaluamos los sistemas agénticos a través de cinco dimensiones extraídas del marco CLEAR:

• Coste eficiencia del uso de herramientas y tokens.
• Latencia a lo largo de la finalización completa de la tarea.
• Eficacia del éxito de la tarea de extremo a extremo.
• Garantía de que las restricciones de seguridad se mantuvieron durante toda la ejecución.
• Fiabilidad a lo largo de ejecuciones repetidas.

Para los agentes que usan herramientas, también evaluamos la precisión en la selección de herramientas, la corrección de los parámetros (los agentes fabrican nombres de parámetros a tasas significativas), la adhesión al alcance y la recuperación ante errores. Para los sistemas multiagente, evaluamos la fidelidad de la comunicación entre agentes, la propagación de fallos en cascada y si los controles del supervisor intervienen realmente cuando los agentes subordinados divergen.

Los benchmarks se están poniendo al día: SWE-bench evalúa tareas reales de ingeniería de software, Terminal-Bench evalúa flujos de trabajo de agentes de línea de comandos y UpBench utiliza ofertas de empleo reales de Upwork actualizadas continuamente. Pero los benchmarks agénticos listos para usar rara vez coinciden con la arquitectura específica de su agente, su conjunto de herramientas y su dominio, por lo que construimos arneses de evaluación agéntica personalizados, porque los modos de fallo de su agente son específicos de su diseño.

Evaluación para la Ley de IA de la UE y el cumplimiento normativo

Las disposiciones de alto riesgo de la Ley de IA de la UE entran plenamente en vigor el 2 de agosto de 2026. El artículo 9 exige un sistema de gestión de riesgos con una metodología de evaluación documentada, pruebas bajo condiciones de uso previsto y de mal uso razonablemente previsible, y una supervisión continua posterior a la comercialización. La evaluación de la conformidad debe completarse antes de introducir un sistema de alto riesgo en el mercado de la UE. El incumplimiento acarrea multas de hasta el 7 % de la facturación anual global o 35 millones EUR.

NIST AI 100-2 E2025 proporciona la taxonomía autorizada de evaluación adversarial, que ahora cubre las vulnerabilidades de los agentes autónomos ausentes en la edición de 2023. Estos marcos están apareciendo en los requisitos de adquisición y en las revisiones de riesgos a nivel de junta directiva.

El reto práctico: aún no existe una norma armonizada que defina qué es una «evaluación adecuada» para el cumplimiento de la Ley de IA de la UE. El CEN/CENELEC JTC 21 incumplió su plazo de agosto de 2025 y apunta al cuarto trimestre de 2026. Diseñamos programas de evaluación que producen evidencia defendible ahora, sin dejar de ser adaptables a normas que aún se están finalizando, un enfoque que exponemos en nuestro whitepaper sobre integridad arquitectónica y responsabilidad regulatoria en la IA generativa empresarial.

Evaluación continua en producción

Una evaluación previa al despliegue le dice que el sistema funcionó en una fecha específica frente a un conjunto de prueba específico. No le dice nada sobre el mes que viene. Los modelos en producción derivan, las distribuciones de entrada cambian, el contenido recuperado varía y las API de las herramientas se actualizan. Un informe LLMOps de 2025 halló que los modelos que se dejaron sin cambios durante seis meses vieron aumentar sus tasas de error en un 35 % sobre datos nuevos. Gartner estima que solo el 18 % de los equipos de ingeniería de software había adoptado plataformas de evaluación y observabilidad de IA en 2025, aunque proyecta una adopción del 60 % para 2028.

Construimos canales de evaluación que se ejecutan de forma continua:

• La monitorización de producción puntúa el tráfico en vivo utilizando los mismos evaluadores del desarrollo.
• Las evaluaciones fallidas se convierten en pruebas de regresión de CI/CD.
• La detección de deriva alerta cuando las distribuciones de entrada divergen de las líneas base.
• Los conjuntos adversariales se ejecutan cada noche contra los puntos finales de producción.

Esta es una infraestructura operativa que mantiene la evaluación actualizada a medida que evoluciona su sistema.

El panorama de las herramientas de evaluación

El mercado está fragmentado y cada herramienta tiene puntos ciegos. Usamos cada una donde encaja y construimos arneses personalizados donde ninguna de ellas llega.