La suspensión temporal de ciertos envíos expone un problema estructural: las herramientas automatizadas descubren vulnerabilidades más rápido de lo que los equipos humanos pueden verificarlas.
Google decidió pausar temporalmente la aceptación de ciertos envíos en su programa de bug bounty después de recibir un volumen creciente de reportes automatizados de baja calidad generados por IA. La medida no responde a un problema técnico en las herramientas de descubrimiento, sino a un cuello de botella en la capacidad humana de validación: los equipos de seguridad no pueden procesar el flujo de hallazgos que las herramientas automatizadas producen, incluso cuando una parte de esos hallazgos es técnicamente válida. La decisión de Google llega después de que en marzo la compañía endureciera las reglas de su programa de vulnerabilidades de código abierto, tras reportar un aumento pronunciado en envíos generados por IA que contenían afirmaciones incorrectas sobre cómo se activaban las vulnerabilidades o identificaban defectos de código con poco impacto práctico en seguridad.
Cómo Google intentó filtrar el ruido antes de pausar el programa
Antes de suspender los envíos, Google implementó requisitos de evidencia más estrictos para ciertas clases de vulnerabilidades: comenzó a exigir resultados reproducibles o parches aceptados como condición para validar ciertos reportes. También dejó de recompensar algunos hallazgos de menor nivel en productos. Estas medidas no fueron suficientes para contener el volumen. La pausa temporal no implica que todos los reportes automatizados carezcan de valor: Vercel recibió 1.285 reportes de vulnerabilidades durante un desafío de seguridad de dos semanas para su entorno Sandbox en septiembre, y decenas de esos envíos fueron validados después de automatizar parte del proceso de triage. Además, una falla crítica en Rejetto HTTP File Server fue descubierta con ayuda del modelo de búsqueda de vulnerabilidades Mythos de Anthropic, y posteriormente fue objetivo de intentos de explotación en producción.
El problema no es que la IA genere hallazgos falsos en todos los casos, sino que genera reportes convincentes a una velocidad que supera la capacidad de verificación. Bhupendra Chopra, Chief Revenue Officer en Kanerika, señaló que un reporte convincente puede generarse rápidamente, pero verificarlo todavía requiere que un ingeniero rastree el código y pruebe las condiciones de ataque afirmadas. Sakshi Grover, directora de investigación de información y seguridad de datos en IDC, advirtió que la IA puede ayudar a investigadores a descubrir vulnerabilidades genuinas, pero también hace que sea económico producir reportes convincentes mal fundamentados. El equipo receptor aún tiene que establecer si el código afectado existe, si la ruta de ataque afirmada es alcanzable y si hay un impacto de seguridad significativo.
Por qué el volumen de hallazgos no equivale a mejor seguridad
Un hallazgo que llega a un propietario de aplicación antes de haber sido evaluado adecuadamente puede consumir tiempo de ingeniería incluso si la versión de software afectada no está implementada o el código vulnerable no puede alcanzarse en el entorno de la organización. Chopra indicó que los equipos de seguridad deberían verificar que una falla reportada realmente afecta su entorno antes de tratarla como una prioridad urgente de remediación. Grover agregó que los CISO deberían juzgar las herramientas de seguridad asistidas por IA por los hallazgos accionables que producen y el esfuerzo requerido para validarlos, en lugar de hacerlo por el número bruto de vulnerabilidades que identifican. Un panel de hallazgos más grande no es, por sí mismo, evidencia de mejor seguridad.
Sunil Varkey, CISO, señaló que las empresas necesitarán cada vez más tratar el triage como una capacidad de seguridad por derecho propio, usando requisitos de evidencia, puntuación de alcanzabilidad y filtrado automatizado antes de que los hallazgos lleguen a revisores humanos. Incluso las vulnerabilidades confirmadas compiten por capacidad de ingeniería limitada: más reportes no crean más capacidad de ingeniería ni ventanas de mantenimiento. Una falla técnicamente válida puede no ser alcanzable en el entorno implementado, mientras que una vulnerabilidad con una puntuación de severidad más baja podría exigir acción más rápida si afecta un sistema crítico para el negocio que está expuesto. Eso hace que el contexto de implementación y la evidencia de explotación sean más útiles para la priorización que depender únicamente de una calificación de severidad generada por un escáner.
El riesgo de que los reportes automatizados se conviertan en vector de distracción
Los reportes de vulnerabilidad baratos y plausibles también podrían crear oportunidades de abuso. Chopra advirtió que, aunque la decisión de Google de detener los envíos de vulnerabilidades de productos no muestra que la compañía fue objetivo de una campaña deliberada de distracción, tal escenario es plausible. Un canal de reporte sin filtrar podría dar a los atacantes una forma de consumir capacidad de seguridad sin primero vulnerar un sistema. Los atacantes podrían, por ejemplo, enviar variaciones de la misma afirmación a través de múltiples servicios, forzando a los equipos de seguridad a gastar tiempo investigando cada envío antes de determinar que se relacionan con el mismo problema o que carecen de fundamento.
Un indicador útil de que el proceso de reporte está consumiendo capacidad que debería usarse para reducir riesgo es si los analistas están gastando más tiempo rechazando hallazgos débiles mientras las vulnerabilidades confirmadas de alto riesgo permanecen sin resolver por más tiempo. Grover indicó que los CISO deberían rastrear el esfuerzo de validación y la antigüedad de exposiciones confirmadas de alto riesgo, en lugar de enfocarse en el número de problemas que una herramienta reporta. Un hallazgo de escáner debería tratarse como una hipótesis en lugar de prueba de una vulnerabilidad explotable: los equipos aún necesitan establecer si el código afectado está presente y es alcanzable, reproducir el problema y evaluar su impacto en su entorno.
Qué significa esto para equipos de seguridad en América Latina que adoptan herramientas automatizadas
La experiencia de Google debería verse como una advertencia sobre la economía del reporte de vulnerabilidades más que como evidencia de que el mismo problema ya está generalizado en empresas, según Grover. Sin embargo, a medida que organizaciones en América Latina adoptan herramientas de seguridad de aplicaciones asistidas por IA dentro de flujos de trabajo existentes, el descubrimiento de vulnerabilidades podría superar la capacidad de validar y remediar lo que esos sistemas encuentran. Esto es particularmente relevante en sectores como banca y telecomunicaciones en México y Brasil, donde la presión regulatoria para demostrar gestión de vulnerabilidades puede llevar a equipos a priorizar el volumen de hallazgos procesados sobre la calidad de la validación.
El riesgo no es solo técnico: es operacional. Si los equipos de seguridad en la región adoptan herramientas automatizadas sin ajustar sus procesos de triage, podrían encontrarse en la misma situación que Google — con capacidad de ingeniería consumida por la validación de hallazgos de bajo valor mientras vulnerabilidades confirmadas de alto riesgo permanecen sin parchar. La pregunta para los CISO no es si las herramientas de IA pueden descubrir vulnerabilidades, sino si los procesos de gestión de vulnerabilidades existentes pueden absorber ese volumen sin permitir que hallazgos de bajo valor consuman recursos necesarios para riesgos confirmados.
Nuestro análisis
La pausa de Google en su programa de bug bounty no es un caso aislado de sobrecarga técnica — es una señal temprana de un problema estructural que afectará a cualquier organización que adopte herramientas de descubrimiento de vulnerabilidades asistidas por IA sin rediseñar sus procesos de validación. El patrón es claro: la automatización puede acelerar el descubrimiento, pero no puede acelerar la verificación humana al mismo ritmo. Lo que hace que este caso sea particularmente relevante es que Google tiene recursos de ingeniería y experiencia en seguridad que superan a la mayoría de las organizaciones. Si Google necesitó pausar envíos para recuperar capacidad de triage, equipos con menos recursos enfrentarán el mismo cuello de botella más rápido y con menos margen para absorber el impacto.
El precedente de Vercel — que procesó más de mil reportes en dos semanas automatizando parte del triage — muestra que el problema tiene solución técnica, pero requiere inversión en capacidad de filtrado antes de que los hallazgos lleguen a revisores humanos. La falla crítica en Rejetto HTTP File Server descubierta con Mythos de Anthropic demuestra que las herramientas automatizadas pueden encontrar vulnerabilidades explotables en producción, lo que significa que ignorar el flujo de reportes automatizados tampoco es una opción viable. La pregunta que queda abierta es si las organizaciones ajustarán sus procesos de triage antes de que el volumen de hallazgos no validados consuma la capacidad necesaria para remediar las vulnerabilidades que ya están confirmadas y son explotables.