Hay un momento incómodo que se repite en casi todos los equipos que están construyendo productos con IA: alguien tiene que decidir si la próxima versión está lista para producción. El equipo de ingeniería corrió un par de demos. Producto probó tres o cuatro casos. Alguien dice "salió bien" y otra persona dice "a mí me dio una respuesta rara ayer". La decisión termina siendo una mezcla de intuición, demos selectivas y pulgar arriba.

En el software tradicional ese momento se resuelve con una suite de tests que pasa o falla. En productos con LLMs no existe esa red de seguridad. La misma entrada puede producir salidas distintas en ejecuciones distintas, dos modelos pueden estar igual de "correctos" pero con respuestas que no se parecen, y los fallos rara vez son crashes ruidosos: son respuestas que parecen razonables pero están mal.

La disciplina que está cubriendo ese vacío se llama AI Evals. No es testing renombrado. No es prompting avanzado. Es una práctica nueva, con su propio modelo mental, sus propias herramientas y su propia comunidad profesional creciendo a velocidad alta. Y es, hoy por hoy, la habilidad que más diferencia a un equipo que sabe shipear productos con IA de uno que solo sabe demostrarlos.

Este artículo cubre qué son los AI Evals, los tres tipos que conviene conocer, cómo se construye un dataset de evaluación, cómo leer outputs de manera sistemática, y por qué un Product Manager (no solo un ingeniero) necesita esta disciplina para tomar decisiones de shipping con respaldo cuantitativo.

Por qué el testing tradicional no alcanza con productos de IA

El testing tradicional descansa sobre una premisa muy fuerte: dado un input, hay un output correcto y todo lo demás es un bug. Esa premisa permite escribir aserciones binarias, automatizar suites de regresión y hacer que un build "pase" o "no pase". Es la base de toda la cultura de QA moderna.

Los productos que integran LLMs rompen esa premisa por varios lados a la vez.

No son determinísticos. El mismo prompt enviado dos veces puede devolver dos respuestas distintas. Ambas pueden ser válidas. Una puede ser mejor que la otra. La aserción output == "respuesta esperada" deja de tener sentido como criterio de calidad: lo que importa no es si el output coincide letra por letra con un valor de referencia, sino si cumple ciertas propiedades (es relevante, es fiel a la fuente, no inventa, sigue el formato pedido, etc.).

Fallan en silencio. Un sistema clásico, cuando se rompe, lanza una excepción, corta una respuesta, devuelve un 500. Un LLM, cuando "se rompe", devuelve una respuesta perfectamente fluida que dice algo incorrecto, irrelevante o inventado. La superficie sigue siendo plausible. Si nadie la lee con cuidado, el fallo nunca se registra.

El criterio de éxito es contextual. En el software tradicional, "correcto" suele tener una definición técnica estable. En IA, "correcto" depende del caso de uso, del usuario, del momento. Una respuesta puede ser correcta en términos factuales y aun así inadecuada en tono. Puede ser útil para un usuario novato y poco profesional para uno experto. Esto exige reglas de evaluación que cambian con el producto, no aserciones universales.

Los datos cambian al sistema. Cuando se actualiza un modelo, cuando se ajusta un prompt, cuando se cambia el sistema de retrieval, cuando se agrega una herramienta nueva: el comportamiento del producto se mueve, a veces de forma sutil, a veces no tanto. La idea de un release "estable" se debilita. La regresión deja de ser un evento puntual y pasa a ser una posibilidad permanente.

Si tu único instrumento es una suite de tests determinística, te quedas sin manera de detectar lo que más duele en este nuevo mundo: respuestas que suenan bien pero están mal, y degradaciones graduales que solo se ven cuando alguien las mira en agregado. Los AI Evals nacen exactamente para cubrir ese hueco.

Qué son los AI Evals (en una definición que sirva)

Un eval es una manera reproducible de medir si un sistema con IA cumple un criterio de calidad sobre un conjunto de casos representativos.

Los tres elementos importan. Reproducible: el resultado tiene que poder repetirse y compararse en el tiempo, lo que descarta probar a mano una vez y dar el shipping por bueno. Criterio de calidad: lo que se mide está definido con la suficiente claridad como para que dos personas distintas, mirando el mismo output, lleguen a la misma conclusión. Casos representativos: el conjunto de pruebas refleja la diversidad real del problema (idiomas, tipos de usuario, casos borde, intentos maliciosos), no solo los tres ejemplos que funcionaron bien en la demo.

