Los evals son la especificación de una función de IA

Una función construida sobre un modelo de lenguaje responde distinto cada vez que se le pregunta. Eso rompe la frase en la que se apoya todo documento de requisitos: «funciona». Este artículo trata de qué la sustituye, quién escribe el sustituto y qué aprendió el estudio especificando ocho entornos de IA en un mismo producto.

¿Por qué «funciona» no sirve para una función de IA?

Porque no hay una única salida que comprobar. Una función determinista se acepta una vez; una basada en un modelo tiene que aceptarse estadísticamente, en los casos que importan, y volver a aceptarse cada vez que cambia el prompt o el modelo. Hamel Husain, consultor de IA que entrega estos sistemas desde 2023, escribió el 29 de marzo de 2024 que los productos de IA fallidos «almost always share a common root cause: a failure to create robust evaluation systems». Los equipos que fallan juegan al topo: arreglan una respuesta, rompen otra y nunca saben dónde están.

¿Qué es un eval, en términos de producto?

Una especificación en tres partes, escrita en el idioma del lector y propiedad del rol de producto.

• Los casos que debe resolver: entradas reales, a ser posible de usuarios reales o de registros, cada una con lo que contiene una buena respuesta.
• Los casos en que debe negarse: las preguntas fuera del alcance, los datos que nunca puede revelar, las acciones que nunca puede afirmar haber realizado.
• La tolerancia: cuántas veces puede fallar en cada conjunto antes de retirar la función, expresada como un número que una persona ha firmado.

Husain describe tres niveles de prueba que encajan con esas partes: comprobaciones baratas que corren en cada cambio, revisión humana y de modelo de las trazas registradas, y pruebas A/B con usuarios reales. Los dos primeros son el eval. La especificación es una lista de casos y un número, y el número es una decisión de producto porque cambia calidad por entrega.

¿Quién lo escribe?

Quien escribiría, si no, los criterios de aceptación. Un ingeniero puede escribir el arnés; solo el rol de producto puede decir qué veinte casos importan, qué negativas son innegociables y qué tasa de fallo tolera el negocio. La guía de Anthropic sobre diseño de agentes, publicada el 19 de diciembre de 2024, hace el mismo punto desde la arquitectura: encontrar «the simplest solution possible, and only increasing complexity when needed», y elegir un flujo predefinido frente a un agente autónomo allí donde los pasos puedan conocerse de antemano. Esa elección es una decisión de especificación, y la toma quien posee los casos.

¿Qué aprendió el estudio al hacerlo?

Torn Studio sostuvo el rol de producto en Changemkr, una plataforma de IA para gestión del cambio de la que el estudio es copropietario, hasta junio de 2026. En el límite de junio, ocho entornos de IA corrían en un servicio, cada uno con su modelo, sus herramientas y su versionado de prompts con reversión en un clic, contables en el registro de prompts. Cada cambio de prompt era una release, y cada release se aceptaba contra sus casos.

En junio de 2026 una consultora externa probó el asistente de IA del planificador y lo reportó como poco fiable. El estudio convirtió el informe en 27 hallazgos numerados, los agrupó por causa raíz antes de tocar código y encontró que 4 de los 27 eran decisiones de producto sin ninguna corrección de código: la función hacía lo que se le había dicho, y lo que se le había dicho estaba mal. Esa separación, bug o decisión, es lo que un eval hace visible antes de que lo haga un tester.

La verificación es donde está el límite honesto. Las correcciones se ejecutaron contra el stack completo en contenedores con pruebas de navegador: 11 pasaron, 1 se omitió, y los tres grandes flujos generativos nunca se verificaron de extremo a extremo, porque sus salidas varían entre ejecuciones y una prueba que espera la misma salida cada vez no puede sostenerlos. El informe lo dice por hallazgo, y ese es el punto: una verificación que se reporta totalmente en verde es una en la que nadie puede confiar la próxima vez.

¿Dónde entra la confianza?

Un eval cubre la corrección; los casos sobre negarse y sobre avisar cubren la confianza, y pertenecen al mismo documento. La People + AI Guidebook de Google PAIR pide a los equipos calibrar la confianza — «tell the user when a lack of data might mean they’ll need to use their own judgment» — y mostrar la seguridad como categorías. La página de la Comisión Europea sobre el Reglamento de IA dice que los chatbots deben hacer saber a las personas que interactúan con una máquina, con normas de transparencia aplicables desde agosto de 2026, y enlaza el texto. Cómo se gana esa confianza una función es un artículo aparte; el eval es donde los casos se escriben primero.

Dónde se sitúa el modelo dentro de un sistema existente — la tarea acotada con una comprobación alrededor — se explica en IA en tus sistemas actuales. Los casos de un eval se eligen igual que se prioriza un backlog, y ese método está en decidir qué construir a continuación.

Así especifica el estudio una función de IA

El Product Management en Torn Studio se cobra por proyecto con el precio fijado antes de empezar, y una función de IA dentro del alcance recibe su eval escrito antes que su prompt: los casos, las negativas, la tolerancia, firmados por la persona que leerá el número. El estudio construye después contra él, de modo que la función se entrega con el documento que dice qué puede hacer y dónde debe negarse.