Todo el mundo dice que "monitoriza IA en producción". Muy pocos equipos pueden responder las preguntas que realmente importan: ¿estamos bloqueando riesgo real o solo generando ruido? ¿Dónde se escapa el presupuesto? ¿Qué casos de uso se están desviando de política?
Si tus métricas no responden esas preguntas, no estás haciendo gobernanza. Estás haciendo teatro de observabilidad.
El problema de los KPIs
La mayoría de equipos miden requests totales, latencia media y uptime del modelo. Son métricas útiles de plataforma, pero débiles para gobernanza. Gobernanza trata de calidad de controles, resultados de política y riesgo de negocio. Las métricas de plataforma te dicen que el sistema funciona. Las métricas de gobernanza te dicen si funciona de forma segura y dentro de política.
La brecha entre ambas es donde viven la mayoría de los incidentes de IA.
8 KPIs de gobernanza que vale la pena medir
1. Tasa de violaciones de política
Porcentaje de requests que disparan violaciones de compliance o seguridad. Mídela por producto, tenant y caso de uso, no solo como agregado global. Una tasa que sube en un tenant mientras el total se mantiene estable significa que algo concreto está cambiando, y necesitas saber qué.
Por qué importa: muestra la tendencia real de exposición al riesgo, no solo la salud del sistema.
2. Ratio bloquear vs advertir
Con qué frecuencia tus políticas bloquean duro frente a emitir solo un aviso. Si la tasa de bloqueo es cercana a cero, probablemente estás infra-aplicando controles. Si es muy alta, puede que estés sobre-bloqueando y creando fricción de producto innecesaria.
Por qué importa: revela si tu postura de política está calibrada o es solo cosmética.
3. Tendencia de precisión en detección de PII
Mide falsos positivos y detecciones fallidas a lo largo del tiempo, no solo el volumen total de detecciones. Un detector que marca todo no es un buen detector: erosiona la confianza y genera fatiga de alertas. Uno que falla en detecciones crea riesgo legal y de seguridad.
Por qué importa: la calidad de detección de PII se degrada silenciosamente a medida que evolucionan los patrones de datos. Medir la precisión te obliga a detectarlo antes de que lo haga un incidente.
4. Coste evitado pre-ejecución
Gasto evitado por controles de presupuesto y rate antes de llamar al modelo. Este es el número que le importa a tu CFO, porque es valor FinOps directo que no requiere explicación.
Por qué importa: el seguimiento de costes post-ejecución te dice lo que gastaste. Los controles pre-ejecución te dicen lo que ahorraste.
5. Cobertura en rutas de alto riesgo
Porcentaje de requests de alto riesgo que pasan realmente por toda la pila de políticas. Si este número está por debajo del 100%, tu postura de gobernanza es más débil de lo que muestra el dashboard.
Por qué importa: una cobertura incompleta significa que tus controles tienen puntos ciegos que quizás no descubras hasta que un incidente los exponga.
6. Tiempo medio de actualización de políticas (MTTU)
Cuánto tiempo pasa entre detectar un hueco de gobernanza y desplegar una política o rulepack actualizada. Los equipos con MTTU rápido se recuperan limpiamente de los incidentes. Los equipos con MTTU lento los repiten.
Por qué importa: la agilidad de políticas es la diferencia operativa entre equipos resilientes y equipos con incidentes repetidos.
7. Tasa de recurrencia de incidentes
Con qué frecuencia se repite la misma clase de incidente después de una supuesta remediación. Una tasa de recurrencia por encima de cero significa que tus controles son cosméticos, no sistémicos. Has parcheado el síntoma sin corregir el hueco subyacente.
Por qué importa: los incidentes repetidos son una señal de que tu proceso de gobernanza genera recomendaciones pero no las implementa.
8. Completitud de evidencia de auditoría
Porcentaje de requests con evidencia completa y trazable: decisión, versión de regla, actor, timestamp y resultado. Sin esto, no tienes una postura de compliance defendible cuando un regulador o cliente pregunta cómo se tomó una decisión.
Por qué importa: sin evidencia no hay compliance. Así de simple.
Cómo operacionalizarlo en 30 días
El objetivo no es medir los ocho desde el primer día. El objetivo es tener owners, umbrales y cadencia de revisión para cada uno dentro de 30 días.
Semana 1. Define los KPIs de gobernanza con owners en Security, Platform, Compliance y FinOps. Establece umbrales rojo, amarillo y verde para cada uno. Sin umbrales, las métricas son solo números.
Semana 2. Instrumenta el pipeline para producir eventos estructurados. Añade dimensiones de tenant y caso de uso a todas las vistas de KPI. Los agregados sin dimensiones esconden la señal en el ruido.
Semana 3. Revisa un incidente real y localiza dónde los KPIs no avisaron a tiempo. Corrige la telemetría faltante o los puntos ciegos de política que revele el post-mortem.
Semana 4. Ejecuta una revisión mensual de gobernanza con producto, ingeniería y compliance juntos. Conecta los ítems del roadmap directamente con deltas de KPIs. Si una métrica no está cambiando decisiones, replantéate si la necesitas.
Lo que hacen las buenas métricas de gobernanza
Las buenas métricas de gobernanza no solo describen el sistema. Cambian decisiones. Si un KPI no puede disparar una acción concreta, elimínalo. Quédate con los que mejoran seguridad, compliance y rendimiento operativo, y asegúrate de que las personas responsables de esos resultados los revisan regularmente.
Los equipos que lo hacen bien no son los que tienen los mejores dashboards. Son aquellos donde una tasa de violaciones creciente en un solo tenant dispara una conversación antes de que se convierta en un incidente en producción.