Una manera más corta de decirlo: un eval es una hipótesis de calidad puesta a prueba con datos.

Esta definición tiene una consecuencia práctica importante. Hacer evals no es un paso al final del ciclo de desarrollo, como puede serlo el QA tradicional en algunos equipos. Es una capa que vive a lo largo de todo el ciclo: cuando se está prototipando un prompt, cuando se cambia de modelo, cuando se decide subir una versión a producción, cuando se hace monitoreo en vivo. Cada uno de esos momentos pide un tipo distinto de eval, con un objetivo distinto.

Por eso el equipo que construye productos con IA termina hablando de "una suite de evaluación" en lugar de "una suite de tests". La diferencia no es semántica: refleja un cambio en cómo se gobierna la calidad en este nuevo paradigma.

Los tres tipos de evals que todo PM debe conocer

Los evals se organizan en tres grandes capas. Cada capa tiene un costo, una velocidad y una superficie de cobertura distintas. Un sistema maduro las combina; un sistema inmaduro suele apoyarse solo en una y arrastrar los puntos ciegos de las otras dos.

Evals determinísticos

Son la capa más barata y más rápida. Cubren todo lo que se puede verificar sin la opinión de nadie: que el output esté en formato JSON válido, que respete una longitud máxima, que contenga (o no contenga) ciertas palabras, que coincida exactamente con un valor de referencia cuando se trata de una clasificación cerrada.

Su gran ventaja es que se ejecutan en milisegundos, sin costo de inferencia adicional, y son perfectamente repetibles. Su gran limitación es que solo sirven para criterios objetivos. Si lo que quieres evaluar es si la respuesta "es útil", "es respetuosa" o "está bien explicada", los evals determinísticos no llegan.

Una buena práctica es maximizar lo que cae en esta capa antes de pasar a la siguiente. Cuanto más criterio puedas expresar como regla, menos depende tu suite de juicio probabilístico, y más rápida y barata se vuelve la iteración.

Evals probabilísticos (LLM-as-judge)

Cuando el criterio es subjetivo, contextual o difícil de capturar con reglas, la práctica que se está consolidando en la industria es usar un modelo como evaluador. Esto se conoce como LLM-as-judge. El juez recibe el input original, el output del sistema bajo evaluación y una rúbrica, y emite un veredicto: una etiqueta categórica ("correcto / parcial / incorrecto"), un puntaje en una escala, o ambos.

Esta capa es donde se evalúa la mayor parte de las decisiones interesantes en productos con IA: tono, fidelidad a la fuente, cobertura, claridad, alineación con políticas. También es donde aparece el siguiente problema, que mucha gente subestima: un juez sin validar es una opinión disfrazada de medición. Los LLMs como evaluadores tienen sesgos conocidos (preferencia por respuestas largas, sensibilidad al orden de presentación, anclaje sobre lo familiar) y si no los confrontas contra criterio humano, terminas optimizando contra los sesgos del juez en lugar de contra calidad real.

Por eso una práctica madura no termina con "configuré un LLM-as-judge". Termina con "calibré un LLM-as-judge contra anotaciones humanas y mido su nivel de acuerdo de manera regular".

Evaluación humana

La capa más cara, más lenta y, para ciertos criterios, irremplazable. La usas cuando estás definiendo lo que es "bueno" en un dominio nuevo (no puedes pedirle a un LLM que evalúe algo que tú mismo no has terminado de definir), cuando estás validando un juez probabilístico, cuando los costos del fallo son altos, o cuando estás haciendo investigación cualitativa para entender por qué tu producto se está rompiendo en cierta manera.

La evaluación humana no es "que un PM mire 5 outputs antes del release". Es un proceso con anotadores entrenados, rúbricas claras y métricas de acuerdo entre evaluadores. Sin esa estructura, dos personas con buena fe pueden llegar a conclusiones opuestas sobre el mismo output, y tu medición pierde valor.

La regla práctica que conviene tener en mente: no hay un único tipo de eval correcto. La pregunta de diseño no es "¿cuál uso?", sino "¿qué combinación cubre las dimensiones de calidad de este producto, dentro de mi presupuesto de tiempo y dinero?".

El Golden Dataset: tu activo más valioso

