¿Qué son las evaluaciones de IA?
Gobernanza, riesgo y aseguramiento
Las evaluaciones de IA son pruebas estructuradas que sirven para medir si un modelo o sistema de IA es suficientemente bueno para una tarea concreta y si su comportamiento se mantiene dentro de límites aceptables. Pueden evaluar la precisión en tareas, la fiabilidad, la seguridad, las salvaguardas, el comportamiento de agentes u otras propiedades, y suelen combinar casos de prueba reservados, reglas de puntuación y revisión humana. El término se usa con cierta libertad en el sector, pero la idea práctica es coherente: sustituir las suposiciones por evidencia reproducible antes y después del despliegue.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
La forma más sencilla de entender las evaluaciones de IA es considerarlas controles de calidad para sistemas probabilísticos. El software tradicional suele comportarse igual cada vez que el código y las entradas no cambian. La IA generativa no. Puede variar, derivar, mejorar en un área mientras empeora en otra, y comportarse de forma distinta según el diseño del prompt, el contexto de recuperación, el acceso a herramientas o la configuración de seguridad. Por eso las comprobaciones puntuales no son suficientes. Se necesitan pruebas estructuradas.
En el sector, "evaluaciones" puede significar varias cosas. OpenAI señala que el término puede referirse a benchmarks públicos, métodos de puntuación numérica o pruebas personalizadas para una aplicación de IA concreta. El sentido explicativo que más importa para el uso empresarial es el tercero: las pruebas específicas de tarea que se diseñan para determinar si el sistema está listo para el trabajo real.
Por eso las evaluaciones de IA no se limitan al modelo de forma aislada. Un sistema empresarial útil suele incluir prompts, recuperación de información, herramientas, políticas, interfaz de usuario y pasos de aprobación en torno al modelo. Anthropic describe una evaluación como proporcionar una entrada a un sistema de IA y aplicar lógica de calificación a su salida para medir el éxito. El AI Safety Institute también trata las evaluaciones como un conjunto de técnicas para medir las capacidades de sistemas de IA avanzados, no solo como preguntas de tipo examen.
Todavía no existe una definición universal en el sector que resuelva todos los límites. Algunos equipos incluyen en "evaluaciones" el red teaming, las pruebas de salvaguardas y las tareas de agentes a largo plazo. Otros lo usan de forma más restringida para conjuntos de pruebas de tipo regresión. Para los líderes, esa ambigüedad importa menos que la idea operativa central: una evaluación es una forma deliberada y reproducible de comprobar si un sistema de IA cumple un estándar que resulta relevante.
Por qué importa
Sin evaluaciones, las decisiones sobre IA suelen basarse en impresiones. Una persona dice que el asistente "parece bueno". Otra dice que le resulta inseguro. Una tercera dice que un modelo rival parece más inteligente. Ninguna de esas impresiones ofrece una base sólida para el lanzamiento, la contratación o el control de cambios. Las evaluaciones proporcionan a los equipos un lenguaje de medición compartido para comparar prompts, modelos, salvaguardas y versiones sobre algo más sólido que anécdotas.
También importan porque los sistemas de IA cambian constantemente. Los prompts evolucionan. La recuperación cambia. Los modelos se sustituyen. Las salvaguardas se refuerzan. Se añaden herramientas. NIST enmarca las pruebas, la evaluación, la verificación y la validación, o TEVV, como actividades que ocurren a lo largo de todo el ciclo de vida de la IA, no solo antes del lanzamiento. Una buena práctica de evaluación respalda tanto el desarrollo como las operaciones en producción.
Para los líderes sénior, las evaluaciones forman parte de la disciplina básica de entrega. Reducen el riesgo de lanzar sistemas frágiles, ayudan a dirigir la escasa revisión experta hacia los fallos correctos y crean un registro más claro para la gobernanza, la contratación y la respuesta a incidentes. Son especialmente importantes cuando un modelo se adapta a un dominio donde los errores son costosos, aunque ese dominio no esté formalmente regulado.
Cómo funciona
Una buena evaluación comienza con un objetivo, no con una métrica. Primero hay que preguntarse: "¿Qué queremos exactamente demostrar o refutar?". Puede ser "el modelo extrae cláusulas contractuales con suficiente precisión para reducir el tiempo de revisión manual", "el asistente de soporte fundamenta las respuestas en el material fuente" o "el agente de codificación completa tickets pequeños sin cambios de archivo inseguros". El objetivo determina el conjunto de datos, el evaluador y el umbral de aprobación adecuados. Si la tarea no se define con claridad, cualquier puntuación obtenida probablemente será engañosa.
A continuación viene el conjunto de datos. La guía de OpenAI sugiere usar una combinación de datos de evaluación sintéticos, datos específicos del dominio, ejemplos seleccionados por personas, datos de producción y datos históricos según la tarea. En la práctica, los conjuntos de evaluación más sólidos suelen mezclar casos habituales con casos límite difíciles. Los casos habituales indican si el sistema es ampliamente útil; los casos límite revelan dónde sorprenderá, rechazará cuando no debería, alucinará o fallará de forma silenciosa.
Luego se elige un método de puntuación. Algunas tareas admiten medición exacta: ¿devolvió el sistema los valores de campo correctos?, ¿llamó a la herramienta adecuada?, ¿produjo una salida estructurada válida? Otras tareas requieren rúbricas o juicios basados en preferencias: ¿es fiel el resumen?, ¿está bien fundamentada la respuesta?, ¿es apropiado el rechazo? La guía de evaluación de agentes de Anthropic lo resume con claridad: se proporciona una entrada al sistema y se aplica lógica de calificación para medir el éxito. A veces esa lógica es código. A veces es revisión experta. A veces es otro modelo calibrado con el juicio humano.
Aquí es donde los equipos suelen subestimar el trabajo. La puntuación automática resulta atractiva porque es barata y rápida, pero rara vez es perfecta en tareas subjetivas o matizadas. OpenAI recomienda combinar métricas con juicio humano y calibrar la puntuación automatizada con retroalimentación humana. Anthropic también advierte que las evaluaciones robustas son difíciles de construir e interpretar. Por eso un programa de evaluación maduro tiende a usar la automatización donde es posible y la revisión humana donde la tarea es ambigua, de alto riesgo o vulnerable a errores de calificación.
Otra distinción importante es la evaluación a nivel de modelo frente a la evaluación a nivel de sistema. Los benchmarks públicos pueden ayudar a comparar modelos de forma aislada, pero los sistemas en producción suelen ser más que modelos. Un asistente de recuperación puede fallar porque el recuperador trajo los fragmentos equivocados. Un agente puede fallar porque una herramienta estaba mal diseñada. Un copiloto de soporte puede fallar porque la ruta de escalada es incorrecta. Las buenas evaluaciones apuntan al sistema que el usuario experimenta realmente, no solo a la puntuación del modelo que queda mejor en el gráfico de un proveedor.
El trabajo de evaluación moderno también va más allá de las respuestas a preguntas cortas. El AI Safety Institute describe evaluaciones automatizadas de capacidades, red teaming, estudios de mejora humana y evaluaciones de agentes como parte del conjunto de herramientas de evaluación más amplio. Su framework de código abierto Inspect está diseñado para una amplia gama de evaluaciones, incluidas codificación, razonamiento, comprensión multimodal y tareas agénticas. Esto importa porque muchos sistemas empresariales dependen ahora del uso de herramientas, la planificación en múltiples pasos y los flujos de trabajo a largo plazo, en lugar de prompts de respuesta única.
El momento también importa. OpenAI recomienda el desarrollo guiado por evaluaciones y la evaluación continua, mientras que el Perfil de IA Generativa de NIST subraya los métodos validados empíricamente y el intercambio de resultados de pruebas previas al despliegue con los responsables de las decisiones de lanzamiento pertinentes. En lenguaje claro, esto significa que las evaluaciones deben estar integradas en el ciclo de construcción, no añadidas después de que el equipo de producto ya esté comprometido con el lanzamiento.
Existen límites. NIST advierte que los enfoques actuales de pruebas previas al despliegue pueden ser inadecuados o no ajustarse a los contextos de uso real. Anthropic señala que muchos conjuntos de evaluación no indican con precisión la capacidad o la seguridad del modelo. Las pruebas fuera de línea pueden no capturar el comportamiento real de los usuarios, y algunos modelos pueden incluso comportarse de forma diferente cuando parecen estar en un entorno de evaluación. Por tanto, las evaluaciones son esenciales, pero no son omniscientes. Son una parte de una disciplina más amplia de pruebas y monitorización.
Ejemplos
Un equipo de atención al cliente puede construir un conjunto de evaluación con tickets reales pero anonimizados junto con respuestas de referencia. El sistema se puntúa entonces por precisión factual, cumplimiento de políticas, calidad de las citas y escalada apropiada. Esto es más útil que probar el modelo base con preguntas genéricas de examen, porque mide directamente la tarea empresarial.
Un equipo de contratación o legal podría evaluar la extracción de cláusulas con comprobaciones de coincidencia exacta para fechas, condiciones de pago y legislación aplicable, y añadir revisión humana para los casos más difíciles, como el lenguaje de responsabilidad ambiguo. Esa combinación de calificación programática y experta es habitual porque muchas tareas empresariales importantes son en parte objetivas y en parte basadas en el juicio.
Un equipo que despliega un agente de IA para trabajar con herramientas de software puede necesitar evaluaciones de agentes en lugar de prompts estáticos. Los materiales de Inspect describen entornos donde el sistema planifica, usa herramientas, edita archivos y gestiona tareas de mayor duración. En esos casos, el éxito o el fracaso depende de toda la trayectoria, no solo de la última respuesta.
Un equipo de riesgos que evalúa salvaguardas podría usar evaluaciones de tareas ordinarias para la utilidad y añadir comprobaciones adversariales o de tipo jailbreak para ver si el sistema se mantiene dentro de la política cuando se le presiona. Ahí es donde las evaluaciones se encuentran con el red teaming sin confundirse con él.
Malentendidos frecuentes
Un malentendido importante es que las evaluaciones de IA son simplemente benchmarks públicos como MMLU. Esos benchmarks pueden ser puntos de referencia útiles, pero OpenAI los separa explícitamente de las pruebas personalizadas que las organizaciones necesitan para sus propios sistemas. Liderar un benchmark no implica automáticamente estar listo para producción.
Otro es que una sola puntuación cuenta toda la historia. No es así. La precisión, la fundamentación, la calidad del rechazo, la latencia, el coste, la robustez y el rendimiento por subgrupos pueden evolucionar en direcciones distintas. Un promedio único puede ocultar un patrón de fallos inaceptable.
Un tercero es que las evaluaciones sustituyen a la revisión humana. En realidad, el juicio humano suele anclar las rúbricas, verificar los evaluadores y revisar los fallos más relevantes. Los programas de evaluación robustos suelen combinar ambos.
Un cuarto es que las evaluaciones son una puerta de entrada puntual antes del lanzamiento. La mejor práctica es continua. Si cambian los prompts, las herramientas, los datos o las versiones del modelo, el conjunto de evaluación debe volver a ejecutarse y, con el tiempo, actualizarse.
Riesgos y límites
Las evaluaciones deficientes generan una falsa confianza. Si el conjunto es demasiado pequeño, demasiado fácil, demasiado sintético o está demasiado ligado a cómo el equipo construyó el sistema, la puntuación puede parecer sólida mientras los usuarios reales siguen encontrando fallos evidentes. NIST advierte que las pruebas previas al despliegue suelen mantenerse demasiado cerca de los entornos de laboratorio, y Anthropic advierte que los conjuntos existentes pueden no reflejar la capacidad o la seguridad real.
También existe el peligro de enseñar para el examen. Una vez que una métrica se vuelve importante, los equipos tienden a optimizar para ella. Eso puede ser útil, pero también puede llevar a sistemas frágiles que rinden bien en el conjunto de evaluación mientras no capturan la capacidad más profunda o el riesgo que la evaluación pretendía medir. La solución no es hacer menos evaluaciones, sino evaluaciones más amplias y mejor diseñadas, actualizadas con el tiempo.
Por último, las evaluaciones no eliminan la necesidad de gobernanza, red teaming, monitorización o escalada humana en contextos de alto riesgo. Proporcionan evidencia. No proporcionan certeza. Este artículo es un explicador práctico, no una garantía profesional ni asesoramiento jurídico.
Qué hacer a continuación
Conviene definir las tareas reales que los sistemas de IA deben realizar y los tipos de fallos que más importan. Luego hay que construir un conjunto de evaluación pequeño pero riguroso para cada flujo de trabajo de alto valor, idealmente usando casos históricos reales o casos seleccionados por expertos en lugar de prompts genéricos. Cincuenta ejemplos sólidos suelen ser más útiles que cientos de ejemplos débiles.
Hay que decidir dónde la calificación automatizada es fiable y dónde la revisión humana es necesaria. Conviene mantener un registro de la rúbrica, la fuente del conjunto de datos, la versión del modelo y el umbral de aprobación. Si no se puede explicar qué significa una puntuación, esa puntuación no está lista para la gobernanza.
Por último, hay que hacer que las evaluaciones sean operativas. Deben ejecutarse ante cambios en el modelo, en los prompts, en la recuperación y en los flujos de trabajo principales. Los fallos deben revisarse de forma estructurada y los problemas recurrentes deben retroalimentarse en los prompts, los datos de entrenamiento, el diseño del producto o el red teaming. Así es como las evaluaciones se convierten en una disciplina de trabajo en lugar de una diapositiva en un informe de gobernanza.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Son las evaluaciones lo mismo que los benchmarks?
No. Los benchmarks comparan modelos de forma aislada, mientras que las evaluaciones empresariales suelen ser pruebas personalizadas diseñadas para la tarea o el sistema propio.
¿Las evaluaciones tienen que ser automatizadas?
No. Muchas buenas evaluaciones combinan puntuación automatizada con revisión humana, especialmente para tareas matizadas o de alto riesgo.
¿Cuántos casos de prueba se necesitan?
No hay un número mágico. Conviene empezar con suficientes casos para cubrir el trabajo habitual, los casos límite de riesgo y los modos de fallo conocidos, y ampliar con el tiempo.
¿Puede otro LLM actuar como evaluador?
Sí, pero debe calibrarse con el juicio humano y tratarse como una herramienta de medición con límites, no como un juez incuestionable.
¿Son el red teaming y las evaluaciones lo mismo?
No exactamente. El red teaming es una práctica de pruebas adversariales que puede generar o reforzar evaluaciones, pero no toda evaluación es red teaming.
¿Cuándo hay que volver a ejecutar las evaluaciones?
Deben volver a ejecutarse siempre que se cambien prompts, versiones del modelo, recuperación, herramientas o salvaguardas de formas que puedan alterar el comportamiento.
Fuentes
Artificial Intelligence Risk Management Framework 1.0 (NIST). Primary. TEVV across the AI lifecycle.
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST). Primary. Empirically validated methods, pre deployment testing, and limitations of current approaches.
AI test, evaluation, validation and verification (NIST). Primary. Importance of reliable measurement and evaluation for trustworthy AI.
AI Safety Institute approach to evaluations (UK Government). Primary. Broader evaluation categories, including automated assessments, red teaming, human uplift, and agent evaluations.
Inspect AI (AI Security Institute). Primary. Current open source framework for broad ranges of evaluations, including agentic tasks.
Early lessons from evaluating frontier AI systems (AI Security Institute). Primary. Limits and value of independent evaluations.