Evaluación continua de IA en producción: golden sets, umbrales de degradación y alerta temprana

El piloto cerró con un informe impecable: accuracy de laboratorio, matriz de confusión y una demo que convenció al comité. Tres meses en producción, el mismo modelo empieza a “sentirse raro”: más escalamientos al humano, respuestas correctas en promedio pero frágiles en segmentos clave, y un error budget que se quema sin que nadie pueda señalar cuándo empezó la pendiente. El problema no fue el go/no-go; fue asumir que la evaluación puntual basta cuando el mundo de inputs no deja de moverse.

Este artículo avanza el arco editorial reciente —de observabilidad y triage a SLOs y error budget, postmortem blameless y cierre de acciones— hacia la mejora proactiva: evaluación continua en producción con golden sets, umbrales de degradación y alerta temprana. No es un segundo postmortem. Es el sistema que intenta detectar la degradación antes de convertirla en incidente.

Por qué la evaluación puntual del piloto no basta en producción

La evaluación del piloto responde a una pregunta de decisión: ¿hay evidencia suficiente para salir? La evaluación continua responde a otra: ¿el servicio sigue dentro de la calidad que prometimos mientras cambian datos, prompts, modelos y comportamiento de usuarios?

En producción fallan, de forma rutinaria, supuestos que el piloto no stress-testeó del todo:

• Drift de inputs. Nuevos productos, jerga regional, tickets atípicos o campañas estacionales desplazan la distribución respecto al set de validación.
• Cambios silentes. Un ajuste de prompt, un umbral de auto-aprobación o un modelo proveedor actualizado puede pasar change control y aun así degradar un segmento.
• Calidad “promedio” engañosa. El score global se mantiene mientras un vertical crítico (cobranza, soporte VIP, compliance) se derrumba.
• Latencia y costo acoplados a calidad. Retrys, context window más largo o retrieval más agresivo disfrazan caídas de calidad… hasta que el SLO de latencia o el presupuesto lo notan.

Sin un ritual de evaluación recurrente amarrado a umbrales y ownership, el equipo solo se entera cuando el burn del error budget ya es visible o cuando el negocio reporta “esto ya no sirve”. La alerta temprana existe precisamente para acortar ese gap.

Qué es un golden set operativo (casos, labels, refresh)

Un golden set operativo no es el dataset de entrenamiento ni el Excel del piloto. Es un corpus vivo, versionado, con casos representativos del tráfico real (y de los modos de falla que te importan), etiquetado con el criterio de aceptación que el negocio reconoce.

Mínimo viable:

• Casos. Entradas realistas (prompts, tickets, documentos, turnos de conversación) con metadatos de segmento: canal, producto, idioma, criticidad. Incluye casos “felices”, borde y conocidos difíciles.
• Labels / criterios. Qué cuenta como correcto: label discreto, rúbrica multi-eje (exactitud, tono, grounding, cumplimiento), o referencia humana. Evita criterios solo el equipo de ML entiende.
• Tamaño útil, no teatral. Cientos bien curados suelen vencer a miles sin dueño. Prioriza cobertura de segmentos de negocio y de fallas históricas del postmortem.
• Refresh. Cadencia explícita (p. ej. semanal o quincenal): retirar casos obsoletos, añadir fallos recientes de producción y rotar un porcentaje para no sobreajustar el set.
• Versionado. Tag del golden set en el mismo change control que modelos/prompts/umbrales. Si evalúas con un set distinto al acordado, comparas peras con manzanas.

Ejemplo hipotético: un asistente de clasificación de tickets en México mantiene un golden set de 320 casos (80 por vertical), rúbrica de exactitud + escalamiento correcto, y cada martes incorpora hasta 10 tickets fallidos del triage de la semana previa, retirando 10 casos estables antiguos.

Señales de degradación: más allá del “accuracy bajó”

La evaluación continua debe mirar un tablero corto, no un museo de métricas. Cuatro familias suelen anticipar problemas de negocio:

1) Calidad de salida

Score sobre golden set (exactitud, pass@rúbrica, grounding). Desglosa por segmento. Una caída de 2 puntos globales puede esconder −15 en un vertical.

2) Latencia

p50/p95 del camino crítico del modelo (no solo del API gateway). Degradación de calidad a veces se disfraza con más tokens o más retrieval; la latencia lo delata antes que el NPS.

3) Tasa de escalamiento humano (HITL)

Si el sistema “se vuelve más humilde” o más agresivo sin cambio de política, algo se movió: umbral, confianza calibrada, o distribución de inputs. El HITL es a menudo el canario de negocio más barato.

4) Drift de inputs

Desplazamiento de features, longitud de prompt, idiomas, categorías nuevas o score de out-of-distribution. No prueba falla de calidad por sí solo; sí justifica una corrida de eval extraordinaria.

Estas señales conviven con la observabilidad de producción: la eval te dice si la calidad prometida se sostiene; la observabilidad te dice qué está pasando ahora en el sistema vivo.

