Los product managers deben escribir evals de AI, no solo specs

Un documento de requerimientos de producto describe qué debería hacer un feature. Un eval set demuestra si realmente lo hace. Para software determinístico, la brecha entre intención y verificación es estrecha — unit tests, integration tests y criterios de aceptación la cierran. Para productos de AI, la brecha es un abismo. El output es probabilístico. Un cambio de prompt puede mejorar una dimensión y degradar otra. Un upgrade de modelo puede cambiar tono, precisión y tasas de alucinación simultáneamente sin que ningún cambio de código dispare un test failure. El único mecanismo que cierra esta brecha es un eval set estructurado — y la persona que entiende qué significa "bueno" para el usuario es el product manager, no el ingeniero.

El prompt es temporal. El eval es permanente. Los prompts se reescriben, los modelos se intercambian, los pipelines de retrieval se reestructuran. El eval set sobrevive a todos estos cambios porque codifica qué debe hacer el producto, no cómo lo hace. Un PM que escribe un párrafo en un spec y nunca ve la rubric de scoring ha entregado la decisión de producto más consecuente — la definición de calidad — a quien editó por última vez un archivo YAML en el pipeline de evaluación.

La calidad de producto en AI no puede depender de percepciones

La calidad de producto tradicional tiene señales observables: el botón funciona, la página carga en menos de 200ms, los datos se guardan correctamente. La calidad de producto en AI es invisible hasta que se mide. Un resumen generado por AI puede omitir un detalle crítico. Una recomendación puede ser plausible pero incorrecta. Una decisión de routing puede escalar a un humano cuando el sistema podía resolver — o peor, resolver cuando la escalación era necesaria.

Los equipos que lanzan features de AI sin evals estructurados dependen de lo que el campo llama "vibe checks": un humano lee un puñado de outputs, decide que se ven bien, y aprueba el cambio. Esto funciona cuando el producto tiene diez usuarios. Colapsa a escala porque las percepciones no detectan regresiones, no se generalizan al long tail de inputs, y no producen evidencia para decisiones de rollback.

La consecuencia operacional: un upgrade de modelo se lanza, el tono se degrada en el 15% de las respuestas de soporte, y nadie lo nota hasta que el NPS cae tres semanas después. Para entonces, el daño está hecho, el modelo anterior está deprecado, y el equipo no tiene un regression set para prevenir que la falla recurra. Un eval estructurado habría detectado la degradación antes del deploy al evaluar tono como una dimensión independiente contra un dataset de baseline.

Los requerimientos se convierten en ejemplos en productos de AI

Un requerimiento tradicional dice: "El resumen debe capturar todos los action items de la reunión." Para software determinístico, esto se traduce directamente en criterios de aceptación. Para software de AI, no se traduce en nada accionable — porque "capturar todos los action items" no tiene una definición computable hasta que alguien provee ejemplos de reuniones, los action items que contienen, y los criterios para evaluar completitud.

Los evals de producto de AI son requerimientos expresados como ejemplos calificados:

• Input: una transcripción de una llamada de soporte de 30 minutos.
• Comportamiento esperado: el resumen incluye el problema declarado por el cliente, la resolución ofrecida y cualquier compromiso de seguimiento.
• Criterios de scoring: accuracy (¿declaró el problema correctamente?), completitud (¿incluyó todos los compromisos?), tono (¿se lee como profesional y neutral?), y comportamiento de fallo (¿qué hace cuando la transcripción es ambigua?).

Cada criterio se convierte en un scorer separado. Agrupar "calidad" en una dimensión hace invisibles las regresiones — una mejora de tono puede enmascarar una degradación de accuracy cuando se promedian en un solo número. El PM define las dimensiones. Ingeniería automatiza la medición.

El workflow práctico: un PM revisa cinco escenarios reales de usuarios de la semana pasada, anota cómo se ve "bueno" para cada uno, define los criterios de scoring en lenguaje simple, y los entrega a ingeniería como el contrato de eval. Esto no es trabajo extra encima de los requerimientos — es el requerimiento, expresado en la única forma contra la que el sistema de AI puede ser evaluado.

