Buenas métricas de seguridad en la era de la IA: qué medir

Todos los programas de seguridad miden algo. Lo difícil es medir las pocas cosas que cambian una decisión y, en 2026, darse cuenta de que la lista de cosas que merece la pena medir ha ganado toda una sección con forma de IA que la mayoría de los paneles todavía ignoran. Esta es una guía práctica de cómo es una buena métrica de seguridad, del conjunto clásico que sigue ganándose su sitio y de las métricas de la era de la IA que probablemente le faltan a tu programa.

Qué hace buena a una métrica (y digna de conservarse)

Antes de añadir una métrica, haz que supere cuatro pruebas. Si falla cualquiera de ellas, es casi seguro una métrica de vanidad y deberías descartarla:

• Accionable. Una mala lectura apunta a algo concreto que alguien puede hacer. El «número de alertas» por sí solo no es accionable; el «porcentaje de alertas críticas triadas dentro del SLA» sí lo es.
• Con responsable. Una persona o un equipo con nombre responde de la cifra y de moverla. Una métrica sin responsable se desvía, genera discusiones y acaba ignorándose.
• Ligada a una decisión. Alguna elección real depende de ella: financiar esto, aceptar ese riesgo, escalar aquí, dotar de personal allí. Si ninguna decisión cambia sea cual sea el valor, la métrica es decoración.
• Difícil de manipular. No puedes satisfacer la cifra sin que mejore la realidad subyacente. «Tickets cerrados» es fácil de manipular; «vulnerabilidades críticas cuya remediación se ha confirmado y se ha vuelto a escanear» no lo es.

Un puñado de métricas que superan las cuatro vale más que un muro de gráficos que impresionan y no significan nada. Más indicadores no hacen que un programa esté más controlado: hacen más difícil ver lo que importa.

KPI, KRI y KCI: tres preguntas, no tres sinónimos

Estas siglas se usan indistintamente, lo que oculta que responden a preguntas distintas:

• KPI (key performance indicator, indicador clave de rendimiento): ¿Estamos rindiendo bien? Tiempo medio de respuesta, porcentaje de vulnerabilidades críticas parcheadas dentro del SLA, tasa de finalización de la formación.
• KRI (key risk indicator, indicador clave de riesgo): ¿Está subiendo nuestro riesgo? Una señal de alerta con vistas al futuro: sistemas expuestos a internet sin parchear, volumen de detecciones de shadow AI, número de cuentas privilegiadas sin MFA. Los KRI deben moverse antes de que lo haga un incidente.
• KCI (key control indicator, indicador clave de control): ¿Funcionan de verdad nuestros controles? Cobertura de MFA, cobertura de EDR, tasa de éxito de las pruebas de restauración de copias de seguridad, cobertura de los logs.

Un programa equilibrado usa los tres. Los KCI demuestran que tus controles existen y funcionan, los KRI te avisan cuando crece la exposición y los KPI muestran si el equipo está cumpliendo sus objetivos.

Adelantados frente a retrasados: guíate por unos y confirma con los otros

Las métricas retrasadas miden resultados que ya se han producido: incidentes de este trimestre, tiempo medio de recuperación, brechas notificadas. Sirven para pedir cuentas, pero describen el pasado. Las métricas adelantadas son predictivas: latencia de parcheo, cobertura de controles, tasa de notificación de phishing, cobertura del inventario de IA. Miden las condiciones que impulsan los resultados futuros, así que todavía tienes tiempo de actuar. Combínalas a propósito: un indicador adelantado para guiarte y uno retrasado para confirmar que la dirección funcionó. Un programa que solo informa de cifras retrasadas está siempre explicando el trimestre pasado en lugar de mejorar el siguiente.

Informa para el público, no para ti

Los mismos datos de base deberían agregarse de tres formas distintas, porque tres públicos distintos toman tres decisiones distintas:

• El consejo toma decisiones de financiación y de aceptación del riesgo. Dale un pequeño conjunto de indicadores de riesgo y de tendencia en términos de negocio: la postura general, la tendencia en el tiempo, los principales riesgos y lo que costarían aproximadamente, la cobertura de los controles críticos y el avance frente a la hoja de ruta que está financiando. Unas pocas cifras con significado, ligadas al dinero y a las decisiones.
• El CISO y la dirección de seguridad siguen los KPI de salud del programa en todo el conjunto: el tejido que une el relato del consejo con la realidad del terreno.
• El SOC vive en las cifras operativas: MTTD, MTTR, volumen de alertas, tasa de falsos positivos, cobertura de detección. Son las que impulsan el ajuste y la dotación de personal del día a día.

El error clásico es enseñar al consejo un panel del SOC, o pedir al SOC que actúe sobre una línea de tendencia de nivel de consejo. Mismos datos, distinta altitud.

El conjunto clásico que sigue ganándose su sitio

Ninguna de estas métricas es nueva, y ahí está la clave: perduran porque están ligadas a decisiones reales:

