El verdadero KPI de seguridad agentic es cuánto riesgo se elimina antes de que el código exista como deuda

Encontrar mucho puede significar llegar demasiado tarde. Los programas de seguridad suelen mostrar volumen de findings como señal de actividad. Pero cien vulnerabilidades detectadas después de integrar y desplegar código pueden representar más riesgo y costo que diez bloqueadas mientras el autor todavía trabaja en el cambio. El enfoque pre-submit de Google permite replantear el KPI: cuánto riesgo nunca se convirtió en deuda. Esa métrica obliga a observar el momento de detección. Una organización madura debería separar hallazgos antes del merge, después del merge y en producción, porque cada etapa implica una superficie distinta de exposición, coordinación y costo de remediación.

La velocidad de reparación es tan importante como la sensibilidad. Un detector extremadamente sensible que produce explicaciones débiles puede ralentizar el equipo y fomentar que los desarrolladores ignoren alertas. La seguridad útil reduce el tiempo entre señal y corrección. Para medirlo conviene registrar cuánto tarda una persona en entender el hallazgo, cuántos ciclos de revisión necesita y si la sugerencia propuesta conduce a un fix que pasa pruebas. Un agente puede aportar valor aunque no encuentre más vulnerabilidades que un scanner tradicional si convierte el feedback en algo localizado, accionable y verificable justo cuando el contexto mental del desarrollador todavía está fresco.

Los falsos positivos consumen capital de confianza. Cada alerta incorrecta obliga a alguien a leer, investigar y descartar. Ese costo no aparece en una gráfica de cobertura, pero erosiona la disposición a escuchar al sistema. Por eso bajar falsos positivos puede ser una mejora de seguridad real aunque el número total de alertas caiga. Una métrica equilibrada combina recall en casos relevantes con precisión y esfuerzo humano. También debería medir overrides: cuántas veces una persona ignoró al agente, por qué y si esa decisión fue correcta después. El objetivo no es construir un guardia que grita más, sino uno que merece atención cuando interrumpe.

Prevenir también crea datos para mejorar el diseño. Cuando un tipo de vulnerabilidad aparece repetidamente en cambios nuevos, la respuesta no debería ser mantener al agente corrigiendo el mismo patrón para siempre. Es una señal para mejorar APIs, templates, librerías o reglas internas. El ledger de hallazgos puede agrupar causas y mostrar dónde el sistema de desarrollo invita al error. Así la IA deja de ser una escoba que limpia defectos y se convierte en sensor de diseño. La métrica de éxito a largo plazo puede ser que cierta categoría de alertas disminuya porque la plataforma eliminó la posibilidad de cometerla de forma habitual.

La prevención necesita contrafactuales modestos. Decir que una alerta evitó un incidente real puede ser imposible de demostrar. Conviene no inflar el ROI con contrafactuales imaginarios. Sí podemos registrar que una vulnerabilidad verificable fue introducida en un diff, que el agente la detectó antes del merge, que el autor aceptó una corrección y que las pruebas confirmaron el fix. Esa cadena es evidencia suficiente para medir proceso. Para estimar impacto económico, la organización puede usar rangos históricos de costo por clase de defecto, claramente etiquetados como estimaciones. Separar hechos observados de valor inferido mejora credibilidad ante seguridad y finanzas.

Aplicación en Goatify. En Goatify deberíamos medir nuestros controles por riesgo interceptado antes de acción, no por cantidad de mensajes de warning. Una publicación bloqueada antes de salir, un destinatario corregido antes de enviar o un permiso inválido detectado antes de modificar un CRM son equivalentes operativos de un pre-submit security check. Cada habilidad puede registrar condición detectada, evidencia, tiempo hasta resolución y resultado final. Ese dataset permite optimizar dónde vale interrumpir y dónde una regla solo genera ruido. El producto se vuelve más seguro cuando aprende a evitar trabajo peligroso sin convertir cada workflow en una ceremonia.