Una suite de evals sin un buen dataset es un termómetro sin escala: mide algo, pero ese algo no necesariamente se parece a la realidad que quieres gobernar. El dataset de evaluación, a veces llamado golden dataset, a veces eval set, es el conjunto de casos sobre los que corres tus evals. Es, en muchos sentidos, el activo más valioso que un equipo de IA puede construir.

Un buen dataset tiene tres propiedades.

Es diverso. Cubre las dimensiones reales del problema: tipos de usuario, idiomas, tonos, longitudes, casos felices, casos borde, intentos maliciosos. Si tu producto tiene que funcionar en español, inglés y portugués, tu dataset también tiene que hacerlo. Si tus usuarios pueden ser tanto novatos como expertos, ambos perfiles deben estar representados.

Es representativo. La distribución de casos en tu dataset se parece a la distribución de casos que ves en la realidad. Si el 70% del tráfico real son consultas simples y el 30% son complejas, esa proporción debería estar reflejada en tu dataset. Un dataset que solo tiene casos difíciles te lleva a optimizar para escenarios poco frecuentes y a perder de vista las regresiones en el flujo principal.

Es vivo. Crece y cambia. Cuando un usuario reporta un fallo, ese caso se incorpora. Cuando aparece un nuevo tipo de pregunta, se agrega. Cuando una sección del producto deja de existir, sus casos asociados se retiran. Un dataset que llevaba dos años sin tocarse no representa al producto actual, representa al producto que era hace dos años.

¿Y cómo se construye un dataset cuando el producto todavía no tiene tráfico real? Ahí entra una técnica que pocos equipos usan bien: la generación de datasets sintéticos a partir de las dimensiones del problema. Si conoces los ejes de variación que importan (idioma, tipo de usuario, intención, complejidad), puedes generar combinaciones cubriendo el espacio de manera intencional, sin esperar a que los usuarios reales te traigan casos. La calidad del dataset sintético depende, casi enteramente, de qué tan bien hayas mapeado esas dimensiones de antemano.

Taxonomía de fallos: cómo leer outputs de manera sistemática

Hay una habilidad que separa a alguien que sabe de evals de alguien que solo los configura: leer outputs de manera sistemática. La gente que entra a evals desde producto suele querer saltarse este paso e ir directo a configurar el juez. Es un error caro.

Cuando corres tu sistema contra un dataset por primera vez, lo que tienes en frente es una sopa de outputs. Algunos están perfectos. Otros están claramente mal. Otros están en una zona gris que es difícil de articular sin trabajo previo. Si configuras un LLM-as-judge antes de haber entendido qué tipos de fallos existen en tu producto, vas a terminar midiendo categorías inventadas en lugar de los modos de falla reales.

La práctica madura se llama construcción de taxonomía de fallos: revisar manualmente una muestra suficiente de outputs (cien, doscientos, depende del producto) y agruparlos por tipo de error. No "respuestas malas", sino algo como: "respuestas que inventan fechas", "respuestas que ignoran el contexto recuperado", "respuestas que cambian de idioma a mitad", "respuestas que confunden dos productos similares". Cada uno de esos clusters es un modo de falla.

Esa taxonomía es el insumo que alimenta todo lo demás. Las rúbricas del juez se escriben contra esos modos de falla. Las regresiones se monitorean por categoría, no en agregado. Las decisiones de roadmap se priorizan según qué tipo de falla afecta más a usuarios reales. Sin esta capa, los evals miden "calidad" en abstracto y no logran traducir hallazgos en mejoras concretas del producto.

Una manera de imaginarlo: los evals te dicen qué tan bien está tu sistema; la taxonomía de fallos te dice en qué se está rompiendo. Las dos preguntas son distintas y las dos importan.

Evals en producción: monitoreo continuo y detección de regresiones

Hasta acá, los evals viven contra conjuntos de prueba controlados. Eso es útil para iteración, pero se queda corto cuando el sistema está en manos de usuarios reales. Los productos con IA, en producción, se enfrentan a tráfico que tu dataset nunca anticipó: prompts inesperados, intentos de jailbreak, dominios que tu equipo no preveía, comportamientos emergentes después de un cambio de modelo.

La capa de evals en producción se ocupa de eso. Sus piezas centrales son tres.