• MTTD (tiempo medio de detección) y MTTR (tiempo medio de respuesta o recuperación): lo rápido que ves y gestionas un incidente.
• Latencia de parcheo: el tiempo desde que hay una corrección disponible hasta que se despliega.
• Porcentaje de vulnerabilidades críticas dentro del SLA: no solo «cuántas», sino cuántas se están gestionando a tiempo.
• Tasa de notificación de phishing: una señal de comportamiento adelantada; la tasa de notificación es más útil que la de clics porque mide la defensa que quieres construir.
• Cobertura de MFA y cobertura de EDR: los dos KCI de cobertura de controles que, en silencio, evitan más incidentes.
• Tasa de éxito de las pruebas de restauración de copias de seguridad: las copias de seguridad que nunca has restaurado son una esperanza, no un control.
• Cobertura de controles: cuánto de tu marco elegido (como el NIST CSF o la ISO 27001) está realmente implantado y respaldado con pruebas, no solo documentado.

Las métricas de la era de la IA que les faltan a la mayoría de los programas

Aquí es donde fallan los programas de 2026. Miden bien el parcheo, la cobertura y la respuesta, y casi no tienen visibilidad sobre su superficie de IA. Si no puedes responder a estas, vas a ciegas en la parte de tu superficie de ataque que más rápido crece:

• Cobertura del inventario de IA y de modelos: ¿conoces cada modelo, API y servicio de IA que se usa en el negocio? Es el equivalente en IA del inventario de activos, y suele empezar cerca de cero.
• Detecciones de shadow AI: herramientas de IA no autorizadas que los empleados adoptan por su cuenta. Un KRI: que suban las detecciones significa que sube el riesgo sin gobierno.
• Tasa de superación de pruebas de inyección de prompts: de tus aplicaciones expuestas a la IA, ¿cuántas superan una batería de pruebas de inyección de prompts?
• Cobertura de AIBOM y de procedencia de modelos: ¿puedes producir un AI Bill of Materials (lista de materiales de IA) de tus sistemas: qué modelos, pesos, datasets y componentes, y de dónde?
• Tasa de cierre de hallazgos del red team de IA: los hallazgos de las pruebas adversarias de tus funciones de IA, y lo rápido que se cierran.
• Nivel de autonomía de los agentes: cuánto tienen permitido hacer tus agentes de IA sin una persona en el bucle. Una autonomía que sube sin que suban los controles es un riesgo que quieres ver en un gráfico.
• Tasa de fundamentación y citas en RAG: en los sistemas con generación aumentada por recuperación, con qué frecuencia las respuestas se basan de verdad en las fuentes recuperadas y las citan, como indicador del riesgo de alucinación.
• Incidentes de fuga de datos a través de la IA: datos sensibles expuestos mediante una herramienta, un prompt o una integración de IA.

No puedes sacar de una diapositiva unos objetivos creíbles para estas métricas, así que no lo intentes.

Fija tus propios objetivos: no copies una «media del sector»

La petición más habitual es «¿cuál es una buena cifra de MTTR, de latencia de parcheo o de cobertura?». No hay una respuesta universal honesta, y citar una de la diapositiva de un proveedor es la forma en que los programas acaban persiguiendo una cifra que no tiene nada que ver con su riesgo. Haz esto en su lugar: mide tu cifra actual, decide dónde dice tu tolerancia al riesgo que tiene que estar y fija un objetivo que cierre la brecha en un plazo realista. Para la mayoría de las métricas de la era de la IA anteriores, el primer objetivo honesto es simplemente «medirla», después «llevar la cobertura por encima del X %» y, a partir de ahí, ir ajustando. Métodos como FAIR pueden ayudarte a traducir un riesgo a un rango en dólares cuando el consejo pregunta «¿y qué?»; marcos como el NIST CSF y la ISO 27001 te dan un conjunto de controles frente al que medir la cobertura. Ninguno te da un objetivo universal: te dan una estructura para fijar los tuyos.

Antipatrones comunes que hay que eliminar en cuanto aparecen

• Métricas de vanidad: cifras grandes que suben y suben (alertas gestionadas, formaciones impartidas) pero no cambian ninguna decisión.
• Métricas sin responsable: un gráfico sin un responsable que rinda cuentas es un gráfico que se discutirá y después se abandonará en silencio.
• Definiciones manipulables: cualquier métrica que puedas satisfacer sin mejorar la realidad acabará satisfaciéndose así.
• Proliferación de paneles: un panel más no es una idea más. Retira métricas con la misma intención con la que las añades.

Ponlo en práctica

Si quieres un punto de partida estructurado en lugar de una hoja de cálculo en blanco, explora la biblioteca completa de métricas y construye una puntuación de riesgo ponderada: elige las métricas que encajan con tu programa, fija tus propios objetivos y pondéralas en una única puntuación de postura de la que puedas seguir la tendencia. A partir de ahí, nuestras herramientas encajan con las medidas anteriores (una cuenta gratuita tiene 3 usos de herramientas gratuitos):

• AI Security Risk Mapper: mapea los riesgos de IA para los que ahora necesitas métricas.
• CSPM Readiness Scorecard: puntúa la cobertura de los controles de postura en la nube.
• Herramientas de seguridad de IA: el conjunto completo para la capa de IA de tu programa.
• Todas las herramientas de PlayCISO: escáneres, scorecards y generadores para todo el programa.

Este artículo es una guía educativa y neutral respecto a los proveedores para responsables de seguridad, no una auditoría, una certificación ni asesoramiento legal. Los nombres de los marcos (NIST CSF, FAIR, ISO 27001) se citan solo como orientación.