GitHub añade a security overview las métricas de AI Scan para pull requests

GitHub amplió el 13 de octubre de 2026 security overview: los administradores de organizaciones y cuentas enterprise ya pueden seguir cómo funciona AI Scan en los pull request. El panel muestra cuántos hallazgos ha generado AI Scan y cuántos han cerrado los desarrolladores. El anuncio en GitHub Changelog ocupa unas pocas líneas, y la lista de métricas se interrumpe a mitad de frase. Por eso, a continuación solo figura lo que está confirmado, junto con una advertencia honesta sobre lo que todavía no se ve.

Qué ha aparecido exactamente

AI Scan para pull request analiza los cambios de código en busca de vulnerabilidades antes de la fusión. Forma parte de code scanning. Hasta ahora, un administrador podía activar la función, pero era difícil evaluar su rendimiento: los hallazgos se mezclaban con los resultados de otros escáneres y la valoración se basaba en indicios indirectos.

Ahora security overview tiene un apartado específico para AI Scan. Del anuncio se desprende lo siguiente:

• las métricas están disponibles para administradores de organizaciones y de cuentas enterprise;
• muestran cuántos hallazgos ha generado AI Scan;
• muestran cuántos hallazgos se han resuelto;
• el texto del anuncio menciona otros indicadores, pero el mensaje está cortado y no es posible reconstruir el conjunto completo a partir de él.

El anuncio no detalla los plazos de disponibilidad, las limitaciones por plan ni si hay desglose por repositorios o equipos. Conviene comprobar todo esto en la documentación de GitHub.

Por qué importa a quienes pagan por la herramienta

Un escáner con IA, igual que el análisis estático clásico, se convierte fácilmente en una fuente de ruido. Si genera muchos hallazgos y solo se cierra una pequeña parte, los desarrolladores empiezan a pasar de largo los comentarios del pull request sin leerlos. El par de indicadores «generados» y «resueltos» ofrece una primera respuesta aproximada a la pregunta de si la función aporta valor. Una proporción alta de hallazgos cerrados indica que las alertas dan en el blanco. Una proporción baja apunta a falsos positivos, a una cobertura mal ajustada o a equipos que simplemente ignoran la revisión.

Hay también un aspecto de gestión. Los equipos de seguridad suelen conseguir presupuesto con argumentos del tipo «hemos encontrado y cerrado tantos problemas antes de llegar a producción». Antes, esas cifras de la parte de IA había que recopilarlas a mano; ahora están en el mismo panel donde ya se ven las alertas del resto de escáneres. Para los clientes enterprise con decenas o cientos de repositorios, esto ahorra tiempo en la elaboración de informes.

Qué hacer en la práctica

El anuncio ofrece pocos datos, así que lo razonable es avanzar por pasos:

1. Abra security overview y busque el nuevo apartado de AI Scan. Si no aparece, compruebe los permisos: la función está dirigida a administradores de organizaciones y de enterprise.

2. Registre los valores iniciales. Sin una línea base, dentro de un mes no habrá nada con que comparar.

3. Contraste el número de hallazgos generados con el de cerrados. Si la brecha es grande, revise por muestreo varias decenas de hallazgos y averigüe si eran fallos reales o ruido.

4. Compare los repositorios entre sí. Si en uno el equipo cierra casi todo y en otro casi nada, lo más probable es que el problema esté en el proceso y no en el escáner.

5. No saque conclusiones sobre la calidad del propio modelo solo a partir de estas métricas. Un hallazgo cerrado no equivale a una vulnerabilidad encontrada, y los problemas que el escáner pasa por alto no entran en esta estadística.

Por su alcance, es una actualización pequeña: una nueva pestaña con métricas, no un modelo ni un agente nuevos. Pero justamente este tipo de cambios muestra que las revisiones con IA de GitHub pasan del modo «lo activamos y esperamos lo mejor» a otro en el que su eficacia se puede medir. Cuando GitHub desvele la lista completa de indicadores, se sabrá hasta qué profundidad permite llegar esta analítica.