Muestreo y evaluación continua. No puedes evaluar el 100% del tráfico (sería carísimo y casi siempre innecesario). En cambio, muestreas un porcentaje, le aplicas tu suite de evals (mayoritariamente probabilísticos) y observas la distribución de resultados en el tiempo. Si la calidad agregada se mueve, lo notas.

Detección de regresiones. Cuando cambias un prompt, un modelo, una configuración del retrieval, comparas la performance de la nueva versión contra la anterior, sobre el mismo dataset y sobre tráfico real. Si una métrica clave cae por debajo de un umbral, abortas el rollout. Esto es lo equivalente a un test de regresión, pero con la diferencia de que el resultado es probabilístico: no estás verificando "este caso pasa", estás verificando "la distribución de resultados sigue siendo aceptable".

Guardrails operativos. Una capa que no es evaluación en sentido estricto, pero que vive cerca: reglas en línea que detectan y bloquean (o redirigen) comportamientos peligrosos en tiempo real. Si tu agente intenta una acción fuera de su scope, si una respuesta supera cierto umbral de toxicidad, si el costo por interacción se dispara, los guardrails actúan antes de que el output llegue al usuario.

Operar evals en producción es lo que convierte la disciplina de "una vez antes del release" a "una capa permanente de la operación". Es también el lugar donde un equipo de producto con buen criterio puede comunicar calidad y riesgo a stakeholders no técnicos con respaldo cuantitativo, en lugar de defenderse con anécdotas.

Por qué los Product Managers necesitan aprender evals

Hay una creencia muy instalada de que los evals son problema del equipo técnico. La realidad es la opuesta: los evals son, antes que cualquier otra cosa, una herramienta de producto.

La razón es simple. La pregunta clave de los evals: ¿qué constituye un buen output en este caso?, es una pregunta de producto, no de ingeniería. Un ingeniero puede implementar la rúbrica, automatizar el juez, escalar la suite. Pero el criterio de qué es "bueno" tiene que venir de quien entiende el problema del usuario, el contexto de uso y el costo de cada tipo de falla. Ese alguien, en la mayoría de los equipos, es el PM.

Sin esta habilidad, el PM termina en uno de dos lugares incómodos. O delega completamente la decisión de calidad al equipo técnico, lo que vacía su rol cuando se trata del producto más importante que está construyendo. O confía en intuición y demos, lo que funciona hasta que un fallo silencioso le explota en producción, y nadie en el equipo puede explicar de manera estructurada por qué pasó.

La transición de PM a AI PM exige varias habilidades nuevas, pero esta es la menos opcional de todas. Si quieres ver cómo se conectan los evals con el resto del rol (discovery, PRDs, descubrimiento de oportunidades, observabilidad) puedes empezar por nuestra guía de qué hace un AI Product Manager y por la introducción a RAG para PMs.

Hay también un perfil dual que conviene mencionar: los profesionales de QA y testing. La cultura de calibración entre evaluadores, la disciplina de leer fallos sistemáticamente y la práctica de reportar con rigor son habilidades que se transfieren casi directamente al mundo de AI Quality. La diferencia es el modelo mental probabilístico que el dominio exige, y que se aprende con práctica deliberada.

Cómo profundizar: el programa EVA

Lo que cubre este artículo es el mapa. Aprender evals de verdad pide otra cosa: trabajar un caso real de extremo a extremo, con las plataformas que el mercado está usando hoy, equivocarse contra outputs propios y calibrar contra criterio humano.

Eso es exactamente lo que recorre nuestro programa AI Evals para AI Product Managers & Testers (EVA). Son 8 encuentros en vivo que llevan a cada participante desde el cambio de modelo mental que el dominio pide, pasando por taxonomía de fallos, evals determinísticos, LLM-as-judge, validación de jueces, evaluación de RAG y agentes, hasta operación en producción. Es el único programa en español enfocado en esta disciplina, y está diseñado para que un PM o un tester lo pueda completar sin necesidad de programar.

Si la decisión de shipping con IA te incomoda hoy (si te encuentras tomándola con intuición y demos selectivas en lugar de con respaldo cuantitativo), la disciplina que cubre ese vacío existe, está madurando rápido y se puede aprender. La pregunta que vale hacerse no es si tu equipo va a necesitar evals; es cuándo, y qué tan caro va a salir aprenderlos en vivo, en producción, con usuarios reales.