Los PMs son dueños de la definición de bueno

La rubric de scoring es el verdadero product spec para un feature de AI. Codifica qué importa, cuánto importa, y dónde están los límites entre aceptable e inaceptable. El PM es la única persona en el equipo con el contexto cross-funcional para tomar estas decisiones: conoce el lenguaje del usuario, las restricciones de negocio, los edge cases que generan tickets de soporte, y los modos de fallo que erosionan la confianza.

Cómo se ve la ownership del PM sobre evals de AI en la práctica:

• Escribir los criterios de la rubric — no el código de automatización, sino la definición en lenguaje simple de qué significa un score de 5 versus un score de 1 para cada dimensión.
• Proveer anchor examples — inputs reales de producción pareados con outputs que el PM ha calificado como excelentes, aceptables y fallidos. Estos anchors calibran el judge automatizado.
• Revisar el agreement del judge — comparación semanal de scores automatizados contra una muestra de outputs calificados por el PM. Si el judge y el PM discrepan en más del 15% de los casos, la rubric es demasiado vaga o el judge ha derivado.
• Mantener el eval como contrato vivo — cuando la dirección del producto cambia, el eval cambia primero. Nuevos modos de fallo de logs de producción se convierten en nuevos regression examples.

Ingeniería es dueña de la infraestructura: los CI gates que bloquean deploys cuando los scores caen, el pipeline de sampling en producción, la orquestación de LLM-as-judge, y los dashboards de observabilidad. Pero ingeniería no puede definir qué significa "bueno" para el usuario. Eso es trabajo de producto.

Ingeniería es dueña de la automatización, instrumentación y gates de deploy

La división de responsabilidad es limpia. El PM define qué medir. Ingeniería construye el sistema que lo mide continuamente, a escala, y con suficiente precisión para bloquear regresiones antes de que lleguen a producción.

El stack de ingeniería para evals de producto de AI incluye:

• Checks determinísticos como primera capa — validación de JSON schema, límites de longitud, detección de rechazo, filtros de contenido prohibido. Son binarios, rápidos, y detectan fallos en los que ningún LLM judge debería gastar inferencia.
• LLM-as-judge para calidad matizada — un evaluador automatizado que califica cada output contra la rubric del PM. El judge corre en cada CI build contra un dataset versionado y en una muestra de tráfico de producción para detectar drift.
• Human review como calibración — una muestra semanal de 50 production traces calificados por el PM o un domain expert, comparados contra el judge automatizado. Cohen's Kappa por encima de 0.6 indica alineamiento aceptable; por debajo de ese umbral, la rubric necesita revisión.
• CI gating — un deploy falla si alguna dimensión de la rubric cae más de 2 puntos desde el baseline trailing en el regression set. El umbral es per-route y per-rubric, así que un cambio de prompt en el agente de soporte no dispara una re-evaluación completa del asistente de ventas.
• Observabilidad en producción — las mismas rubrics que corren en CI corren sobre tráfico live muestreado para detectar fallos que el dataset offline no representa. Alertar cuando una dimensión sostiene una caída sobre una ventana configurable.

El contrato de eval — la tupla de (judge_model_id, rubric_version, prompt_template_hash) — se fija y versiona. Cambiar cualquier elemento es un acto deliberado que requiere review del PM, no un efecto secundario de un upgrade de modelo del vendor.

¿Qué hace útil un eval de producto de AI?

La diferencia entre un eval útil y un ejercicio de checkbox es especificidad. Los evals útiles detectan regresiones reales. Los evals inútiles aprueban todo y arrullan al equipo hacia falsa confianza.

¿Cómo deberían los PMs crear eval examples a partir de uso real?

Comenzar desde fallos en producción, no desde escenarios abstractos. Extraer los últimos 30 días de quejas de usuarios, escalaciones de soporte y feedback negativo. Cada queja recurrente se convierte en un criterio: "las respuestas suenan robóticas" se traduce en un eval de tono; "fechas incorrectas en el resumen" se convierte en un eval de accuracy factual; "no respondió la segunda pregunta del cliente" se convierte en un eval de completitud. Cinco ejemplos de producción bien elegidos con outputs calificados por el PM valen más que cincuenta test cases sintéticos que nunca representan la distribución real.