Umbrales y su amarre a SLOs / error budget

No reescribimos aquí el marco de SLOs para servicios de IA. La regla práctica es: los umbrales de evaluación continua son indicadores adelantados del SLO de calidad (y a veces de latencia), no un segundo contrato paralelo sin dueño.

• Umbral verde. Score de golden set (global y por segmento crítico) dentro de la banda acordada en el go/no-go o en el último change control.
• Umbral ámbar (degradación temprana). Cruce de banda inferior o tendencia de N corridas consecutivas a la baja. Dispara review, no freeze automático.
• Umbral rojo (riesgo de burn). Nivel en el que, de sostenerse, el error budget de calidad se consumiría fuera de ritmo. Escala a contención / change freeze según runbook —alineado a lo que ya documentaste para error budget agotado.

Amarras útiles:

1. Define el SLO de calidad en lenguaje de negocio (p. ej. “≥ X% de casos del golden set pasan rúbrica en segmentos A/B”).
2. Traduce a umbrales de eval con histéresis (evita flapping por ruido de muestreo).
3. Registra umbrales en change control: quién puede bajarlos y con qué evidencia.
4. Cuando el umbral ámbar se active de forma recurrente, abre acción con dueño —el mismo rigor que en el cierre de acciones a 14 días, sin esperar al incidente.

Diseño de alerta temprana vs alerta de incidente

Mezclar ambos canales es la forma más rápida de crear fatiga y de ignorar la degradación lenta.

La alerta temprana debe ser accionable y aburrida: un mensaje con segmento afectado, delta vs baseline, enlace a la corrida y dueño sugerido. Si cada ámbar pagina al on-call, en dos semanas nadie mirará el canal. Reserva el pager para rojo de SLO o para síntomas de incidente —ver el runbook de triage en 30 minutos.

Ownership: quién revisa los fallos del eval semanal

Sin dueño, el golden set se convierte en un dashboard decorativo. Propón un RACI mínimo:

• Owner del servicio (accountability). Decide si el ámbar escala a change freeze, rollback o solo backlog. Es quien responde ante el burn del error budget.
• Operador de eval (ejecución). Corre el job, valida que el set versionado sea el correcto, publica el reporte.
• Revisor de fallos (calidad). Muestrea casos fallidos, clasifica modo de falla (prompt, retrieval, label, drift, bug) y propone acciones.
• Producto / negocio (criterio). Confirma si un “fallo” del golden set sigue alineado al criterio de aceptación —especialmente tras cambios de política.

Ritual sugerido (30–45 min/semana): abrir el reporte → top fallos por segmento → 3 acciones con dueño/fecha → actualizar umbrales solo si hay evidencia y change control. Si el fallo es recurrente y ya hubo incidente similar, no inventes un proceso nuevo: enlázalo al backlog de acciones del postmortem o abre uno corto con el mismo template de cierre.

Anti-patrones

• Eval de una sola vez. El PDF del piloto no sustituye la corrida semanal. Si no hay job programado y artefacto versionado, no hay evaluación continua.
• Golden set estático. Un set que no incorpora fallos reales ni retira casos obsoletos se vuelve un examen memorizado. El modelo (o el prompt) se sobreajusta al ritual y falla en producción.
• Umbral sin dueño. Números en un Notion sin change control ni persona que pueda bajar/subir el umbral con evidencia. Resultado: o se ignora o se mueve a dedo bajo presión.
• Solo métrica global. Ignorar segmentos críticos es cómo “todo verde” convive con clientes furiosos.
• Alertar como incidente cada caída de 0.5 puntos. Fatiga → silencio. Separa ámbar (review) de rojo (contención).
• Eval desconectada de SLOs. Si la métrica de golden set no informa el SLO de calidad ni el burn, es teatro de métricas.

Cómo empezar esta semana (checklist corto)

1. Elegir 1 servicio de IA en producción y documentar el criterio de aceptación en una página.
2. Curar un golden set v1 (aunque sea 100–200 casos) con segmentos y labels revisados por negocio.
3. Automatizar una corrida semanal; guardar score global + por segmento + lista de fallos.
4. Definir umbrales verde/ámbar/rojo y amarrarlos al SLO de calidad existente.
5. Nombrar owner, operador y revisor; agendar el ritual de 30 minutos.
6. Cablear alerta temprana al canal de calidad (no al pager), con enlace a la corrida.

Con eso cierras el círculo: observas, triages, cuidas el error budget, aprendes con postmortems… y además detectas la pendiente antes de que se convierta en incendio. El siguiente paso natural del arco —FinOps y costo-calidad— tiene más sentido cuando ya sabes qué calidad estás comprando cada semana.

¿Listos para montar evaluación continua sin teatro de métricas?

En NextWave AI ayudamos a equipos B2B en México y LatAm a diseñar golden sets operativos, umbrales amarrados a SLOs y rituales de alerta temprana que el negocio entiende. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969.