Imagina que tu equipo activa un escaneo de seguridad en cada pull request. A la semana aparecen docenas de hallazgos. ¿Mejoró el código o solo aumentó el ruido? GitHub acaba de añadir una vista para responder esa pregunta en AI Scan, su análisis de seguridad asistido por IA para pull requests. La novedad, anunciada el 13 de octubre de 2026, interesa sobre todo a quienes administran la seguridad de una organización.

Qué cambió

En Security overview, la página antes llamada «CodeQL pull requests» pasa a llamarse «Code scanning on pull requests». Tiene pestañas separadas para CodeQL y AI Scan. La de AI Scan muestra hallazgos generados y resueltos, tasa de remediación, repositorios con hallazgos, tendencias del periodo y frecuencia con que se aplican sugerencias de autofix. También distingue hallazgos con sugerencia de corrección de los que no la tienen.

Esto permite responder una pregunta operativa: ¿en qué repositorios la herramienta detecta problemas que el equipo realmente corrige? Antes de ampliar el despliegue, conviene mirar la evolución de cada repositorio y no solo el total de alertas. Según el anuncio oficial de GitHub, la vista está en vista previa pública en github.com, incluido GitHub Enterprise Cloud, para clientes de GitHub Code Security o GitHub Advanced Security. GitHub Enterprise Server no está incluido en este lanzamiento.

Una evaluación de 30 minutos para tu equipo

1. Abre Security overview en tu organización y entra a «Code scanning on pull requests». Si no ves la pestaña AI Scan, revisa primero el plan y la disponibilidad de la vista previa. No asumas que está habilitada para todos.

2. Elige dos repositorios con actividad comparable y fija un mismo periodo. Anota pull requests abiertos, hallazgos generados y resueltos. El número bruto de hallazgos aislado no describe la calidad.

3. Revisa una muestra pequeña de hallazgos: cuál era el problema, si la sugerencia era correcta y si la corrección llegó al código. Apunta falsos positivos y problemas que se cerraron sin resolver.

4. Pregunta al equipo si el escaneo agregó tiempo al flujo de revisión o evitó retrabajo. Toma la decisión de ampliar o ajustar el piloto con estas observaciones y la tendencia de remediación.

Cómo leer los números sin engañarte

Una tasa de remediación alta puede significar que la herramienta encontró fallas fáciles de corregir; también puede reflejar que se cerraron alertas poco relevantes. Y que un desarrollador aplique un autofix no prueba por sí solo que desapareció el riesgo: la corrección debe pasar pruebas y revisión. Estas son inferencias de evaluación, no afirmaciones de GitHub sobre el desempeño del producto.

La comparación más útil es dentro del mismo repositorio a lo largo del tiempo, acompañada de ejemplos revisados. Si la actividad de pull requests se duplicó, un aumento de hallazgos no implica un retroceso en seguridad. Si el equipo deja de atenderlos, investiga si el problema es precisión, prioridad o flujo de trabajo. Para un proyecto pequeño sin el plan requerido, esta novedad no justifica comprar una licencia a ciegas; primero define qué resultado de seguridad necesitas medir.

La utilidad real de esta vista está en decidir si AI Scan merece extenderse y dónde necesita ajustes. El tablero aporta señales; la decisión todavía exige leer código, hablar con quienes revisan y medir la corrección real.

Fuentes: GitHub Changelog, 13 de octubre de 2026. La metodología de evaluación es propuesta editorial de SoyJB.