¿Cuántas dimensiones debería tener una rubric de eval?

Calificar una dimensión por evaluador. Tres a cinco criterios ortogonales cubren la mayoría de features de AI: accuracy, completitud, tono, seguridad y task completion. La tentación es agregar más — resistirla. Cada dimensión adicional requiere sus propios anchor examples, su propio ciclo de calibración y su propio baseline tracking. Comenzar con tres dimensiones donde el equipo tiene ejemplos fuertes calificados por el PM, luego agregar dimensiones solo cuando un fallo en producción revele un gap que los criterios existentes no detectan.

¿Cuándo deberían los evals bloquear un deployment?

Gatear por regresión, no por score absoluto. Un cambio de prompt que baja faithfulness en 3 puntos sobre el regression set — incluso si el score absoluto sigue por encima de 0.7 — representa una degradación que el equipo debería investigar antes de shippear. Los umbrales absolutos son útiles como pisos (no deployar si accuracy cae debajo de 0.6), pero la regresión relativa desde el baseline trailing detecta drift lento que los pisos absolutos no captan. La lógica de gating vive en CI y usa los umbrales definidos por el PM por dimensión.

Una visión opuesta

Un argumento común sostiene que los evals son testing — y testing pertenece a ingeniería. Los PMs definen qué construir; los ingenieros definen cómo verificar que funciona. Esta separación de responsabilidades ha servido bien al software por décadas, y extender la responsabilidad del PM hacia infraestructura de evaluación arriesga confusión de roles, iteración más lenta, y calidad de rubric que sufre por ownership no técnico.

Este argumento aplica para software determinístico donde el spec describe sin ambigüedad el comportamiento esperado. Se rompe para productos de AI porque el spec es el eval. El spec tradicional dice "el botón guarda el registro"; no hay ambigüedad en la verificación. El spec de AI dice "el resumen captura todos los action items" — y sin ejemplos calificados mostrando qué significa "captura" en el boundary, ninguna cantidad de infraestructura de ingeniería puede determinar si el sistema funciona. El PM no está testeando el sistema. El PM está definiendo el contrato de calidad del sistema en la única forma que produce verdad computable. Ingeniería automatiza ese contrato. El playbook operacional para agentes de AI en producción depende de que este contrato exista antes del deployment, no después de la primera queja de usuario.

Lo que importa recordar

• Para productos de AI, el eval set es el requerimiento de producto que no se degrada — sigue corriendo después del lanzamiento y detecta regresiones que specs en prosa no pueden.
• Los PMs son dueños de la rubric: la definición en lenguaje simple de qué significa un score de 5 versus 1 para cada dimensión de calidad.
• Calificar una dimensión por evaluador. Agrupar calidad en un solo número esconde si una regresión viene de accuracy, tono o completitud.
• Comenzar desde fallos en producción, no escenarios sintéticos. Cinco ejemplos reales con outputs calificados por el PM superan a cincuenta test cases abstractos.
• Fijar el contrato de eval — (judge_model_id, rubric_version, prompt_template_hash) — y requerir review del PM para cualquier cambio.
• Gatear deploys por regresión desde baseline trailing, no solo por pisos de score absoluto.

Conclusión

El trabajo de un product manager de AI ha absorbido una nueva responsabilidad central: definir calidad en una forma contra la que el sistema puede evaluarse a sí mismo. Esto no es una tarea de testing delegada a QA. Es el acto de especificar qué debe hacer el producto — expresado no como párrafos que acumulan polvo en un wiki, sino como ejemplos calificados que corren en cada build, cada deploy y cada muestra de producción. El PM que nunca ha abierto la rubric de eval no está liderando el producto. Está esperando que el producto funcione. Y en AI, la esperanza es el mecanismo por el cual las regresiones llegan a los usuarios sin ser detectadas.